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

From: Benoit Claise <[email-masked]>
Date: Tue, 15 Apr 2014 16:32:08 +0200

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Apr 2014 12:46:55 -0400

> Does the MUST also apply to the DTLS Data and Last Traffic as well?

  The MUST means that the 4 tuple MUST contain the DTLS session
information.  The Last Traffic need be there only if it's used.  The
implementation-specific DTLS data information is there only if it's
needed by the implementation.

  I'll update the text to make this clearer.

> stress_ for all DTLS sessions_?

  Yes.  I'll make that clear.

> https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/

  I'll take a look.

> Please make sure to spell out the exact IANA registry.

  Done.

>    associated with RADIUS/UDP

  Done.

>    Each 4-tuple points to a unique session entry, which contains the

  I'll update the text.

> "protocol" looks lonely there :-)

  Fixed.

> - please extend CSPRNG

  Done.

>    discussed earlier in Section 2.2.1 <http://tools.ietf.org/html/draft-ietf-radext-dtls-09#section-2.2.1>, client identies should be

  Fixed.

  Alan DeKok.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Apr 2014 18:52:15 +0200

Hi Alan,

Thanks for the quick reply.
Please provide a new version and I'll progress the draft.

Regards, Benoit
> .