RE: [Geopriv] HELD guidance for IP address ID

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Wed Nov 07 2007 - 21:56:41 EST

I wasn’t making a point about clever programming. I was saying that it is almost an unavoidable consequence of developing working software. That is, if it works at all, it’s highly likely that it works correctly as well.

 

Quibbles aside, I think we have consensus on putting the text in.

 

Cheers,

Martin

 

________________________________

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Thursday, 8 November 2007 1:48 PM
To: Stark, Barbara
Cc: geopriv@ietf.org; Marc Linsner
Subject: RE: [Geopriv] HELD guidance for IP address ID

 


Hi,

I have been trying to stay out of this now looong debate, but cannot any more... It is just giving me too much gas.

I side very strongly with the view of "simplicity is what will happen, no matter what we specify" in this. Wording below aside (which i think is a good improvement BTW), a fundamental issue with anything at L7 remains that the application doing the location determination may well have absolutely no idea what interface is being used, even if it can know. There is no easy way to absolutely guarantee that it is not going across VPN unless the application itself comes up before VPN -- not a practical constraint, especially for soft client apps. Yeah, clever programming can figure it out (as Martin points out) ... but WILL IT??? Always ???? Even then, there could still be other devices in path that implement VPN that are completely invisible to any application on the endpoint. In the end, especially on soft client type apps, developers will always err in favour of doing what is easy, and miss the subtle points. They will very often not even realize the subtle points exist. Possibility that there is a VLAN will be missed. Fire truck will roll to head office ... not where *I* currently am. Hate when that happens ....

We need to be use wording somewhat along these lines, but I think it needs to be written very strongly, and such that the query needs to be done before any application needing location can ask for it. Don't know how to write that, short of OS-level requirement.

-- Peter Blatherwick







 

"Stark, Barbara" <bs7652@att.com>

07.11.07 11:24

        
        To: "Marc Linsner" <mlinsner@cisco.com>, <geopriv@ietf.org>
        cc:
        Subject: RE: [Geopriv] HELD guidance for IP address ID




I've seen a number of VPNs that send Internet traffic across the local
network interface. But, I think that's beside the point. Would the
following rewording be better?

To minimize the impact of VPNs, endpoints using IP address as the HELD
identifier need to do their HELD query prior to establishing a VPN
tunnel.


-----Original Message-----
From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Wednesday, November 07, 2007 11:12 AM
To: Stark, Barbara; geopriv@ietf.org
Subject: RE: [Geopriv] HELD guidance for IP address ID

Barbara,

>
> To minimize the impact of VPNs that do not support split
> tunneling, endpoints using IP address as the HELD identifier
> need to do their HELD query prior to establishing a VPN tunnel.
>

Even if the VPN soft client supports split tunneling (allowing traffic
on
the local subnet as well as the tunnel), this does not guarantee that
HELD
will work. When an end host has more than one interface, in this case a
tunnel interface and local network interface, you must be ensure that
the
routing table in the host sends the HELD request via the correct
interface
otherwise the request will arrive at the LIS with an unknown source
address
on the packet. My experience has been that VPN tunnel establishment
modifies the host routing table such that the only traffic put out the
local
network interface is traffic destined for that subnet (the default
gateway
is on the tunnel).

-Marc-


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 7 Nov 2007 20:56:41 -0600

This archive was generated by hypermail 2.1.8 : Wed Nov 07 2007 - 21:56:56 EST