[radext] Last call comments on draft-ietf-radext-fragmentation-02
"Jim Schaad" <ietf@augustcellars.com> Fri, 07 February 2014 00:43 UTC
Return-Path: <ietf@augustcellars.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 6D61F1A0579 for <radext@ietfa.amsl.com>; Thu, 6 Feb 2014 16:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 jPMg3ZlAxd14 for <radext@ietfa.amsl.com>; Thu, 6 Feb 2014 16:43:53 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 803ED1A057B for <radext@ietf.org>; Thu, 6 Feb 2014 16:43:53 -0800 (PST)
Received: from Philemon (50-39-223-207.bvtn.or.frontiernet.net [50.39.223.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id EC22738F03; Thu, 6 Feb 2014 16:43:51 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-radext-radius-fragmentation@tools.ietf.org
Date: Thu, 06 Feb 2014 16:42:12 -0800
Message-ID: <07a101cf239d$7132dc70$53989550$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8jjx+78axBUoK6RGqWK20NGnZ5Yw==
Content-Language: en-us
Cc: radext@ietf.org
Subject: [radext] Last call comments on draft-ietf-radext-fragmentation-02
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: Fri, 07 Feb 2014 00:43:56 -0000
In general, yes I believe this document is in good shape and ready to go forward. There are a couple of small things that need to 1. !!! Pet Peeve !!! - I would request that the authors please review the use of 2119 language. There are places where, IMHO, it is used incorrectly. Examples are: (section 1) Nevertheless, if a proxy supports this specification, it MAY re-assemble the data in order to either examine and/or modify it. --- This is not protocol statement it is a statement of why one might wish to do something. If the proxy does not implement the spec, it does not have this capability. (section 2) Instead, the CoA client MUST send a CoA-Request packet containing session identification attributes, along with Service-Type = Additional-Authorization, and a State attribute. ---- I don't think this is part of the fragmentation protocol (section 3) An authorization exchange before authentication allows a RADIUS client to provide the RADIUS server with information that MAY modify how the authentication process will be performed (e.g. it MAY affect the selection of the EAP method). --- This decision process is independent of the fragmentation protocol and thus is not appropriate 2119 language. 2. !!! Pet Peeve !!! - I have run into people who believe that the capitalization of may, should, must do not matter when defining 2119 language. Personally I think they are idiots for this view, but they strongly believe it. For this reason I have started including the sentence "When these words appear in lower case, they have their natural language meaning." As part of the 2119 boiler plate. You might want to consider doing so. 3. On page 9 (after figure 2) - It is not clear to me what you mean by Non-compliant servers. Are these servers that do not implement this specification or are they servers that do not correctly implement the RADIUS specification. (Simple way to make it clear would be to add a parenthetical after the first occurrence of the term "non-compliant (i.e., servers not implementing fragmentation)" 4. Same paragraph - suggest s/a particular Service-Type/a Service-Type other than Additional-Authorization/ (I am not sure that is a correct statement in terms of the actual value returned, but particular does not give me something to code to) 5. Next paragraph - does it really need to be globally unique? Is it sufficient to be unique to either the server or the server/NAS pair? The problem with the phrase "globally and temporally unique" is that says to me that it can never be re-used ever in the history of the world by anybody and I don't think that is what is implied here. 6. Section 4.2 - Para #1 - The requirements on the Service-Type attribute, while understandable, appear to violate a previous statement that the order of the attributes not be changed (Section 3 para 3 The encoding process is a simple linear walk over the attributes to be encoded. This walk preserves the order of the attributes, as required by [RFC2865].) This should probably be explicitly called out as being ok. (This may be done by a proxy rather than the server.) - Maybe point to the discussion in section 7.2 as well, although there it says that the attributes can be re-ordered. After a second pass through the document (with jumps to other documents), I still find this somewhat confusing language here. Something that might make things a bit clearer In section 3 para 3 - s/order of the attributes/order of attributes of the same type/ 7. Section 7.1 - I may have a slight misunderstanding here (and it may not be worth changing the document for this in any case). However, I believe that a proxy can remove all previous proxy-state information and just insert its own into a packet. Thus it is possible that the server does not know how many bytes to allow for proxy state as not all of the attributes will be sent to the server. (I just found that this is discussed in step #2 of this section, which makes me less inclined to include in the general discussion but still unsure.) 8. Section 7.4 - Service-Type = Additional-Authorization should be included in the server list. 9. section 10 - !! Pet Peeve !! - A MAC is not a signature and should not be called one. 10. References (Which of the documents do I need to understand to implement - as oppose to understand background reasoning) RFC 2866 should be informational RFC 3579 should be informational RFC 5080 should be informational (Yes I could list others here such as how to write IANA considerations which the author needs to know but not the reader). 11. Did I miss where you defined the T bit - or did you? 12. This may just be me, but I have a problem with the terms "pre-authorization" and "post-authorization". My issue with the terms is that there are three cases where I see things happening: a) Before doing the authentication (NAS->server) b) Post doing the authentication (NAS->Server) c) "post" doing the authentication (Server->NAS as part of the access-accept process). However the document currently says that c is post-authorization but b is not covered in section 12. 13. Should the Access-Request (ID=181) be Frag-Status = More-Data-Pending ? 14. In the last paragraph on page 15, you are putting in a state attribute where one did not exist in the original request. It is not clear to me why this is happening just because this is the fragmentation protocol. It would seem to me that this is something that should be done in general for all access-accept messages, whether or not it is going to be fragmented. 15. Section 5 - I don't know if there is a reason to discuss packing based on the re-ordering of attributes which have disparate types in order to pack the chunk tighter. 16. Section 8.1 - It might be worthwhile to repeat that implementations SHOULD send this attribute in the an Access-Request with the value of Fragmentation-Supported if fragmentation is not going to happen. Spelling errors s/wand/and/ s/eight (7)/seven (7)/ s/how many space/how much space/ s/MUST not/MUST NOT/ s/before start forwarding/before starting to forward/ s/could be a reasonable limits/could be a reasonable limit/ or /could be reasonable limits/
- [radext] Last call comments on draft-ietf-radext-… Jim Schaad
- Re: [radext] Last call comments on draft-ietf-rad… Alejandro Perez Mendez
- Re: [radext] Last call comments on draft-ietf-rad… Jim Schaad
- Re: [radext] Last call comments on draft-ietf-rad… Alejandro Perez Mendez