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

[Alan DeKok <[e-mail]>]

Sam Hartman wrote:
> We're talking about a period of less than a few seconds, right, while
> requests are in flight?
> So, this issue only comes up in operational environments where a single
> NAS or proxy cannot afford  an outage of the maximum lifetime of a
> RADIUS request.

  How about this text below.  It clarifies that the transition path is
meant to be temporary.  The text around transition is there only to
ensure we get it right.



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.

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.