Subject: [radext] RDTLS #64 (new): 4.1 source port inclusion in the tracking table

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

#64: 4.1 source port inclusion in the tracking table

 ''4.1. "An RADIUS/DTLS server MUST maintain a table that tracks ongoing
 DTLS sessions based on a key composed of the following 4-tuple:''

       * source IP address
       * source port
       * destination IP address
       * destination port"

 ''3.
 "Clients can no longer have multiple independent RADIUS implementations or
 processes that originate packets.  We RECOMMEND that RADIUS/DTLS clients
 implement a local RADIUS proxy that arbitrates all RADIUS traffic."''

 I am confused with how this tracking is supposed to work.

 Throughout the document it is recommended clients use connected socket
 options... Now what happens when a client tries to send a new Access-
 Request message using a different source port over a DTLS session that was
 already established?

 Judging by keys of the table such a request would be discarded since there
 is no known session in the table matching key.

 If this is the intention it should be made clear clients can't switch
 their source ports unless they also open a new DTLS session.  Client
 implementors (most of us:) tend to gloss over server specific areas and
 may not realize the implication.

 If true and this is really the intention what stops clients from
 originating packets from different processes per sec 3 above?

 My recommendation is to remove the source port from the tracking table key
 and just allow DTLS session to be client specific so any source port can
 be used as we do traditionally to get around the ID limit mess.

 This approach will cut down on the number of DTLS sessions in a busy
 environment and simplify implementations. If you want to support NATs and
 the like you still can by broadcasting the packet to all matching DTLS
 sessions.

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

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/64>
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:32:52 +0100

>  Request message using a different source port over a DTLS session that was

  Then the packet is discarded.  The DTLS sessions are keyed by (src
ip/port, dst ip/port).  It is by definition impossible to send packets
for one DTLS session from two different source ports.

>  may not realize the implication.

  Hmm... OK.

>  originating packets from different processes per sec 3 above?

  Nothing.

>  be used as we do traditionally to get around the ID limit mess.

  IMHO, that is a very bad idea, and quite likely impossible to
implement in practice.  If you have two DTLS sessions from a client, and
packets from more than two different source ports, you'll need to
somehow inspect the traffic to determine which packet belongs to which
session.

>  the like you still can by broadcasting the packet to all matching DTLS

  Ouch.  With 100 sessions, that means every packet results in 99 failures.

  I don't think that's a good idea at all.

  Alan DeKok.

---

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

> somehow inspect the traffic to determine which packet belongs to which

It is quite easy to implement but I agree with your sentiment.

>  I don't think that's a good idea at all.

1:100 NAT does not work in RADIUS nor does it work in DTLS so why should I 
care about this ridiculous example?

If someone is gonzo enough to run a 100 sessions thru a 1:100 NAT then 
they deserve to waste each and every CPU cycle that entails.

Actually if you track the jitter window of the incoming datagram against 
the sequence number for each session you can substantially pair down the 
number of attempts.

regards,
Peter

---

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

Peter Deacon wrote:
> 1:100 NAT does not work in RADIUS nor does it work in DTLS so why should
> I care about this ridiculous example?

  I'm not sure what you mean by that.

  RADIUS works quite nicely through a NAT, so long as all of the clients
behind the NAT use the same shared secret.

  DTLS can work through a NAT, where each client has a unique
certificate.  The only requirement is that the mapping of client IP/port
to NAT source port doesn't change for the lifetime of the session.

  I believe that this is how NATs work today.

  Alan DeKok.

---

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

Changes (by bernard_aboba@…):

  * owner:  => aland@…

 Reporter:  peterd@…                 |       Owner:  aland@…                  

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