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

[Alan DeKok <[e-mail]>]

Benoit Claise wrote:
> - 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?

  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.

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

  Yes.  I'll make that clear.

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

  I'll take a look.

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

  Done.

> 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

  Done.

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

  I'll update the text.

>       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 :-)

  Fixed.

> - please extend CSPRNG

  Done.

> - 
>    When DTLS is used, the fixed IP address model can be relaxed.  As
>    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
>    determined from TLS parameters.
> 
> identies?

  Fixed.

  Alan DeKok.