[Softwires] [Technical Errata Reported] RFC6519 (3372)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 08 October 2012 12:35 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 0735F21F8522 for <softwires@ietfa.amsl.com>; Mon, 8 Oct 2012 05:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.331
X-Spam-Level:
X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 HhOZu9wpRd66 for <softwires@ietfa.amsl.com>; Mon, 8 Oct 2012 05:35:43 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0D221F874C for <softwires@ietf.org>; Mon, 8 Oct 2012 05:35:36 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id F3455B1E003; Mon, 8 Oct 2012 05:30:51 -0700 (PDT)
To: roberta.maglione@telecomitalia.it, adurand@juniper.net, rdroms.ietf@gmail.com, brian@innovationslab.net, suresh.krishnan@ericsson.com, cuiyong@tsinghua.edu.cn
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20121008123051.F3455B1E003@rfc-editor.org>
Date: Mon, 08 Oct 2012 05:30:51 -0700
Cc: softwires@ietf.org, rfc-editor@rfc-editor.org, aland@deployingradius.com
Subject: [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: Mon, 08 Oct 2012 12:35:44 -0000

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