[core] What is a session

[Jim Schaad]

I have managed to get back to this topic and given it some deep thought over
the last 24 hours and would like to get some feedback.

First, what does it mean to have something on the same session? There are
three different things that I can think of:
1. A response is required to be returned on the same session. Reconnect on
a different session and the response is dropped on the floor.
2. An observe relationship is defined as returning responses -- see item 1
3. An application could, in theory, require that a sequence of operations
must be done on a single session.

That is the total set that I can think of. Authorization as it is currently
defined is attached to keys for the secure sessions, thus if a new session
is created with the same key the same set of authorizations can be expected.

How one defines a session:
* For UDP, it would be based on the 4-tuple address. A session would last
as long as nobody interferes with the routing table. This can be
indefinitely for a static routing table or something short like 2 minutes or
so. (I had to remotely diagnose this at one point, the fire wall closes the
routing and observe values stop getting to the client. The value depends on
the specific version of windows that is being uses as well as which of the
different firewalls is being used.)
* For TCP, it is based on the TCP session.
* For TLS/DTLS, it would be based on the TLS idea of a session. Sessions
can be re-connected if that was setup when the initial handshakes was
performed. There is also coming the ability to have DTLS sessions be able
to automatically re-route without needing to re-connect the session. The
only potential problem with this concept is that one could do two TLS
session reconnections at the same time. This would either need to be
disallowed or some thought would need to be put into questions of what this
means. I would lean towards the disallow myself, but it is a harder
question for DTLS where the client may think that the session had been lost
and the server thinks it is still open just on a different address 4-tuple
because a re-routing operation. (Closing the first and rolling over to the
second would be a viable option for DTLS.)

These concepts would completely replace the current text in RFC 7252 where
it says it needs to be the same session, but text such as the same EPOCH
would be removed because, from a DTLS view it just does not make any sense.

Future:
1. Is this is correct set of concepts for sessions?
2. What re-writes in what documents need to be made?
3. What is the correct way to do those re-writes. (Are there enough
problems w/ RFC 7252 that a re-issue is needed or could this just be an
update?)

Jim

[Carsten Bormann]

Hi Jim,

Not sure that “session” is the right concept for this, but for now I’ll go with that.
(Ironically, I worked on the OSI session layer some 35 years ago :-) Some memories…)

Post by Jim Schaad
* For UDP, it would be based on the 4-tuple address.

This. And we have some special precautions in CoAP and Observe to handle the case that one end of the session has lots its memory (one case of which is that the IP address is reallocated).

Post by Jim Schaad
A session would last
as long as nobody interferes with the routing table.

The routing table is the internal working of the IP layer and simply doesn’t enter the picture here.

Post by Jim Schaad
* For TCP, it is based on the TCP session.

TCP calls that a “connection”.
(Which in turn is based on the 4-tuple and a pair of 32-bit sequence numbers at both ends, hopefully chosen with some entropy; we usually entertain the fiction that this is uniquely identifying the connection.)

Here, we have fate-sharing between the application state and and connection state.

Post by Jim Schaad
* For TLS/DTLS, it would be based on the TLS idea of a session.

Which is the part where we have to find out whether the concepts match.
(Right now, again, it is the (D)TLS *connection*.)

Post by Jim Schaad
Sessions
can be re-connected if that was setup when the initial handshakes was
performed. There is also coming the ability to have DTLS sessions be able
to automatically re-route without needing to re-connect the session.

Can you point to the mechanism/document you have in mind?

Post by Jim Schaad
The
only potential problem with this concept is that one could do two TLS
session reconnections at the same time. This would either need to be
disallowed or some thought would need to be put into questions of what this
means.

Right. So we don’t seem to have a perfect match of concepts.

Post by Jim Schaad
I would lean towards the disallow myself, but it is a harder
question for DTLS where the client may think that the session had been lost
and the server thinks it is still open just on a different address 4-tuple
because a re-routing operation. (Closing the first and rolling over to the
second would be a viable option for DTLS.)

Right.

Post by Jim Schaad
These concepts would completely replace the current text in RFC 7252 where
it says it needs to be the same session, but text such as the same EPOCH
would be removed because, from a DTLS view it just does not make any sense.
1. Is this is correct set of concepts for sessions?
2. What re-writes in what documents need to be made?
3. What is the correct way to do those re-writes. (Are there enough
problems w/ RFC 7252 that a re-issue is needed or could this just be an
update?)

I don’t think there is a reason to re-issue 7252.
This document would simply be an “updates 7252” RFC.
(And we could update the MTI ciphers at the same time, if we want.)
We could also go ahead and define extended session concepts for non-secure, as well.

Grüße, Carsten

[Jim Schaad]

Carsten,

-----Original Message-----
Sent: Thursday, December 14, 2017 10:42 PM
Subject: Re: [core] What is a session
Hi Jim,
Not sure that “session” is the right concept for this, but for now I’ll go with that.
(Ironically, I worked on the OSI session layer some 35 years ago :-) Some memories…)

There is never a good term for any of these ideas in part because they are so overloaded.

Post by Jim Schaad
* For UDP, it would be based on the 4-tuple address.

This. And we have some special precautions in CoAP and Observe to handle the
case that one end of the session has lots its memory (one case of which is that
the IP address is reallocated).

Post by Jim Schaad
A session would last
as long as nobody interferes with the routing table.

The routing table is the internal working of the IP layer and simply doesn’t
enter the picture here.

Anything that causes the addresses to be re-used plays a picture here. As a server and a client, as long as my IP address does not change which is the normal case, it can always re-use the port number allowing for the same "UDP session" to be established even if it goes down for a period of time. However, if there is any IP entity in the middle which changes any of those values for any reason then that is the effective lifetime limit.

Post by Jim Schaad
* For TCP, it is based on the TCP session.

TCP calls that a “connection”.
(Which in turn is based on the 4-tuple and a pair of 32-bit sequence numbers at
both ends, hopefully chosen with some entropy; we usually entertain the fiction
that this is uniquely identifying the connection.)
Here, we have fate-sharing between the application state and and connection state.

Right.

Post by Jim Schaad
* For TLS/DTLS, it would be based on the TLS idea of a session.

Which is the part where we have to find out whether the concepts match.
(Right now, again, it is the (D)TLS *connection*.)

Post by Jim Schaad
Sessions
can be re-connected if that was setup when the initial handshakes was
performed. There is also coming the ability to have DTLS sessions be
able to automatically re-route without needing to re-connect the session.

Can you point to the mechanism/document you have in mind?

https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-02 establishes a connection identifier that would allow the 5-tuple to change and it would still be recognized as being the same DTLS session.

Post by Jim Schaad
The
only potential problem with this concept is that one could do two TLS
session reconnections at the same time. This would either need to be
disallowed or some thought would need to be put into questions of what
this means.

Right. So we don’t seem to have a perfect match of concepts.

Post by Jim Schaad
I would lean towards the disallow myself, but it is a harder question
for DTLS where the client may think that the session had been lost and
the server thinks it is still open just on a different address 4-tuple
because a re-routing operation. (Closing the first and rolling over
to the second would be a viable option for DTLS.)

Right.

Post by Jim Schaad
These concepts would completely replace the current text in RFC 7252
where it says it needs to be the same session, but text such as the
same EPOCH would be removed because, from a DTLS view it just does not

make any sense.

Post by Jim Schaad
1. Is this is correct set of concepts for sessions?
2. What re-writes in what documents need to be made?
3. What is the correct way to do those re-writes. (Are there enough
problems w/ RFC 7252 that a re-issue is needed or could this just be an
update?)

I don’t think there is a reason to re-issue 7252.
This document would simply be an “updates 7252” RFC.
(And we could update the MTI ciphers at the same time, if we want.) We could
also go ahead and define extended session concepts for non-secure, as well.

Making it an updates would be the simplest method to do this. I was not sure if there were enough things like errata and other concepts to make it worthwhile doing a re-issue. Also I am unsure of where things are/want to be in the standards process.

Jim

Grüße, Carsten

[John Carter]

Not sure that “session” is the right concept for this, but for now I’ll go
with that.
(Ironically, I worked on the OSI session layer some 35 years ago :-) Some
memories
)

To go completely off on a tangent...... (although in some senses very
related)

...I've been trying to wade my way through "Patterns in Network
Architecture: A Return to Fundamentals" by John Day
<https://www.pearson.com/us/higher-education/program/Day-Patterns-in-Network-Architecture-A-Return-to-Fundamentals/PGM207118.html?tab=overview>

<https://www.pearson.com/us/higher-education/program/Day-Patterns-in-Network-Architecture-A-Return-to-Fundamentals/PGM207118.html?tab=overview>
Which is largely a rant against the failings of the OSI....

I get the impression John Day's memories of OSI weren't very pleasant....
does that match your memory?

Have you read John Day's book and/or have an opinion on his "RINA
<http://pouzinsociety.org/>" initiative?

Thanks!

[Christian Amsüss]

Hello Jim,

Post by Jim Schaad
First, what does it mean to have something on the same session? There are
1. A response is required to be returned on the same session. Reconnect on
a different session and the response is dropped on the floor.
2. An observe relationship is defined as returning responses -- see item 1
3. An application could, in theory, require that a sequence of operations
must be done on a single session.
That is the total set that I can think of. Authorization as it is currently
defined is attached to keys for the secure sessions, thus if a new session
is created with the same key the same set of authorizations can be expected.

I think that this can be narrowed down even further to:

* Where can a response be sent to, and where does the server accept a
response to come from?
* Where can observe notices be sent to (and are accepted from)?
* Where are follow-up blockwise fragments sent to (and are accepted
from)?

Anything higher-level (especially applications) should IMO not try to
establish anything session-ish from the involved addresses. Applications
should only access authentication information (detached from the
addresses/sessions) the but not routing information any more -- such an
access would violate the REST principle of being stateless.

Post by Jim Schaad
* For UDP, it would be based on the 4-tuple address. [..]
* For TCP, it is based on the TCP session.
* For TLS/DTLS, [...]

I'd add OSCORE, and argue that all the use of a context constitutes a
"session" (or as I prefer to call it, compatible addresses).

Post by Jim Schaad
These concepts would completely replace the current text in RFC 7252 where
it says it needs to be the same session, but text such as the same EPOCH
would be removed because, from a DTLS view it just does not make any sense.

7252 mentions sessions only in the DTLS context. For everything else, it
talks about the "same endpoint" (eg. messsage deduplication from same
message ID and source endpoint, or observation requirements of matching
endpoint/token pairs).

The definition of Endpoint in 7252 kind of already covers the DTLS
session definition by by saying that an endpoint is identified by
"transport layer multiplexing information", detailing that in 4.1. It
could be more explicit there, talk of address 4-tuples rather "IP
address and UDP port", and ask documents on other transports to define
"endpoint (address) identity" there, but IMO this concept only needs to
be explained better and not replaced with sessions.

Best regards
Christian

[Jim Schaad]

Hi Christian,

-----Original Message-----
Sent: Friday, December 15, 2017 12:32 AM
Subject: Re: [core] What is a session
Hello Jim,

Post by Jim Schaad
First, what does it mean to have something on the same session? There
1. A response is required to be returned on the same session.
Reconnect on a different session and the response is dropped on the

floor.

Post by Jim Schaad
2. An observe relationship is defined as returning responses -- see
item 1 3. An application could, in theory, require that a sequence of
operations must be done on a single session.
That is the total set that I can think of. Authorization as it is
currently defined is attached to keys for the secure sessions, thus if
a new session is created with the same key the same set of

authorizations can

be expected.
* Where can a response be sent to, and where does the server accept a
response to come from?
* Where can observe notices be sent to (and are accepted from)?
* Where are follow-up blockwise fragments sent to (and are accepted
from)?
Anything higher-level (especially applications) should IMO not try to

establish

anything session-ish from the involved addresses. Applications should only
access authentication information (detached from the
addresses/sessions) the but not routing information any more -- such an

access

would violate the REST principle of being stateless.

That makes it easier. I was trying to think of anything that might be of
interest. The biggest one for me was observations which can cause all sorts
of problems depending on who goes to sleep and how often things change. I
had not thought of the blockwise case because I tend to think of that as
something that is done "quickly".

Post by Jim Schaad
* For UDP, it would be based on the 4-tuple address. [..]
* For TCP, it is based on the TCP session.
* For TLS/DTLS, [...]

I'd add OSCORE, and argue that all the use of a context constitutes a

"session"

(or as I prefer to call it, compatible addresses).

That would make sense to me as well.

Post by Jim Schaad
These concepts would completely replace the current text in RFC 7252
where it says it needs to be the same session, but text such as the
same EPOCH would be removed because, from a DTLS view it just does not

make any sense.
7252 mentions sessions only in the DTLS context. For everything else, it

talks

about the "same endpoint" (eg. messsage deduplication from same message ID
and source endpoint, or observation requirements of matching

endpoint/token

pairs).
The definition of Endpoint in 7252 kind of already covers the DTLS session
definition by by saying that an endpoint is identified by "transport layer
multiplexing information", detailing that in 4.1. It could be more

explicit there,

talk of address 4-tuples rather "IP address and UDP port", and ask

documents

on other transports to define "endpoint (address) identity" there, but IMO

this

concept only needs to be explained better and not replaced with sessions.

Does that mean that for DTLS an endpoint would be defined as a DTLS session
identifier? Some of my thinking is influenced by the code base that I am
maintaining. It has the concept of an endpoint only for the local half of
the 4-tuple of UDP and shoves all of the "other side" parts under the
covers. This means that my way of thinking of things might be wrong. Oh to
have been in the original discussions so that my concepts matched better.

Jim

Best regards
Christian
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom