Re: [Softwires] [Technical Errata Reported] RFC6519 (3372)
Leaf yeh <leaf.y.yeh@huawei.com> Tue, 09 October 2012 02:38 UTC
Return-Path: <leaf.y.yeh@huawei.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E4B21F8487; Mon, 8 Oct 2012 19:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.469
X-Spam-Level:
X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBIKVFZPHRSa; Mon, 8 Oct 2012 19:38:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3403D11E809B; Mon, 8 Oct 2012 19:38:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKK63389; Tue, 09 Oct 2012 02:38:21 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 9 Oct 2012 03:38:05 +0100
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 9 Oct 2012 03:38:17 +0100
Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 9 Oct 2012 10:38:14 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: "aland@deployingradius.com" <aland@deployingradius.com>, Bernard Aboba <bernard_aboba@hotmail.com>
Thread-Topic: [Softwires] [Technical Errata Reported] RFC6519 (3372)
Thread-Index: AQHNpVF09lcNwk9Xbke928JQybrftJewPERg
Date: Tue, 09 Oct 2012 02:38:13 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3CE37318@szxeml546-mbx.china.huawei.com>
References: <20121008123051.F3455B1E003@rfc-editor.org>
In-Reply-To: <20121008123051.F3455B1E003@rfc-editor.org>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.83.152]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "softwires@ietf.org" <softwires@ietf.org>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [Softwires] [Technical Errata Reported] RFC6519 (3372)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2012 02:38:24 -0000
Could we update the description of 'service-type(6)=Call check' as follows, '... typically based on the NAS-Port-Id(87), or Calling-Station-Id(31) attributes, etc. It is recommended that such Access-Requests use the value of NAS-Port-Id or Calling-Station-Id as the value of the User-Name.' if we believe the *call* is not only associated with the telephone system? Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Monday, October 08, 2012 8:31 PM To: roberta.maglione@telecomitalia.it; adurand@juniper.net; rdroms.ietf@gmail.com; brian@innovationslab.net; suresh.krishnan@ericsson.com; cuiyong@tsinghua.edu.cn Cc: softwires@ietf.org; rfc-editor@rfc-editor.org; aland@deployingradius.com Subject: [Softwires] [Technical Errata Reported] RFC6519 (3372) The following errata report has been submitted for RFC6519, "RADIUS Extensions for Dual-Stack Lite". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6519&eid=3372 -------------------------------------- Type: Technical Reported by: Alan DeKok <aland@deployingradius.com> Section: 3 Original Text ------------- In the scenario depicted in Figure 2, the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17); thus, according to [RFC5080], the Access-Request packet MUST contain a State attribute. Corrected Text -------------- In the scenario depicted in Figure 2, the Access-Request packet contains a Service-Type attribute with the value Call-Check (10). Notes ----- The document references RFC 5080. However, the use of the State attribute in this document is wrong. The text in RFC 5080 clearly says that State is used to tie an "Authorize Only" request to a previous authentication. The text requiring State in "Authorize Only" is surrounded by explanations describing *why* it's required. The original text in RFC 6519 appears to say that adding State magically satisfies the requirements of 5080. But it ignores all of the surrounding text. The NAS can't simply invent a State attribute, to satisfy the requirement of 5080. It MUST get the State from a previous Access-Accept. Since there's no previous Access-Accept here, the use of Authorize-Only and State is wrong. RFC 2865 suggests the use of "Service-Type = Call Check" for this kind of authorization checking: Call Check Used by the NAS in an Access-Request packet to indicate that a call is being received and that the RADIUS server should send back an Access-Accept to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes. It is recommended that such Access-Requests use the value of Calling-Station-Id as the value of the User-Name Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6519 (draft-ietf-softwire-dslite-radius-ext-07) -------------------------------------- Title : RADIUS Extensions for Dual-Stack Lite Publication Date : February 2012 Author(s) : R. Maglione, A. Durand Category : PROPOSED STANDARD Source : Softwires Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
- [Softwires] [Technical Errata Reported] RFC6519 (… RFC Errata System
- Re: [Softwires] [Technical Errata Reported] RFC65… Leaf yeh