Subject: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 2 Oct 2012 11:37:07 -0400

draft-ietf-softwire-6rd-radius-attrib-06.txt has been submitted for publication.  As it defines a RADIUS attribute, I'd like to get a review of the document from aaa-doctors.  In particular, is the complex datatype format of the attribute acceptable, or would some other format such as String carrying the DHCP 6rd option as opaque data be more appropriate?

- Ralph

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Oct 2012 09:48:24 -0700

I have some questions about this document. 

RFC 5080 Section 2.1.1 lays out the requirements for use of a State attribute: 

   The only permissible values for a State attribute are values provided
   in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
   Request packet.  A RADIUS client MUST use only those values for the
   State attribute that it has previously received from a server.  An
   Access-Request sent as a result of a new or restarted authentication
   run MUST NOT include the State attribute, even if a State attribute
   has previously been received in an Access-Challenge for the same user
   and port.
This requirement exists to ensure that a State attribute ties back to an authenticated RADIUS session.  

Within the document, the flow diagram describes "cooperation between DHCP and RADIUS":

     6rd CE                       BNG                       AAA Server
         |                          |                             |
         |-------DHCPDISCOVER------>|                             |
         |                          |--Access-Request(6rd Attr)-->|
         |                          |                             |
         |                          |<--Access-Accept(6rd Attr)---|
         |<-------DHCPOFFER---------|                             |
         |                          |                             |
         |--------DHCPREQUEST------>|                             |
         |      (6rd Option)        |                             |
         |<--------DHCPACK----------|                             |
         |      (6rd option)        |                             |
         |                          |                             |
                   DHCP                         RADIUS
                Figure 1: the cooperation between DHCP and RADIUS
This
 diagram neither indicates that the RADIUS Access-Request/Accept 
sequence is authenticated, nor does it show any previous previous 
authenticated RADIUS interaction.   It therefore appears to violate the 
RFC 5080 requirement. 

> From: [email-masked]
> Date: Tue, 2 Oct 2012 11:37:07 -0400
> To: [email-masked]
> Subject: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt
> 
> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Alan DeKok <[email-masked]>
Date: Tue, 02 Oct 2012 20:46:31 +0200

> RFC 5080 Section 2.1.1 lays out the requirements for use of a State
...
> authenticated RADIUS session. 

  The document references RFC 5080, and says:

   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.

  They seem to have missed the paragraph you quoted.  It is immediately
above the paragraph requiring State for Authorize Only.

> This diagram neither indicates that the RADIUS Access-Request/Accept

  The document repeatedly refers to "authentication", where no
authentication is taking place:

   ... A 6rd configuration request may
   also be sent in the same message. If the user authentication is
   approved by the AAA server,

  There is no "user", and no credentials supplied for authentication.

  My reading is that State was added solely to satisfy portions of RFC
5080.  I think it, and all references to 5080 should be removed from the
draft.

  Since no user authentication is taking place, perhaps a better
suggestion would be to allocate a new Service-Type, of
IPv6-6rd-Configuration.  The Access-Request could contain:

	Service-Type = IPv6-6rd-Configuration
	IPv6-6rd-Configuration = ... data ...

  RADIUS servers should be able to key off of the Service-Type to
distinguish 6rd requests from all other RADIUS requests.  They can then
respond correctly, even though no user credentials are in the request.

  The draft should also replace the four references to "authentication"
on page 4 with "authorization".

  The format of the IPv6-6rf-Configuration attribute is not ideal.  This
is OK, as the RADIUS extensions document has not been published.  The
only suggestions I would have are:

- make the IPv4MaskLen field 32 bits long.  RFC 6158 Section A.2.1 has
this text forbidding 8-bit fields:

      * Unsigned integers of size other than 32 bits.
        SHOULD be replaced by an unsigned integer of 32 bits.  There is
        insufficient justification to define a new size of integer.

- make it clear that since the subtypes have values, they can appear in
any order.  e.g. subtype 1,2,3 is OK, but so is subtype order 2,3,1 and
3,2,1.

- if new subtypes are envisioned, then an IANA registry for subtypes
should be allocated, subject to expert review, or IETF consensus

  Alan DeKok.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 2 Oct 2012 16:24:29 -0400

Bernard, Alan - thanks for your feedback on draft-ietf-softwire-6rd-radius-attrib-06

Authors - please review this feedback and revise your document appropriately.  Once the aaa-doctors are satisfied with the revisions, I'll proceed with IETF last call and IESG review.  

- Ralph

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 8 Oct 2012 03:04:14 +0000

Bernard, Alan and Ralph - thanks for your review and comments. We are working on the revision accordingly. We will ask your confirmation before submission a new version. :)

Many thanks and best regards,

Sheng

>-----Original Message-----
>From: Ralph Droms [mailto:[email-masked]]
>Sent: Wednesday, October 03, 2012 4:24 AM
>To: [email-masked]
>Cc: Softwire Chairs; Bernard Aboba; [email-masked]; Alan DeKok
>Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt
>
>Authors - please review this feedback and revise your document appropriately.
>Once the aaa-doctors are satisfied with the revisions, I'll proceed with IETF
>last call and IESG review.
>
>- Ralph
>

---

From: Leaf yeh <[email-masked]>
Date: Mon, 8 Oct 2012 11:48:28 +0000

a.
Alan - <quote>The format of the IPv6-6rf-Configuration attribute is not ideal.  This
is OK, as the RADIUS extensions document has not been published...
- make it clear that since the subtypes have values, they can appear in
any order.  e.g. subtype 1,2,3 is OK, but so is subtype order 2,3,1 and
3,2,1.</quote>

I tend to suggest draft-ietf-softwire-6rd-radius-attrib-06 to adopt the data type of TLV newly defined in draft-ietf-radext-radius-extensions.

b.
draft-ietf-softwire-6rd-radius-attrib-06 - <quote> ... 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. </quote>
Alan - <quote> There is no "user", and no credentials supplied for authentication.
  My reading is that State was added solely to satisfy portions of RFC
5080.  I think it, and all references to 5080 should be removed from the
draft.
Since no user authentication is taking place, perhaps a better
suggestion would be to allocate a new Service-Type, of
IPv6-6rd-Configuration.  The Access-Request could contain:
	Service-Type = IPv6-6rd-Configuration
	IPv6-6rd-Configuration = ... data ...
  RADIUS servers should be able to key off of the Service-Type to
distinguish 6rd requests from all other RADIUS requests.  They can then
respond correctly, even though no user credentials are in the request. </quote>

There is almost the same description in section 3 of RFC 6519. Quoted as follows: '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.'  Is it an Errata here?

c. IPv6-6rd-Configuration sounds not in the category of Service-Type (6) per the following records @ http://www.iana.org/assignments/radius-types/radius-types.xml.

1 Login  
2 Framed  
3 Callback Login  
4 Callback Framed  
5 Outbound  
6 Administrative  
7 NAS Prompt  
8 Authenticate Only  
9 Callback NAS Prompt  
10 Call Check  
11 Callback Administrative  
12 Voice 
13 Fax
14 Modem Relay
15 IAPP-Register
16 IAPP-AP-Check
17 Authorize Only [RFC3576] 
18 Framed-Management

Do we really find the suitable registry for the attribute of 6rd Configuration?

d. How about replace the type name of this newly designed attribute to be '6rd-configuration'?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Wednesday, October 03, 2012 2:47 AM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]; Ralph Droms
Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt

...

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Oct 2012 08:46:51 -0400

> I tend to suggest draft-ietf-softwire-6rd-radius-attrib-06 to adopt the data type of TLV newly defined in draft-ietf-radext-radius-extensions.

  The extensions document isn't published, so this draft can't use the
TLV data type.  However, it can use the *format*, which is OK.

> a State attribute.'  Is it an Errata here?

  I submitted one.  It's wrong.

...
> Do we really find the suitable registry for the attribute of 6rd Configuration?

  I suggest using "Call Check".

  Alan DeKok.