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

[Peter Deacon <[e-mail]>]

On Sat, 6 Apr 2013, Alan DeKok wrote:

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

>  I don't see how that relates to what I said.  The text doesn't
> *prevent* you from flagging IP addresses, or warning an admin about
> packets from those IPs.

Requests from unknown IPs by itself is not useful.  Normally access to the 
RADIUS request (NAS-ID) often provides relevant clue.

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

>  This is how RADIUS works today.  Clients are keyed by known IP.
> Changing that is not an option for RADIUS/UDP.

The comment above was in context of MUST requirement within text quoted. 
I'm not arguing the policy.. only MUST is too strong.  For example 
changing to SHOULD would be fine.

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

>  The draft already discusses a flag for the client.

I apologize for any misunderstanding.  The migration would be in the 
client rather than server.  They would both have flags but the automatic 
upgrade with memory to prevent downgrade would be handled at the client.

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

>  The draft allows it to me administratively configured.

This appears to be restricted by the current text of the draft.  See the 
following from section 3.1.  The server MUST maintain the flag and 
description of "false" value mandates migration using MUST keyword.

    "RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for
    each client that indicates if it requires a client to use
    RADIUS/DTLS.  The interpretation of this flag is as follows. If the
    flag is "true" then the client supports RADIUS/DTLS, and all packets
    from that client MUST be processed as RADIUS/DTLS.  If the flag is
    "false", then the client supports RADIUS/UDP, but may still support
    RADIUS/DTLS. "

    "Once a RADIUS/DTLS server has established a DTLS session with a
    client that previously had the flag set to "false", the server MUST
    set the "DTLS Required" flag to "true".  This change requires all
    subsequent traffic from that client to use DTLS, and prevents
    bidding-down attacks."

regards,
Peter