RE: Questions on modified Extended Attribute format?

["Glen Zorn" <glenzorn@comcast.net>]

Alan DeKok <> scribbled on Tuesday, January 08, 2008 12:32 AM:

> Glen Zorn wrote:
>> You keep saying that but I really don't know where you get this
>> funny idea. 
> 
>   New extensions cannot break existing deployments.
> 
>   This is NOT the same as saying new extensions require new code for
> implementations to support those extensions. 
> 
>>> [ re: packing standard attributes inside of extended ]
>> Only if the authentication method in use is EAP, I think.  RFC 2865
>> doesn't list any attributes as required in any type of response; if
>> your client fails because it can't find any attributes in the packet,
>> your client is broken.
> 
>   The client will reject the user, 

If it does, it is broken (modulo the above).

> or will apply the wrong policy
> (i.e. 
> default "empty response" policy, rather than the policy in the
> response).  Please explain to the user and administrator that the
> users are being rejected because of a new feature in RADIUS, and that
> this is a Good Thing.  

The users are being rejected because the provider of their client has
made up his own rules about what a valid response is; if they get the
wrong policy (or the wrong service), tell me how that is different from
a client getting tunnel attributes that it doesn't understand &
therefore ignores.
 
> 
>> Really?  Tell me what happens when a NAS receives, say, a tunnel
>> attribute that it doesn't understand; then tell me how that is
>> different from the introduction of _any_ new standard attribute and
>> how it constitutes "communication".
> 
>   The issue is NOT introduction of a new standard attribute.  The
> issue is encapsulating standard attributes that the client DOES
> understand in a VSA that the client DOES NOT understand.  

Tell me the difference in effect.  As for encapsulating all the
attributes in VSAs, that is easily handled by disqualifying the
mandatory attributes (such as User-Name, EAP-Message, etc.) from
inclusion.

> 
>> Care to expand upon that a bit?
> 
>   If you're going to increase the attribute space, AND support long
> attributes, you might as well give up and use the Diameter AVP
> format.  
> Your proposal involves:
> 
>    VSA header: 2 bytes  (type, length)
>    Vendor-Id of zero: 4 bytes
>    Extended attribute header: 3 bytes (16 bit type + length)
>    "continuation" flag: 1 byte

I'm going to give you the benefit of the doubt & assume that you have
actually read the draft & merely misspoke: the "continuation flag" is
one bit, not one byte; the rest of that octet is the Tag field.

> 
>   For a total of 10 bytes of header for one attribute.
> 
>   The "Diameter AVP in RADIUS" involves:
> 
>    new attribute header: 2 bytes
>    Diamater header: 8 bytes (4 byte type + 4 byte length)

Pardon me: 4 byte type, 1 byte of flags (BTW, are those 8 bits of flags
actually useful in RADIUS?) and a 3 byte length.  

> 
>   For a total of 10 bytes.  Plus, conversion to Diameter in Diameter
> to RADIUS gateways is easy.  We can get arbitrary grouping via the
> Diameter method.  We can have attributes as long as we want.  

Really?  The "new attribute header" that you conveniently gloss over
above contains a 1 octet total length for the attribute, giving the same
length limit as old-style RADIUS; of course, you could always either a)
just concatenate "Diameter AVPs" of the same AVP type together (but then
you can only have one AVP of a given type in a message) or b) add an
"awkward" continuation BIT to the Flags field of the AVP...

> AND the
> coding is much, much, easier.   
> 
>   I implemented the Diameter format as a test a while ago, and it was
> ~400 LoC, in part because it could leverage the existing code base of
> Diameter encapsulation/decapsulation.  I've been looking at the
> extended attribute format.  It doesn't leverage any existing code. 
> It has an awkward "continuation" byte, which means it can't use any
> of the pre-existing VSA handlers, etc.  

Again, I'm kind of amazed: I thought that you had implemented the WiMax
VSAs.  You mean that that code couldn't be leveraged?  The formats are
practically identical.
   
> 
>   This proposal offers LESS than the "Diameter AVP in RADIUS" does,
> at the cost of MORE work. 

See above.

> 
>   We've been having this argument for too long.  We need to stop NOW,
> pick a format, and move on.  The endless re-visiting of attribute
> format is holding up other key work.  

I agree completely: it is becoming rather painfully obvious (from the
landing of red herrings (make that whales ;-), the frothing at the
mouth, grasping at straws & confusing of implementations with standards)
that this idea is entirely too close to useful to be approved by this
committee.

> 
>   Alan DeKok.


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