Subject: Re: [radext] #64: 4.1 source port inclusion in the tracking table

From: "radext issue tracker" <[email-masked]>
Date: Wed, 07 Nov 2012 19:36:20 -0000

#64: 4.1 source port inclusion in the tracking table

Changes (by aland@…):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  RDTLS => dtls

Comment:

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

 Then it's not using the existing DTLS session.  Client-server
 communication in UDP involves the client sending traffic from one source
 port to a well-known port on the server.  The server responds to that
 client port.  If the client starts sending traffic from another port, then
 it is another session.

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

 Yes.  That's how it works.

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

 I welcome suggestions for text to make it clearer.  It's already as clear
 as I know how.

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

 Nothing.  It's permitted, but not recommended.

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

 Then how will you identify a DTLS session?  There is nothing in the DTLS
 header which identifies a particular session.  You can only identify the
 session by looking at the 5-tuple from IP/UDP.

-- 
--------------------------------+-------------------------
 Reporter:  peterd@…            |       Owner:  aland@…
     Type:  defect              |      Status:  closed
 Priority:  minor               |   Milestone:  milestone1
Component:  dtls                |     Version:  1.0
 Severity:  Active WG Document  |  Resolution:  wontfix
 Keywords:                      |
--------------------------------+-------------------------

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

---

From: "radext issue tracker" <[email-masked]>
Date: Wed, 07 Nov 2012 23:07:47 -0000

Comment (by peterd@…):

 A solution is to assume a limited number of sessions from the same source
 IP address and send same UDP packet to each active DTLS session.  Sessions
 for which the packet do not belong would simply be ignored by the DTLS
 stack.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 00:25:49 -0000

Comment (by aland@…):

 > A solution is to assume a limited number of sessions from the same
 source IP address and send same UDP packet to each active DTLS session.

 That is just not scalable.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 03:33:27 -0000

Comment (by peterd@…):

 There are related unresolved problems such as what to do when multiple
 connections are attempted from the same source port from possibly recycled
 source port happening to still have an existing valid session.

 I realize with a many:1 NAT you could construct a scenario with lots of
 clients opening sessions from the same apparent address ... this scenario
 was always problematic with RADIUS due to keying of secret with source
 address.

 I think the solution of broadcasting UDP packet to each DTLS session per
 source address significantly simplifies implementations who also no longer
 need to worry about establishing and maintaining multiple DTLS sessions
 with the same server.

 With regards to scalability DTLS sequence window could be leveraged to
 effectively preselect candidate sessions minimizing any impact of large
 numbers of sessions from single source address.

 My first choice for resolution requires changes to wire format.  A small 4
 byte header before the DTLS header is added to each UDP packet.  One byte
 to set a RADIUS command code reserved specifically for RADIUS/DTLS.
 Remaining three bytes used for DTLS session identification replacing
 source port in tuple.

 {{{

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |          Session ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | DTLS ...
 }}}

 Clients establishing new DTLS sessions send Session-ID 0.

 When DTLS session is allocated server responds with Session-ID.  In all
 subsequent requests Session-ID is sent by clients.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 14:31:34 -0000

As the document says, RADIUS is fundamentally incompatible with NAT.  The
 problems therefore cannot be resolved.

 > My first choice for resolution requires changes to wire format.

 Which has its own set of issues.

 And what do you do when you get multiple requests from the same source
 port with Session-ID 0?

 Putting bandaids on an unsolvable problem is just wasting everyones time.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 17:33:26 -0000

Comment (by peterd@…):

 There are no issues establishing a session due to use of stateless cookies
 within initial DTLS handshake.  When server allocates state it also sets
 session id allowing multiple connection requests from the same source port
 to complete from its view without ambiguity.

 This change is intended to address long term problems dealing with
 recycling of source ports by NATs or local operating system..however any
 client wishing to attempt to establish multiple DTLS sessions concurrently
 using the same source port can successfully do so.

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