RE: Questions on RADIUS Extended attributes

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> supposedly scribbled:

> At IETF 66, we discussed how to extend the RADIUS attribute space. 
> The consensus in the room as well as on the WG mailing list seems to
> be to focus on extending the space only, not adding functionality,
> along the lines that Avi had proposed:   
> 
> http://www.watersprings.org/pub/id/draft-lior-radius-attribute-type-extension-00.txt
> 
> During IETF 66, there was some sentiment that the RADIUS Extended
> attribute should utilize a new RADIUS attribute value, rather than
> using a Vendor-Id value of zero (0) with the existing RADIUS VSA
> attribute (Type 26). 

Hmm.  I don't remember any discussion like that at during the meeting, and searched in vain for mention of it in the draft minutes; I know that a couple of people stated that preference on the list recently, but without any technical justification.
  
> 
> Taking that into account, find below a strawman proposal for what the
> Extended-Type attribute would look like. 
> 
> Some questions:
> 
> a. Do we want an Extended-Type field of two or four octets?  If it is
> four octets, this would seem to imply that RADIUS attributes and
> Diameter AVPs share the same type space.  Will this work?  If it is
> two octets, we could reserve 65535 values within the existing
> Diameter attribute space for RADIUS Extended-Type attributes.  
> Opinions solicited. 

Is it really necessary to do more than double the number of standard attributes?  That is what the VSA approach would do, without requiring code changes...
   
> 
> b.  Should the second length field include the Extended-Type field or
> not? 
> If it is included and Extended-Type is 4 octets, then this implies
> that the Value field could only be 251 octets.  If the second length
> field doesn't include Extended-Type, it could be as long as 255
> octets, but then we'd need to allow Extended-Type attributes to be
> split among multiple RADIUS attributes.  

In combination with the tagging scheme (or something very similar) you mentioned in a recent message, the "VSA Zero" approach solves this problem, as well.
  
> 
> c. Should we allow multiple Extended-Type attributes to be placed
> inside a single RADIUS attribute? This is OK for RADIUS VSAs, is
> there an issue here? 

Ditto.
 
...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>