RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

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

 Hi Alan,

See inline....

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Thursday, September 08, 2005 1:02 PM
> To: Bernard Aboba
> Cc: radiusext@ops.ietf.org
> Subject: Capabilities (was Re: AW: Review of 
> draft-ietf-geopriv-radius-lo-04.txt )
> 
> Bernard Aboba <aboba@internaut.com> wrote:
> > [ re: location ]
> >
> > However, I don't see a need for "Capabilities Announcement" 
> by the NAS. 
> 
>   I agree.  

For location I don't agree.  Currently we all seem to agree that if the
RADIUS server wants location it simply challenges for the location
information.  No problem here.

However, if a RADIUS server challenges for location information and the
NAS does not support location information, the NAS will treat the
challenge as an Access-Reject and drop the session.

The is problematic.  Because the RADIUS server may request location and
if it can't get the location information it may still want to provide
service.

So the correct way to do this is to have the NAS advertize its location
capability and then the RADIUS server will know whether it should ask
for location.

In the case where a RADIUs server does not receive and advertizment it
may still challenge but then it will do so at the peril of having the
NAS reject the session.

This is a more complete solution don't you agree?


>For the larger capabilities case, I see the 
> requirements as follows:
> 
>  a) NAS requires information from the RADIUS server
>  b) RADIUS server requires the NAS implement X
> 
>   For (a), the NAS can simply drop any session where it 
> doesn't get the information it needs.  The NAS *MUST* also 
> advertise the information it needs in Access-Request packets, 
> otherwise the RADIUS server won't know to send the 
> information.  (The format of this advertisement is less of an issue.)

You mean in Access-Accept not Access-Request right?

>   For (b), the current RADIUS spec says that it's permissible 
> for NASes to ignore attributes they don't understand, making 
> (b) impossible to satisfy in the current RADIUS system.
> 
>   The solution discussed previously is two-fold.  For 
> existing RADIUS conversations that use Access-Challenge, a 
> "capability request"
> attribute can be sent by the RADIUS server to the NAS.  In 
> order to be sure that the NAS supports that capability, the 
> NAS must reply with an "capability ack" in the next Access-Request.

But if the NAS does not support this challenge it will drop the session.

>   For RADIUS conversations that don't use Access-Challenge, 
> the solution is to extend them to use Access-Challenge.  This 
> is "fail-safe" under the current design, in that existing 
> implementations will treat unsupported Access-Challenge as 
> reject.  The method above for capability exchange can then be 
> used to enforce capability requirements.
> 
>   In conclusion, I think a capabilities protocol outlined as 
> above would be very useful, and would fit in with existing 
> RADIUS deployments and practices.

However there is another way to achieve B)

The RADIUS server requires the NAS to deliver capability X based on what
it received during the advertizement.  This is far simpler.

If RADIUS requires NAS to deliver X it may send capbility X in the
access-accept.  Or it may sent capability x back in a Challenge.
Ofcourse if the NAS did not advertize that it supported X in the first
case then the RADIUS server should not send it.

If the NAS never advertized X and RADIUS request it then:
-if the NAS does not support capabillity it will simply ignore the
request
-if the NAS does not support challenge it and a challenge is used it
will reject.
Etc....

I think that this approach is far simpler.  No?



>   Alan DeKok.
> 
> --
> 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/>