RE: Questions on modified Extended Attribute format?

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

Glen Zorn wrote:

> As I said, put that way or any other way you like, ANY change is
> incompatible with existing deployments.  If one were to add a new
"standard"
> attribute (in the old format or the proposed VSA-like format or any other)
> it would be incompatible with existing deployments.

  That isn't the point.  Everyone accepts that implementations have to
be updated to handle new standards.  One of the major efforts in RADIUS
has been to maintain backwards compatibility with existing deployments.
[gwz] 
You keep saying that but I really don't know where you get this funny idea.
[/gwz]

  i.e. if a product doesn't implement the new standard, it can still
communicate with products that do implement that standard.
[gwz] 


  This proposal breaks that completely.  It will be perfectly legal for
implementations of your proposal to put ALL RADIUS attributes as
grouped, inside of an "extended attribute".  Any NAS that receives such
a response will get a packet containing *nothing* but VSA's.  It will
then decide that there is nothing in the packet that it recognizes, and
will fail.
[gwz] 
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.  Of course, if the aim is to maintain backwards compatibility with
existing _deployments_ (rather than the existing _protocol_) we need to
support broken clients, right?
[/gwz]

  i.e. your proposal creates a new protocol that is incompatible with
legacy RADIUS.

[gwz]
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".
[/gwz]

> Actually, while the timeframe was long, the discussion wasn't: I've only
> received a couple of comments on it in the last months.  It _did_ take an
> inordinate amount of time to reject the 'Diameterization' of RADIUS,
> though...

  This proposal is no better.  It's worse in many respects.

[gwz]
Care to expand upon that a bit?
[/gwz]

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