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

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

Hi David,

Please see inline.... 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Thursday, September 08, 2005 1:58 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Capabilities (was Re: AW: Review of 
> draft-ietf-geopriv-radius-lo-04.txt )
> 
> Avi Lior writes...
> 
> > 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.
> 
> Bernard Aboba has previously argued, convincingly IMHO, that 
> if the RADIUS server simply *wants* to get location 
> information, it can request in the Access-Accept that 
> location information be included in Accounting-Request 
> messages, if it happens to be available at the NAS.
> If the RADIUS server *needs* to get location information, 
> then the NAS would be doing the right thing to terminate the 
> session when it does not support location.

This is where I think that we have an issue.

The RADIUS server may REQUIRE location in order to evaluate a
authentication/authorization policy.  That policy could state that if
location is not provided then allow the user on with certain
contstraints.

The current approach will not allow this to happen. In certain cases the
session will be rejected by the NAS.  So this is where I am consistantly
disagreeing with Bernard. 

> > >   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?
> 
> The NAS doesn't send Access-Accept messages, so how could the 
> NAS advertise its requirements in anything other than an 
> Access-Request?

I guess it depends how you read the above statement.  But what we are
saying is:

The NAS must also advertize the information it needs in an Access-Accept
packet in an Access-Request packet.

Or something like that....

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