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

[Alan DeKok <[e-mail]>]

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.