Subject: RE: [dhcwg] Geographic position option

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 16 Aug 2002 08:13:38 -0700

Just as a thought.  Any reason why you picked a GPS-based format instead of
perhaps the DNS format for geographical location?  (RFC 1712)  I was
originally going to suggest that the device simply ask the DNS for this
information, but the device may want to use this information in selecting
which Offer to accept, and as a result has no IP yet so cannot ask the DNS
(yet).

> -----Original Message-----
> From: Sam Critchley [mailto:[email-masked]]
> Sent: Friday, August 16, 2002 7:52 AM
> To: [email-masked]
> Subject: [dhcwg] Geographic position option
> 
> 
> 
> Hi,
> 
> Included below is a draft proposing an option to allow a DHCP 
> server to
> pass its geographic location to a DHCP client.
> 
> From RFC 2489:
> 
> "Preferably, the author will submit the Internet Draft to the 
> DHC Working
> Group,..."
> 
> and
> 
> "The specification is reviewed by the DHC WG (if it exists) or by the
> IETF."
> 
> So, I'd be interested in people's comments on this document. 
> What should I
> do with the document now?
> 
> Many thanks,
> 
> 
> Sam
> 
> 
> Here is the draft:
> 
> **************************************************************
> **********
> 
> Network Working Group                                      
> Sam Critchley
> Internet Draft                                             
> Worldcom, Inc
> 
>                                                             
> August, 2002
>                                                    Expires 
> January, 2003
> 
> 
> 	     The Geographic Position Option for DHCP
>            <draft-critchley-dhc-location-option-00.txt>
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is subject to all provisions
>    of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six
>    months and may be updated, replaced, or obsoleted by other
>    documents at any time.  It is inappropriate to use Internet-
>    Drafts as reference material or to cite them other than as
>    "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/1id-abstracts.html
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
> 
> Abstract
> 
>    This document describes a DHCP option in which the geographic
>    position of the DHCP server is passed to the DHCP client in order
>    to allow the client to make use of Location-Based Services.
> 
> 1. 	Introduction
> 
>    Mobile telephony networks are able to make use of certain
>    technologies which supply the geographic location of a mobile
>    suscriber's handset to a Location-Based Services (LBS) 
> provider. The
>    mobile subscriber is then able to take advantage of such services
>    as point-of-interest (POI) location, mapping, route-determination,
>    traffic services and location-aware mobile instant messaging.
> 
>    There is currently no standardised mechanism in place to supply
>    a geographic location to Internet hosts not connected to mobile
>    telephony network, including, but not limited to, hosts connecting
>    using IEEE 802.11x wireless protocols, and those connected to
>    wire-based networks but configured with non-static IP addresses.
>    Consequently, these hosts are more limited in their ability to
>    take advantage of LBS, including having to manually enter a
>    geographic position or street address in many cases.
> 
>    This document defines a DHCP option by which a DHCP server can pass
>    its geographical location, in the form of a latitude, longitude and
>    altitude position, to its clients.
> 
>    This document does not seek to define a method to allow a host to
>    pass its location to a LBS server, as there are already in place
>    several standards which propose these mechanisms, such as 
> the Mobile
>    Location Protocol (MLP) developed by the Location Interoperability
>    Forum (LIF), although it does make one security recommendation in
>    this area.
> 
>    Furthermore, this document does not attempt to propose a mechanism
>    which would perform in the same manner as critical 
> emergency location
>    services such as the Enhanced 911 (E-911) service being implemented
>    in US mobile telephony networks, nor does it propose a mechanism
>    to be used for highly accurate positioning applications, 
> such as that   provided by the Global Positioning System (GPS).
> 
>    However, the Geographic Position Option for DHCP does propose a
>    mechanism which, in many cases, will provide a position to the same
>    degree of accuracy as that provided by mobile telephony networks'
>    geographic location mechanisms.
> 
> 2. 	The Geographic Position Option for DHCP
> 
> 2.1	DHCP Option field definitions.
> 
>    This option contains the following fields:
> 
>    a) Option Code - TBD
>    b) Option length in bytes
>    c) DHCP Server Geographic Position Sentence
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Code = TBD  |    Length     |  Geographic Position Sentence |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 Geographic Position Sentence                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            . . . .                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            . . . .                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 2.2 	DHCP Server Geographic Position Sentence
> 
>    The DHCP Server Geographic Position Sentence takes the form of a
>    comma-separated ASCII string of position terms. This is in 
> some ways
>    similar to the format used in the National Marine Electronics
>    Association's NMEA 0183 and NMEA 2000 standards, commonly used by
>    GPS navigation devices for passing location information to other
>    devices.
> 
>    The sentence takes the following form:
> 
>    DHCPPS,A,B,C,D,E,F,G,H,I,J,K
> 
>    Where the following are field definitions:
> 
>    - DHCPPS - DHCP Position Sentence. Indicates to the DHCP 
> client that
>    this is a sentence designed to provide the geographic position of
>    the DHCP server to the DHCP client, as opposed to any other
>    information.
> 
>    - A - Latitude. Expressed in decimal degrees, to a maximum of 6
>    decimal places.
> 
>    - B - Latitude N/S. Whether the latitude figure expressed 
> is North or
>    South of the equator, expressed simply as the letter "N" or the
>    letter "S" in upper case.
> 
>    - C - Longitude. Expressed in decimal degrees, to a maximum of 6
>    decimal places.
> 
>    - D - Longitude E/W. Whether the longitude figure expressed is East
>    or West of the Greenwhich Meridian, expressed simply as the letter
>    "E" or the letter "W" in upper case.
> 
>    - E - Altitude. The altitude, expressed to a maximum of 2 decimal
>    places, and preceded with a "+" or a "-" symbol to indicate whether
>    the value is above mean sea level (positive) or below mean 
> sea level
>    (negative).
> 
>    - F - Altitude unit. The upper-case letter "M" to indicate that the
>    unit is in Metres, or the upper-case letters "FT" to indicate that
>    the unit is in feet.
> 
>    - G - Horizontal Accuracy. The horizontal accuracy of the latitude
>    and longitude position obtained by the DHCP client from the DHCP
>    server. Intended to represent the maximum horizontal distance that
>    a DHCP client will be from its DHCP server, and useful, 
> for example,
>    in the case of DHCP scenarios such as IEEE 802.11b setups using
>    bridging, and where the DHCP client can expect to be some distance
>    from the DHCP server. Figure given to a maximum of three decimal
>    places.
> 
>    - H - Horizontal Accuracy unit. The upper-case letter "M" 
> to indicate
>    that the unit is in metres, the upper-case letters "KM" to indicate
>    that the unit is in kilometres, the upper-case letters "FT" to
>    indicate that the unit is in feet, or the upper-case 
> letters "ML" to
>    indicate that the unit is in miles.
> 
>    - I - Vertical Accuracy. The vertical accuracy of the Altitude
>    position obtained by the DHCP client from the DHCP server. Intended
>    to represent the maximum vertical distance that a DHCP 
> client will be
>    located from its DHCP server, and useful, for example, in the case
>    of network segments located in tall buildings.
> 
>    - J - Vertical Accuracy unit. The upper-case letter "M" to indicate
>    that the unit is in metres, the upper-case letters "KM" to indicate
>    that the unit is in kilometres, the upper-case letters "FT" to
>    indicate that the unit is in feet, or the upper-case 
> letters "ML" to
>    indicate that the unit is in miles.
> 
>    - K - Geodesic Datum. The standard abbreviated form of the geodesic
>    datum used to calculate position. This term has a default value of
>    "WGS84" should no datum be specified.
> 
>    The DHCP Server Geographic Position Sentence would normally have a
>    maximum length of between 49 and 64 bytes, depending on the values
>    used.
> 
>    Apart from the first term of the DHCP Server Geographic Position
>    Sentence, which always must have a value of "DHCPPS", and must be
>    present, the presence of a value in all other fields is optional.
>    However, all fields, whether a value is present or not, must be
>    comma-separated. Furthermore, it is understood that a DHCPPS
>    containing few or no values might be of little use in determining
>    the position of the DHCP client.
> 
> 
> 2.2.1 	Example of a DHCP Server Geographic Position Sentence
> 
>    DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84
> 
>    This sentence indicates that the DHCP server is located at 52.3742
>    degrees North, 4.8925 degrees East, at 3.12 metres above mean sea
>    level, that the DHCP client is a maximum of 50.9 metres 
> horizontally
>    from the DHCP server, a maximum of 5 metres altitude above or below
>    the DHCP server, and that the datum used to calculate this position
>    was WGS-84.
> 
> 2.3	Security Concerns
> 
>    Whilst this document does not seek to define a method to allow a
>    host to pass its location to a LBS server, it does note that
>    there are possible security concerns involved in the location of
>    an Internet host being passed to an LBS server. In the 
> case of mobile
>    telephony networks, most subscriber locations are passed to an LBS
>    server from a mobile provider's location server, not directly from
>    the mobile handset, and the list of permitted LBS servers 
> is strictly
>    controlled. However, in the case of a Geographic Position 
> option for
>    DHCP, this security infrastructure may not be in place, and it is
>    therefore recommended that any client application supplying a
>    DHCP-acquired position to an LBS server should implement 
> an adequate
>    security mechanism to protect users from any possible wrongdoing.
>    Such mechanisms might include implementing a list of permitted LBS
>    servers, popup alerts when passing a host's location to an LBS
>    server, or the ability to turn on/off the passing of location
>    information.
> 
> 
> 3.	Author's Address
> 
>    Sam Critchley
>    Worldcom EMEA Network Service
>    Joan Muyskenweg 22
>    1096 CJ Amsterdam
>    The Netherlands
> 
>    Phone: +31 20 711 6082
>    Email: [email-masked]
> 
> **************************************************************
> *************
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Sam Critchley <[email-masked]>
Date: Fri, 16 Aug 2002 17:58:40 +0200 (MET DST)

Hi Andre,

Thanks also for your reply and comment.

There were immediately a couple of main reasons why RFC1712 wasn't used
for this:

1. If the host is on a closed network or the resolver isn't available,
then a host can't get its location easily.

2. If the DNS server is not administered by the organisation/person
running the DHCP server (for example in the case a small 802.11 AP with
roaming users), then there may be procedural issues with getting updates
done etc - whilst it's very easy, for example, for an AP administrator to
input a latitude, longitude and approximate altitude into the
configuration interface of an AP or another machine running the DHCP
server.

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.

4. All DNS servers/resolvers need to be equipped to use this system.

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?

Thanks,

Sam

> > do with the document now?

******************************************************
Sam Critchley           Technology Integration Manager
                        Network Services EMEA
[email-masked]  Worldcom
                       	Joan Muyskenweg 22
Tel: +31 20 711 6082    1096 CJ Amsterdam
                        The Netherlands
******************************************************

---

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 16 Aug 2002 09:11:25 -0700

Inline....

> There were immediately a couple of main reasons why RFC1712 

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

> configuration interface of an AP or another machine running the DHCP

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.

> easily allow users to choose which LBS servers are given 

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

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

> use the information in deciding which Offer to accept 

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.

---

From: Sam Critchley <[email-masked]>
Date: Mon, 19 Aug 2002 12:20:27 +0200 (MET DST)

Hi Andre,

> Inline....

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

> 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]
> of the server?  Presumably that wouldn't be changing very often, so it's

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.

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

> Uh, it's just one resource record in the DNS?  Most existing DNSes can

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.

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