Subject: [core] What is a session

From: Jim Schaad <[email-masked]>
Date: Thu, 14 Dec 2017 18:35:11 -0800

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Dec 2017 07:41:44 +0100

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…)

> * 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).

> 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.

> * 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.

> * 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*.)

> Sessions
> to automatically re-route without needing to re-connect the session.  

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

> The
> means.  

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

> I would lean towards the disallow myself, but it is a harder

Right.

> problems w/ RFC 7252 that a re-issue is needed or could this just be an

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

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 15 Dec 2017 09:32:27 +0100

Hello Jim,

> 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.

> * For UDP, it would be based on the 4-tuple address.  [..]
> * 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).

> 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

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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 15 Dec 2017 09:32:02 -0800

Carsten,

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Thursday, December 14, 2017 10:42 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [core] What is a session
> 
> Hi Jim,
> 

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

> 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).
> 
> > A session would last

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. 

> (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.)
> 

Right.

> > performed.  There is also coming the ability to have DTLS sessions be
> > able to automatically re-route without needing to re-connect the session.
> 

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.

> > 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.)
> 
> Right.
> 
> > 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:
> (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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 15 Dec 2017 09:38:02 -0800

Hi Christian,

> From: Christian Amsüss [mailto:[email-masked]]
> Sent: Friday, December 15, 2017 12:32 AM
> > 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.
establish
> anything session-ish from the involved addresses. Applications should only
> access authentication information (detached from the
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".

> 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.

> 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

---

From: John Carter <[email-masked]>
Date: Mon, 18 Dec 2017 09:52:27 +1300

> (Ironically, I worked on the OSI session layer some 35 years ago :-)  Some

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!

-- 

------------------------------
This Communication is Confidential. We only send and receive email on the
basis of the terms set out at www.taitradio.com/email_disclaimer
------------------------------