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

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: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Alan DeKok
Sent: Wednesday, October 03, 2012 2:47 AM
To: Bernard Aboba
Cc: aaa-doctors@ietf.org; draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org; Ralph Droms
Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt

Bernard Aboba wrote:
> I have some questions about this document.
> 
> RFC 5080 Section 2.1.1 lays out the requirements for use of a State
> attribute:
...
> This requirement exists to ensure that a State attribute ties back to an
> 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
> sequence is authenticated, nor does it show any previous previous
> authenticated RADIUS interaction.   It therefore appears to violate the
> RFC 5080 requirement.

  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.
_______________________________________________
AAA-DOCTORS mailing list
AAA-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/aaa-doctors