Subject: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?

From: "radext issue tracker" <[email-masked]>
Date: Mon, 21 Feb 2011 08:24:16 -0000

#65: Multiple dtls sessions in a tuple?

 Section 4.1 does not provide guidance regarding what to do when there is a
 new session established against a tuple having an existing session.

 Can it maintain multiple sessions and broadcast any subsequent datagrams
 or does it automatically trigger discard of the previous session(s)?

-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:            
     Type:  enhancement              |      Status:  new       
 Priority:  trivial                  |   Milestone:  milestone1
Component:  RDTLS                    |     Version:  1.0       
 Severity:  Active WG Document       |    Keywords:            
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/65>
radext <http://tools.ietf.org/radext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Feb 2011 10:33:49 +0100

>  or does it automatically trigger discard of the previous session(s)?

  Session initiation packets have no security or authentication, and can
this be spoofed.  I think that the new packet should be discarded.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 21 Feb 2011 01:59:32 -0800 (Pacific Standard Time)

> this be spoofed.  I think that the new packet should be discarded.

Imagine my table has an entry:

SP  SA          DP   DA          DTLS
333 10.20.30.40 1812 10.0.0.1    Old-Session-Lives-Here

Now from the same source port and address comes a brand new yet 
valid request to start yet another session.

But there is already a valid session in the table...  Are you saying the 
behavior should be to not accept the establishment of the new session?

I would think the new session would have the same security and spoof 
protections as the initial (Old-Session-Lives-Here) session since it is 
doing the same thing it did before?

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Feb 2011 11:07:38 +0100

Peter Deacon wrote:
> Now from the same source port and address comes a brand new yet valid
> request to start yet another session.

  ... which can be trivially spoofed by anyone.

> behavior should be to not accept the establishment of the new session?

  I'm saying that it should prefer to keep an existing session, which
has recently sent signed packets.

> doing the same thing it did before?

  Once the new session is established, yes.  Until it is established,
no.  The first packet of a new DTLS session has *no* security.

  Allowing new session requests to destroy "live" sessions results in a
trivial DoS attack.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 21 Feb 2011 02:14:28 -0800 (Pacific Standard Time)

>  ... which can be trivially spoofed by anyone.

Isn't this what client hello /w cookies and the secure handshakes are for? 
Surely these can't be spoofed so easily?!

> has recently sent signed packets.

What if the session does not exist anymore and the client tries to 
reestablish or it is behind a NAT and there is unlucky synchronization of 
source ports?

> no.  The first packet of a new DTLS session has *no* security.

To be clear... the new session would be established only after the full 
DTLS handshake.  Not just on first packet...

>  Allowing new session requests to destroy "live" sessions results in a

You can have both by broadcasting the datagram to both sessions which is 
why I'm asking what the expected behavior in this instance should be.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Feb 2011 11:32:00 +0100

Peter Deacon wrote:
> Isn't this what client hello /w cookies and the secure handshakes are
> for? Surely these can't be spoofed so easily?!

  This is assuming you get that far.  My assumption is that maintaining
multiple DTLS sessions for the same {src ip/port dst ip/port}
combination is a bad idea.  I do not know the security implications of
doing it, and I don't think I'm enough of a TLS expert to say.

> reestablish or it is behind a NAT and there is unlucky synchronization
> of source ports?

  The client can retry.  The server can discard unused sessions.

  It's imperfect.

> why I'm asking what the expected behavior in this instance should be.

  I am *very* wary of doing that.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 21 Feb 2011 03:00:17 -0800 (Pacific Standard Time)

> doing it, and I don't think I'm enough of a TLS expert to say.

There are no implications.  DTLS does not know or care about the 
underlying transport.  It does not know what "UDP" is.  If the transport 
can't handle app data it does not know about then there are much bigger 
problems because its trivial for anyone to spoof such packets.

Given a choice I prefer whatever gets characterized as impractical, ugly, 
unacceptable hacks if they translate into operational reduction in 
unreliable behavior and happy customers.

I agree with you it is better not to go there if not absolutely necessary 
and in this case it may not be but old ports are now potholes... and this 
scares me.

These things should be in the RDTLS draft. It would stink if someone used 
a "connected" socket and (IMHO naturally) tried to reconnect the TLS 
channel using the same socket(src port).. and when doing this some servers 
sometimes did not accept the new connection for some period of time 
because of this behavior.

regards,
Peter

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 21 Feb 2011 22:12:21 -0000

Changes (by bernard_aboba@…):

  * owner:  => aland@…

 Reporter:  peterd@…                 |       Owner:  aland@…                  

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/65#comment:1>
radext <http://tools.ietf.org/radext/>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Feb 2011 14:58:36 +0100

> problems because its trivial for anyone to spoof such packets.

  That makes sense.

> I agree with you it is better not to go there if not absolutely
> necessary and in this case it may not be but old ports are now
> potholes... and this scares me.

  Yes.

> These things should be in the RDTLS draft. It would stink if someone
> used a "connected" socket and (IMHO naturally) tried to reconnect the
> TLS channel using the same socket(src port).. and when doing this some
> servers sometimes did not accept the new connection for some period of
> time because of this behavior.

  That is an issue, unfortunately.  The solution is largely to have
graceful shutdowns, and don't re-use ports.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Tue, 22 Feb 2011 12:29:05 -0800 (Pacific Standard Time)

> graceful shutdowns, and don't re-use ports.

Some thoughts:

It seems possible one would have the freedom to implement a _server_ with 
broadcasting to fill the potholes or even remove source port from the 
tuple while still maintaining 100% interoperability with clients and 
servers following this draft as currently written.  I agree it is not a 
particularly good idea but at least it is workable.

Here is an alternate proposal to resolve issues and make transport more 
reliable and easier for developers to implement client and server codes.

List of issues:

1. Stealing type codes is bad form even if we all think noone is using them

2. Multiple DTLS sessions to the same server is an unnecessary waste of 
resources and may lead to unnecessary confusion regarding connection state 
should one but not all sessions under management be disconnected without 
the peers knowledge.

3. Client must implement strategies to maintain multiple connections if 
they need to effectively deal with the problem of insufficient ID space.

4. Expecting NATs to maintain long term stateful UDP mappings in sync with 
underlying DTLS session is not something I would want to bet on.  Mapping 
request and response is all RADIUS currently has to do.. It is much 
different than expecting the whole train of all subsequent requests to 
continue to use the same source port...

5. Potholes.

6. Depending on DTLS packet formatting and content type parameters to not 
change in the future for compatibility with the detection method is not 
ideal.

What I propose is allocating two type codes used for all RDTLS requests.

RDTLS-Request
RDTLS-Response

They will be used in a simple 4-byte prefix before the DTLS data by RADIUS 
clients and servers.

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |               RDTLS-Session-ID                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  DTLS ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-

Clients send code RDTLS-Request
Servers send code RDTLS-Response

Clients seeking new connections set RDTLS-Session-ID to 0.

Servers respond setting an internal value corresponding with the session 
table during the DTLS handshake.

Clients subsequently resend RDTLS-Session-ID for all future requests 
against the session.

Clients wishing new session send RDTLS-Session-ID = 0.

The tracking table in 4.1 is changed to replace source port with the 
RDTLS session id.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 Feb 2011 10:02:32 +0100

Peter Deacon wrote:
> It seems possible one would have the freedom to implement a _server_
> with broadcasting to fill the potholes or even remove source port from
> the tuple while still maintaining 100% interoperability with clients and

  Yes.

> 1. Stealing type codes is bad form even if we all think noone is using them

  Yes.  It's less bad because the type code being stolen is a *response*
code.  So it shouldn't be sent to servers.

> resources and may lead to unnecessary confusion regarding connection
> state should one but not all sessions under management be disconnected
> without the peers knowledge.

  Quite possibly, yes.  However, the limited ID space is an issue.

> they need to effectively deal with the problem of insufficient ID space.

  Yes.  This is the same as today.

> 4. Expecting NATs to maintain long term stateful UDP mappings in sync
> with underlying DTLS session is not something I would want to bet on. 
> Mapping request and response is all RADIUS currently has to do.. It is
> much different than expecting the whole train of all subsequent requests
> to continue to use the same source port...

  If the client is continually sending traffic, it's OK.  The document
suggests a watchdog timer, which means at least one packet every few
tens of seconds.  That *may* be enough to keep the NAT state active.

> 5. Potholes.
> 
> 6. Depending on DTLS packet formatting and content type parameters to
> not change in the future for compatibility with the detection method is
> not ideal.

  Pretty much, yes.

> They will be used in a simple 4-byte prefix before the DTLS data by
> RADIUS clients and servers.

  If we're doing that, we might as well solve the ID limitation at the
same time.  Add a 64-bit unique "packet identifier", so that one DTLS
session can transport more than 256 RADIUS packets at the same time.

  This worries me a little, though.  It involves the creation of a new
protocol, which is neither RADIUS nor DTLS.  I'm not sure it solves
enough problems to warrant the extra complexity.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 23 Feb 2011 10:10:45 -0800 (Pacific Standard Time)

> session can transport more than 256 RADIUS packets at the same time.

This is not needed since source port is also replaced with 
RDTLS-Session-ID in the DTLS tracking table.

When source port is removed the effective ID space per DTLS session is the 
same as RADIUS... ~2^16 (source ports) * 2^8 (Ids)

> enough problems to warrant the extra complexity.

To simplify somewhat the proposal is just stealing first 4 bytes for 
session selection and sending the rest to the DTLS stack.

I don't know how it would be classified politically.  In terms of Interop 
whether RADIUS sees DTLS or 4 bytes + DTLS the reaction from RADIUS 
implementations not supporting DTLS I would expect to materially be the 
same.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Feb 2011 13:39:55 +0100

> RDTLS-Session-ID in the DTLS tracking table.

  Ah, OK.

> When source port is removed the effective ID space per DTLS session is
> the same as RADIUS... ~2^16 (source ports) * 2^8 (Ids)

  OK.

> I don't know how it would be classified politically.  In terms of
> Interop whether RADIUS sees DTLS or 4 bytes + DTLS the reaction from
> RADIUS implementations not supporting DTLS I would expect to materially
> be the same.

  Yes.

  Alan DeKok.