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

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Nov 2007 04:03:08 -0400

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:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> > Sent: Wednesday, October 31, 2007 8:51 AM
> > To: [email-masked]
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> > *****
> >
> > The information transmitted is intended only for the person or entity
> to which it is addressed and may contain confidential, proprietary,
> and/or privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon this information
> by persons or entities other than the intended recipient is prohibited.
> If you received this in error, please contact the sender and delete the
> material from all computers. GA623
> >
> >
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> R
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> --------------------------------------------------------------------------
> ----------------------
> 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]
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 1 Nov 2007 05:41:47 -0400

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:[email-masked]] 
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

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

> > https://www1.ietf.org/mailman/listinfo/geopriv
------------------------------------------------------------------------
--
------------------------------------------------------------------------
--

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 1 Nov 2007 04:45:22 -0500

Aren't these issues already characterized in the L7 LCP problems
statement?

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Thursday, 1 November 2007 8:42 PM
> To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT
> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier
> > Perhaps more importantly, there should be a complementary
requirement
> on
> > enterprise, where that enterprise supports VPN access, should know
or
> > and/or privileged material. Any review, retransmission,
dissemination
> or
to
> which it is addressed and may contain confidential, proprietary,
and/or
> privileged material. Any review, retransmission, dissemination or
other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited.
If
> you received this in error, please contact the sender and delete the
> material from all computers. GA625
> 
> 
> 

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Nov 2007 06:16:02 -0400

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 

> Sent: Thursday, November 01, 2007 5:42 AM
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> persons or entities other than the intended recipient is prohibited. If

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 1 Nov 2007 08:34:40 -0500

If you've got two enterprise sites connected via a branch to branch VPN
tunnel then it's quite possible to have a single LIS at the one site or
separate LIS at each site providing successful location fixes for both
sites. So it's not a case of forbidding hardware VPNs.

I think the only hard rule - and it should be obvious anyway - is that
if a LIS can't provide the location for a presented IP address then it
should not provide a location.

If an enterprise, for example, deploys a locked down VPN client on their
Internet-nomadic staff computers such that they cannot communicate
outside the VPN once the tunnel is established, then that enterprise has
made a decision that they do not want to let those devices access the
location service available at the local physical network - particularly
if it won't even make the HELD query prior to tunnel establishment.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 1 November 2007 9:16 PM
To: 'Stark, Barbara'; Dawson, Martin; 'Richard Barnes'; 'ECRIT'
Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier

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.

Brian 

requirement
or
dissemination
to
and/or
other
If

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Nov 2007 09:43:44 -0400

Right. Agree with all of this.  More text to add.

Brian

> Sent: Thursday, November 01, 2007 9:35 AM
> To: Brian Rosen; Stark, Barbara; Richard Barnes; ECRIT

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 1 Nov 2007 09:58:27 -0400

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:[email-masked]] 
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

That's helpful.

Brian 

requirement
or

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Nov 2007 10:09:33 -0400

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

> Sent: Thursday, November 01, 2007 9:58 AM

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 1 Nov 2007 10:38:39 -0400

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:[email-masked]] 
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

Brian

> > > it cannot associate a physical location with. For example, a LIS
in
> an
> > > > landline broadband services, this NAT exists, but doesn't
produce
> an
> > > > The VPN could be originated out of the router, and not the
client.
> > How
> > > > good identifier for determining the location of the client.
There
> > is
> > > > Use of HELD is subject to the viability of the identifier used
by
> > > > there is a VPN between the client and the server, for example
for
> > > > and the server which could produce incorrect location.  HELD
MUST
> > NOT

---

From: Richard Barnes <[email-masked]>
Date: Thu, 01 Nov 2007 10:54:37 -0400

As far as which document this belongs in, I mostly don't care.  However, 
  it shouldn't be in phonebcp because it's not emergency-specific.

My analysis of the situation is below, if it's helpful.

--Richard

There are two things that cause problems for HELD (using IP source 
address as an identifier for the endpoint):
1. The IP address that HELD uses is the IP source address
2. There are several logical steps between IP address and location
	-- e.g. IP --> MAC --> WLAN AP --> Loc
	-- e.g. IP --> MAC --> port --> Loc

So a HELD LIS can position an endpoint if:
1. The LIS has sufficient knowledge of the network to which the endpoint 
is physically attached to derive its location (given the proper IP address)
2. The IP source address in the HELD request is the one that will direct 
the LIS to return the endpoint's location
In most cases, (2) means that the source address is the one the network 
assigned, or that the source address was not changed while the packet 
was in transit.

Martin's pair of enterprise networks "glued together" with a VPN meets 
these criteria (with all three versions of 2).  The LIS is an enterprise 
asset, so it can be provisioned with knowledge of both networks.  And 
even if a packet traverses the VPN, it's just tunneled whole, and the 
source address is never changed.

In the "road warrior" VPN case:
1. In a query from the endpoint to an enterprise LIS: Criterion (2) is 
true -- IP source addresses are carried faithfully from source to LIS. 
But criterion (1) is false, because the LIS does not have sufficient 
information about the host's attachment to locate it.
2. In a query from the endpoint to an access network LIS through the 
tunnel: Criterion (1) is true, but criterion (2) is false.  The LIS has 
sufficient information, but the source address is in the enterprise 
network, not the right one.
3. In a query from the endpoint to an access network LIS outside the 
tunnel: This works because (1) the LIS knows about the network the 
endpoint is physically attached to, and (2) the LIS gets the IP address 
that it assigned.

If the endpoint and the LIS are on opposite sides of a NAT, (1) is 
almost always false, and (2) as well.  (1) is only true if the LIS is 
aware of the network topology behind the NAT (even if not the 
addressing), and (2) is only true if the LIS is aware of the address 
mapping in the LIS.  Note that (2) cannot be true if there's multiple 
hosts with different locations are fronted by a NAT with a single public 
address (since HELD doesn't account for port numbers).

In a particular deployment scenario, the problem is to determine under 
what observable conditions these criteria are true, and constrain the 
LIS to answering queries only when they are likely to be true.

With respect to (2): It seems like you could have some assurance using 
the HELD identity extension for the endpoint to include it's own IP 
address in the HELD request.  The LIS could then detect changes in the 
source IP addresses by comparing the two.

With respect to (1): This is much more difficult to deal with, since you 
can extend the network without the LIS being aware, like by adding a VPN 
out to a remote point.  Getting any assurance on this point requires 
strong constraints on the structure of the network.

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 1 Nov 2007 10:58:38 -0400

In addition to Brian's comment, the whole discussion assumes IP address as
the identifier a LIS utilizes for location lookup.  I simply ask that the
use case is clarified when text is added.

-Marc-

> To: 'Stark, Barbara'; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT'
> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP 
> addressasanidentifier 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 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 
> > different than public access networks. You already have 
> some VPN and 
> > NAT requirements there:
> > 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
> > 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
> > 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
> > 
> > > characterized. But when we write requirements, I want to be sure 
> > > that the requirements are implementable.
> > >
> > > 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
> > > The access network (access provider + ISP) also has a 
> responsibility
> > not
> > > 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
> > >
> > > I think the problem that Barbara points out is precisely 
> the problem
> > in
> > > 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
> > > might also include text on how enterprise networks should be 
> > > configured.
> > >
> > > Brian
> > >
> > >
> > > > 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.
> > > >
> > > > the LIS that it not attempt to provide location for an 
> IP address
> > that
> > > > 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
> > > >
> > > > 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:
> > > > > modification exists between the client and the server which 
> > > > > could produce incorrect location"? One of the best 
> uses of HELD 
> > > > > is the
> > > case
> > > > > The VPN could be originated out of the router, and 
> not the client.
> > > How
> > > > > Unless you can tell me the logic to use to implement this 
> > > > > proposed requirement, I can't support it.
> > > > > Barbara
> > > > >
> > > > > 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
> > > > > draft that describes alternate identifiers.  However, 
> there is 
> > > > > no discussion in the present draft of the base 
> protocol on these 
> > > > > issues.
> > > > >
> > > > > 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
> > > > > external IP address used on the WAN side of the NAT 
> is in fact 
> > > > > the
> > > > right
> > > > > 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.
> > > > >
> > > > > 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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Nov 2007 11:22:31 -0400

The current HELD document ONLY allows IP addresses as identifiers.  I agree
with your point, and the text should be made clear on that point.  If you
read my original proposed text, I believe I was clear.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Thursday, November 01, 2007 10:59 AM
> To: 'Brian Rosen'; 'Stark, Barbara'; 'ECRIT'

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 1 Nov 2007 10:38:13 -0500

Hi Richard,

A network can be extended in many ways without the LIS being "aware".
Generally that would be a failure to maintain the LIS state on the part
of the administrator.

As Brian said, wrt the NAT scenario, it's not a problem as long as the
location of the NAT device is actually considered adequate as far as
representing the location of the end point is concerned. Typically
that's the case for a residential broadband connection and, indeed, is
exactly analogous to a POTS service providing the residential address
associated with the phone service even though there may be a cordless
phone on that POTS connection with a one kilometre range.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Friday, 2 November 2007 1:55 AM
To: Stark, Barbara
Cc: Brian Rosen; Dawson, Martin; ECRIT
Subject: Re: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier

--Richard

is physically attached to derive its location (given the proper IP
address)
2. The IP source address in the HELD request is the one that will direct

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 1 Nov 2007 16:31:51 -0500

I have to strongly agree with Barbara.  If -phone-bcp isn't the right place for these recommendations then someone can write another BCP.

> Sent: Friday, 2 November 2007 1:39 AM
> networks
> must
> devices
> "small
> asanidentifier
> efforts
> response
> could
> location
> deployed,

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 02 Nov 2007 14:33:20 -0500

Hi, Barbara and Martin,

My question may be more appropriate for the ADs, but as far as I know, there 
is no prohibition about putting MUST and SHOULD language governing 
device/network behavior in standards-track documents.

Putting this information in a separate document might be the right thing to 
do, but isn't required by our standards process.

> directly related to formatting of the protocol messages.

The first example I thought of, "TCP Congestion Control", 
ftp://ftp.rfc-editor.org/in-notes/rfc2581.txt, is a Proposed Standard and 
includes both MUSTs and SHOULDs governing device behavior with no protocol 
message formatting specification at all.

I'm not a routing expert, but I'd be surprised if I couldn't find routing 
standards-track documents that also include 2119 normative language about 
router behavior.

I'm also not a security expert, but I'd expect SecDir reviewers to need this 
information to evaluate security considerations for HELD.

Thanks,

Spencer

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 2 Nov 2007 15:37:13 -0400

Chair/AD opinion please

I will write a BCP if we need it.  I think that would be silly, and the
protocol document is the appropriate place for documenting deployment
concerns for the protocol.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Thursday, November 01, 2007 5:32 PM
> To: Stark, Barbara; Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT
> I have to strongly agree with Barbara.  If -phone-bcp isn't the right
> place for these recommendations then someone can write another BCP.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Nov 2007 16:53:09 -0400

I agree with Spencer.

Based on previous experience, message/syntax-only documents are  
frowned upon. (We had to rewrite RPH, for example, largely because it  
was perceived as being too syntax-focused. RFC 3261 tries to provide a  
much more semantically-based description, compared to the syntax- 
focused RFC 2543).

In other words, standards MUST describe semantics, not just syntax,  
and applicability, and SHOULD describe motivation and background where  
necessary and helpful to implementors.

In my personal opinion, RFCs are meant to be useful to implementors  
and should be self-contained. Describing how to make something  
actually work (or where it might not work) is something that every  
implementor needs to know. I don't see a need for a separate BCP here.

Henning

On Nov 2, 2007, at 3:33 PM, Spencer Dawkins wrote:

> Hi, Barbara and Martin,
>
> My question may be more appropriate for the ADs, but as far as I  
> know, there is no prohibition about putting MUST and SHOULD language  
> governing device/network behavior in standards-track documents.
>
> Putting this information in a separate document might be the right  
> thing to do, but isn't required by our standards process.
>
>
> The first example I thought of, "TCP Congestion Control", ftp://ftp.rfc-editor.org/in-notes/rfc2581.txt 
> , is a Proposed Standard and includes both MUSTs and SHOULDs  
> governing device behavior with no protocol message formatting  
> specification at all.
>
> I'm not a routing expert, but I'd be surprised if I couldn't find  
> routing standards-track documents that also include 2119 normative  
> language about router behavior.
>
> I'm also not a security expert, but I'd expect SecDir reviewers to  
> need this information to evaluate security considerations for HELD.
>
> Thanks,
>
> Spencer
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 3 Nov 2007 13:11:46 -0500

Perhaps I am missing something here, but it seems to me that this not a
HELD problem so much as a service discovery problem, which from what I
am lead to believe can be just as problematic with DHCP when it is run
over VPNs. Consequently unless we are going to address that issue too, I
think that AGAIN singling HELD out to address a generic problem is
totally inappropriate.

A simple HELD-based LIS/relay-service added to a home router will avoid
the issues that have been described by Brian to the same degree that
they are avoided by DHCP. This is very easy to do and we have made this
work in OpenWRT running on a linksys home-router. I am not keen to start
describing these kinds of solutions in the base HELD specification, a
BCP is more appropriate, though a mention of care would seem reasonable.

Cheers
James

> Sent: Saturday, 3 November 2007 6:37 AM
> To: Thomson, Martin; 'Stark, Barbara'; Dawson, Martin; 'Richard
Barnes';
> 'ECRIT'
> Subject: RE: [Ecrit] Re: [Geopriv] Use of IPaddressasanidentifier
indraft-
> ietf-geopriv-http-location-delivery
> 
> Chair/AD opinion please
> 
asanidentifier
asanidentifier
> > > > Within phonebcp, I think that enterprise networks (that are not
able
> > > > implicit, but perhaps it should be explicit. Then all
requirements
> > > > 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
> > > >    AN-15 Placement of NAT devices should consider the effect of
the
> > > > 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
> > > > 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
asanidentifier
> > > > location update at call time.  We haven't worked out this
detail,
> but
> > > I
> > > > isn't reliable as an identifier to be used for location, which
is
> why
> > > I
> > > > > The Access Network, however, needs to have the requirement
that
> its
> > > > > coming over VPN access, or have been provided to a company
that
> > > > > configurable in the LIS. Then there's the requirement that the
LIS
> > > > > access network. Note that this isn't meant to apply to home
router
> > > > NATs,
> > > > > 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
> > > > > areas". One of the requirements we need for these, is that
they
connections to
> > > > > I think the problem that Barbara points out is precisely the
> problem
> > > > in
> > > > > should not be mentioned is, uh, ?unhelpful?  Having the
"caveat"
> > > > instead
> > > > > 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,
> > > > > 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
> > > > > > should be made to ensure that the LIS is discovered and used
on
> > > > > > the LIS that it not attempt to provide location for an IP
> address
> > > > that
> > > > > > enterprise, where that enterprise supports VPN access,
should
> know
> > > > or
> > > > > be
> > > > > > able to determine that the client requests are arriving over
a
> VPN
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
> > > > > > > produce incorrect location"? One of the best uses of HELD
is
> > > > > > > incorrect location. So this NAT is ok. How can you
distinguish
> > > > > between
> > > > > > a
> > > > > > > NAT that produces an incorrect location, vs. one that
produces
> > > > > > > concerns a few of us have had is the problem than an IP
> address
> > > > may
> > > > > > not
> > > > > > > be a
there is
> > > no
> > > > > > > determine location.  This document describes the use of
the IP
> > > > > address
> > > > > > > of
> > > > > > > the client as the identifier.  When a NAT, VPN or other
forms
> > > > > > > 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
> > > > > > > teleworker, then the address seen by the server may not be
the
> > > > > > > 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

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Nov 2007 08:13:08 -0500

Brian,

IMO, applicability belongs in the base document.  I believe there will be
much difficulty moving the HELD draft through the IESG without strict usage
guidelines included.

-Marc-

> Sent: Friday, November 02, 2007 3:37 PM
> To: 'Thomson, Martin'; 'Stark, Barbara'; 'Dawson, Martin'; 
> 'Richard Barnes'; 'ECRIT'
> Subject: RE: [Ecrit] Re: [Geopriv] Use of 
> IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery
> 
> Chair/AD opinion please
> 
> I will write a BCP if we need it.  I think that would be 
> silly, and the protocol document is the appropriate place for 
> documenting deployment concerns for the protocol.
> 
> Brian
> 
> addressasanidentifier 
> > > 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.
> > >
> > > device manufacturers, I'd recommend making sure that 
> phonebcp does 
> > > have what's needed, as far as use of HELD for emergency services.
> > > Barbara
> > >
> > > The text belongs in the HELD document because it has 
> nothing to do 
> > > with emergency calls.  It affects all uses of HELD.
> > >
> > > > 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:
> > > > 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.
> > > >
> that sets 
> > > > up
> > > > non-split tunneling VPN on behalf of its LAN needs to 
> be required 
> > > > (in
> > > > part of the additional requirements I'm working on 
> providing you (Brian).
> > > > Barbara
> > > >
> > > > 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 
> > > > You need to discuss enterprise networks behind access networks 
> > > > that provide HELD, or try to use HELD within an enterprise 
> > > > network.
> > > >
> > > > isn't reliable as an identifier to be used for 
> location, which is 
> > > > why
> > > I
> > > > > I definitely agree with having the problem mentioned and 
> > > > > properly characterized. But when we write 
> requirements, I want 
> > > > > to be sure
> > > that
> requirement that 
> > > > > coming over VPN access, or have been provided to a 
> company that
> > > > provides
> > > > > 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,
> > > > > 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
> connections 
> > > > > 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.
> > > > >
> > > > > We might also include text on how enterprise networks 
> should be 
> > > > > configured.
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > > > 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
> > > > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as 
> > > > > > anidentifier indraft-ietf-geopriv-http-location-delivery
> > > > > >
> > > > > > > other IP
> > > > > > > produce incorrect location"? One of the best uses 
> of HELD is 
> > > > > > > the
> > > > > case
> > > > > > > produces a
> > > > > > > In the long set of discussions that have lead to 
> HELD, one 
> > > > > > > of
> > > the
> > > > > > > biggest
> > > > > > > draft that describes alternate identifiers.  
> However, there 
> > > > > > > is
> > > no
> > > > > > > discussion
> > > > > > > determine location.  This document describes the 
> use of the 
> > > > > > > IP
> > > > > address
> > > > > > > of
> > > > > > > forms of
> > > > > > > example, a
> > > > > > > a residential local area network is typically not 
> a problem,
> > > > because
> > > > > > the
> > > > > > > identifier for all of the devices in the 
> residence.  On the
> > > other
> > > > > > hand,
> > > > > > > if
> > > > > > > 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
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.
> >

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 5 Nov 2007 08:38:24 -0500

OK. So I agree that descriptive usage guidance is a good thing. It
sounds like there's general consensus on that.

If you want normative language in these guidelines, I can be swayed, but
I would ask that such requirements be reasonable, rational,
implementable, and do not attempt to unnecessarily cripple usage of the
protocol. If they aren't useful, implementers like me will be tempted to
simply ignore them. We implementers have a long history of doing that,
and I think it weakens RFCs when implementers freely pick and choose
which normative guidance they want to abide by.
Barbara 

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Monday, November 05, 2007 8:13 AM
To: 'Brian Rosen'; 'ECRIT'
Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier

Brian,

IMO, applicability belongs in the base document.  I believe there will
be
much difficulty moving the HELD draft through the IESG without strict
usage
guidelines included.

-Marc-

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Nov 2007 08:52:18 -0500

James,

In-line.... 

> Perhaps I am missing something here, but it seems to me that 
> this not a HELD problem so much as a service discovery 
> problem, which from what I am lead to believe can be just as 
> problematic with DHCP when it is run over VPNs. Consequently 
> unless we are going to address that issue too, I think that 
> AGAIN singling HELD out to address a generic problem is 
> totally inappropriate.

1) I don't understand your service discovery statement.  DHCP server
discovery is under strict control of the broadcast domain administration.
The end host does not participate in this process.

2) In the case of a software VPN client, it is assumed the end host receives
configuration information prior to establishment of the tunnel.  It has been
stated many times the end host must utilize the location received during the
first step, prior to tunnel establishment.  It would also be prudent that
location information not be passed during tunnel establishment.

3) In the case of a hardware VPN it is typical that the remote device
co-located with the end host provides network configuration.  Location can
be included at that time.

> 
> A simple HELD-based LIS/relay-service added to a home router 
> will avoid the issues that have been described by Brian to 
> the same degree that they are avoided by DHCP. This is very 
> easy to do and we have made this work in OpenWRT running on a 
> linksys home-router. 

4) This would not work in the typical hardware VPN environment.

5) I assume you are not suggesting home users to run OpenWRT..?

I am not keen to start describing these 
> kinds of solutions in the base HELD specification, a BCP is 
> more appropriate, though a mention of care would seem reasonable.

6) As I stated in another email, in my experience, the IESG will want
applicability included in the base draft, but I'm continually surprised by
the IESG... :^)

-Marc-

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 5 Nov 2007 06:58:24 -0700

P-A-I (RFC 3325) is an example of a 'base' document that defines a
protocol mechanism and also contains an applicability statement.  

A suggestion may be to formulate what (deployment/implementation)
conditions make the protocol applicable to warn folks developing it when
they design the implementation, as opposed to listing many concerns or
negative cases.

Jean-Francois.

> Sent: Monday, November 05, 2007 6:13 AM
> > > > >    devices (by subnet choice, for example), and LISs should
> not
> > > > attempt
updates,
> > > > > > deploying HELD.  Claiming that a problem can't be solved,
> and
> > > > > therefore
> > > > > > > > where there is a NAT (and the box with the NAT is
> location
> > > > > unaware).
> > > > > > > For
> > > > > > > > Use of HELD is subject to the viability of the
> identifier
> > > > > > > > used
> > > > by
> > > > > > the
> > > > > > > > LIS to
> > --------------------------------------------------------------------
> --
> > > ----
> > > ----------------------
> > --------------------------------------------------------------------
> --
> > > ----
> > > ----------------------
> > > [mf2]
> >
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Nov 2007 15:28:16 +0100

RFC 4776 and RFC 3825 do not contain an applicability statement either 
although the applicability of DHCP is also limited.

Ciao
Hannes

Jean-Francois Mule wrote:
>>>> To: Stark, Barbara; Brian Rosen; Dawson, Martin; Richard
>>>>         
>>> Barnes; ECRIT
>>>       
>>>> I have to strongly agree with Barbara.  If -phone-bcp isn't
>>>>         
>>> the right
>>>       
>>>> place for these recommendations then someone can write another
>>>>         
> BCP.
>   
>>>>> HELD is a protocol, purely and simply. It's not a BCP and
>>>>>           
>>> cannot and
>>>       
>>>>> phonebcp only applies to use for emergency services, then I
>>>>>           
>> guess
>>     
>>>>> Since such a HELD BCP (from geopriv) may or may not be
>>>>>           
>>> recognized by
>>>       
>>>>> have what's needed, as far as use of HELD for emergency
>>>>>           
> services.
>   
>>>>> Barbara
>>>>>
>>>>>> I have no problem with your proposed verbiage
>>>>>>             
>>> characterizing the
>>>       
>>>>>> problem.
>>>>>>
>>>>>> control the capabilities of devices attaching to them)
>>>>>>             
>>> are already
>>>       
>>>>>> apply to access networks will explicitly apply to such
>>>>>>             
>>> enterprise
>>>       
>>>>>> 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
>>>       
>>>>>>    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.
>>>>>>
>>>>>> To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes';
>>>>>>             
>> 'ECRIT'
>>     
>>>>>> I don't think it's sufficient.  My example, hardware
>>>>>>             
>> VPN/tunnel
>>     
>>>>>> (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.
>   
>>>>>> I think it's hard to think through ALL the instances where an
>>>>>>             
>> IP
>>     
>>>>> address
>>>>>           
>>>>>>> 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.
>>>       
>>>>>>> be able to know which subnets of IP addresses are supplied
>>>>>>>               
>> to
>>     
>>>>> devices
>>>>>           
>>>>>>> configurable in the LIS. Then there's the requirement
>>>>>>>               
>>> that the
>>>       
>>>>>>> LIS
>>>>>>>               
>>>>>> must
>>>>>>             
>>>>>>> since those aren't part of the access network,
>>>>>>>               
>>> according to the
>>>       
>>>>>>> I really think that the access network has greater
>>>>>>>               
>>> ability, and
>>>       
>>>>>>> To: 'Dawson, Martin'; 'Richard Barnes'; Stark,
>>>>>>>               
>>> Barbara; 'ECRIT'
>>>       
>>>>>>> is possible to deploy HELD so that it almost always works,
>>>>>>>               
>> it
>>     
>>>>>>>> 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
>>>>>           
>>>>>>>>> modification exists between the client and the
>>>>>>>>>                   
>>> server which
>>>       
>>>>> could
>>>>>           
>>>>>>>>> landline broadband services, this NAT exists, but
>>>>>>>>>                   
>> doesn't
>>     
>>>>> produce
>>>>>           
>>>>>> an
>>>>>>             
>>>>>>>>> The VPN could be originated out of the router, and not
>>>>>>>>>                   
>> the
>>     
>>>>> client.
>>>>>           
>>>>>>> How
>>>>>>>               
>>>>>>>>> Unless you can tell me the logic to use to implement
>>>>>>>>>                   
>> this
>>     
>>>>> proposed
>>>>>           
>>>>>>>>> good identifier for determining the location of
>>>>>>>>>                   
>>> the client.
>>>       
>>>>> There
>>>>>           
>>>>>>> is
>>>>>>>               
>>>>>>>> a
>>>>>>>>                 
>>>>>>>>> in the present draft of the base protocol on these
>>>>>>>>>                   
>> issues.
>>     
>>>>>>>>> modification occur between the client and the server,
>>>>>>>>>                   
>> the
>>     
>>>>> location
>>>>>           
>>>>>>>>> returned
>>>>>>>>> external IP address used on the WAN side of the NAT is
>>>>>>>>>                   
>> in
>>     
>>>>>>>>> fact
>>>>>>>>>                   
>>>>> the
>>>>>           
>>>>>>>> right
>>>>>>>>                 
>>>>>>>>> teleworker, then the address seen by the server
>>>>>>>>>                   
>>> may not be
>>>       
>>>>>>>>> the
>>>>>>>>>                   
>>>>>> right
>>>>>>             
>>>>>>>>> address
>>>>>>>>> often have the ability to bypass the VPN for a
>>>>>>>>>                   
>>> transaction
>>>       
>>>>>>>>> like
>>>>>>>>>                   
>>>>>>> HELD.
>>>>>>>               
>>>>>>>>> and the server which could produce incorrect
>>>>>>>>>                   
>>> location.  HELD
>>>       
>>>>> MUST
>>>>>           
>>>>>>> NOT
>>>>>>>               
>>>>>>>> be
>>>>>>>>

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Nov 2007 10:11:57 -0500

Hannes,
> 
> RFC 4776 and RFC 3825 do not contain an applicability 
> statement either although the applicability of DHCP is also limited.

The applicability of DHCP is well known, stated elsewhere and not required
in drafts that are simply adding options.  The applicability of the option
is prudent.  An example of an applicability statement from RFC 3825:

"
The goal of this option is to enable a wired Ethernet host to obtain its
location, which it could provide to an emergency responder, as one example.

Wireless hosts can utilize this option to gain knowledge of the location of
the radio access point used during host configuration, but would need some
more exotic mechanisms, maybe GPS, or maybe a future DHCP option, which
includes a list of geo-locations like that defined here, containing the
locations of the radio access points that are close to the client.
"

The intent of the above is a state this option is most applicable to wired
Ethernet hosts.

As I stated in other emails, IMO, if you don't provide words in the base
draft that provide guidance to utilizing IP address as the identifier for
location lookup, the IESG will immediately come back and ask what happens
when the host is behind NATs and/or VPN tunnels.  Yes, such guidance will
appear to restrict the usage of the protocol, but it's certainly best that
everyone know that prior to implementation.

-Marc-

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 5 Nov 2007 16:21:14 +0100

But this text relates more to the supported location shapes rather to the usage of DHCP for conveying location information as such. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Marc Linsner [mailto:[email-masked]] 
> Gesendet: Montag, 5. November 2007 16:12
> An: 'Hannes Tschofenig'
> Cc: 'ECRIT'
> Betreff: [Ecrit] RE: Applicability Statement
> 
> Hannes,
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 5 Nov 2007 09:51:00 -0600

Marc, 
Inline.

> configuration information prior to establishment of the tunnel.  It
has
> been
> stated many times the end host must utilize the location received
during
> location information not be passed during tunnel establishment.

[AJW] Assumptions are always dangerous. Why is it okay for you to assume
this for DHCP but it is not okay for HELD to make the same assumption?
Seems like yet another double standard to me.

> be included at that time.

[AJW] Where does the remote device get it from? If it is a PPP-based
device it would have to be manually configured, surely you are not
suggesting that this is a good option? I can equally well put a HELD
server in my local router and do the same thing. 

> 4) This would not work in the typical hardware VPN environment.

[AJW] Actually see point 3, it works just as well as the DHCP option you
have suggested.

> 5) I assume you are not suggesting home users to run OpenWRT..?

[AJW] It works and it is reliable, but I don't need it in order to run
HELD in 95% of cases, and I don't have to upgrade the home router and
all of the intervening network connectivity to support DHCP either... ;)

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Nov 2007 11:46:21 -0500

Hannes, 

> 
> But this text relates more to the supported location shapes 
> rather to the usage of DHCP for conveying location 
> information as such. 
> 

No, the text relates to the applicability of utilizing DHCP as the LCP for
wired and wireless end hosts.  I don't see any reference to location
shapes....??

What am I missing?

-Marc-

> > Hannes,
> > > 
> > > RFC 4776 and RFC 3825 do not contain an applicability statement 
> > > either although the applicability of DHCP is also limited.
> > 
> > The applicability of DHCP is well known, stated elsewhere and not 
> > required in drafts that are simply adding options.  The 
> applicability 
> > of the option is prudent.  An example of an applicability statement 
> > from RFC 3825:
> > 
> > "
> > The goal of this option is to enable a wired Ethernet host 
> to obtain 
> > its location, which it could provide to an emergency 
> responder, as one 
> > example.
> > 
> > Wireless hosts can utilize this option to gain knowledge of the 
> > location of the radio access point used during host 
> configuration, but 
> > would need some more exotic mechanisms, maybe GPS, or maybe 
> a future 
> > DHCP option, which includes a list of geo-locations like 
> that defined 
> > here, containing the locations of the radio access points that are 
> > close to the client.
> > "
> > 
> > The intent of the above is a state this option is most 
> applicable to 
> > wired Ethernet hosts.
> > 
> > As I stated in other emails, IMO, if you don't provide words in the 
> > base draft that provide guidance to utilizing IP address as the 
> > identifier for location lookup, the IESG will immediately come back 
> > and ask what happens when the host is behind NATs and/or 
> VPN tunnels.  
> > Yes, such guidance will appear to restrict the usage of the 
> protocol, 
> > but it's certainly best that everyone know that prior to 
> > implementation.
> > 
> > -Marc-
> > 
> > 
> >

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Nov 2007 11:46:21 -0500

James,

This thread has mutated from the topic of using IP address identifier in
HELD.

In-line...

> Seems like yet another double standard to me.

This assumption is not dangerous.  If the end host does not have local
network configuration/knowledge, the software VPN cannot be established.
Certainly, after establishing network connectivity, the end host could
perform a HELD query for location.  But using HELD for location discovery
after establishment of the VPN tunnel (original topic of this thread) will
likely fail.  The two failure modes are: The VPN client does not allow
traffic to the local network, or the VPN tunnel is the primary route and the
HELD server is off-net.

> > co-located with the end host provides network 
> configuration.  Location
> can

Remote device = hardware VPN box.  The normal implementation for this device
is to sit behind the home gateway/router/firewall, parallel to the home
network.  I have no problem manually configuring such a box with location
for distribution.  Typically, end hosts that are connected to the remote
device have no knowledge of the home network, nor connectivity to it, hence
an end host connecting behind this remote device could not use HELD to
discover location from the home network or local SP.

> [AJW] Actually see point 3, it works just as well as the DHCP 

No, it does not/would not work.

> all of the intervening network connectivity to support DHCP 

Then I suggest you include such verbiage in the HELD draft and see if the
IESG accepts it.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 5 Nov 2007 11:02:10 -0600

Inline,

> discover location from the home network or local SP.

[AJW] huh?? LIS Discovery clearly states that a DHCP option can be used
to provide the identity of the LIS to the end-device. There is
absolutely nothing stoping this URL from pointing to a location object
on the hardware box. In fact if it has a webserver running on it (as
most home routers do) then you have 90% of the HELD server already in
place. Supporting manual location configuration and a new DHCP option is
the same amount for work for either solution.

> No, it does not/would not work.

[AJW] I think it does, please at my clarified response to 3.

> Then I suggest you include such verbiage in the HELD draft and see if
the

[AJW] Okay.. thanks.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Nov 2007 12:17:54 -0600

At 09:21 AM 11/5/2007, Tschofenig, Hannes (NSN - DE/Munich) wrote:
>But this text relates more to the supported 
>location shapes rather to the usage of DHCP for 
>conveying location information as such.

The word "shape" (or any such synonym) is not in 
3825, so I don't find this criticism relevant or applicable.

> > applicable to wired

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Nov 2007 13:47:54 -0500

James,

You seem to be connecting several dots and making assumptions that I'm not. 

> 
> [AJW] huh?? LIS Discovery clearly states that a DHCP option 
> can be used to provide the identity of the LIS to the 
> end-device. There is absolutely nothing stoping this URL from 
> pointing to a location object on the hardware box. In fact if 
> it has a webserver running on it (as most home routers do) 
> then you have 90% of the HELD server already in place. 
> Supporting manual location configuration and a new DHCP 
> option is the same amount for work for either solution.

1) Are you including hardware VPN devices in the 'home router' ("as most
home routers do") category?  They are not the same device.

2) You are assuming a hardware VPN device includes a http server AND that
enterprise IT departments have a desire to turn them on.  That's a long
stretch.

3) You are requesting enterprise IT departments to deploy HELD in the
hardware VPN device when DHCP is already deployed.  Most will object.

4) So, the LIS discovery option is not new to DHCP?  ;^)

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 6 Nov 2007 04:44:34 -0600

Hi Marc,

Could you elaborate, specifically, on what the "hardware" VPN issue is
that you're describing? What are the network elements involved, where is
the signalling going, and where does the problem arise?

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 6 November 2007 12:52 AM
To: Winterbottom, James; 'ECRIT'
Subject: RE: [Ecrit] Re: [Geopriv] UseofIPaddressasanidentifier

James,

In-line.... 

1) I don't understand your service discovery statement.  DHCP server
discovery is under strict control of the broadcast domain
administration.
The end host does not participate in this process.

2) In the case of a software VPN client, it is assumed the end host
receives
configuration information prior to establishment of the tunnel.  It has
been
stated many times the end host must utilize the location received during
the
first step, prior to tunnel establishment.  It would also be prudent
that
location information not be passed during tunnel establishment.

3) In the case of a hardware VPN it is typical that the remote device
co-located with the end host provides network configuration.  Location
can
be included at that time.

6) As I stated in another email, in my experience, the IESG will want
applicability included in the base draft, but I'm continually surprised
by
the IESG... :^)

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 6 Nov 2007 09:13:12 -0500

Martin,

> 
> Could you elaborate, specifically, on what the "hardware" VPN 
> issue is that you're describing? What are the network 
> elements involved, where is the signalling going, and where 
> does the problem arise?
> 

I am not sure what you are asking.  As this thread mutated, James proposed
the cautions suggested for inclusion in the HELD draft surrounding NATs &
VPNs were not related to HELD, but to service discovery.  James also
suggested that "A simple HELD-based LIS/relay-service added to a home
router" could solve part/all of the issue.  I was attempting to explain
service discovery and how these claims worked with each VPN use case.

-Marc-   

> James,
> 
> In-line.... 
> 
> > Perhaps I am missing something here, but it seems to me 
> that this not 
> > a HELD problem so much as a service discovery problem, 
> which from what 
> > I am lead to believe can be just as problematic with DHCP 
> when it is 
> > run over VPNs. Consequently unless we are going to address 
> that issue 
> > too, I think that AGAIN singling HELD out to address a 
> generic problem 
> > is totally inappropriate.
> 
> 1) I don't understand your service discovery statement.  DHCP 
> server discovery is under strict control of the broadcast 
> domain administration.
> 2) In the case of a software VPN client, it is assumed the 
> end host receives configuration information prior to 
> establishment of the tunnel.  It has been stated many times 
> the end host must utilize the location received during the 
> first step, prior to tunnel establishment.  It would also be 
> prudent that location information not be passed during tunnel 
> establishment.
> 
> 3) In the case of a hardware VPN it is typical that the 
> remote device co-located with the end host provides network 
> configuration.  Location can be included at that time.
> 
> 
> > 
> > A simple HELD-based LIS/relay-service added to a home router will 
> > avoid the issues that have been described by Brian to the 
> same degree 
> > that they are avoided by DHCP. This is very easy to do and we have 
> > made this work in OpenWRT running on a linksys home-router.
> 
> > kinds of solutions in the base HELD specification, a BCP is more 
> > appropriate, though a mention of care would seem reasonable.
> 
> 6) As I stated in another email, in my experience, the IESG 
> will want applicability included in the base draft, but I'm 
> continually surprised by the IESG... :^)
> 
> 
> -Marc-
> 
> 
>