RE: backwards compatible introduction of NEW attribute such as CUI

["Nelson, David" <dnelson@enterasys.com>]

Lothar Reith writes (in HTML format!)... 

As pointed out earlier, using an approach of "always send a hint"
attribute in all Access-Request messages may be prohibitively expensive,
...

DBN: I understand that this assertion has been made on the list.  In the
minutes I was simply reporting a brief summary of the discussion at the
meeting.  As a side note, I have never been convinced about the
"prohibitive expense" of including an attribute, especially a short one,
in an Access-Request message, given the popular practice of including
all sorts of "hint" attributes in Access-Accept messages (this would be
just one more) and the small percentage increase in packet size.

Before including a new mandatory attribute "NEW" into an access-accept
message a server may want to challenge the NAS in order to verify if the
NAS supports that particular new attribute "NEW".

DBN:  Be careful.  The only attribute that RADIUS considers "mandatory"
is the Service-Type. Introducing the concept of mandatory attributes
into RADIUS, as the concept exists in Diameter, is a substantial
undertaking.

This "Challenge" can be done implicitly (reject with a hint) or
explicitly (challenge with a hint).

DBN: As Bernard Aboba has previously stated, we don't want to use
Access-Reject as a negotiation method.  It's a slippery slope, and it
has all sorts of backwards compatibility problems.

I believe this behaviour should be in line with Bernard's below earlier
comment.

DBN: I respectfully disagree.

Alternatively perhaps an explicit challenge may be used as follows: 
2) on receipt of an access-request message which does not include a
Null-NEW attribute, but where the server would only send an
access-accept if assured that the NAS supports NEW, the Server may
respond with an Access-Challenge message which includes the Null-NEW
attribute. A NAS which supports an attribute NEW MUST on receipt of a
Null-NEW attribute in an access-challenge message include a Null-NEW
attribute in the subsequent ACCESS-Request message in order to confirm
support of NEW attribute to the challenging Server.

DBN:  This method might be made to work.  There are backwards
compatibility issues here too.  What happens when the RADIUS client has
no idea what the inclusion of a NEW attribute in the Access-Challenge
message means?  Should the client treat the Access-Challenge as an
Access-Reject?  Should it send a new Access-Request without the NEW
attribute (which it doesn't understand)?  Will the server respond with
yet another Access-Challenge?  Will this cause an endless loop?  :-)


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