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

[Peter Deacon <[e-mail]>]

On Fri, 5 Apr 2013, Alan DeKok wrote:

>> If an operator is deciding they want to improve the security of their
>> system they would be *required* to accept responses with lower security
>> after they have declared otherwise.

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

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

>  The point of the transition path is to *allow* a transition path. 
> Otherwise an administrator needs to modify both ends simultaneously. 
> He also needs to deal with dropped traffic due to the human 
> "simultaneous" having a different timescale from the computer 
> "simultaneous".

>  i.e. there may be seconds to minutes where the two systems are out of 
> sync, and *all* RADIUS traffic is dropped.

>  For someone who is worried about idle timeout synchronization, it's 
> surprising that you're OK with having no protocol synchronization.  One 
> works in the real world and causes no real-world problems.  The other
> causes network outages and potentially loss of revenue.

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.

As draft points out in section 10.3 this automatic scheme causes breakage 
while there are multiple clients behind a single IP.  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.

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.

>> We see lots of NASes with only a few if any concurrent users.  It is not
>> uncommon for new RADIUS traffic to be seen on orders of tens of minutes
>> to hours.  Having a connection open hurts nobody and prevents delay
>> including possibly additional delay to failover for users coming
>> online.  It also prevents state sync problems..(see my comments below)

>  This is related to the RFC2865 issue of "keep alive considered
> harmful".  If there's no traffic to the RADIUS server for hours, having
> DTLS heartbeats have little benefit.

>  I think the arguments against this are best summarized by the 20
> year-old argument against keep-alives.

RFC 2865 makes this argument in context of probing server availability.

DTLS heartbeat communicates DTLS session availability.

Now that there are sessions to be managed and connect first constraints on 
source port usage have to be careful with context of RFC 2865 keepalive 
philosophy.

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.

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

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.

regards,
Peter