Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations

From: "Abbott, Nadine B" <[email-masked]>
Date: Fri, 9 Sep 2005 10:22:19 -0400

I admit I am a bit confused about exactly which requirement is being
debated/tailored...but if I'm not too far off...

It seems to me that the proposed requirement could be stated:
An emergency call should be able to be originated remotely via a VPN
through an enterprise network, and accurate location information for the
caller should be made available to route the call.

If the caller's IP device is capable of supporting a method for
acquiring its location (with or without the assistance of its local
access network), and is capable of storing and passing its location
information with call signaling in a PIDF-LO, then it is the
responsibility of the enterprise to pass that location information along
with the call. This makes it possible for an emergency call from an IP
device remotely connected to the enterprise VPN to still have its call
routed to the correct PSAP based on the caller's location.

The point of greatest difficulty is when either the IP device or its
local Internet access provider cannot support a method for the IP device
to acquire its location.  In this case, when the remote user originates
a call using a VPN to the enterprise, the enterprise must somehow
acquire location on-behalf-of the location-incapable/unaware device.
This is of concern in the real world because there are lots of existing
devices and networks that do not as yet support these capabilities. I
believe there are existing enterprise solutions that use provisioning to
support relatively static access via VPNs (e.g., the telecommuter with a
fixed home address). But the problem of the road warrior is much more
difficult. 

If we assume that it is the Internet access provider that is aware of
the remote IP device's location, then the road warrior problem requires
the enterprise to not only discover the IP device's Internet access
provider from among all possible Internet access providers, but also to
be able to exchange information necessary to determine the caller's
location with all such possible Internet access providers on-behalf-of
the IP device.  There is much discussion in North American forums about
what it might take to make this possible.
However, this IS a very complex problem, and the comments below seem to
be a pragmatic recognition that it may be a lot simpler for the
enterprise to supply its roaming members with IP devices that are
capable of automatically acquiring and passing location, than to support
the mechanisms necessary to acquire location information remotely on
their behalf. (Not to mention how much simpler it would also make life
for the Internet access providers.)

If the requirement is that emergency calls should be able to be
originated remotely via VPNs through an enterprise and that accurate
location information must be available to route the call, then there are
various solutions that can meet this requirement and these solutions
place varying degrees of responsibility on the enterprise and its IP
devices (with only a few possible examples sketched above).  It seems to
me that the enterprise that supports the VPN is the entity in the best
position to take ownership of the problem.  I think that maybe this is
not so much tailoring the requirement as it is an acknowledgment that
some solutions may be better than others in meeting the requirement? 

I might suggest a clarification to the requirement, e.g.,
If an emergency call is originated remotely via a VPN through an
enterprise network, the enterprise shall ensure that accurate location
information for the caller is made available to route the call.

I do not think that this tailors the requirement to a particular
solution, but it does identify responsibility for the solution and makes
use of a VPN for this purpose conditional upon implementation of a
solution.

Nadine

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner
Sent: Friday, September 09, 2005 8:14 AM
To: 'Winterbottom, James'; 'Michael Hammer (mhammer)'; 'Stastny
Richard'; 'ECRIT'
Subject: RE:
[Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConside
rations

I'm amused at the tayloring of requirements to meet solutions.

:^)

-Marc- 

> -----Original Message-----
> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Thursday, September 08, 2005 8:36 PM
> To: Marc Linsner; Michael Hammer (mhammer); Stastny Richard; ECRIT
> Subject: RE: [Ecrit] 
> EmergencyContextRoutingofInternetTechnologies-ArchitectureCons
iderations
> 
> It is also a way to eliminate draconian IS policies.. ;)
> 
> > -----Original Message-----
> > From: Marc Linsner [mailto:[email-masked]]
> > Sent: Friday, 9 September 2005 10:30 AM
> > To: Winterbottom, James; 'Michael Hammer (mhammer)'; 'Stastny
> Richard';
> > 'ECRIT'
> > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-
> > ArchitectureConsiderations
> > 
> > 
> > >
> > > This issue has been discussed in NENA at quite some length. The 
> > > consensus that is growing there, and I know that
> there are some
> > > people that still disagree, is that if an enterprise is
> prepared to
> > > allow this to occur, that the onus is-Maqr on the enterprise to
> > > ensure that it works.
> > > This makes the problem a little easier to deal with.
> > 
> > That's one way to eliminate difficult requirements.... :^)
> > 
> > -Marc-
> > 
> 
> --------------------------------------------------------------
> ----------------------------------
> 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: Henning Schulzrinne <[email-masked]>
Date: Fri, 09 Sep 2005 20:44:55 -0400

> for the Internet access providers.)

Not to mention issues of privacy - the Internet service provider has no 
clue that this is an emergency call and it seems rather difficult for 
some random hotel 802.11 provider to recognize hundreds of thousands of 
businesses, many of them in a different country than that provider, to 
make sure that this is indeed a legitimate request.

> some solutions may be better than others in meeting the requirement? 

At least some of the VPN software can be configured not to route 
"random" (non-corporate) Internet addresses via the VPN at all. This 
makes some sense - there is little benefit of visiting the web page of 
some outfit by tromboning or hairpinning (to use the PSTN equivalents) 
via the corporate campus. Maybe such configurations will become more 
common, given these difficulties (or OS will support the ability to 
select the non-VPN interface explicitly when opening a socket.)

---

From: John Schnizlein <[email-masked]>
Date: Sat, 10 Sep 2005 10:21:14 -0400

A valid reason for organizations that deploy Internet VPNs to prohibit 
split tunneling, with some traffic through the VPN tunnel and some 
straight to Internet destinations, is control of the corporate network 
perimeter.  A host with split tunneling is exposed to worms and other 
security threats through its access outside the VPN.  Because it is 
also inside the VPN, this host is a disease vector between the outside 
and inside.

It would be a serious mistake to force a choice between this valid 
deployment of VPN technology and location information access for 
emergency services.

John

---

From: John Rosenberg <[email-masked]>
Date: Mon, 12 Sep 2005 09:28:47 -0500

Have to agree with John here. As one data point, our own corporate VPN does 
not allow split tunneling, and our IT folks are *very* clear that even 
connecting a PC that's on the VPN to another network (e.g. the public 
internet) is prohibited. I would think that this is the rule rather than 
the exception.

John

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Sep 2005 11:43:33 -0400

I have a feeling this takes an overly optimistic view of the cleanliness 
of the corporate network.  It's possible IT thinking has moved on from 
this position -- one I recognize -- to realize that every host has to be 
responsible for its own protection.

John Schnizlein wrote:
> security threats through its access outside the VPN.  Because it is also 
> inside the VPN, this host is a disease vector between the outside and 
> inside.
> 
...