Re: Questions on modified Extended Attribute format?

[Alan DeKok <aland@nitros9.org>]

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, 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.

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

> 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

  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)

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

  This proposal offers LESS than the "Diameter AVP in RADIUS" does, at
the cost of MORE work.

  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.

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