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

Alejandro Perez Mendez <alex@um.es> Tue, 02 December 2014 07:39 UTC

Return-Path: <alex@um.es>
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 E7ECB1A0154 for <radext@ietfa.amsl.com>; Mon, 1 Dec 2014 23:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CVeEp_dd77Zm for <radext@ietfa.amsl.com>; Mon, 1 Dec 2014 23:39:44 -0800 (PST)
Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C51A0151 for <radext@ietf.org>; Mon, 1 Dec 2014 23:39:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id B907BADF for <radext@ietf.org>; Tue, 2 Dec 2014 08:39:40 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon24.um.es
Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5-wcHwpUM+e1 for <radext@ietf.org>; Tue, 2 Dec 2014 08:39:40 +0100 (CET)
Received: from [10.42.0.18] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 81BA94CB for <radext@ietf.org>; Tue, 2 Dec 2014 08:39:39 +0100 (CET)
Message-ID: <547D6CBB.40908@um.es>
Date: Tue, 02 Dec 2014 08:39:39 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: radext@ietf.org
References: <54779834.9030205@cisco.com>
In-Reply-To: <54779834.9030205@cisco.com>
Content-Type: multipart/alternative; boundary="------------010503060806080203090809"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/CZjV28SA3MXeaO1CVNhdFXig6ZY
Subject: Re: [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: Tue, 02 Dec 2014 07:39:48 -0000

Dear Benoit,

thanks for the review. We will prepare a new revision considering your 
comments.

Best regards,
Alejandro

El 27/11/14 a las 22:31, Benoit Claise escribió:
> 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
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext