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

[Sheng Jiang <[e-mail]>]

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:[e-mail]]
>Sent: Wednesday, October 03, 2012 4:24 AM
>To: [e-mail]
>Cc: Softwire Chairs; Bernard Aboba; [e-mail]; Alan DeKok
>Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt
>
>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.