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

[Peter Deacon <[e-mail]>]

On Fri, 5 Apr 2013, Jim Schaad wrote:

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

Hi Jim,

Apologize if I gave a different impression than intended.  Did not intend 
to exclude or imply no notification only notification is unreliable.

Advocating mitigating with small changes to default settings or idle 
algorithm as in suggested text.

regards,
Peter

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