Subject: [Geopriv] Review of draft-ietf-geopriv-radius-lo-04.txt

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 14:09:09 -0700 (PDT)

Review of draft-ietf-geopriv-radius-lo-04.txt

The RADEXT WG Issues page discloses that 13 issues remain open against
this document:
http://www.drizzle.com/~aboba/RADEXT/

Based on a preliminary review of the -04 version, it appears that some
of these open issues still have not been addressed.  Some notes below: 

Section 2

"  Furthermore, the authors believe that there is a relationship
   between the location of the network and the location of the entity
   that triggered the network access authentication.  Knowing the
   location of a network (where the user or end host is attached to)
   might in many networks also reveal the location of the user or end
   host.  In some networks it is even possible to provide a accurate
   location of the user or end host.  A similar assumption is also made
   with regard to the location information obtained via DHCP (see for
   example [4]).  This information might be used by applications in
   other protocols (such as SIP [12] with extensions [13]) to indicate
   the location of a particular user even though the location "only"
   refers to the location of the network or equipment within the
   network.  The assumption here is also that the location of the
   network has some relationship to the location of the end host (and
   subsequently to a user).  This assumption might not hold in all
   scenarios.  Nevertheless, it seems to be reasonable."

RADEXT Issue 27 points out that this assumption is
not correct -- the location of the peer and the location of the
NAS are not the same thing.  There are APs today that are capable
of providing the location of the user with a high degree of accuracy. 
Can those APs use this specification to provide the NAS and peer
location information independently? 

Section 3.2

RADEXT Issue 74 points out problems with the way this document uses
RFC 3576.  

   The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request.

This paragraph appears to retroactively update RFC 3576.  

   Upon receiving the Authorize-Only message from the access network,
   the AAA server MUST respond with either an Access-Accept message or
   an Access-Reject message.

This also sounds like an update of RFC 3576.  Why should RFC 3576 
behavior be different when location attributes are included? 

More fundamentally, why does RFC 3576 need to be used to obtain location 
information in mid-session when the same info is available in Accounting 
packets?  Or is the issue that location data may not be included in 
Interim accounting information? I didn't notice a way that the RADIUS
server can configure the way the NAS sends location info (e.g. don't send 
in interims, send at a given interval different from the interim interval, 
etc.)

Section 4

   How the network obtains the user's
   location information is out of the scope of this document. 

See RADEXT Issue 27.  Obtaining the peer location is one of the
fundamental usage scenarios for RADIUS-based location information.
If this is out of scope for this specification, a different 
specification will be needed to address that issue.  Why not handle
both issues within the same document? 

Section 8

   The capability attribute allows the RADIUS client to indicate whether
   civic and/or geospatial location information can be provided to the
   RADIUS server.  This is useful to avoid sending location information
   with every request if no further out-of-band arrangements are made
   with regard to the transport of location information.  The AAA server
   uses the capability attribute to indicate that the AAA client has to
   provide civic and/or geospatial location information as part of this
   particular protocol exchange.  If the AAA server does not send a
   capability attribute then the AAA client MUST NOT return location
   information.  The user's authorization policies MUST be consulted by
   the AAA server before requesting location information delivery from
   the AAA client.  If the AAA server encounters that the AAA client
   does not support the desired location information it might respond
   with an Access-Reject with the corresponding error cause attribute
   (with the Location-Info-Required error code).

The above paragraph seems vague about the nature of the capability
negotiation.  Terms like "might respond" imply a range of
acceptable behaviors, which could result in interoperability problems. 

Since Access-Requests are initiated by the NAS, there is no way
for the NAS to know beforehand whether a given RADIUS server requires
location information or not.  However, a NAS might default to not
sending location information and then if the AAA server sends back
an Access-Reject with a Location-Info-Required error code, then it
could enable it.  This seems to handle the case where the RADIUS
server requires location (e.g. won't grant access without it). 

Based on the rest of Section 8, it appears that there are other
scenarios in which the RADIUS server might like location information 
if available, but does not require it.   In these cases, the 
RADIUS server could send back an Access-Accept with a request for
location information, specifying what kind of location it is
asking for (NAS or peer). If the NAS does not understand
the attribute it will ignore it.

Overall, it is not clear to me why the Capability attribute is needed, or 
if so, what the goal is.  

Section 11

Why is a capability attribute needed in an Access-Challenge?  Why
is "Location-Info-Required" a new attribute rather than a value
of Error-Cause?  Why are Basic-Policy-Rules, Extended-Policy-Rules,
Capability and Location-Info-Required attributes allowed in an 
Access-Reject? 

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

---

From: "Avi Lior" <[email-masked]>
Date: Sat, 27 Aug 2005 01:26:00 -0400

Hi Bernard,

Please see inline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, August 26, 2005 8:43 PM
> To: [email-masked]; [email-masked]
> Subject: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt
> 
> In thinking about the problem of capabilities negotiation 
> within the RADIUS-GEOPRIV document, it is not clear to me 
> that it is necessary for a NAS to advertise location support. 
> 
> Instead, the NAS can be set by default not to send location 
> attributes unless the server asks for them.  The problem then 
> reduces to how the server communicates its needs to the NAS. 
> 
> There are several cases of interest: 
> 
> 1) The RADIUS server REQUIRES the NAS to provide location in 
> the Access-Request (e.g. it implements location-based access control).
> In this case the RADIUS server can send an Access-Reject with 
> an Error-Cause attribute with a value of "Location Required". 
> Alternatively if the authentication mechanism (e.g. EAP) 
> supports Access-Challenges, the RADIUS server can place a 
> "Send location" attribute in the Challenge.  On receiving 
> either of these indications, the NAS includes location 
> attributes in the Access-Request. 
> Note that the server's decision is not influenced by whether 
> the client has advertised location support, only by the 
> inclusion of location attributes in the Access-Request.

Access Reject case is grossly inefficient requiring the
re-authentication and is simply not acceptable in many deployement and
in particular in mobile deployements where authentication is resouce
intensive.

The Challenge Option is better but we will benefit in efficiency if the
home network knew whether or not the NAS supported the feature in the
first place.  After all, if you required location information, why would
you challenge a NAS that couldn't deliver the information?

> 2) The RADIUS server does not require location in the 
> Access-Request, but would like location attributes to be 
> included in Accounting packets, if available.  In this case, 
> the RADIUS server sends an Access-Accept including a "Send 
> location" attribute, perhaps specifying more details on how 
> location should be provided (e.g. Accounting-Stop only, 
> interim records, civil/geographic, etc.).

This would work but if the authentication is predicated on whether or
not I could have location in the accounting stream, then your scheme
would not work right?
 
> Since the RADIUS server does not require location attributes, 
> a legacy NAS can ignore the "send location" attribute with no 
> ill effects.  This is how legacy NAS implementations behave, 
> and the "Issues and Fixes" document indicates that this is in 
> fact the correct behavior.
> If the NAS does understand the "send location" attribute then 
> it will send location in the Accounting packets as requested.
> 
> Am I missing something, or is the problem really this simple? 

I think advertizement as described in the current Geopriv document is
well thoughtout.

I think the issue raised is whether or not to take care of it in the
End-to-End capability or in the document itself.

---

From: "Avi Lior" <[email-masked]>
Date: Sat, 27 Aug 2005 23:13:57 -0400

Hi Bernard,  

> Sent: Saturday, August 27, 2005 6:55 AM
> To: [email-masked]
> Cc: [email-masked]; Alan DeKok
> Subject: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt
> 
> > And blindly requesting for location information (as you 
> propose) I run 
> > the risk of having a rejection by getting to a NAS that does not 
> > support Challenge in the first place.
> 
> The only reason a RADIUS server will need to send an 
> Access-Challenge is if it *requires* location and it is not 
> present.  In that case, the RADIUS server cannot allow access 
> if location isn't provided.  

Not true at all!   A RADIUS server may require to get location but if it
does not that does not mean that its only action is to reject the
session.  It may still grant access but the access could be limited in
scope.

I can have a policy that states the service X may only provided at a
certain location.  I request for the location and if it is not provided
then I grant access but do not grant access to service X.

Blindly challenging the NAS -- requesting location without even knowing
whether the NAS even supports a challenge let alone location information
-- runs the risk of outright rejection of the session.

> If the RADIUS server doesn't require location, then it can 
> just request location in the Access-Accept.  If it gets it, 
> great.  If not, it is willing to live with out it. 

You mean for accounting purposes.  I am not even talking about that.
Above I am talking about needing location as part of the policy decision
function for granting access.
 
> In either case (mandatory or optional), capability 
> advertisement by the NAS is irrelevant. 

I disagree.  There is a distinct advantage of letting the RADIUS server
know whether or not the NAS supports a particular function.  Blindly
challenging should only be done in cases where the NAS does not support
a capability exchange mechanism.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Aug 2005 08:30:46 -0700 (PDT)

> A simple solution would be that a NAS that knows both the NAS and 
> user location always sends both (when sending location information).
> 
> (I don't think we need more fine-grained capability negotiation 
> for this.)

I agree that this would work and also agree that capability negotiation is 
not needed.  However, I thought that the idea was not to send any location 
data by default.