Subject: [Geopriv] draft-jones-radius-geopriv

From: John Schnizlein <[email-masked]>
Date: Tue, 10 Feb 2004 13:12:11 -0500

Including the GeoPriv WG..

One concern, if this location configuration information (LCI) 
is to be carried over RADIUS, is that the example in section 6 
seems to be 993 characters long. This one attribute seems to be 
taking a large share of the maximum RADIUS packet size of 4096.
[RFC 2865, p 15] Is there enough room for everything else that
would be expected with this attribute?

John

At 12:05 PM 2/10/2004, Hannes Tschofenig wrote:

>you can find the geogriv/radius draft at: 
>http://www.tschofenig.priv.at/drafts/draft-jones-radius-geopriv-00.html
>http://www.tschofenig.priv.at/drafts/draft-jones-radius-geopriv-00.txt
>
>the draft tries awareness for privacy and reuses results of the geopriv
>working group. 

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Feb 2004 11:06:13 -0800 (PST)

> would be expected with this attribute?

I'm curious as to the contrast in approach taken by this draft versus the
DHCP option.  Given the recent activity on encapsulation of RADIUS
attributes in DHCP, isn't it important for the DHCP option and the RADIUS
attribute to take similar approaches?

For example, if the goal is to make both the client and RADIUS server
aware of their location, then the NAS might pass a location attribute to
the RADIUS server, as well as passing this to the DHCP server in a relay
option.  Encoding the information two very different ways seems like it
results in unnecessary overhead.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Feb 2004 11:28:42 -0800 (PST)

> would be expected with this attribute?

Even if a RADIUS packet can be up to 4096 octets in length, it's still not
a good idea to cause fragmentation if it can be avoided.

---

From: John Schnizlein <[email-masked]>
Date: Tue, 10 Feb 2004 14:49:10 -0500

Comments embedded in context:

At 02:06 PM 2/10/2004, Bernard Aboba wrote:

>I'm curious as to the contrast in approach taken by this draft 
>versus the DHCP option.  Given the recent activity on encapsulation 
>of RADIUS attributes in DHCP, isn't it important for the DHCP 
>option and the RADIUS attribute to take similar approaches?

I would be surprised to see anyone determine the host's location
through the RADIUS server, and pass that location through the 
relay-agent sub-option to the DHCP server, in order for the DHCP 
server to configure it at the host. However, similar approaches 
to encoding the information would match the similar constraints
that both DHCP and RADIUS are carried in a single UDP datagram.

>For example, if the goal is to make both the client and RADIUS 
>server aware of their location, then the NAS might pass a location 
>attribute to the RADIUS server, as well as passing this to the 
>DHCP server in a relay option.  Encoding the information two very 
>different ways seems like it results in unnecessary overhead.

A summary of the various intersections might be useful here:
(for others - I know Bernard knows this background)

draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a 
DHCP server to give a host the host's location, using (circuit-ID)
information from the relay-agent and knowledge of the wiring plant.

draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP
relay agent to relay RADIUS information to the DHCP server for its
use in allocating configuration options.

draft-jones-radius-geopriv specifies a way for a NAS to tell a 
RADIUS server the location of the NAS. The location of the NAS could
be manually configured either in the NAS or in the RADIUS server
with which it shares a secret. The radius-geopriv attribute might
be added to the RADIUS attributes that are forwarded to a different
(home) RADIUS server (in the global roaming situation).
(If this summary is incorrect, please clarify.)

Before combining these ideas in a creative way, one would need to
have a clear understanding of whose location information is needed
where, and which provider of the information has the best access to it.
Since this analysis is already too difficult for some of us to want
to attempt, making it worse with different information formats seems
like over-kill.

John

---

From: John Schnizlein <[email-masked]>
Date: Sun, 15 Feb 2004 19:53:25 -0500

I am sorry I quoted the wrong part of RFC 2865.
The length of an attribute is at most 255, one octet [page 25].
It seems unlikely that GML, or any XML, would be efficient 
enough to be carried in a RADIUS attribute.