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

[Sheng Jiang <[e-mail]>]

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