Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04

I found a few other issues beyond those Alan mentions below.

Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring. 

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:

   Access-Request packets that contain a Service-Type attribute with the
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.  This last requirement often means that an Access-
   Accept needs to contain a State attribute, which can then be used in
   a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.   Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:

   This attribute MAY be used in Access-Accept packets as a hint to the
   RADIUS server; for example if the NAS is pre-configured with a
   default tunnel name, this name MAY be inserted in the attribute.  The
   RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
   different AFTR tunnel name.

> Date: Mon, 8 Aug 2011 10:52:08 -0400
> From: aland@freeradius.org
> To: dromasca@avaya.com
> CC: aaa-doctors@ietf.org
> Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04
> 
> Romascanu, Dan (Dan) wrote:
> > Hi AAA Doctors,
> > 
> > Did any of you review this document? 
> 
>   I have minor nit-picks on the format.  The discussion of
> type/length/value at the top of page 9 doesn't follow the traditional
> RADIUS format.  It's minor, but still..
> 
>   On a related note, there's been a surge of interest recently in adding
> DHCP attributes to RADIUS.  I registered a PEC a while back to address
> the issue.  I created a vendor-specific dictionary for RADIUS, which is
> intended to carry DHCP options:
> 
> https://github.com/alandekok/freeradius-server/blob/master/share/dictionary.freedhcp
> 
>   The intention is that VSAs with PEC of 34673 are duplicates of the
> IANA allocation DHCP options.
> 
>   Using this would solve a few issues.  The IETF standard RADIUS space
> would feel less pressure, as the VSAs could be used.  All of the other
> vendors "ad hoc" ways of carrying DHCP options in RADIUS could be
> replaced by using this dictionary.
> 
>   If people think it's worth-while, I can submit an individual draft
> documenting this practice.  It may not help for this document, but it
> will help for future documents.
> 
>   Alan DeKok.
> 
> _______________________________________________
> AAA-DOCTORS mailing list
> AAA-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/aaa-doctors