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

[Ralph Droms <[e-mail]>]

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

On Oct 2, 2012, at 2:46 PM 10/2/12, Alan DeKok wrote:

> 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.