Subject: [Geopriv] Introduction

From: Stefan Winter <[email-masked]>
Date: Thu, 3 Feb 2005 10:48:35 +0100

Hello,

my name is Stefan Winter. I work for the Luxembourg national research and 
education network and am involved in several projects around the RADIUS 
protocol, the most important being the development of a world-scale roaming 
hierarchy for scientific users in the research network GÉANT.
As such I am very interested in the transport and use of location information 
over the RADIUS protocol (and later maybe even over Diameter).
I have read the current draft "Carrying Location Objects in RADIUS" and would 
like to actively participate in the further development of this early draft 
(pending clearance from my employer).
So, I'd like to hear if there is need for and interest in my participation 
here. I have some very limited experience with IETF working groups as I was 
marginally involved in the MPLS working group when I was writing my thesis a 
year ago. I use RADIUS servers on an almost daily basis, momentarily 
FreeRADIUS (which would probably make a good candidate for a prototype 
implementation that is needed if the above draft should be levered to draft 
standard some time in the future).

Greetings,

Stefan Winter

-- 
Stefan WINTER

RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Network and Systems Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: [email-masked]     Tel.:      +352 424409-33
http://www.restena.lu                     Fax:      +352 422473

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 3 Feb 2005 09:15:33 -0500

On Feb 3, 2005, at 4:48 AM, Stefan Winter wrote:

> here.

Welcome.
Document review is something we always need.  If you find errors or 
issues with the GEOPRIV RADIUS document, please bring it to our 
attention.

-andy

---

From: Stefan Winter <[email-masked]>
Date: Thu, 3 Feb 2005 15:22:09 +0100

Hello!

> Welcome.

Thank you :-)

> issues with the GEOPRIV RADIUS document, please bring it to our

I just summarised my thoughts about the doc to the authors of the current 
draft in a private mail. Of course I can copy&paste them here again (Sorry, 
Hannes et al., for sending this twice):

One point is that the content that is to be transferred is encoded in a single 
attribute, Location-Information. This implies that a possible implementation 
would need to write its own parser just to get to the content (and, given 
that most fields of the geospatial Location-Info part are far from being 
32-bit aligned, this would be an errorprone job to do). That is not the way 
RADIUS usually works. You mostly often only put a single piece of information 
into a single attribute, so that the general RADIUS packet parser can easily 
decode the content you want. This would imply that either IANA has to assign 
more attribute values (no idea how generous they are in issuing these) or that 
a different solution had to be employed: VSAs. This wouldn't be exactly 
clean, but RADIUS servers are very well prepared to handle VSAs if you just 
give them a dictionary file. You also shouldn't forget that NAS equipment 
should be able to send the location information, and these are usually very 
hard to modify.
Another thing is the handling of user privacy. The Basic-Policy-Rules 
attribute is very limited. You can only make a binary decision to allow or 
deny the transfer of the location information. A more fine-grained control 
(like: only allow Country and City to be transported after the first hop) 
would be a nice addition. Plus, giving a URL reference to a policy is not 
very practical IMO. You certainly don't expect a human being to inspect each 
arriving packet to get to know its policy. My suggestion for this attribute 
is that instead of a "Note Well", a bit field is introduced where each bit 
represents a permission flag which type of information may be transferred. (I 
am aware of the reference to a richer ruleset in Extended-Policy-Attribute, 
but the need to first fetch the info via a TLS connection and evaluating a 
ruleset document and then modifying the RADIUS packet makes an efficient 
parsing and proxying of packets almost impossible). The "Note Well" could 
still survive, but I'd move it into the Extended-Policy-Attribute.

Greetings,

Stefan Winter

-- 
Stefan WINTER