[radext] draft-ietf-radext-radiusdtls-bis-02.txt TLS vs DTLS

[Fabian Mauchle <[e-mail]>]

Upon another review of radiusdtls-bis:

There are a few paragraphs in sections 5 and 6 (addressing specific TLS 
and DTLS aspects) which I think should actually apply to both (and thus 
be moved to section 4?)

# idle timeout and session timeout and connection limit
Section 5.3 (TLS) defines that implementations SHOULD have configurable 
limits, but specifies no further details

Section 6.4.1.1 (DTLS client) defines idle timeout and session limit 
(currently omitting the details from RFC7360
Section 6.4.2 (DTLS server) defines session timeout

RFC7360 originally defined idle timeout (on the server) between 60 and 
600 seconds, also referencing the clients watchdog timeout (without any 
means of knowing it).
For clients, it defined an abstract 'three watchdog timeouts'.

My proposal would be to unify idle/session timeouts and connection limit 
for all cases (client and server), make them a SHOULD requirement make 
them configurable and recommend some reasonable values. Maybe also hint 
why too short timeouts are not useful.



# response cache
Section 5.1 (TLS) specifies that "If a TLS session or the underlying TCP 
connection is closed or broken, any cached RADIUS response packets [...] 
associated with that connection MUST be discarded. [...]"

Since DTLS also uses TLS sessions, the same logic should apply too, when 
either receiving a TLS close notify, or sending one based on timeouts or 
notification form the underlying transport that the connection is no 
longer usable.



# session resumption
Sections 6.4.1.1 and 6.4.2 (DTLS) define client and server SHOULD 
implement session resumption.

TLS has currently no requirement regarding resumption in the draft

I-D.ietf-radext-tls-psk (which is mandatory for servers) also has it as 
a SHOULD requirement.

So again this should be unified and maybe also include some of the 
provisions of I-D.ietf-radext-tls-psk about storing and re-verifying the 
clients identity.



I will try to come up with some proposals (Github PR) in the coming days 
(before the WG meeting).


-- 
Fabian Mauchle
Network
NOC:    [phone]
Direct: [phone]

Switch
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland