RE: Capabilities negotiation problem statement

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

Hi Bernard,

Please see inline... 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 7:27 AM
> To: radiusext@ops.ietf.org
> Subject: RE: Capabilities negotiation problem statement
> 
> > 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.

I am aware of that but this is inefficient!  It requires that we send a
message and try.  It is more efficient if we know up front via a
capability indication.  

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

In some cases they don't work at all and in other cases they work but
not efficiently.
 
> > 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.  

But in subsequent interaction for that session --  either in accounting
or in subsequent requests or in issuing commands such as proposed by LOG
OFF then the Server can indicate what it may desire.

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

Ahhhhh so you do support a capability exchange!!!  I thought you didn't.
So we have at least one.
 
> > 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.  

Not true. Is 2865 focused? Is 2869 focused? I would even argue that 3576
presents two different capabilities, DM and COA  Each may be supported
independantly.


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

Ideally sure but in some cases it is not possible to split a complex AAA
application into smaller RFCs just to stay true to that ideal.  

Diameter CC is a perfect example of that.  Not all the features will be
implemented by a given vendor or even be ever be implmented by anyone.

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

You mean like user-name?  Perhaps let user-name carry the actual user
name and have another attribute carry the routing information?  I would
agree.

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