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

Benoit Claise <bclaise@cisco.com> Tue, 15 April 2014 14:32 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 730F61A0667 for <radext@ietfa.amsl.com>; Tue, 15 Apr 2014 07:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.372
X-Spam-Status: No, score=-8.372 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yrCjwv7D31cG for <radext@ietfa.amsl.com>; Tue, 15 Apr 2014 07:32:13 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 01E451A0430 for <radext@ietf.org>; Tue, 15 Apr 2014 07:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7296; q=dns/txt; s=iport; t=1397572330; x=1398781930; h=message-id:date:from:mime-version:to:subject; bh=RuxZRly/HQ2IJX91/tmx8Y1EDFzd+Uc8a6Bn6C06+eY=; b=Cp00SvuHbj77o4PXVkwjuK6smyEbu6X8A/Brd5+T7jTeoDP7cuhfMOBo JdjbSurRtWV3zB7O1wgFEOwAIirzlAoHWQC9w9fTksobBi6/V/7EhFMbd qEqO6OqpFr93M2n6kBHqcicxXkck2jHqmddQfmIHJhhOFNsXR4TFVvUOl s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtkEAHFCTVOtJssW/2dsb2JhbABYg0G7DIosdIMkPRYYAwIBAgFLDQgBAYd4DZoDsg8XkyIEmGKBNoUei3GDMzs
X-IronPort-AV: E=Sophos; i="4.97,864,1389744000"; d="scan'208,217"; a="18428464"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([]) by aer-iport-1.cisco.com with ESMTP; 15 Apr 2014 14:32:09 +0000
Received: from [] (ams-bclaise-8915.cisco.com []) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3FEW8Dc028722 for <radext@ietf.org>; Tue, 15 Apr 2014 14:32:08 GMT
Message-ID: <534D42E8.8020501@cisco.com>
Date: Tue, 15 Apr 2014 16:32:08 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
Content-Type: multipart/alternative; boundary="------------010108040308060104090103"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/f9PhCg7YSYgiyTDhsQwkslyC0Rk
Subject: [radext] AD review http://tools.ietf.org/html/draft-ietf-radext-dtls-09
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 14:32:15 -0000

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

    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

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

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

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

- OLD:

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

    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:

      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.


      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.


Regards, Benoit