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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Peter Deacon
> Sent: Friday, April 05, 2013 12:24 AM
> To: Alan DeKok
> Cc: [e-mail]; [e-mail]
> Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04
> 
> On Wed, 3 Apr 2013, Alan DeKok wrote:
> 
> >> 2.2.2 "We re-iterate that much of [RFC6614] applies to this document.
> >>    Specifically, Section 4 and Section 6 of that document are
applicable
> >>    in their entirety to RADIUS/DTLS."
> 
> >> RFC 6614 section 6 dedicates a few sentences to TCP specific
> >> properties which do not apply to RADIUS/DTLS.
> 
> >  Do you have suggested text for the draft?
> 
> Recommend removing "in their entirety"
> 
> >> 4. "Adding these
> >>    parameters means that the client MUST start using DTLS to the server
> >>    for all new requests.  The client MUST, however, accept RADIUS/UDP
> >>    responses to any outstanding requests."
> 
> >> MUST does not seem appropriate.  We have no business in what client
> >> elect to do with outstanding requests after a security configuration
> >> change.
> 
> >  Yes, we do.  We're writing the standards here, which means we must
> > address security, migration, implementation cost, etc.
> 
> What security, migration or implementation concern does this "MUST"
> address?
> 
> 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.
> 
> 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.
> 
> >  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.  What safety or
productivity
> implications does the MUST requirement provide?  If it did not exist how
> would safety or productivity be negatively impacted?
> 
> >> 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.
> 
> >> I think it might be helpful to note RFC5080 in the context of
> >> continuing to support this mechanism and to continue to do it at the
> >> RADIUS packet layer rather than DTLS or you're likely to end up on
> >> the wrong side of the DTLS sequence window.
> 
> >  I'm not sure what that means.
> 
> Normally with RFC 5080 replay system an implementation will store a
> response for a given request and simply resend a stored response (UDP
> message) on wire.
> 
> With DTLS implementations RADIUS packets must be resent thru new DTLS
> messages rather than storing a previous DTLS response and resending.
> 
> The reason for this is DTLS replay protection uses a sequence window where
> only a fixed number of previously unaccepted packets are accepted.  Retry
> timers on orders of seconds on a busy client are likely lead to
retransmitted
> messages being too stale to be accepted on DTLS stack unless
retransmissions
> are performed by retransmitting stored RADIUS response thru DTLS.
> 
> 
> Suggest a short text:
> 
> Any duplicate detection strategy such as [RFC5080] section 2.2.2 where
> previously transmitted RADIUS packets are replayed MUST be replayed thru
> DTLS creating a new DTLS packet before transmission.  Previously
transmitted
> DTLS packets MUST NOT be retransmitted.
> 
> >> 5.1 "Last Packet
> >>      A variable containing a timestamp which indicates when the last
> >>      valid packet was received for this connection.  Packets which are
> >>      "silently discarded" MUST NOT update this variable."
> 
> >> As long as the packet was valid while being silently discarded it
> >> should count for the purpose of last packet.
> 
> >  Why?  What benefit does that offer?
> 
> My concern is in minimizing situations where client accounting of idle
timeout
> becomes unsynchronized with server view of same.
> 
> >> 5.1.1 - I still think we can do better on the UDP / DTLS
> >> disambiguation using the 4 byte header I described earlier or by
> >> explicitly requiring a server knob to declare what protocol would be
> >> accepted from a given source address.
> 
> >  The draft already defines a "DTLS Required" flag.  Servers use it to
> > decide which protocol is accepted from a given client.
> 
> My suggestion the mechanism to automatically migrate clients to DTLS after
> successful DTLS handshake is not necessary.
> 
> 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.
> 
> >>   "A server may also use watchdog packets from the client to
> >>    determine that the connection is still active."
> >>
> >>    "The
> >>    timestamp SHOULD be updated on reception of a valid RADIUS/DTLS
> >>    packet.  The timestamp MUST NOT be updated in other situations."
> >>
> >> The RADIUS packet layer does not see heartbeats. Should this cause a
> >> change in Last Packet?
> 
> >  No.  That is for RADIUS packets, not DTLS heartbeats.
> 
> >>  Do you intent for sessions to idle out and expire even with active
> >> DTLS layer keepalives?
> 
> >  Yes.  If there's no RADIUS traffic for a long time, there are few
> > reasons to keep the session up.
> 
> 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 session "idle timeout" SHOULD be exposed to the administrator
as
> >>    a configurable setting.  It SHOULD NOT be set to less than 60
> >>    seconds, and SHOULD NOT be set to more than 600 seconds (10
> minutes).
> >>    The minimum value useful value for this timer is determined by the
> >>    application-layer watchdog mechanism defined in the following
> >>    section."
> 
> >> The recommended maximum idle timeout is too low in my view.
> >> Resetting connections should be as rare as possible as clients now
> >> have the added burden of correctly guessing whether packets were
> >> dropped on wire or dropped on DTLS stack in addition to possibility
server
> may not be alive.
> 
> >  Did you read the text about RADIUS watchdog packets and DTLS
> > heartbeats?  No "guessing" is required.
> 
> Heartbeats do not effect last packet and watchdog is for detection of
server
> failure rather than communication of compatible 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.

But you are also going assume that the teardown message on the DTLS link is
also going to be lost.  In the more common case the close_notify alert is
going to get sent from the server to the client (or the other way) and both
sides are going to know that the session has been shut down.   

Jim

> 
> None of the active probing mechanisms work at these timescales and they
> should not be necessary to prevent this sort of problem from occurring.
> 
> TCP TLS provides reliable notification of shutdown DTLS does not.
> 
> I recommend that recommended client idle parameters be specified and not
> overlap with recommended server idle parameters.
> 
> For example something like clients may close the connection at 60-600
> seconds.  Servers may close the connection after >600 seconds.
> 
> 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.
> 
> 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.
> 
> >> There are no timing guidelines provided for transition to "idle" state.
> 
> >  Do you have suggested text for the draft?
> 
> What does the idle state actually do?  What is the difference vs using
"idle
> timeout" since last packet without an "idle" transition?
> 
> >> Mismatch of idle expectations between client and server could trigger
> >> unnecessary delay which could be mitigated by separating client and
> >> server expectations so there is no overlap in the recommended settings.
> >> Clients severely outnumber servers.
> 
> >  Do you have suggested text for the draft?
> 
> 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.
> 
> 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".
> 
> 
> 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.
> 
> regards,
> Peter
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext