[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Avi Lior wrote:

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.


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.

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.


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.

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.


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



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






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