[radext] AD review http://tools.ietf.org/html/draft-ietf-radext-dtls-09

[Benoit Claise <[e-mail]>]

Dear all,

- In section 5.1:

    A RADIUS/DTLS server MUST track ongoing DTLS client session based the
    following 4-tuple:

Does the MUST also apply to the DTLS Data and Last Traffic as well?
I guess so for the Last Traffic because I see later on "RADIUS/DTLS 
servers which do not implement an application-layer watchdog MUST also 
maintain a "Last Traffic" timestamp per DTLS session.", but it's not 
clear for the DTLS Data. Maybe it is "RADIUS/DTLS servers SHOULD also 
monitor the total number of open sessions.", but then it's a SHOULD, 
while the other is a MUST.
I would make it clear in section 5.1, one way or the others 
(MUST/SHOULD, or forward references)

- Any reason why this sentence is repeated. Maybe the third one wants to 
stress_for all DTLS sessions_?

    Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
    DTLS Heartbeats [RFC6520  <http://tools.ietf.org/html/rfc6520>] to determine connectivity between the two
    servers.

    Once a DTLS session is established, a RADIUS/DTLS client SHOULD use
    DTLS Heartbeats [RFC6520  <http://tools.ietf.org/html/rfc6520>] to determine connectivity between the two
    systems.

    For these reasons, it is RECOMMENDED that RADIUS/DTLS clients
    implement DTLS heartbeats and/or watchdog packets for all DTLS
    sessions.

- Section 7 "Implementation experience" should follow RFC 6982 
"Implementation Status" format.
Example: 
https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ or 
https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/

- IANA considerations.
Please make sure to spell out the exact IANA registry.




Editorial:
- OLD:

    This specification does not, however, solve all of the problems
    associated with RADIUS.

NEW:
    This specification does not, however, solve all of the problems
    associated with RADIUS/UDP

- Some misalignement in section 5.1:
    Each 4-tuple points to a unique session entry, which contains the
    following information:

DTLS Data
      An implementation-specific variable containing information about
      the active DTLS session.

Last Taffic
      A variable containing a timestamp which indicates when this session
      last received valid traffic.

      Each entry may contain other information, such as idle timeouts,
      session lifetimes, and other implementation-specific data.

-


      10.1
      <http://tools.ietf.org/html/draft-ietf-radext-dtls-09#section-10.1>.
      Legacy RADIUS Security

    protocol.  We suggest that RADIUS clients and servers implement
    either this specification, or [RFC6614  <http://tools.ietf.org/html/rfc6614>].

"protocol" looks lonely there :-)

- please extend CSPRNG

-
    When DTLS is used, the fixed IP address model can be relaxed.  As
    discussed earlier inSection 2.2.1  <http://tools.ietf.org/html/draft-ietf-radext-dtls-09#section-2.2.1>, client identies should be
    determined from TLS parameters.

identies?

Regards, Benoit