RE: Capabilities negotiation problem statement

["Avi Lior" <avi@bridgewatersystems.com>]

Hi Bernard,

Thank you for your review. 

I presented a slide presentation at IETF 62 that describes the problem
statement for Cap Exchange.

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Friday, August 26, 2005 1:23 PM
> To: radiusext@ops.ietf.org
> Subject: Capabilities negotiation problem statement
> 
> 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? 

In fact, CUI and other work has introduced a capability exchange.

3GPP2 for example use advertisement for:
Prepaid - Before we push down a Prepaid policy we need to know whether
the NAS supports that policy.  Otherwise the NAS will ignore the policy
and allow the session to continue. As you can see this is a serious
problem.

Dynamic Auth - we need to understand whether a NAS supports 3576 for
correct operation.  There maybe more the one way to kill a session.  So
we want to know what the NAS can do.  This is laregely an efficiency
problem but also 

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

Sure for simple deployement scenarios like Dial up.  But now we are
talking about more sophisticated usage for RADIUS.


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

But this is not efficient.  Why send an attribute or a set of attributes
if the are not required by the Server?

Also if you look at new drafts such as logoff.  Why send a logoff
message if the Server doesn't need it?

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

I don't think that that is all.
 
> 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? 


For one I need to be assured that the NAS supports the mandatory
semantics.  So as a minimum we need that information.  But there is
more....

But mandatory is not enough.  Since some Applications have different
options or capabilities.  We need to understand which ones are
supported.  For example, I may support volume based or time based
prepaid but not support Prepaid Pools which are much more difficult to
implement.  I may support NAS Filter Rule but only some of its options.
So knowing what the NAS supports allows me to send the appropriate
attributes to the NAS invoking the modes that it supports for a given
application.  After all, the name of the game is not to have the NAS
reject the session.

Finally, A server may need to understand what features are supported as
part of its authentication/authorization policy decision.  If the NAS
does not support prepaid then, in a mobile IPv4 scenario, the server
will not rely on the NAS for prepaid but rather the HA.  It will then
force the NAS (acting as FA) to reverse traffic all the flows to the HA
and not send any prepaid attributes to the NAS.


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

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