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

[Alan DeKok <[e-mail]>]

Peter Deacon wrote:
> Recommend removing "in their entirety"

  OK.

> What security, migration or implementation concern does this "MUST"
> address?

  It allows a transition.  If you're fine with having a "flag day" with
no RADIUS traffic, you don't need a transition path.

> I can think of a couple drawbacks..
> 
> 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 no sense to send RADIUS/UDP packets, and then ignore the
responses because DTLS is now required.

> Increased client implementation complexity as a short term security
> exception has to be made for receiving non DTLS packets including
> protocol disambiguation procedure for clients not specified in draft.

  Nonsense.  There is no need for protocol disambiguation on the client.

  Clients already keep track of requests/responses.  The protocol used
by the request is the protocol used by the response.

  The draft never says that clients should accept RADIUS/DTLS responses
to RADIUS/UDP requests.  That would be a horrible idea.

>>  In this case, there are no known issues with a client accepting
>> responses to packets it previously sent.  The goal here is to ensure a
>> safe and productive transition between RADIUS/UDP and RADIUS/DTLS.
> 
> I am looking for specific technical justifications.

  Allowing people to transition to DTLS isn't a technical justification?

>  What safety or
> productivity implications does the MUST requirement provide?  If it did
> not exist how would safety or productivity be negatively impacted?

  Network stability.  The client would have to either time-out all
RADIUS/UDP traffic, or pro-actively re-transmit it all as DTLS.  That
leads to either network instability due to no responses, or network
spikes due to duplicate requests.

>>> 5. "We note that [RFC5080] Section 2.2.2 already mandates a duplicate
>>>    detection cache.  The connection tracking described below can be seen
>>>    as an extension of that cache, where entries contain DTLS sessions
>>>    instead of RADIUS/UDP packets."
> 
>>> I think bringing this up is likely to cause more confusion than
>>> necessary. Tuples and authenticator usage are different, session
>>> lifecycle is different and state logic is different (You would not
>>> ignore anything while a response is pending)
> 
>>  Do you have suggested text for the draft?
> 
> I would suggest as properties of the state tracking are discussed in
> detail in section 5 removing RFC 5080 paragraph.

  We're into competing requirements here.  The text was added to address
concerns of how DTLS session tracking interacted with existing tracking.

> With DTLS implementations RADIUS packets must be resent thru new DTLS
> messages rather than storing a previous DTLS response and resending.

  Yes, that's true.

> Suggest a short text:

  OK.

> My concern is in minimizing situations where client accounting of idle
> timeout becomes unsynchronized with server view of same.

  There is no mechanism for exchanging idle timeout values.  The server
could be set at 30 seconds, and the client at 10.  So they will always
be unsynchronised.

> My suggestion the mechanism to automatically migrate clients to DTLS
> after successful DTLS handshake is not necessary.

  It also involves changing the protocol, and changing multiple
interoperable implementations.

> We already need manual knobs to make this work.  Perhaps simply
> requiring a knob in client and server is the best approach. This would
> remove RADIUS/UDP to RADIUS/DTLS migration and RADIUS/DTLS
> disambiguation. Explicit configuration in client AND server would be
> necessary to successfully speak RADIUS/DTLS.

  The draft already describes explicit configuration to make RADIUS/DTLS.

  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.

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

> Heartbeats do not effect last packet and watchdog is for detection of
> server failure

  I would guess that both DTLS and watchdog packets are handled by the
same process.  In which case... the same process is responsible for both
heartbeat and watchdog.  It's unclear to me how it would respond to one
and not to the other.

> rather than communication of compatible session timeout
> parameters.

  Well, the draft doesn't propose communication of session timeout
parameters.

> The following example explains my concern:
> 
> RADIUS/DTLS server - 60 second idle timeout.
> RADIUS/DTLS client - 90 second idle timeout.
> 
> (5.2 "RADIUS/DTLS clients SHOULD pro-actively close sessions when they
> have been idle for a period of time")
> 
> For the sake of this example RADIUS client is connected to a NAS that
> sees only a few concurrent sessions and only sparse activity every few
> minutes...From our experience typical AP in a low traffic environment.
> 
> At 75 seconds the client sends a RADIUS request to RADIUS/DTLS server.
> Server promptly ignores this request because the session was torn down
> due to exceeding idle timeout.  The client runs thru all of its retries
> and timeouts IGNORED by the server before it either picks a different
> RADIUS server or tries to open a new RADIUS/DTLS session to the same
> server.

  That is an issue.  It's mitigated by the suggestion to use an
application-layer watchdog.  While keep-alives are harmful, the client
can use the watchdog to ensure that the server is up.

  If the client doesn't use a watchdog, then it can't rely on DTLS
hearbeats.  Or so you say above.

> Other thoughts to minimize this problem have client enforce an idle
> timeout algorithm based on usage but allow server idle timer to be
> refreshed by DTLS heartbeats.

  Which is what the draft suggests.

> The server can take other actions if there is pressure on resources to
> manage DTLS sessions but normally it is important to do EVERYTHING
> possible to make sure RADIUS/DTLS is as reliable as RADIUS/UDP with no
> delays for clients to figure out and react to rug being pulled out from
> under them.

  Of course.  But if the client isn't sending traffic... there's no
reason for the server to keep the session alive.  I think the only
disagreement here is whether the "idle timeout" values are large or small.

> What does the idle state actually do?  What is the difference vs using
> "idle timeout" since last packet without an "idle" transition?

  That is what I meant by "idle".

> 5.2...
> 
> RADIUS/DTLS clients MAY proactively close sessions when they have been
> idle for 60-86400 seconds if DTLS heartbeats or active watchdog probes
> are used.  When unused RADIUS/DTLS client SHOULD close sessions idle for
> 60 to no longer than 600 seconds.

  Which still has the problem you noted.  Clients have an idle timeout
of 600s, and servers of 60s.  Changing the suggested timers works around
the problem without solving it.

  Suggesting that the client use the watchdog algorithm solves the problem.

> 5.1.1...
> 
> This session "idle timeout" SHOULD be exposed to the administrator as a
> configurable setting. RADIUS servers SHOULD timeout after at least 600
> seconds.
> 
>    As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
>    MUST also maintain a "Last Packet" timestamp per DTLS session.  The
>    timestamp MUST be updated on reception of a valid RADIUS/DTLS
>    packet or DTLS heartbeat.  The timestamp MUST NOT be updated in other
>    situations. The server SHOULD delete idle DTLS sessions after
>    an "idle timeout".

  Hmm... OK.  I'll work on some text.

> 10.2
> 
> While total number of sessions tracked exceeds the configured limit
> servers SHOULD close idle sessions starting with highest idle time until
> a sufficient number of sessions have been closed or lower idle timeout
> threshold of 60 seconds or more has been reached.

  That's not clear to me.  I'll work on some text.

  Alan DeKok.