[secdir] proposed text for packet flow in draft-ietf-softwire-6rd-radius-attrib-08

Sheng Jiang <jiangsheng@huawei.com> Tue, 04 December 2012 03:02 UTC

Return-Path: <jiangsheng@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA8721F8920; Mon, 3 Dec 2012 19:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 vQy6p7FCp0TR; Mon, 3 Dec 2012 19:02:45 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D27F21F8879; Mon, 3 Dec 2012 19:02:42 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANL52401; Tue, 04 Dec 2012 03:02:39 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 03:02:12 +0000
Received: from SZXEML443-HUB.china.huawei.com (10.82.67.181) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 11:02:38 +0800
Received: from SZXEML545-MBS.china.huawei.com ([169.254.2.174]) by SZXEML443-HUB.china.huawei.com ([10.82.67.181]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 11:02:35 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: proposed text for packet flow in draft-ietf-softwire-6rd-radius-attrib-08
Thread-Index: Ac3Ry85QaXs3BN28SU6EM6WO6V/3XA==
Date: Tue, 4 Dec 2012 03:02:33 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239FCBEFE@szxeml545-mbs.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.140]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Dave Nelson <dnelson@elbrys.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "Benoit Claise \(bclaise\)" <bclaise@cisco.com>, "draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org" <draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>, Barry Leiba <barryleiba@computer.org>
Subject: [secdir] proposed text for packet flow in draft-ietf-softwire-6rd-radius-attrib-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 03:02:45 -0000

Dear AAA doctors and Secdir members,

Following your comments on draft-ietf-softwire-6rd-radius-attrib-06 and 07 versions, the authors has refined the packet flow for the cooperation between DHCP and RADIUS. The blow is the proposed text for 08 version. Could you please review it and comment whether your early comments have been properly solved? If you have any further modification suggestions, we are willing to follow. Many thanks.

The below Figure 1 illustrates how the RADIUS protocol and DHCP cooperate to provide 6rd CE with 6rd configuration information.
 
6rd CE                    BNG              AAA Server
   |                      |                        |
   |-------DHCPDISCOVER------>|                       |
   |(Parameter Request w/ 6rd option)                  |
   |                      |--Access-Request(6rd Attr)-->|
   |                      |                        |
   |                      |<--Access-Accept(6rd Attr)---|
   |<-------DHCPOFFER---------|                        |
   |      (6rd option)      |                       |
   |                     |                        |
                DHCP                      RADIUS 
      Figure 1: the cooperation between DHCP and RADIUS
              combining with RADIUS authentication

The BNG acts as a client of RADIUS and as a DHCP server for DHCP protocol. First, the 6rd CE initiates a DHCPDISCOVER message that includes a Parameter Request option (55) [RFC2132] with 6rd option [RFC5969]. When the BNG receives the DHCPDISCOVER, it initiates a Radius Access-Request message to the Radius server, requesting normal authentication as defined in [RFC2865] and IPv6-6rd-Configuration attribute, defined in the next Section, in the desired attribute list. If the authentication request is approved by the AAA server, an Access-Accept message is acknowledged with the IPv6-6rd-Configuration Attribute. Then, the BNG responds to the 6rd CE with a DHCPOFFER message, which contains DHCP 6rd option.

Figure 2 describes another scenario - later re-authorize, in which the authorization operation is not coupled with authentication. 6rd relevant authorization is done independently after the authentication process.

6rd CE                    BNG               AAA Server
   |                      |                        |
   |--------DHCPREQUEST------>|                       |
   |(Parameter Request w/ 6rd option)                   |
   |                      |--Access-Request(6rd Attr)-->|
   |                      |                        |
   |                      |<--Access-Accept(6rd Attr)---|
   |                      |                        |
   |<---------DHCPACK---------|                         |
   |      (6rd option)      |                        |
   |                      |                        |
           DHCP                       RADIUS
    Figure 2: the cooperation between DHCP and RADIUS
               decoupled with RADIUS authentication

In the abovementioned scenario, 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 that succeeds from the previous authentication process.

Many thanks and best regards,

Sheng & Dayong