RE: Capabilities negotiation problem statement

[Bernard Aboba <aboba@internaut.com>]

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

This case sounds the same as the security issue with filter rules. That 
is, the RADIUS server needs to send an attribute that cannot be safely 
ignored by the NAS. 

> Dynamic Auth - we need to understand whether a NAS supports 3576 for
> correct operation. 

RFC 3576 already specifies how a RADIUS server can determine if a 
NAS supports it.  Where the RADIUS client does not support RFC 3576, the 
server  will receive an ICMP port unreachable message in reply to a 
Disconnect or CoA-Request.  If the proxy supports RFC 3576, but the NAS 
does not, then the proxy replies with an Error-Cause value of "Unsupported 
Extension":

   "Unsupported Extension" is a fatal error sent due to lack of support
   for an extension such as Disconnect and/or CoA messages.  This will
   typically be sent by a proxy receiving an ICMP port unreachable
   message after attempting to forward a Request to the NAS.

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

The existing RADIUS mechanisms work for all services.  They are not just 
for "dialup". 

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

RADIUS is a request/response protocol.  There is no way for a NAS to know 
what the RADIUS server requires before sending an Access-Request.  

> For one I need to be assured that the NAS supports the mandatory
> semantics.  

That's relatively simple though -- a NAS can signal support for the 
extended format with a single attribute. 

> I may support NAS Filter Rule but only some of its options.

To date, RADIUS documents have focused on a single subject and included 
clear guidelines about what is needed to be considered compliant.  As an 
example, RFC 2868 is focused on tunnel attributes, so that a vendor can 
indicate that they are compliant with it, without being forced to 
implement attributes relating to a different capability. 

Similarly, existing RADIUS attributes are typically either implemented or 
not implemented.  If an attribute covers divergent capabilities so that 
vendors are unlikely to fully implement it within a single device, I would 
argue that that attribute should be broken down into distinct attributes, 
each with a unitary purpose.


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