Capabilities negotiation problem statement

[Bernard Aboba <aboba@internaut.com>]

In looking at the Capabilities Negotiation draft, I was struck by the 
vagueness of the problem statement. 

RADIUS has existed without capabilities negotiation for more than a decade 
now.  As far as I know,  there are not even any Vendor-Specific 
implementations.  Given the level of experimentation on other areas (see 
RFC 2882) this is surprising.  If this problem is so important and 
pervasive (as the draft argues) how come the industry seems to have 
ignored it for a decade, without creating huge problems? 

The answer is that RADIUS already enables NASes and RADIUS servers with 
different capabilities to interoperate.  For example, RFC 2865 allows a 
NAS to ignore attributes it does not understand, and this is how most 
existing RADIUS client implementations behave.  This allows a RADIUS server 
to send attributes to a NAS without having to worry about whether it 
understands them, as long as those attributes can be safely ignored. 

Similarly, a NAS does not need to know whether a RADIUS server understands 
an attribute in order to send it, as long as the attribute can be safely 
discarded by the RADIUS server.

As a result, the real issue is specification of mandatory attributes, 
not "capability-negotiation" per se.  Note that a proposal for 
mandatory/optional marking has recently been put forward in the Design 
Guidelines document. 

Some of the cases where the mandatory/optional issue comes up include: 

a. Where the RADIUS server REQUIRES the NAS to understand an attribute in 
order for access to be provided.  A classic case of this is use of 
security attributes (VLANs, Filters, etc.).  A NAS cannot safely 
ignore a security attribute sent by the RADIUS server.  

This situation is the most common one;  there are documented cases 
where existing behavior has resulted in substantial financial losses.  
At the same time, the behavior of existing implementations can't be 
changed retroactively. 

b. Where the NAS REQUIRES that the RADIUS server send an attribute in 
order for it to provide access. 

Other cases are already handled by the RADIUS protocol as it exists today: 

c. Where the RADIUS server requires an attribute that the NAS does not 
provide in an Access-Request, the server can send an Access-Reject, 
potentially including an Error-Cause (101) attribute.  If the NAS 
understands the Error-Cause attribute, it can correct the problem. 

In looking at the proposal within the Design Guidelines document, it 
appears to me that the Mandatory/Optional functionality described there 
potentially handles both cases a) and b).  In case a), a RADIUS server can 
send an attribute with the "M" bit set.  In case b), a NAS can send an 
attribute with the "M" bit set. 

Given all of this -- what is the problem statement for Capabilities 
Negotiation, and how does it differ from the problem statement for 
Mandatory/Optional attributes? 

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