[radext] AD review: draft-ietf-radext-radius-fragmentation

Benoit Claise <bclaise@cisco.com> Thu, 27 November 2014 21:31 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A21A00D8 for <radext@ietfa.amsl.com>; Thu, 27 Nov 2014 13:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK4qa149nDnU for <radext@ietfa.amsl.com>; Thu, 27 Nov 2014 13:31:36 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E2F1A0049 for <radext@ietf.org>; Thu, 27 Nov 2014 13:31:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11227; q=dns/txt; s=iport; t=1417123895; x=1418333495; h=message-id:date:from:mime-version:to:subject; bh=p7aUaySLkzVSP+dEle7HeET9LtDxB8mqUUBYhbYUd/M=; b=JeajdOiOXT7X12fd0shi56j9Gyk6U7K2qcl4NPX+eYnF/FIsVmlWFcCX UpBvP6kfzUshKzbh7MNKVSehfG5GcsCM/EtFl23kF6fAWjsya5F2ZDRJh DFs3Z9eZHo2BCAOhf9uyA8j8EyoctJ1O7TSB/V07MYOvR57dLqynt32n1 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: At8EAC+Xd1StJssW/2dsb2JhbABbg1fGM4Fuh2sBAQEBAX2FAT0WGAMCAQIBSwEMCAEBiDwN0hgBAQEBBgEBAQEBARyQJIUrBYcCkEqHNYE1P4Magn6HSoM8hAqDfT4wAQEBgQMBBQEZA4EhAQEB
X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208,217";a="252557933"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 27 Nov 2014 21:31:33 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sARLVWOR001287; Thu, 27 Nov 2014 21:31:32 GMT
Message-ID: <54779834.9030205@cisco.com>
Date: Thu, 27 Nov 2014 22:31:32 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>, draft-ietf-radext-radius-fragmentation@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------010400020109050708040403"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/SMRRkNKolWxaSR0l628yqoEzXwI
Subject: [radext] AD review: draft-ietf-radext-radius-fragmentation
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: Thu, 27 Nov 2014 21:31:39 -0000

Dear all,

Here is the AD review.
Note that I initiated a discussion with the IESG on the topic of an 
experimental doc updating a Standard Track doc. More on this pretty soon 
(hopefully).

1.
Since this is an experimental future RFC, the experiment should be 
better explained. And if/when the experiment is successful, what's the 
next step.
As an example, 
http://tools.ietf.org/html/draft-ietf-radext-dtls-13#section-1.3 was 
appreciated by the IESG.
Coming back to this draft, if the experiment is success, the Standard 
Track version will update RFC 2865?

2.
Open question: Does this draft update RFC 6158?

    The Length field in the RADIUS packet header is defined in[RFC2865]
    Section 3  <http://tools.ietf.org/html/rfc2865#section-3>.  It is noted there that the maximum length of a RADIUS
    packet is 4096 octets.  As a result, attribute designers SHOULD NOT
    assume that a RADIUS implementation can successfully process RADIUS
    packets larger than 4096 octets.

Or maybe this is taken care of by:

    No such
    exchange is possible for accounting or authorization data.[RFC6158]
    Section 3.1  <http://tools.ietf.org/html/rfc6158#section-3.1>  suggests that exchanging large amounts authorization data
    is unnecessary in RADIUS.

Or, maybe, if this experiment is successful, then the Standard Track 
version will update RFC 6158?


_Editorial:_
-
Your first sentence in the introduction speaks about "Authentication 
Server (AS)", but some other parts of the document speak about "server"
Example:

    In some cases, however, the
    authorization data sent by the server is large and highly dynamic.
    In other cases, the NAS needs to send large amounts of authorization
    data to the server.

Btw, RFC 6158 speaks of RADIUS Server, which I believe is the right term.
Please be consistent regarding terminology: server, AS, RADIUS server
Same remark for client, RADIUS client.

-
OLD
  [RFC6158] recommends three approaches for the transmission of large
    amount of data within RADIUS.  However, they are not applicable to
    the problem statement of this document for the following reasons:

NEW:
  [RFC6158] section 3.1 recommends three approaches for the transmission of large
    amount of data within RADIUS.  However, they are not applicable to
    the problem statement of this document for the following reasons:

-
OLD
    o  The first approach does not talk about large ...

    o  The second approach is not usable either, ...

    o  PMTU discovery does not solve the problem, as it does not allow to
       send data larger than the minimum of (PMTU or 4096) octets.

NEW:
    o  The first approach (Utilization of a sequence of packets) does not talk about large ...

    o  The second approach (Utilization of names rather than values) is not usable either, ...

    o  PMTU discovery does not solve the problem, as it does not allow to
       send data larger than the minimum of (PMTU or 4096) octets.

-
Similarly, there is no need to fragment CoA packets.

A reference, or at least expanding the acronym would help

-
This limit is the minimum of 4096 octets, and the current PMTU.
I guess you want to say
This limit is the minimum of 4096 octets and the current PMTU.

-
It is strongly RECOMMENDED that servers include a State attribute

So strongly RECOMMENDED is between RECOMMENDED and MUST? :-)
Let's not invent new RFC 2119 semantics.
NEW: It is RECOMMENDED that servers include a State attribute

- Section 4.2
OLD: Compliant clients receiving this packet will see the Frag-Status
    attribute, wand suspend all authorization and authentication handling
    until all of the chunks have been received.

NEW: Compliant clients receiving this packet will see the Frag-Status
    attribute,_and_suspend all authorization and authentication handling
    until all of the chunks have been received.

Regarding this sentence, we are in the "post-authorization section".
So shouldn't be:

NEW: Compliant clients receiving this packet will see the Frag-Status
    attribute,_and_suspend all authorization handling
    until all of the chunks have been received.

- Section 11.2

  The authors acknowledge that this specification violates the "MUST"
    requirement of[RFC2865] Section 4.1  <http://tools.ietf.org/html/rfc2865#section-4.1>.

Be specific on which MUST requirements in [RFC2865] Section 4.1 
<http://tools.ietf.org/html/rfc2865#section-4.1>. you refer to

While you revise the document, you might want to take care of 
http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-radext-radius-fragmentation-08.txt

Regards, Benoit