[AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT)
Dan Romascanu <dromasca@avaya.com> Thu, 11 August 2011 12:59 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56E121F86AE; Thu, 11 Aug 2011 05:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2Jk8AeT-SSu; Thu, 11 Aug 2011 05:59:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DE121F8596; Thu, 11 Aug 2011 05:59:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Dan Romascanu <dromasca@avaya.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 3.57
Message-ID: <20110811125940.9802.75899.idtracker@ietfa.amsl.com>
Date: Thu, 11 Aug 2011 05:59:40 -0700
Cc: aaa-doctors@ietf.org, draft-ietf-softwire-dslite-radius-ext@tools.ietf.org, softwire-chairs@tools.ietf.org
Subject: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT)
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2011 12:59:40 -0000
Dan Romascanu has entered the following ballot position for draft-ietf-softwire-dslite-radius-ext-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated DISCUSS - taking out one issue that was resolved in draft-05. The DISCUSS and COMMENT is in part based on the reviews and discussions on the AAA-Doctors list. 1. Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring. As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests: Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access- Accept needs to contain a State attribute, which can then be used in a later Access-Request that performs authorization checks. The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents. So either this is a protocol violation, or the exchange described is under-specified. 2. RFC 5176 requires that session identification attributes not be used to request authorization changes. I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as session-identification attributes which cannot be changed by CoA-Request packets. The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request. (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets to request authorization changes). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. The use of keywords in section 3 seems inconsistent. Why are the 'may' and 'shall' in the second paragraph of the section non-capitalized, while in the rest of the section the keywords are capitalized. > This list may also contain the AFTR Tunnel Name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel Option, the NAS shall use the name returned in the RADIUS DS- Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message. 2. I support item #2 in David's DISCUSS about the need to document the operational considerations of the NAS configuration and device configuration changes. 3. Two of the AAA-Doctors made in early reviews the comment that it was not clear why the authors needed a new AVP when the RADIUS tunnel attributes (RFC2868) could probably be reused here. One of them even proposed an alternative based on RFC2868 but authors argued that their approach was better… that may be true, but it would have been good to document the decision and explain why the alternative was rejected.
- [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ie… Dan Romascanu
- [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ie… Dan Romascanu
- Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draf… Maglione Roberta
- Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draf… Romascanu, Dan (Dan)
- [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ie… Dan Romascanu
- Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draf… Maglione Roberta