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

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Sep 2005 15:39:14 -0400

All,

I've asked Hannes to open an issue tracker for this document.

If you have a particular issue with this document, please summarize  
it and send it to the list so that he may enter it into the issue  
tracker.  When sending the issues, please send them in separate  
messages using subjects that denote the nature of the issue.

-andy

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

---

From: [email-masked]
Date: Tue, 30 Aug 2005 15:37:11 +0300

Bernard Aboba wrote:

> The "server-driven" approach also provides a mechanism to 
> address RADEXT Issue 27 (Who's Location). 
> 
> One of the major problems with the RADIUS-GEOPRIV document is that 
> it does not support user location determination, only  NAS location. 

Are you sure? The Location-Information attribute includes a field
called "Entity", described as follows

   Entity (8 bits):
     Describes which location this attribute refers to:
     (0) describes the location of the user's client device
     (1) describes the location of the AAA client

It looks like NAS could use this field to describe which location
it's sending, or send two Location-Information attributes if it 
knows both.

Best regards,
Pasi

---

From: [email-masked]
Date: Tue, 30 Aug 2005 16:47:06 +0300

Bernard Aboba wrote:

> But the NAS isn't sending location by default.  So how does 
> the RADIUS server that requires a given kind of location indicate 
> what it needs? Keep in mind that if the RADIUS server REQUIRES 
> location then it may need to send an Access-Reject. 

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

Best regards,
Pasi

---

From: [email-masked]
Date: Tue, 30 Aug 2005 16:55:51 +0300

John Schnizlein wrote:
> 
> The inclusion of the "entity" field reintroduces the problem
> we had with the initial draft, which is that no practical
> mechanism has been identified through which the NAS would know
> the location of the host attempting attachment.
> 
> Rather than prolong the illusion, it would be better to
> eliminate this field and let the location attribute refer to
> the location of the NAS.

This depends on what kind of NASes you're considering. In PSTN
dial-up, determining the host location probably isn't feasible,
but there certainly are practical mechanisms for e.g. GSM/GPRS
and IEEE 802.11 networks. Although they're not necessarily that 
widely used, I would not call them an "illusion"...

Best regards,
Pasi

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 30 Aug 2005 10:10:40 -0400

Pasi Eronen writes...

> This depends on what kind of NASes you're considering. In 
> PSTN dial-up, determining the host location probably isn't 
> feasible ...

It's probably more accurate to say that in PSTN dial-up it isn't always
possible to determine the host location accurately.   Technologies such
as ANI or Caller-ID provide that information.  For the traditional
land-line subscriber loop, it is very likely that the host is located
within the premises served by the subscriber loop.  This is almost
always the case with residential customers.  It will more often not be
the case with commercial customers, who may have centralized outgoing
trunk lines that can be accessed from a variety of locations.

---

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

hi bernard, 

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

location is not sent by default. 

the aspect is similar to the civic vs. geospatial discussion. you could
send both, if you have it. sometimes you just don't have civic and
geospatial location information (depending on the deployment). 

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 4 Sep 2005 16:26:20 +0200

hi bernard, 

i went through your suggestions and i don't think i have a disagreement
with what you say. 

ciao
hannes

> > 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. 
> > sounds good to me. 
> 
> 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.  
> 
> > i hope it is simple. 
> 
> From the RADEXT WG discussion so far, it does appear to be 
> quite simple.  
>