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

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 12 Nov 2005 16:29:37 -0600

John,

Please see comments inline.

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Friday, 4 November 2005 10:30 AM
> To: Winterbottom, James
> Cc: GEOPRIV
> Subject: Re: [Geopriv]
draft-winterbottom-http-location-delivery-02.txt
> 
> 
> On Nov 1, 2005, at 1:12 AM, Winterbottom, James wrote:
> >
> > 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-
> > 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.

[AJW] I think that this shows a lack of understanding on how most of
these systems actually work in communications devices today. I am not
going to give you a tutorial on A-GPS merely point out that this is
something that you should consider.

> 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
> 
[AJW] The is "somewhat" is important as it limits the statement to the
degree that the recipient trusts that the target is not lying.

> 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.
> 
[AJW] I believe that this point is clarified in to the GeoPriv WG
meetings. HELD makes not claim to discovering a location server for an
arbitrary target. The discovery mechanisms highlight only point to serve
a target to discover the location server responsible for its current
access network.

> 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.
>
[AJW] This argument is somewhat philosophical. My position that location
is a service and not base host configuration stands. Currently deployed
architectures for cellular systems support this assertion.
 
> 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.
>
[AJW] I am hoping that the talking past each other on this point has
been resolved now. The draft was not implying that DHCP is not available
at all in the network, merely that it was not the mechanism used by the
ISP or access provider to provide configuration data to a DSL modem and
the such like.

[AJW] Getting the address of the LS from DHCP is a step that occurs
once. The application or device may then seek to acquire location from
the LS many times over and in many forms. In the case of a fixed line,
the LS query might only occur on the same interval as the DHCP request,
but this is the most extreme case only.   
 
> 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.
>
[AJW] As I indicated at the WG meeting I am having discussions with
member from the DNS WG on how appropriate or not this solution is.
Certainly they have indicated that there are precedents for it. Whether
it will work in all situations is another manner, and just because there
are situations in which it will not work these may not be compelling
reasons enough to not support it at all. It may be sufficient to state
under what circumstances it won't work, the example you cite being one.
The reduction statement I believe to have been resolved.

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

[AJW] As indicated this was added tentatively based on comments provided
at the IETF in Paris. Its continued inclusion is a matter for discussion
and your comments regarding its deployment base will most certainly be
taken on board.

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

[AJW] I do not believe that continuing to propagate location delivery
techniques into every layer 2 protocol in use is good practice. An
application layer protocol is far more adept to supporting this kind of
exchange.

> 
> 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.
> 
[AJW] As indicated at the meeting this was a tentative inclusion and
will likely not being in any future revisions of this protocol.

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

[AJW] Perhaps some clarification is required on this point. Although I
do wish that I had a magical hash function that could an IP address
return a location. In order to switch, direct or route traffic between
nodes something somewhere somehow must be able to provide an association
between a logical identifier and a physical interface. In many instances
this is a chain, and the associations are not always easy to get at, but
they always exist, for without them there is no way to route. The IP
address is therefore associated with one or more of these identifiers
such that physical location can be determined. Location determination is
in itself outside of scope for GeoPriv, so whether you believe the
argument is compelling or not is somewhat academic. I certainly believe
that I can acquire sufficient association to address most of the initial
target deployments.

[AJW] The VPN tunnel issue is a rathole since in this circumstance you
in effect have two IP address, one for the local network and one for the
VPN. As has been by all sides, you obtain location for the local access
network, in this case the local LS. In a circumstance where location is
requested from a remote LS, the LS should recognize that the IP address
is associated with a VPN and return a suitable error.

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

[AJW] LS-LS communications shall be re-addressed to hope clarify the
intent and applicability.

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

[AJW] The document explicitly states that mutual authentication is
required. Perhaps you can elaborate a bit on exactly what the concern is
here? 

> With so many questions still unresolved, the proposal described in
this
> draft does not appear ready for the WG charter.
> 
> John
------------------------------------------------------------------------------------------------
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