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

[Alan DeKok <[e-mail]>]

Peter Deacon wrote:
>>  Uh... they declared that RADIUS/UDP packets were acceptable.  The DTLS
>> flag is for *new* traffic.
> 
> It makes a decision for the operator by assuming past configuration is
> still desired or applicable.

  The point of a specification is to do exactly that: mandate good
decisions where the local admin may make bad ones.

>>  It makes no sense to send RADIUS/UDP packets, and then ignore the
>> responses because DTLS is now required.
> 
> When switching to DTLS clients may no longer be capable or willing to
> touch RADIUS/UDP.  I'm not arguing against the behavior.  I just think
> the MUST requirement is too strong.

  You're very concerned about miscommunication for idle timeouts, but
you're unconcerned with miscommunication here.  I'm not sure why.

> At some point the operator would have had to update firmware or software
> taking the system offline to obtain RADIUS/DTLS functionality.  These
> kinds of things are handled normally within a planned maintenance window.

  There is no requirement to *use* DTLS when you upgrade the firmware.
Allowing for a gradual migration path is good, in my opinion.

> As draft points out in section 10.3 this automatic scheme causes
> breakage while there are multiple clients behind a single IP.

  Which is not supported by RADIUS/UDP.  This document isn't the place
to standardize that behavior.

>  When just
> one of them upgrades all other clients break causing network outage and
> potential loss of revenue.  The simple manual server knobs without
> migration behavior in this case prevents migration from *causing* an
> outage.

  If people aren't following the specs, then they're responsible for
breaking their own networks.  I don't have a lot of sympathy here.

> Having thought about this a bit more perhaps it would be better simply
> to move migration procedure from server to client.  This would fix NAT
> problems and server "flag" would only be used to declare level of
> security it is willing to accept.

  That results in down-bidding attacks from the clients, which won't
pass a security review.

> The main reason I see a need to use heartbeats is to thread the needle
> keeping UDP NAT associations from expiring, letting servers know our
> session is not forgotten and detecting session termination.  None of
> these concerns apply to RADIUS/UDP.

  If you're going to run multiple RADIUS clients behind one NAT, you're
not really doing RADIUS.

> I would be happy if DTLS heartbeats were able to reset server idle
> timeout.  Thats all I want.

  OK.

> In my view the only "application layer" thing that works for purpose of
> determining useful overall systems availability is still passive
> observation of response to client requests in the spirit of RFC 2865.

  Using Status-Server is a reasonable substitute.  Especially when (as
you say) the client may not be sending "normal" packets for long periods
of time.

  Alan DeKok.