Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04

[Peter Deacon <[e-mail]>]

On Fri, 5 Apr 2013, Alan DeKok wrote:

> 3. Transition Path

> Transitioning to DTLS is a process which needs to be done carefully.
> A poorly handled transition is complex for administrators, and
> potentially subject to security downgrade attacks.  It is not
> sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS.  That
> approach would result in timeouts, lost traffic, and network
> instabilities.

> The end result of this specification is that nearly all RADIUS/UDP
> implementations should transition to using RADIUS/DTLS.  In some
> cases, RADIUS/UDP may remain where IPSec is used as a transport, or
> where implementation and/or business reasons preclude a change.
> However, long-term use of RADIUS/UDP is NOT RECOMMENDED.

> This section describes how clients and servers should transition to
> DTLS.  There is a fair amount of discussion around this transition, as
> it is critical to get it correct.  We expect that once implementations
> have transitioned to RADIUS/DTLS, the text in this section will no
> longer be relevant.

> 3.1 Server Transition to DTLS

> As this specification permits server implementations to accept both
> RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a
> method to disambiguate packets between the two protocols.  This method
> is applicable only to RADIUS/DTLS servers.
> The disambiguation method leverages the RADIUS/UDP requirement that

> clients be known by source IP address.  RADIUS/DTLS servers MUST treat
> packets from unknown IP addresses as being DTLS.  This requirement

> does not mean that the server is required to accept these packets.  It
> means that if the server chooses to accept them, they are to be
> treated as being DTLS.

I don't think this will work for us.  This is data that people use to 
flag/report possible new clients they should have known about, existing 
clients with changed addresses and plain old configuration errors.

It can be a configuration option, done conditionally within the context 
protocol disambiguation or even a recommendation but not something 
unconditionally required.

> For packets from known IP addresses RADIUS/DTLS servers MUST maintain
> a boolean "DTLS Required" flag for each client that indicates if it
> requires a client to use RADIUS/DTLS.  If the flag is "true" then all
> packets from that client MUST be processed as RADIUS/DTLS.

> The transition to RADIUS/DTLS is performed only when the "DTLS
> Required" flag is "false".  This setting means that the client is
> known to support RADIUS/UDP, but may also support RADIUS/DTLS.
> Packets from the client need to be examined to see if they are
> RADIUS/UDP or RADIUS/DTLS.  The protocol disambiguation method
> outlined below in Section 5.1.2 MUST be used to determine how received
> packets are treated.

Suggest reversing this.  Have the client maintain the flag.  If DTLS 
handshake has succeeded then client uses DTLS from then on for any 
inquiries without the option of automatically falling back to UDP.

Servers would still maintain flag but it would only be a manually turned 
knob to indicate security level it is willing to accept.

This causes less breakage for the case of multiple clients behind a single 
IP where they can not all be upgraded at once to DTLS.  Whether client or 
server does the enforcement seems moot as the same outcome is realized 
either way.

The more I think about it the more I agree with Joe's points on separate 
UDP ports.

regards,
Peter