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

From: Avi Lior <[email-masked]>
Date: Thu, 3 Mar 2005 15:20:30 -0500

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:[email-masked]] 
> Sent: Thursday, March 03, 2005 3:09 PM
> To: Bernard Aboba
> Cc: [email-masked]; [email-masked]; 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Jari Arkko <[email-masked]>
Date: Fri, 04 Mar 2005 10:28:54 +0200

>is not an issue since we already have a challenge happening.
I realize that but I wonder how likely that is. In fact, are there
any cases where you'd not be doing challenges anyway? Seems
like WLAN, PPP CHAP, and SIP all need that... the only case that
does not need it is PPP PAP, but we deprecated that, didn't we?

Or maybe there is some mode of RADIUS or Diameter SIP that doesn't
need a request -- its too late in the night for me to go and re-read
the documents to find out, but maybe you remember it directly.

In any case, I would like to avoid a very complicated mechanism
that works differently for different apps. All I wanted is a privacy
knob to the system where (a) if the client and NAS have a protocol
that can negotiate location policies, then the NAS MUST obey the
results of the negotiation, and (b) if the home network has a "do not
disclose" policy about location information it MUST prevent the
information from being sent in the first place. But I see the problems
that you bring up.

>that is how they will want it to be used.
I'm pretty sure we have this in any case. Just because you installed
a newer firmware version to the NAS with location attribute support
doesn't mean that it should necessarily be turned on.

>But Capability Exchange is still drafty.
Yes. But the indication we are talking about here is more about
policy "do I want you to send the info even if you have it?" than
capability "can you send it?". But I agree it could be encoded in
a general e2e capability exchange feature.

--Jari

>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>
>
>  
>