RE: [dhcwg] Geographic position option

Sam Critchley <Sam.Critchley@wcom.com> Mon, 19 August 2002 10:23 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27069 for <dhcwg-archive@odin.ietf.org>; Mon, 19 Aug 2002 06:23:17 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10620 for dhcwg-archive@odin.ietf.org; Mon, 19 Aug 2002 06:24:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10469; Mon, 19 Aug 2002 06:20:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10443 for <dhcwg@optimus.ietf.org>; Mon, 19 Aug 2002 06:20:49 -0400 (EDT)
Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27014 for <dhcwg@ietf.org>; Mon, 19 Aug 2002 06:19:26 -0400 (EDT)
Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQncon27627; Mon, 19 Aug 2002 10:20:44 GMT
Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncon09953; Mon, 19 Aug 2002 10:20:27 GMT
Received: from anocserve1.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: anocserve1.ams.ops.eu.uu.net [146.188.99.69]) id QQncon09949; Mon, 19 Aug 2002 10:20:27 GMT
Date: Mon, 19 Aug 2002 12:20:27 +0200
From: Sam Critchley <Sam.Critchley@wcom.com>
X-X-Sender: <samc@anocserve1.ams.ops.eu.uu.net>
To: "Kostur, Andre" <Andre@incognito.com>
cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Geographic position option
In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A671D6@homer.incognito.com>
Message-ID: <Pine.SOL.4.33.0208191137100.3159-100000@anocserve1.ams.ops.eu.uu.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org


Hi Andre,

On Fri, 16 Aug 2002, Kostur, Andre wrote:

> Inline....

Same for me. More important stuff towards the bottom....

> Note that I was referring the RFC1712's format for supplying the
> information, not necessarily using 1712 to obtain the actual location.  But
> if the client won't be using this information until after it has bound to an
> address, it would make much more sense to me if the client _did_ use 1712 to
> find out the server's location.
>
> > 1. If the host is on a closed network or the resolver isn't available,
> > then a host can't get its location easily.
>
> Presumably if the host can reach a DHCP server, it should be able to reach a
> DNS too.  BTW: are we talking about the client obtaining it's _own_
> location?  Or the location of the DHCP server?

Well, what I was proposing was that the client find out the location of
the DHCP server. With a DNS-based system it indeed be possible to be more
precise, although this would not work in the case of wirelessly connected
hosts, where you would again have to rely on the location of some fixed
device nearby.

[snip]
> Um, wasn't this an option to inform the client of the geographical position
> of the server?  Presumably that wouldn't be changing very often, so it's
> only 1 DNS update.

True, although someone running, for example, a mom-and-pop (if that term's
acceptable) internet cafe with an 802.11b AP might not be able to do that
without some confusion, whereas if the initial configuration screen of the
AP allowed them to fill in their latitude/longitude etc, it might be more
likely to get done. Another point here is that using DNS in these cases
does put extra overhead on the upstream ISP... and they might not be
geared up to make these changes.

> > 3. There are security concerns with allowing those with access to the
> > global DNS system (every Internet host) to see the geographic
> > location of
> > all hosts. Granted, you can set up access-lists to restrict
> > who views the
> > information, but this can be complicated and for a client
> > host to set up
> > the LBS server's permissions to obtain the client's position
> > through DNS
> > using this method wouldn't be so practicable. A DHCP-based
> > system should
> > easily allow users to choose which LBS servers are given
> > their location.
>
> You can also use private DNSes to supply that information (ie: a DNS only
> reachable by clients which have obtained an address by your DHCP server).

Ah, that's a possibility, I see. You mean that, instead of the LBS server
looking up the GPOS of the host, the host looks up its own GPOS using a
private DNS setup, then supplies it to the LBS server if it wants to?

In the case of APs running in small cafes etc, this requires either a
local resolver/server, or quite a lot of ISP overhead to administer. If
your customers are roamers whose subscriptions are from companies like
Boingo, iPass, Megabeam etc, then they will expect the system to work the
same in every place. Given that the underlying ISPs in each place are
different, then this may not be so easy to administer, although no doubt
there are ways to improve its efficiency.

Another point worth considering is that many 802.11b APs are connected
with, for example, DSL or cable connections where a single IP address is
assigned by the DSL or cable modem provider using DHCP. This IP address
sometimes remains the same for long periods of time, but in many cases you
can't guarantee the same address if, for example, you reboot the AP. The
AP then uses NAT (and assigns RFC1918 addresses) for its hosts locally. In
this case, you'd have to have a clever ISP-based DNS setup to change the
GPOS records in individual zones each time DHCP renewed.

Do we have anyone from an 802.11b provider or AP vendor reading this mail?
If so, I think it would be interesting to hear your comments...

I think that, for Location-Based Service, perhaps the most vital go/no-go
criterion is whether you can provide adequate security for the end user. I
definitely do not want anyone with access to global DNS to be able to find
out precisely where I am (and I don't think anyone would want this), but I
do want to be click "Yes" or "No" on a popup box that asks the question
"Do you want to give this server your location?". I believe that a
private DNS system could provide that, but that it would be easier and
more likely to happen if it were done in DHCP.

>
> > 4. All DNS servers/resolvers need to be equipped to use this system.
>
> Uh, it's just one resource record in the DNS?  Most existing DNSes can
> support this now....

Okay, I think I didn't quite phrase that one right... plus I probably
wasn't quite thinking about it straight... presumably you'd first perform
a reverse lookup on the IP address, then a forward lookup on the hostname
to get the GPOS record. As I think you imply, only the immediate zone
would need to hold this record.

> > I'm not sure I can imagine a scenario where the DHCP client
> > might want to
> > use the information in deciding which Offer to accept
> > though.... can you
> > elaborate?
>
> I was thinking mostly theoretically where a client device which knows it's
> own location (through some other means) may wish to use the location
> parameter to choose the physically closest server.  Or perhaps only servers
> within a certain geographical area.  Although I don't see a whole lot of
> practical use for this.  It would be lousy "security" to use geographical
> location (which can be spoofed by servers).  You might as well use RFC 3118.

Ah, this is quite interesting, although I agree that I don't see a whole
lot of practical use for it.

Thanks,


Sam


PS BTW, what should I do with the draft document? Do I submit it as an
individual contribution and say "please notify the DHC WG"?



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg