Subject: RE: [Geopriv] HELD concerns (was: IETF 63 GEOPRIV Session Minutes)

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 11 Sep 2005 19:36:55 -0500

Hi John,

Thanks for summarizing your concerns so concisely and giving me an opportunity to address them.

> (a) reliance on "the" access network fails because there are often 
> multiple ones - a tunnel for example

(a) Reliance on the concept of "the" access network might seem like a simplistic approach when you consider how complex access networks can become, but it is a valuable simplification that enables us to focus on the real problems.

There are a few places where multiple access networks appear:
 
  - An enterprise network, which subsequently connects to the network via an ISP.  In this case, the first access network is the enterprise network, which should be able to provide location information.  The second access network (the ISP), might be able to do the same at a different level of granularity.  The new version of HELD includes an example to this effect.

  - An access network might be made of multiple portions, each owned and operated by different entities.  In this case, it isn't really multiple access networks.  For example, a DSL network might have a loop provider (layer 1 provider), a DSLAM owner (layer 2 provider) and an ISP (layer 3 provider).  This gets complicated further with regional broadband providers and other entities that own the intermediate networks that data may traverse.  In this sort of scenario, the customer buys a service from ONE business (typically the ISP), who then becomes responsible for providing the location service.
      The ISP in this scenario is "the" access network provider.  The responsibility is on the ISP to negotiate with each of the other business entities for those parts of the location service that are required.  These sorts of arrangements are already needed to provide connectivity; this only adds an extra aspect to those agreements.

  - The VPN discussion currently rages (again) on the ECRIT list.  To summarize my view: it is not unreasonable to require that tunnels are not used for the purposes of acquiring location information.  The physical access network is where location information comes from.

> (b) discovery using DNS unnecessarily relies on DHCP, then on a record not
> intended for the public use of DNS,

(b) Your concern with our DNS discovery mechanism is that it requires two pieces of information in order to operate.  Those are the address of the DNS server and the domain suffix (or a list thereof).  I will address your concerns about the validity of the suffix in part c), but there are two factors that you may not have considered:

   - DHCP is not the only means of discovering these data.  I can think of a few off the top of my head: PPP, multicast DNS (Bonjour), and static configuration.

  - Using DNS in the manner described means that intermediary nodes do not need to be modified; indeed, the DNS server only needs to have an extra record added.  The only dependency is then on the requesting entity.

DNS has other advantages, such as making the address of the location server that serves a particular network known.  This expands the potential use of the "on behalf of" facility.

> (c) reliance on the domain returned by DHCP does not work either: e.g. the
> domain for the host in my hand is not here in France where the access is 

(c) I presume that you were talking about the fact that you were given an IP address with the domain "some-host.ietf.org".  This is a clear example of the case where the access provider needs to understand their network.  In this case, the host returned by the DNS query _locserv+http._tcp.ietf.org needs to have knowledge about the network that it serves.  If that network includes disparate locations (Rockville, Paris, Vancouver, wherever) and the domain suffixes are not unique for those locations, then that server will need to have access to information for each of those locations.

This is a good example of where the need to provide location information may actually affect network deployment.  In this case, a simple change to network configuration might make the entire scenario easier: make the domain name "some-host.ietf63.ietf.org". 

> (d) the feasibility of generating a location from just an IP address is
> not clear.

(d) If you read section 1, you will note that HELD describes an acquisition protocol, it purposefully does not discuss how location is determined.

There is, however, an expectation that a location server has access to sufficient information about a network to determine location from IP address.  This might be as simple as being able to query a DHCP server for the information that it includes.  Like I have said before, location determination varies greatly depending on circumstance; if you like, describe a specific example and we can explore solutions for that situation.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Schnizlein
Sent: Saturday, 10 September 2005 6:47 AM
To: Andrew Newton
Cc: GEOPRIV WG
Subject: Re: [Geopriv] IETF 63 GEOPRIV Session Minutes

I would prefer clarification of the points I made on HELD (item 5), 
replacing what you have:

John Schnizlein raised concerns regarding using DNS and DHCP to find 
HELD servers, and specifically noted that the use of DNS in the 
discovery mechanism of HELD does not match the normal uses of DNS.  He 
also noted that there are often disconnects between information given 
out by DHCP and the domains used in DNS configuration of mobile 
devices.  John also identified the issue that determining a location 
based on IP addresses may not be feasible.

with this:

  4 concerns: (a) reliance on "the" access network fails because there 
are often multiple ones - a tunnel for example (b) discovery using DNS 
unnecessarily relies on DHCP, then on a record not intended for the 
public use of DNS, (c) reliance on the domain returned by DHCP does not 
work either: e.g. the domain for the host in my hand is not here in 
France where the access is, and (d) the feasibility of generating a 
location from just an IP address is not clear.
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: John Schnizlein <[email-masked]>
Date: Mon, 12 Sep 2005 10:06:50 -0400

On Sep 11, 2005, at 8:36 PM, Thomson, Martin wrote:
> (a) Reliance on the concept of "the" access network might seem like a 
> simplistic approach when you consider how complex access networks can 
> become, but it is a valuable simplification that enables us to focus 
> on the real problems.

The point I was trying to make is that the simplification you propose 
creates real problems, and there are already enough.  The 
(counterfactual) assumption of a single access network makes the 
problem more complex.

>   - An enterprise network, which subsequently connects to the network 
> via an ISP.  In this case, the first access network is the enterprise 
> network, which should be able to provide location information.  The 
> second access network (the ISP), might be able to do the same at a 
> different level of granularity.  The new version of HELD includes an 
> example to this effect.

Many enterprises attach to the Internet through multiple ISPs and in 
multiple locations (for good reasons).  While the locations of hosts 
within the enterprise might be known to the enterprise network 
operators, they might have valid reason not to operate the sort of LIS 
proposed for HELD.  Note that some enterprises provide only a central 
telephone number for caller-ID.

>   - An access network might be made of multiple portions, each owned 
> and operated by different entities.  In this case, it isn't really 
> multiple access networks.  For example, a DSL network might have a 
> loop provider (layer 1 provider), a DSLAM owner (layer 2 provider) and 
> an ISP (layer 3 provider).  This gets complicated further with 
> regional broadband providers and other entities that own the 
> intermediate networks that data may traverse.  In this sort of 
> scenario, the customer buys a service from ONE business (typically the 
> ISP), who then becomes responsible for providing the location service.
>       The ISP in this scenario is "the" access network provider.  The 
> responsibility is on the ISP to negotiate with each of the other 
> business entities for those parts of the location service that are 
> required.  These sorts of arrangements are already needed to provide 
> connectivity; this only adds an extra aspect to those agreements.

A design that depends on the existence of a variety of business 
relationships to be reflected in information exchange is probably not 
deployable.  A better design would identify the smallest set of 
necessary information holders and protocol mechanisms for the simplest 
transfer from the source of the information to the recipient.

The ISP that operates a DNS server might not operate the local loop 
that provides location information.  The design of protocols for 
GeoPriv should not demand transfer of information between these 
different operators unless no alternative is possible.

I think we agree that the party that has location information is the 
one that operates the link closest to the host.  A mandate that this 
information be made available to the emergency call's source and/or 
destination seems to be the minimal intrusion.

>   - The VPN discussion currently rages (again) on the ECRIT list.  To 
> summarize my view: it is not unreasonable to require that tunnels are 
> not used for the purposes of acquiring location information.  The 
> physical access network is where location information comes from.

We simply disagree that valid reasons for tunnels can be set aside in 
the pursuit of a particular GeoPriv solution.

>> (b) discovery using DNS unnecessarily relies on DHCP, then on a 
>> record not intended for the public use of DNS,
>
> (b) Your concern with our DNS discovery mechanism is that it requires 
> two pieces of information in order to operate.  Those are the address 
> of the DNS server and the domain suffix (or a list thereof).  I will 
> address your concerns about the validity of the suffix in part c), but 
> there are two factors that you may not have considered:

My point about the proposal involving both DNS and DHCP is that there 
is no need for the DHCP server to provide a local DNS server, with 
another lookup in the DNS for information that is intended to be useful 
only for the local client.  If you want the answer from DHCP to provide 
the LIS information, just send it through DHCP.  Chaining through two 
services is unnecessary.  In fact, why not provide the useful 
information - the location - rather than a pointer to a LIS for 
location information?

>    - DHCP is not the only means of discovering these data.  I can 
> think of a few off the top of my head: PPP, multicast DNS (Bonjour), 
> and static configuration.

Yes, it would be reasonable to provide location information through PPP 
as long as the Network Access Server (NAS) can provide the location.

I would hope that we would limit discussion to the Internet 
specification - Linklocal Multicast Name Resolution (LLMNR) 
draft-ietf-dnsext-mdns-41.txt - rather than its proprietary precursor.

How would LLMNR or static configuration know the location of the host 
or the LIS for where the host happens to be?

>   - Using DNS in the manner described means that intermediary nodes do 
> not need to be modified; indeed, the DNS server only needs to have an 
> extra record added.  The only dependency is then on the requesting 
> entity.

Here again we have ambiguity in the use of "the".  To which DNS server 
is a record added?  How does the operator of that DNS server know what 
to add?  What name gets this record?  How does the "requesting entity" 
know what name to query?

> DNS has other advantages, such as making the address of the location 
> server that serves a particular network known.  This expands the 
> potential use of the "on behalf of" facility.

It was my impression that the WG agreed with Ted Hardie that the "on 
behalf of" facility opened too large a security hole to be worth 
further consideration.

> (c) I presume that you were talking about the fact that you were given 
> an IP address with the domain "some-host.ietf.org".  This is a clear 
> example of the case where the access provider needs to understand 
> their network.  In this case, the host returned by the DNS query 
> _locserv+http._tcp.ietf.org needs to have knowledge about the network 
> that it serves.  If that network includes disparate locations 
> (Rockville, Paris, Vancouver, wherever) and the domain suffixes are 
> not unique for those locations, then that server will need to have 
> access to information for each of those locations.

No, my computer remains in the cisco.com domain even when it is at an 
IETF meeting in Paris.  The access provider is actually the set of 
volunteers who operate the IETF network, the ISP is (usually) the 
gracious donor of Internet access.  How is the operator of the 
cisco.com domain supposed to have understanding of such a remote 
network?

> This is a good example of where the need to provide location 
> information may actually affect network deployment.  In this case, a 
> simple change to network configuration might make the entire scenario 
> easier: make the domain name "some-host.ietf63.ietf.org".

The implication that detailed information must exchanged among all the 
possible contributers of Internet access in order to satisfy a 
particular GeoPriv proposal is evidence that a different design is 
needed.  It is not reasonable to demand changes in Internet deployment.

>> (d) the feasibility of generating a location from just an IP address 
>> is not clear.
>
> (d) If you read section 1, you will note that HELD describes an 
> acquisition protocol, it purposefully does not discuss how location is 
> determined.
>
> There is, however, an expectation that a location server has access to 
> sufficient information about a network to determine location from IP 
> address.  This might be as simple as being able to query a DHCP server 
> for the information that it includes.  Like I have said before, 
> location determination varies greatly depending on circumstance; if 
> you like, describe a specific example and we can explore solutions for 
> that situation.

Yes, I read the part of the HELD specification that stated that how an 
IP address is mapped to a location is outside the scope.  But that this 
mapping is feasible must be established or the expectation has no 
foundation.  If the feasibility depends on "query a DHCP server", then 
the feasibility of having the location in the DHCP server, and the 
protocol for this query (presumably not DHCP) would be necessary.  
While it might be possible to construct situations in which this 
mapping would work, the general case would have to be established in 
order for HELD to be a reasonable solution.  It is not reasonable to 
insist that all existing parts of the Internet be redesigned to enable 
HELD.

John