[radext] Review of draft-ietf-radext-bigger-packets-02.txt

Alejandro Perez Mendez <alex@um.es> Thu, 26 February 2015 13:59 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 B2EB81A00F3 for <radext@ietfa.amsl.com>; Thu, 26 Feb 2015 05:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 PGP34VRWwjan for <radext@ietfa.amsl.com>; Thu, 26 Feb 2015 05:59:03 -0800 (PST)
Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 612991A0122 for <radext@ietf.org>; Thu, 26 Feb 2015 05:59:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 49A403FAD for <radext@ietf.org>; Thu, 26 Feb 2015 14:59:01 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon22.um.es
Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h70NFsiDzk0K for <radext@ietf.org>; Thu, 26 Feb 2015 14:59:01 +0100 (CET)
Received: from [10.42.0.179] (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 xenon22.um.es (Postfix) with ESMTPSA id 13E743E90 for <radext@ietf.org>; Thu, 26 Feb 2015 14:59:00 +0100 (CET)
Message-ID: <54EF26A3.6040502@um.es>
Date: Thu, 26 Feb 2015 14:58:59 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
Content-Type: multipart/alternative; boundary="------------030407000802000303060902"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/Esmo9bpxeeemyY9Cmj-nTirPXgU>
Subject: [radext] Review of draft-ietf-radext-bigger-packets-02.txt
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, 26 Feb 2015 13:59:10 -0000

Hi Sam,

here is my review of the new version of draft. Most of them are just typos.
Overall, I think the document is ready for the WGLC, although as I 
mention below, I would appreciate more information about the handling of 
the Protocol-Error messages and the  in the Proxies.

1. Abstract. RADIUS over TCP experiment needs a reference (RFC6613) as 
for the RADIUS over TLS experiment mentioned in the first sentence.

2. Abstract and Introduction. I'm not convinced that the reason of 
having new use cases where more than 4096 bytes are required in RADIUS 
is motivated only by RFC6614. Other security mechanisms such as IPsec or 
a trusted network would be enough to motivate use cases such as those 
described in ABFAB and/or in the aaa-saml draft. In our RADIUS 
fragmentation draft we mention ABFAB as the motivation.

3. Section 1. s/the RADIUS layer.RADIUS Fragmentation/the RADIUS layer. 
RADIUS Fragmentation/

4. Section 1. Reference to draft-ietf-radext-radius-fragmentation seems 
quite old (-04, April 2014). Nevertheless, it should be an RFC sooner 
than later, so it can be updated then.

5. Section 1. s/arrises/arises/

6. Section 2. While the text indicates that RADIUS Servers and CLients 
MUST be able to receive a packet of maximum length, proxies only SHOULD 
be able to do that. What's the reason of such a difference? Besides, I 
think the text should say "Proxies implementing this specification MUST 
be....".

7. Section 2. It has been difficult to me to understand the following 
paragraph:

Proxies MUST include the Response-Length attribute when
    forwarding a request received over a transport with a 4096-octet
    maximum length over a transport with a higher maximum length.


I would suggest to reword it, with something like this: (note that I 
also indicated that the value of the attribute should be 4096. Remove it 
if that's not correct)

When a proxy receives a request over a transport with a 4096-octet
    maximum length, and this request is to be forwarded over a transport with
    a higher maximum length, the proxy MUST include a Response-Length
    attribute with a value of 4096 in such a request.


8. Section 2.1. s/Status-Request messages/Status-Server messages

9. Section 2.1. s/by including the attribute/By including the attribute

10. Section 3. s/When an RFc/When an RFC/

11. Section 3. This section says that Respone-Length attribute MAY be 
included in a request to indicate that larger responses are desirable. 
Shouldn't it say "acceptable" instead of "desirable"?

12. Section 4. The section is titled "Protocol Error Type". Shouldn't it 
be "Protocol-Error code" instead?

13. Section 4. It is not clear to me what's the purpose of the 
Original-Packet-Code attribute. It is mentioned in the text, and 
described which values it should take. However, it is not explained how 
this value is used.

14. Section 4. s/TBD/TBDCODE/ (according to section 6)

15. Section 4. It is not clear to me how the messages with this code are 
handled by Proxies. Are they supposed to forward them back to the 
Client? Should they handle them individually?

16. Section 6. s/the maximum size RADIUS request that is/the maximum 
size of a RADIUS request that is/

17. Section 7. s/these attacks/These attacks/

18. Section 7. Does the sentence "This specification updates RFC 6613 
and will be used with [RFC6614]" implies that TLS is mandatory for this 
specification? (see my comment for abstract and introduction)

Regards,
Alejandro