RE: [Geopriv] Re: Radius-Geopriv: When to send location info?

[Avi Lior <avi@bridgewatersystems.com>]

Hi folks,

The problem is this,  assuming that you have a Location Capable NAS that
sends location only on request, then in a scenario where the AAA always
requires it, then you will be introducing another exchange FOR every
REQUEST.  So that is clearly bad.  However, if EAP is being used then this
is not an issue since we already have a challenge happening.

So perhaps we can do the following (just thinking out loud).

1) The NAS (based on local policies) may be configured to send location info
to the home network. So in some deployments that is what it will do because
that is how they will want it to be used.

2) The NAS does not send the location information. But the home network may
challenge for it. Hence forth for that session it will continue to send that
information.

In step 2) how does the home network know that the NAS support location
information capability.  Well the NAS simply advertizes this using
Capability Exchange see our draft for that in RADEXT.

Note that in step 2 the home AAA needs to request location information.  We
can invent an attribute for that but this is yet another example where the
AAA can also include the Capability attribute to indicate that it MUST have
location, or that location information SHOULD be provided.

Note we had a debate whether or not the capability exchange should also come
from the home network. This is a clear case of such example.  SO the NAS
says "Hey I can deliver Location Information" the HOME Server says "Hey I
MUST have location information, or I it would be nice if you could deliver
location information" -- you get the drift.

But Capability Exchange is still drafty.



> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Thursday, March 03, 2005 3:09 PM
> To: Bernard Aboba
> Cc: geopriv@ietf.org; radiusext@ops.ietf.org; Tschofenig Hannes
> Subject: [Geopriv] Re: Radius-Geopriv: When to send location info?
> 
> 
> Bernard Aboba wrote:
> 
> >>[hannes] to me it seems reasonable not to include location 
> information 
> >>with every request. a  visited network which knows that it 
> has to send 
> >>location information to a particular home network  might do 
> so. i also 
> >>think that it would be good to have an error attribute to indicate 
> >>that it was  not possible to authorize the user properly 
> based on the 
> >>missing location information.
> >>
> >>we have added the usage of the error-cause attribute. 
> within the iana 
> >>section we need to register  a new type:
> >>    
> >>
> >
> >I am confused by the model that is described here.  I could 
> understand 
> >why the NAS might not send the NAS location with every 
> Access-Request.  
> >But user location is another matter.  If the NAS is set up 
> to send user 
> >location data, why would it not send it on each request?
> >
> >My reading of RFC 2865 is that service provisioning attributes 
> >(including
> >VSAs) are forbidden in a RADIUS Access-Reject.  However, 
> information on
> >why the request failed is ok (e.g. Reply-Message, 
> EAP-Message/EAP-Failure,
> >etc.).  So I think that Error-Cause can be included.
> >
> >However, Error-Cause will not solve the problem that is 
> described.  If 
> >the NAS is not sending User location on every Access-Request and the 
> >server requires this, then every Access-Request that is sent without 
> >the user location will be denied.
> >
> >I'd suggest that language be included in the document to say 
> that "by 
> >default, a NAS that is set up to provide user location 
> information to 
> >the RADIUS server MUST provide this information in every 
> >Access-Request."
> >  
> >
> 
> Yes. I would in fact extend this by having the NAS send this 
> information in the first place if and only if the home AAA 
> earlier instructed the NAS to do so for this specific 
> session. The cost would be very small, no additional 
> roundtrips for instance.
> 
> --Jari
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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