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

[Sam Hartman <[e-mail]>]

>>>>> "Alan" == Alan DeKok <[e-mail]> writes:


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

Alternative:

MOST clients can transition to RADIUS/DTLS by disabling UDP and enabling
RADIUS/DTLS.
Any UDP requests active during the transition will not receive a
response.

Servers need a way to indicate that a particular client is permitted to
send both UDP and DTLS requests during a transition so that timing of
transitions is not closely coordinated on the server and client.

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

I'm uncomfortable with the above statement.  I'm not sure that
RADIUS/DTLS is better than RADIUS/TLS. It seems a lot more complex, it
doesn't provide a solution to fragmentation, and I'm not convinced by
the arguments RFC 2865 makes against TCP.
So, I'm not sure I'd support a claim about where the world should go
other than to say away from RADIUS/UDP.