Re: [radext] Last call comments on draft-ietf-radext-fragmentation-02
Alejandro Perez Mendez <alex@um.es> Mon, 10 February 2014 08:45 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 EDA801A05CD for <radext@ietfa.amsl.com>; Mon, 10 Feb 2014 00:45:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.249
X-Spam-Level:
X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 iSOS7gWZd3mQ for <radext@ietfa.amsl.com>; Mon, 10 Feb 2014 00:45:35 -0800 (PST)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id BB1931A06A7 for <radext@ietf.org>; Mon, 10 Feb 2014 00:45:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 580423F86D for <radext@ietf.org>; Mon, 10 Feb 2014 09:45:33 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon21.um.es
Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6mIvIClw8vK5 for <radext@ietf.org>; Mon, 10 Feb 2014 09:45:33 +0100 (CET)
Received: from [155.54.205.49] (inf-205-49.inf.um.es [155.54.205.49]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 3C1643F86C for <radext@ietf.org>; Mon, 10 Feb 2014 09:45:32 +0100 (CET)
Message-ID: <52F891AC.2000800@um.es>
Date: Mon, 10 Feb 2014 09:45:32 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: radext@ietf.org
References: <07a101cf239d$7132dc70$53989550$@augustcellars.com> <52F49D24.7000702@um.es> <006701cf242a$30e2f3c0$92a8db40$@augustcellars.com>
In-Reply-To: <006701cf242a$30e2f3c0$92a8db40$@augustcellars.com>
Content-Type: multipart/alternative; boundary="------------080809000304010409090907"
Subject: Re: [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: Mon, 10 Feb 2014 08:45:41 -0000
El 07/02/14 18:29, Jim Schaad escribió: > > *From:*Alejandro Perez Mendez [mailto:alex@um.es] > *Sent:* Friday, February 07, 2014 12:45 AM > *To:* Jim Schaad; draft-ietf-radext-radius-fragmentation@tools.ietf.org > *Cc:* radext@ietf.org > *Subject:* Re: Last call comments on draft-ietf-radext-fragmentation-02 > > Hi Jim, > > thanks for the valuable comments. See my responses inline: > > El 07/02/14 01:42, Jim Schaad escribió: > > 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 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 > > > Take into account that Service-Type = Additional-Authorization is a > new value defined in this document. > > [JLS] Then I have a confusion about why this needs to be done. It says > that there is no need to fragment CoA packets, so why is there a need > to do this? This may be due the fact that I don’t really understand > what CoA is doing – so I am willing to say this is reader > misunderstanding and you can ignore it. > > > > > 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. > > > Note that it says globally and temporally unique. That "temporally" > addition would allow others to use the same value after/before a > reasonable amount of time. > Anyway, I think it would be sufficient to be temporally unique to the > server, as it is the one using it to recognise the conversation. The > NAS just copies the value into the next Access-Request packet, without > further processing. > > To avoid confusion, I think it could be rephrased as: > > We only note that it MUST be temporally unique to the server. > > [JLS] Yes – I think this is probably a sufficient degree of uniqueness. > > > > > > > 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.) > > > Proxies can do anything they want, even completely change the whole > packet removing the existing attributes and inserting new ones. From > this assumption, the NAS and the AS can only wish proxies will behave > according to some conventions. Anyway, this discovery mechanism is a > best effort. That's why step #2 specifies to artificially increase the > amount of free space. > > [JLS] – I can easily live with no change for this. > > > > > > 11. Did I miss where you defined the T bit - or did you? > > > Page 7, first paragraph says: > > We address this issue > by defining a new field in the Reserved field of the "Long Extended > Type" attribute format. This field is one bit in size, and is called > "T" for Truncation. > > That is, the T flag belongs to a different specification: RFC 6929. > Perhaps we should add a reference. s/attribute format/attribute format > [RFC6929]/ > > [JLS] The following text is in your document > > We address this issue > > by defining a new field in the Reserved field of the "Long Extended > > Type" attribute format. This field is one bit in size, and is called > > "T" for Truncation. > > > This says you need to have a section to define it and mark your > document as updating RFC 6929. > > Seems reasonable. I'll do it. > > 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. > > > Personally, I don't see your case b) as a plausible case (I may be > wrong). Note that the NAS does not distinguish "after authentication" > until it receives the Access-Accept packet, and that would be c) already. > > If your concern is more related to the naming itself, maybe these > phases/steps should be renamed to "pre-authentication" and > "post-authentication". I have thought on changing them sometimes in > the past. > > [JLS] This is something that Plasma is looking at for a standard > model. We are going to be using ABFAB and doing the following steps: > > 1. Do a pre-authentication by sending a policy to the server as part > of the initial Access-Request step > > 2.Do a post-authentication by sending a SAML request to the server to > get various attributes that we need in order to do the policy > evaluation to grant access to a resource. > > By doing this as two operations rather than one, we can restrict the > amount of items that we ask for, i.e. by not asking for things that > are not applicable to the person that is authorized. This increases > the privacy and reduces the chances that the server would see us as > trying to just get tons of attributes. > > We are looking at doing this by sending another Access-Request with a > state from the previous Access-Request in order to tie together the > two sessions. Since this dialog would not need to do an authentication > (tied from the previous dialog) it still is a post-authentication > dialog, but is NAS initiated again. > > > From my view, in that case you'd be doing a pre-authorization phase (policies), then authentication (EAP), then a post-authorization where the AS is not sending any authorization information (EAP-Succes), but it will include a State attribute to allow the NAS to start a new pre-authorization exchange afterwards (SAML request), ending with another post-authorization (SAML response). > > > 13. Should the Access-Request (ID=181) > > 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. > > > I guess you mean page 14. It is stated that "The AS includes an State > attribute to allow the client to send additional authorization data." > > We added this text because we wanted the AS to provide the NAS with > the means to continue with the authorization exchange (e.g. further > requests). Now that you brought up, I think that it should probably > be out of the fragmentation protocol. Perhaps it should be a > recommendation for ASs to include a State attribute on all their > Access-Accept, as a way to allow NASs to continue with the conversation. > > [JLS] No I meant the last pargraph on page 15. I was looking at the text > > The AS includes an State > > attribute to allow the client to send additional authorization data. > > This is where the final chunk is being constructed. > > However – yes I would like a recommendation that a state attribute be > included in all Access-Accept messages where “post-authorization” in > terms of what I laid out above is going to be possible. > I agree. > > > > > 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. > > > I'm not sure that would be worthy. That would require to execute an > optimization algorithm just to gain some bytes. > > [JLS] – No problems – I would have stated it in terms of – you can do > this but it is not worth the effort. > > > > 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. > > > I guess we could provide a one-line explanation of each value for > "code" field. > > [JLS] No that is not what I was asking for. I was looking for a > restatement of the following text from section 4.2 > > Client supporting this specification MUST include a Frag-Status = > > Fragmentation-Supported attribute in the first Access-Request sent to > > the server, in order to indicate they would accept fragmented data > > from the sever. This is not required if pre-authorization process > > was carried out, as it is implicit. > > Seems reasonable. Regards, Alejandro > > > Thanks and best regards, > Alejandro > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext
- [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