Subject: [Geopriv] draft-winterbottom-http-location-delivery-02.txt

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 1 Nov 2005 00:12:08 -0600

Hi All,

This is the updated HELD draft and includes a lot of the helpful
insights and comments provided by people from the last IETF.

http://www.ietf.org/internet-drafts/draft-winterbottom-http-location-del
ivery-02.txt

Quite a lot has changed since the last issue, a specific change section
is include din the document.

Cheers

James 

------------------------------------------------------------------------------------------------
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: Thu, 3 Nov 2005 18:30:01 -0500

On Nov 1, 2005, at 1:12 AM, Winterbottom, James wrote:
> http://www.ietf.org/internet-drafts/draft-winterbottom-http-location- 
> delivery-02.txt
>  
> Quite a lot has changed since the last issue, a specific change  
> section is included in the document.

Thank you for the change log, which aided navigation.

My current comments are in email to avoid the problem at IETF 63 of too  
little time for more than just identification of problems with the -01  
draft (which I fear were too brief).  Excerpt from (correction to the)  
minutes copied here for background:

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

We agree on several points made in this draft:
A The removal of on-behalf-of.
B That the access network is the only network able to provide location.
   We disagree that the host "cannot be relied upon for location  
information" because
   mobile hosts with GPS or Galileo capability are the best sources of  
their locations.
C The LS providing the Target with its location immediately.
D [Fraudulent location] "is somewhat less applicable when providing  
location
    information directly from Target to Location Recipient

The serious problems I see with the current draft are addressed under  
these headings:
(1) "The Target discovers or is informed of the Location Server".
(2) Alleged problems with DHCP delivery of location to the Target
(3) Elaboration of HELD to provide emergency routing (LERO)
(4) "The LS identifies the Target based on its IP address."
(5) "cascading of location information requests between LSs"
(6) "LSs and Location Generators support X.509v3 certificate-based  
authentication

(1) Part of the over-all conceptual problem is that the phrase "The  
Location Server" is confusion about which location server is to be  
discovered or queried - the LS associated with the Target or the LS  
associated with the host making the query.  When the LS has a private  
(unspecified) channel to location provided by the access network where  
the Target is attached, it can be considered as part of the Target's  
administrative realm.  In this case, communication of location within  
the administrative realm may not need all the machinery proposed for  
HELD, and just giving the host its location would suffice.  In the  
other case, it is unclear that an authorized association between LSs in  
different administrative realms exists.  HELD does not create the  
complex network of these critical associations, which might involve  
business relationships, just by assuming any LS may discover (or get  
information from) any other.

All the LS discovery methods in the draft are limited to a host finding  
its own LS, not the LS that has the location of some other Target.

The previously identified problems with DNS and DHCP to inform clients  
of the Location Server (LS) for a target are not resolved.  SLP has its  
own problems, even if inventing several ways to find the LS were better  
than just getting the location through the most appropriate way.

Using DHCP to get the address of a local LS (to get Target location) is  
just a reliant on DHCP as getting the location directly from DHCP. It  
requires a longer sequence of operations.

Using a special record in the local DNS to find the address of the LS  
adds another complicated layer of operations and configuration.  If the  
suffix of the record name is determined by DHCP options, the above  
reduction occurs.  If the suffix is different (as with my host with my  
company's domain suffix) the LS record will be at headquarters rather  
than local to my (roaming) host.

SLP [RFC 2608] includes an applicability statement that it is suitable  
for enterprise networks rather than wide area discovery. The  
limitations of SLP especially where multiple scopes of multicast are  
not deployed are covered by [RFC 2610] configuring SLP agents through  
DHCP.  If DHCP would be needed to configure SLP, it is unclear why not  
just use DHCP directly.  While I found an open source development  
community for SLP, I am curious about the existence of any operational  
deployment of it.

(2) Regarding "residential broadband", the sweeping statement: "do not  
use DHCP to deliver host configuration data" might be over done.  Do  
DSL routers that connect to the aggregation router through PPP provide  
DHCP over their ethernet attachment to the residential host or not?   
One wonders how the residential Internet/DSL user ever finds a DNS  
server, for example. Maybe all that is missing for the widespread case  
of PPP-connected hosts is an option in the control protocol to deliver  
location just as DHCP does?

Although "The operator of the DHCP server might have no direct  
knowledge of where physical access points terminate, as the equipment  
is outside their control", control and DHCP are not the essence of the  
alternative.  The DSLAM, for example can provide a circuit ID to the  
aggregation router, and the authorized termination locations of the DSL  
(virtual) circuit can be used to locate the subscriber.  Either DHCP or  
PPP could be used to inform the host of its location.  The information  
only needs to be exchanged between adjacent physical and layer-2 (DHCP  
is more like 2.5) operators at the rate of access provisioning, which  
is much less challenging than real-time among all edges.

Although it is fashionable to use HTTP and extensibility for everything  
new, the Internet was designed with purpose-built protocols because  
future-proofing too often precludes deployment until the future.  I  
suggest deleting the "second drawback" and concentrating on engineering  
the best way to inform hosts of their locations and empower their users  
to control this information.

(3) Elaborating HELD to include features for routing emergency calls  
seems to be the epitome of feature creep.  Once we have a  
too-general-purpose protocol, it gets used for a variety of related but  
different things.  It is not clear that replacing the method of routing  
emergency calls to the responsible party is looking for this sort of  
feature.

(4) The previously identified problem that IP addresses do not imply  
locations has not been resolved.  Elaborating relationships between  
abstract and hypothetical Location Generators and LSs does not make a  
convincing feasibility argument.  The specific example that has been  
mentioned before is that of host-site VPNs, of the sort commonly used  
at IETF meetings.  Traffic from my host has a source address allocated  
to the VPN-tunnel concentrator to which I actually connect the tunnel  
from my location.  It would require a magic Location Generator to  
determine the location of my original access.

(5) The ambiguity of "the Location Server" is not resolved by proposing  
that LSs communicate among each other globally.  First, related to item  
(1), it is not clear how any LS would discover an LS in some other  
administrative realm, since the discovery proposals rely on local  
information. Second, no analysis is provided that the complex set of  
authorization relationships among LSs is feasible.

Regarding remote LS discovery, We could speculate that the host name  
part of the URI (reference provided by the Target) would identify an  
LS, but this would have to be an LS that is reachable (presumably at  
the address in the global DNS) from anywhere, which does not work for  
the NATed LS.  The word "cascade" suggests more than a 2-step process  
of ask the local LS, which asks the remote LS based on the host name in  
the URI.  What is proposed?

The complex of caching, referring, and delegating among LSs and  
Location Generators begs the question of the feasibility of the result.  
  Among questions that need to be resolved by detailed analysis is how  
the user can tell what went wrong when it does.  Especially of concern  
is the security model for all the relationships, leading to the  
authentication concern, next.

6) Many wonderful applications have been proposed and died since the  
X.509 certificate was supposed to be on the verge of deployment.  It is  
not clear what about X.509v3 and the particular details of HELD would  
exempt it from the same fate. The security area should be asked to  
study the complete system, with care to issues like certificate  
validation, lifetime, revocation - the usual suspects.  Is mutual  
authentication of LSs required?  How is authorization to exchange  
particular host locations specified for LS-to-LS communication?

With so many questions still unresolved, the proposal described in this  
draft does not appear ready for the WG charter.

John