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

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sat, 3 Sep 2005 21:36:11 +0200

hi bernard, 

thanks for summarizing the potential options regarding this particular issue. 

please find my feedback inline: 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Samstag, 27. August 2005 02:43
> An: [email-masked]; [email-masked]
> Betreff: 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. 

the problem was the following. the nas might support 
- civic location
- geospatial location
- both 
(or nothing) 

the radius server might also understand either civic, geospatial or both. 
when we tried to mandate civic location as the default that has to be understood i was told that this is not possible in all environments. geospatial is not possible as a default either. 

now, the idea was include something in the first exchange from the nas to the aaa server to allow the aaa server to determine whether he actually understands the format that can be provided by the nas. 

whether the desire to support this functionality justifies the introduction of an avp is subject for discussion. 
based on the feedback from the current mailing list thread at least you do not seem to be in favor of it. 

> 
> 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".

from previous discussions i remember that this was not the best approach particularly if many radius server want to obtain location information from the nas. 
 
> Alternatively if the authentication mechanism (e.g. EAP) supports 
> Access-Challenges, the RADIUS server can place a "Send 
> location" attribute in the Challenge.

this was the approach that was suggested to us in previous discussions. 
sounds good to me. 

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

i guess you would suggest to return an access reject if the the nas is unable to understand the returned location information format. 

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

sounds good to me. 

> perhaps specifying 
> more details on
> how location should be provided (e.g. Accounting-Stop only, interim
> records, civil/geographic, etc.).

this requirement hasn't be presented to me yet. 

> 
> 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 hope it is simple. 

ciao
hannes

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 3 Sep 2005 22:13:57 -0700 (PDT)

> The radius server might also understand either civic, geospatial or  both. 

We need to distinguish between the RADIUS Accounting Server and the RADIUS 
Authentication Server.  The RADIUS Accounting Server can be assumed to 
"understand" anything (e.g. it just writes AVPs to stable storage).  The 
RADIUS Server should be thought of as either REQUIRING or NOT REQUIRING an 
attribute.  If an attribute is REQUIRED the RADIUS Server will request it 
in an Access-Challenge.  

> whether the desire to support this functionality justifies the introduction of an avp is subject for discussion. 

I think there is a need for an attribute to be sent from the RADIUS Server 
to the NAS to describe what it wants (e.g. Geospatial, Civil), what 
location is to be sent (user or NAS)),  and how it 
wants it.  Presumably this attribute can be sent in an Access-Challenge. 

There is also a need for location attributes, to be sent from the NAS to 
the RADIUS server. 

However, I don't see a need for "Capabilities Announcement" by the NAS. 

> this was the approach that was suggested to us in previous discussions. 

The Access-Challenge approach is ok only if it is made clear that a NAS 
that is not expecting an Access-Challenge MUST treat it as a Reject, as 
mandated in RFC 2865.  And of course, a RADIUS Server MAY send a Reject if 
the Challenge isn't answered correctly, so you need to support that case 
or the NAS/RADIUS server exchange could go on indefinitely. 

> i guess you would suggest to return an access reject if the nas is 
> unable to understand the returned location information format. 

The NAS can't send an Access-Reject.  It can only treat the Challenge as 
an Access-Reject. 

> this requirement hasn't been presented to me yet. 

Given that it's the RADIUS server that is determining what is needed, 
there needs to be a way for the server to actually request what it needs.  A 
given RADIUS server may require user location (there are installations 
today that do locatoin-based authorization) in geospatial or civil format. 
Or it just may need NAS location.  

>From the RADEXT WG discussion so far, it does appear to be quite simple.