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

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Sep 2005 00:06:51 -0500

John,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of John Schnizlein
> Sent: Tuesday, 13 September 2005 12:07 AM
> To: Thomson, Martin
> Cc: GEOPRIV WG
> Subject: Re: [Geopriv] HELD concerns (was: IETF 63 GEOPRIV Session
> Minutes)
> 
> 
> On Sep 11, 2005, at 8:36 PM, Thomson, Martin wrote:
> >
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 

[AJW] There is an expectation in this case that ISP also runs a LIS. The
complexity of these types of networks is going to require these types of
arrangements, it does already to some degree to enable the connectivity
in the first place. Having looked at the DSL scenarios in a lot of
detail I must admit that I am at a loss as to how you provide this
functionality without these relationships.

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

[AJW] As has been stated more than once, the DHCP option for providing
location does not work in all cases, indeed in RFC-3825 it explicitly
excludes wireless networks. DHCP is nice yes, but quite simply is not
the answer to all things IP related. There are cases where a static
location simply does not work, and a locationURI is more appropriate.
James Polk's latest draft includes a specific option for this (nice idea
James).

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

[AJW] Again I see no requirement for the NAS to provide location. For
the most part NAS implementations can and do provide measurement
information that can be converted to location by a LIS quite easily
without any change to the NAS. Why change the NAS when it is completely
unnecessary? The thrust of your arguments seem to be that change is not
good, yet you want to instigate change in devices where it is neither
appropriate nor required. There is no rule that says location may only
be acquired through layer 2, and I fail to understand this constant
underlying theme that says it must be.

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

[AJW]
As stated previously DHCP and static location delivery do not work in
all circumstances, and as mobility increases in its proliferation I
would argue that it will not work for the majority of cases in a few
years without significant modification.
The suggestion has often been made that the client can simply re-plug
the DHCP server for updated location information when it wants it, I
would like to understand how you plan to make this work. For non-mobile
users fine, but in this case the re-plug is hardly necessary, for
anything remotely mobile this simply breaks down. The entire DHCP
location determination mechanism is reliant upon relay information which
has a multitude of problems.

1) It does not support cascading relay agents. If the network is
configured with a hierarchy of relays the relay seen by the DHCP server
is the last one. So this implementation already places tight constraints
on network configuration.

2) Relay information for most DHCP servers today is not included in the
lease data, further to this, if a client has moved the original relay
data may not be valid anymore.

3) Sending a lease renewal message by-passes any relays in the network,
I quote from RFC-2131, "DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

      A client MAY choose to renew or extend its lease prior to T1.  The
      server may choose not to extend the lease (as a policy decision by
      the network administrator), but should return a DHCPACK message
      regardless."
 In this case, where is my location determination going to come from?

The arguments you raise against HELD and a LIS identifier are equally
applicable if not more so to DHCP LCI since you propose no alternatives
to DHCP relay determination. HELD does not restrict itself to a single
location determination technology, as such it presents a uniform way of
acquiring location, nothing more.

Cheers
James

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

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