RE: [Geopriv] HELD guidance for IP address ID

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Wed Nov 07 2007 - 22:27:58 EST

You are right, and this is the gist of Barbara’s text. If the server knows (and it had better know) then it can say no.

 

There are scenarios where the server can determine the location of a host on the other end of a VPN, but that’s more an exception than a rule. Most likely, Barbara’s recommendation that the VPN device act as a LIS is going to be needed. The VPN device could use its own (non-VPN) connection to acquire the necessary location information.

 

I think that this is a good general rule – if a VPN is established, whatever establishes that VPN should go outside the tunnel to acquire location information and become a LIS for those who are trapped within. If the VPN doesn’t capture all traffic, it’s not a problem.

 

________________________________

From: Tatham Oddie [mailto:tatham@oddie.com.au]
Sent: Thursday, 8 November 2007 2:12 PM
To: Thomson, Martin; peter_blatherwick@mitel.com; 'Stark, Barbara'
Cc: geopriv@ietf.org; 'Marc Linsner'
Subject: RE: [Geopriv] HELD guidance for IP address ID

 

Hi all,

 

Is it not also the LIS’s responsibility to not hand out information that it can’t reasonably believe to be accurate (ie. not issuing location information to known VPN clients)? If an LIS opts to not provide location data, the client should perform discovery on other interfaces. This way, the issue is mostly solved server-side, where knowledge of the VPN is mostly likely to exist.

 

I envision a process like:

 

1. Discovery occurs on “default” interface (as per routing table)

2. Query server – server responds “I don’t know where you are”

3. Discovery occurs on next interface

4. Etc

 

Is there a scenario where the information returned over the VPN would be useful at all (assuming no other data sources can be found)? This would mean that the first server would need to return the location data, as well as an “unsure” flag... That just makes things more complex and I can’t think of a benefit to it.

 

[ First post BTW – so please don’t shoot me down too much :) ]

 

 

Thanks,

 

Tatham Oddie

call:+61414275989 <callto:+61414275989> , call:+61280113982 <callto:+61280113982> , skype:tathamoddie <skype:tathamoddie?call> , msn:tatham@oddie.com.au <msnim:chat?contact=tatham@oddie.com.au> , tatham.oddie.com.au <http://tatham.oddie.com.au/>

 

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

 

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]

 

------------------------------------------------------------------------------------------------
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 21:27:58 -0600

This archive was generated by hypermail 2.1.8 : Wed Nov 07 2007 - 22:28:15 EST