RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Thu Nov 01 2007 - 10:56:20 EDT

<I moved this back to Geopriv, where I think it belongs>
It's customary to have text in a protocol document describing when it is
appropriate to apply it, and what requirements exist for protocol entities
to effectively use it. Although the issues we are raising would apply to
ANY LCP that used an IP address, we agreed that the IETF would only produce
one such protocol (for now anyway) and HELD is it. If you deploy HELD, you
need to know these things.

Notice that we're talking about where this text goes, not if the text is
somewhere, and what it says. If we need to create a separate RFC that
describes how to deploy HELD, then we have to do that. I don't think it
needs to be a separate document. Chair/AD advice might be welcome on this
point.

Brian

> -----Original Message-----
> From: Stark, Barbara [mailto:bs7652@att.com]
> Sent: Thursday, November 01, 2007 10:39 AM
> To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT
> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier
> indraft-ietf-geopriv-http-location-delivery
>
> HELD is a protocol, purely and simply. It's not a BCP and cannot and
> should not attempt to use MUST and SHOULD language around behavior of
> devices and networks that use the protocol, outside of requirements
> directly related to formatting of the protocol messages.
> Http-location-delivery MUST NOT contain normative language that attempts
> to restrict the environment where HELD may be used. I have no problem
> with including a discussion of these issues in http-location-delivery.
> But if you want something stronger, it needs to be a BCP. Since phonebcp
> only applies to use for emergency services, then I guess you'd need a
> more generic BCP out of geopriv.
>
> Since such a HELD BCP (from geopriv) may or may not be recognized by
> device manufacturers, I'd recommend making sure that phonebcp does have
> what's needed, as far as use of HELD for emergency services.
> Barbara
>
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, November 01, 2007 10:10 AM
> To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT'
> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier
> indraft-ietf-geopriv-http-location-delivery
>
> The text belongs in the HELD document because it has nothing to do with
> emergency calls. It affects all uses of HELD.
>
> I don't have a problem with expanding text in -phonebcp
>
> Brian
>
> > -----Original Message-----
> > From: Stark, Barbara [mailto:bs7652@att.com]
> > Sent: Thursday, November 01, 2007 9:58 AM
> > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT
> > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier
> > indraft-ietf-geopriv-http-location-delivery
> >
> > I have no problem with your proposed verbiage characterizing the
> > problem.
> >
> > I think that requirements on end devices using HELD and access
> networks
> > providing HELD responses is a phonebcp issue, and not
> > http-location-delivery.
> >
> > Within phonebcp, I think that enterprise networks (that are not able
> to
> > control the capabilities of devices attaching to them) are already
> > included in the definition of access network. That seems to currently
> be
> > implicit, but perhaps it should be explicit. Then all requirements
> that
> > apply to access networks will explicitly apply to such enterprise
> > networks. I'm not sure I see what such enterprise networks need to do
> > different than public access networks. You already have some VPN and
> NAT
> > requirements there:
> > AN-14 Network administrators MUST take care in assigning IP
> addresses
> > such that VPN address assignments can be distinguished from local
> > devices (by subnet choice, for example), and LISs should not
> attempt
> > to provide location to addresses that arrive via VPN connections.
> >
> > AN-15 Placement of NAT devices should consider the effect of the
> NAT
> > on the LCP.
> >
> > The device location update when the device has a VPN established that
> > doesn't allow split tunneling is definitely a gap. I think it could be
> > solved with some HELD extensions (which is a geopriv issue). That is,
> I
> > think that if we allow the initial (pre-VPN) request to also negotiate
> > identification and authentication for future updates, that we could
> > solve the update problem.
> >
> > The intermediary SOHO (small office/home office) router that sets up
> the
> > non-split tunneling VPN on behalf of its LAN needs to be required (in
> > phonebcp) to act as the LIS for all devices in its LAN. That's part of
> > the additional requirements I'm working on providing you (Brian).
> > Barbara
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Thursday, November 01, 2007 6:16 AM
> > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT'
> > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier
> > indraft-ietf-geopriv-http-location-delivery
> >
> > That's helpful.
> >
> > I don't think it's sufficient. My example, hardware VPN/tunnel
> > mechanisms
> > cannot be permitted, has to be spelled out. Also, phonebcp recommends
> > location update at call time. We haven't worked out this detail, but
> I
> > think we want to at least recommend that a mobile device send routing
> > location as a value, and dispatch location as a reference (where
> > needed),
> > just to avoid the repeated dereference by all call routing elements.
> > That
> > means you would want to do the HELD LCP operation at call time.
> >
> > You need to discuss enterprise networks behind access networks that
> > provide
> > HELD, or try to use HELD within an enterprise network.
> >
> > I think it's hard to think through ALL the instances where an IP
> address
> > isn't reliable as an identifier to be used for location, which is why
> I
> > phrased my proposed text the way I did.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Stark, Barbara [mailto:bs7652@att.com]
> > > Sent: Thursday, November 01, 2007 5:42 AM
> > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT
> > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier
> > > indraft-ietf-geopriv-http-location-delivery
> > >
> > > Oh, fine, I'll try to be helpful, then.
> > > I definitely agree with having the problem mentioned and properly
> > > characterized. But when we write requirements, I want to be sure
> that
> > > the requirements are implementable.
> > >
> > > Certainly, end devices must do location configuration before
> > > establishing a VPN. Once an end device has established a VPN, it
> must
> > > not do any LIS discovery or HELD queries over the VPN connection.
> > >
> > > The Access Network, however, needs to have the requirement that its
> > LIS
> > > be able to know which subnets of IP addresses are supplied to
> devices
> > > coming over VPN access, or have been provided to a company that
> > provides
> > > its own LIS. That is, such blocks of IP addresses need to be
> > > configurable in the LIS. Then there's the requirement that the LIS
> > must
> > > not provide location to these IP addresses.
> > >
> > > The access network (access provider + ISP) also has a responsibility
> > not
> > > to place a LIS on the core side of any NAT that is employed in the
> > > access network. Note that this isn't meant to apply to home router
> > NATs,
> > > since those aren't part of the access network, according to the
> > > definition of access network.
> > >
> > > I really think that the access network has greater ability, and
> > > therefore greater responsibility, to minimize the occurrence of
> > problems
> > > due to VPNs and NATs.
> > >
> > > As we discussed (Brian and I), I'm going to try to suggest a way to
> > > better include in phonebcp requirements for routers employed in
> "small
> > > areas". One of the requirements we need for these, is that they MUST
> > act
> > > as the LIS for LAN-side devices, when they have VPN connections to
> the
> > > WAN.
> > > Barbara
> > >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Thursday, November 01, 2007 4:03 AM
> > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT'
> > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier
> > > indraft-ietf-geopriv-http-location-delivery
> > >
> > > I think the problem that Barbara points out is precisely the problem
> > in
> > > deploying HELD. Claiming that a problem can't be solved, and
> > therefore
> > > should not be mentioned is, uh, ?unhelpful? Having the "caveat"
> > instead
> > > of
> > > a deployment recommendation understates the problem. While it is
> > > possible
> > > to deploy HELD so that it almost always works, it will take a lot of
> > > attention by a lot of entities to make that happen. For example, if
> > > HELD is
> > > deployed, no non-bypassable VPNs can be permitted. The protocol
> > > document
> > > should be very clear about what it takes to make HELD work.
> > >
> > > I have no problem including text that covers what devices and LIS's
> > need
> > > to
> > > do, as long as it was noted that it won't always be sufficient. We
> > > might
> > > also include text on how enterprise networks should be configured.
> > >
> > > Brian
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > Sent: Wednesday, October 31, 2007 11:58 AM
> > > > To: Richard Barnes; Stark, Barbara; ECRIT
> > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address
> asanidentifier
> > > > indraft-ietf-geopriv-http-location-delivery
> > > >
> > > > I think that the "device" requirement at most should be that
> efforts
> > > > should be made to ensure that the LIS is discovered and used on
> the
> > > > physical access network and not via any VPN tunnel.
> > > >
> > > > Perhaps more importantly, there should be a complementary
> > requirement
> > > on
> > > > the LIS that it not attempt to provide location for an IP address
> > that
> > > > it cannot associate a physical location with. For example, a LIS
> in
> > an
> > > > enterprise, where that enterprise supports VPN access, should know
> > or
> > > be
> > > > able to determine that the client requests are arriving over a VPN
> > > from
> > > > an end point whose location cannot be determined. The HELD
> response
> > > > should indicate that location cannot be provided.
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > > -----Original Message-----
> > > > From: Richard Barnes [mailto:rbarnes@bbn.com]
> > > > Sent: Thursday, 1 November 2007 1:22 AM
> > > > To: Stark, Barbara; ECRIT
> > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier
> > > > indraft-ietf-geopriv-http-location-delivery
> > > >
> > > > Right, I think what's needed is more a caveat that HELD provides
> the
> > > > location of the source IP address in the IP header of the request
> --
> > > > whatever that may be.
> > > >
> > > > --Richard
> > > >
> > > >
> > > >
> > > > Stark, Barbara wrote:
> > > > > How is a client supposed to know whether a "VPN, NAT or other IP
> > > > address
> > > > > modification exists between the client and the server which
> could
> > > > > produce incorrect location"? One of the best uses of HELD is the
> > > case
> > > > > where there is a NAT (and the box with the NAT is location
> > unaware).
> > > > For
> > > > > landline broadband services, this NAT exists, but doesn't
> produce
> > an
> > > > > incorrect location. So this NAT is ok. How can you distinguish
> > > between
> > > > a
> > > > > NAT that produces an incorrect location, vs. one that produces a
> > > > correct
> > > > > location?
> > > > >
> > > > > The VPN could be originated out of the router, and not the
> client.
> > > How
> > > > > would the client know this VPN even exists?
> > > > >
> > > > > Unless you can tell me the logic to use to implement this
> proposed
> > > > > requirement, I can't support it.
> > > > > Barbara
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > > Sent: Wednesday, October 31, 2007 8:51 AM
> > > > > To: geopriv@ietf.org
> > > > > Subject: [Geopriv] Use of IP address as an identifier
> > > > > indraft-ietf-geopriv-http-location-delivery
> > > > >
> > > > > In the long set of discussions that have lead to HELD, one of
> the
> > > > > biggest
> > > > > concerns a few of us have had is the problem than an IP address
> > may
> > > > not
> > > > > be a
> > > > > good identifier for determining the location of the client.
> There
> > > is
> > > > a
> > > > > draft that describes alternate identifiers. However, there is
> no
> > > > > discussion
> > > > > in the present draft of the base protocol on these issues.
> > > > >
> > > > > I would like to propose that we add text something like:
> > > > >
> > > > > Use of HELD is subject to the viability of the identifier used
> by
> > > the
> > > > > LIS to
> > > > > determine location. This document describes the use of the IP
> > > address
> > > > > of
> > > > > the client as the identifier. When a NAT, VPN or other forms of
> > > > address
> > > > > modification occur between the client and the server, the
> location
> > > > > returned
> > > > > may be inaccurate. This is not always the case. For example, a
> > NAT
> > > > > used in
> > > > > a residential local area network is typically not a problem,
> > because
> > > > the
> > > > > external IP address used on the WAN side of the NAT is in fact
> the
> > > > right
> > > > > identifier for all of the devices in the residence. On the
> other
> > > > hand,
> > > > > if
> > > > > there is a VPN between the client and the server, for example
> for
> > a
> > > > > teleworker, then the address seen by the server may not be the
> > right
> > > > > address
> > > > > to identify the location of the client. Where a VPN is
> deployed,
> > > > > clients
> > > > > often have the ability to bypass the VPN for a transaction like
> > > HELD.
> > > > >
> > > > > HELD Clients MUST NOT send HELD requests where IP address is the
> > > > > identifier
> > > > > and a VPN, NAT or other IP address modification exists between
> the
> > > > > client
> > > > > and the server which could produce incorrect location. HELD
> MUST
> > > NOT
> > > > be
> > > > > deployed in networks where the client cannot comply reasonably
> > > > reliably
> > > > > with
> > > > > that requirement.
> > > > >

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 1 Nov 2007 10:56:20 -0400

This archive was generated by hypermail 2.1.8 : Thu Nov 01 2007 - 10:56:56 EDT