Subject: RE: [Ecrit] Emergency [VPN issue]

From: "James M. Polk" <[email-masked]>
Date: Sun, 11 Sep 2005 17:44:29 -0500

James

I don't understand the point you're making here.

Are you suggesting NENA believes a VPNd phone should not communicate over 
the VPN when calling <sos> ?

I don't believe this will be universally available

At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote:
>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 on the enterprise to ensure that it works.
>This makes the problem a little easier to deal with.
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
>Of
> > Rodrig, Benny (Benny)
> > Sent: Friday, 9 September 2005 9:14 AM
> > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner
>(mlinsner);
> > ECRIT
> > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-
> > ArchitectureConsiderations
> >
> > Not sure it's always possible for emergency calls to not go though the
> > corporate VPN. For example, the endpoint may have no means (e.g. no
>TURN
> > server) to establish a session directly through the NAT at the
>Backwater
> > Inn, in the example below.
> >
> > Benny
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Michael Hammer (mhammer)
> > Sent: Thursday, September 08, 2005 6:26 PM
> > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT
> > Subject: RE: [Ecrit]
> > EmergencyContextRoutingofInternetTechnologies-Architecture
> > Considerations
> >
> > Richard,
> >
> > My original question was about whether a PSAP should expect calls
> > (signaling and media) to originate from non-local destinations, e.g.
> > international, and by inference the need for the PSAPs to be able to
> > make call backs to those locations.  If not, then perhaps it is a DDoS
> > clue.
> >
> > Marc pointed out the VPN possibility.
> >
> > You seem to suggest that emergency calls should never go by VPN when
> > dialed.
> >
> > So, is the VPN situation a possibility or precluded?
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[email-masked]]
> > > Sent: Thursday, September 08, 2005 5:58 PM
> > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT
> > > Subject: Re: [Ecrit] Emergency
> > > ContextRoutingofInternetTechnologies-Architecture Considerations
> > >
> > > Sorry, but I am confused with this examples:
> > >
> > > Somebody sitting say in Chicago should get routed to a local PSAP in
> > > Chicago, regardless where his provider or sip-server is located
> > >
> > > If he is using a VPN to say a network in Berlin, he may either also
> > > get routed by some magic we still have to work out also to a PSAP in
> > > Chicago, or he is routed wrongly to a PSAP in Berlin.
> > >
> > > But, the PSAP in Berlin will at least get some location and also
>some
> > > identification from Berlin, at the network, so there is some local
> > > relationship
> > >
> > > So what is the point?
> > >
> > > -richard
> > >
> > > ________________________________
> > >
> > > Von: [email-masked] im Auftrag von Michael Hammer (mhammer)
> > > Gesendet: Do 08.09.2005 22:56
> > > An: Marc Linsner (mlinsner); ECRIT
> > > Betreff: RE: [Ecrit] Emergency
> > > ContextRoutingofInternetTechnologies-Architecture Considerations
> > >
> > >
> > >
> > > That is certainly possible.  I'm trying to get an idea of the
>assumed
> > > topology models here.  If the call gets dropped, does the PSAP make
>an
> >
> > > "international call" to call back such subscribers?  Could the call
> > > back number be a number in some Caribbean island that happens to be
>a
> > > 9xx equivalent?  Could Berlin Ind. send a 3xx response and say drop
> > > out of this VPN to make the call?
> > >
> > > In any case, your example proves the exception, so likely mine was a
> > > dead end thought.
> > >
> > > Mike
> > >
> > >
> > > > -----Original Message-----
> > > > From: Marc Linsner (mlinsner)
> > > > Sent: Thursday, September 08, 2005 4:18 PM
> > > > To: Michael Hammer (mhammer); 'ECRIT'
> > > > Subject: RE: [Ecrit] Emergency Context
> > > > RoutingofInternetTechnologies-Architecture Considerations
> > > >
> > > > How about an employee of Berlin Industries, Inc. sitting at the
> > > > Backwater Inn with a full vpn up to their corp. hq and calling for
> > > > help.  Wouldn't they look like they were coming from Berlin
> > > (the .ru
> > > > domain and IP address would probably be a hint)?  Do you
> > > want to block
> > > > them?
> > > >
> > > > I certainly think that it is reasonable to raise a flag to the
> > > > calltaker in this situation, but I wouldn't think you want
> > > to build a
> > > > state machine to simply block such calls.
> > > >
> > > > Replace Berlin with New Hampshire, New York, Mass........
> > > >
> > > > -Marc-
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf
> > > > > Of Michael Hammer (mhammer)
> > > > > Sent: Thursday, September 08, 2005 3:12 PM
> > > > > To: Ted Hardie; [email-masked];
> > > > [email-masked]; Andrew
> > > > > Newton; Stastny Richard; ECRIT
> > > > > Subject: RE: [Ecrit] Emergency Context
> > > > > RoutingofInternetTechnologies-Architecture Considerations
> > > > >
> > > > > Ted,
> > > > >
> > > > > I'm confused.  Are calls from Asia or Europe to the Vermont
> > > > PSAP ever
> > > > > legitimate?
> > > > >
> > > > > Somehow, I can't picture the local sheriff being able to
> > > > help someone
> > > > > in Berlin.  I thought the point of i3 is to enable the call
> > > > to go to
> > > > > the local Berlin Polizei.  Put another way, is it possible
> > > > to use the
> > > > > local nature of emergency service to protect agains DDoS?
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf
> > > > > > Of Ted Hardie
> > > > > > Sent: Thursday, September 08, 2005 1:55 PM
> > > > > > To: [email-masked]; [email-masked];
> > > > Andrew Newton;
> > > > > > Stastny Richard; ECRIT
> > > > > > Subject: RE: [Ecrit] Emergency Context Routing
> > > > > > ofInternetTechnologies-Architecture Considerations
> > > > > >
> > > > > > After reading the thread, I wanted to come back to Nate's
> > > > original
> > > > > > concern and call something out:
> > > > > >
> > > > > > >Here is the PSAP concern:
> > > > > > >
> > > > > > >An enterprising thief could figure out that a business
> > > > (without an
> > > > > > >alarm
> > > > > > >system) in Backwater, Vermont is served by a PSAP located 25
> > > > > > miles away.
> > > > > > >If one creates an IP-based denial of service attack on that
> > > > > > PSAP then
> > > > > > >it is safe to assume that the target of opportunity that the
> > > > > > thief is
> > > > > > >looking at in Backwater will not be able to contact the PSAP
> > > > > > to summon
> > > > > > >help.
> > > > > >
> > > > > > I'm assuming that the PSAP being 25 miles away means
> > > > nothing about
> > > > > > where the responders are.  The responders in this
> > > > instance might be
> > > > > > sheriffs, for example, who are stationed nearby, even
> > > > > further than 25
> > > > > > miles away, or whose patrol routes mean that their distance
> > > > > from the
> > > > > > target of opportunity is variable.  So I think we
> > > should cut the
> > > > > > distance from this description completely, and simply see
> > > > > the threat
> > > > > > as "If the bad actor can determine which PSAP serves an
> > > > > area in which
> > > > > > a target is present, a successful attack on the PSAP prevents
> > > > > > responses to the target".
> > > > > >
> > > > > > Does that make sense?
> > > > > >
> > > > > >
> > > > > > > Using PSTN technologies, an enterprising thief could create
> > > > > > a PSTN DoS
> > > > > > >on the PSAP by simply using an auto call generator from a
> > > > > pay phone
> > > > > > >located in the same proximity as the target of opportunity
> > > > > however,
> > > > > > >this would still create a response to the general area of
> > > > > the crime.
> > > > > >
> > > > > > There are lots of other kinds of PSTN attacks here--the
> > > > > most commonly
> > > > > > portrayed being "cutting the line", which doesn't work
> > > > quite as it
> > > > > > seems in the movies, but does have some effect.
> > > > > >
> > > > > > To avoid the locality problem in this attack, the bad actor
> > > > > can use an
> > > > > > accomplice, meat or mechanical, in any other area served by
> > > > > the PSAP
> > > > > > to do the same thing.  This avoids the response hitting
> > > > the general
> > > > > > area of the crime.  It also has the same counter-measure;
> > > > > > call-blocking of the attacking phone.  This counter-measure
> > > > > is  also
> > > > > > relatively easy to accomplish with an IP-based service,
> > > > > provided the
> > > > > > attack is coming from a single IP or block. I believe the
> > > > > problem is
> > > > > > harder in the IP case not because the area from which the
> > > > > attack can
> > > > > > originate is larger but because it is easier to create a
> > > > > Distributed
> > > > > > Denial of Service, largely because of zombie networks and
> > > > > IP spoofing.
> > > > > > That is, if the attack is coming from Europe while the
> > > attack is
> > > > > > happening on Backwater, my response is the same as if it
> > > > came from
> > > > > > Nearwater, VT:
> > > > > > block the attack source.  But if it is coming from
> > > Europe, Asia,
> > > > > > Nearwater, Backwater, and many other points as well,
> > > > > attempts to block
> > > > > > the attack either requires effectively severing connectivity
>or
> > > > > > maintaining a fair amount of information about who at the
> > > > IP layer
> > > > > > should be talking to this PSAP.  We've discussed the
> > > > > effectiveness of
> > > > > > that in the past.
> > > > > >
> > > > > > >If I
> > > > > > >know the URI of the PSAP, I can now distract it from another
> > > > > > continent
> > > > > > >and do what I would need to do in Backwater and no
> > > > > response would be
> > > > > > >created in that direction - that is the new paradigm with
> > > > > > IP. If I know
> > > > > > >the boundaries of the Derby PSAP, I could create a PSTN
> > > > based DoS
> > > > > > >attack anywhere from within that boundary (potentially 50
> > > > > miles from
> > > > > > >Island Pond).
> > > > > > >
> > > > > > >Would this happen? I don't know - I am pretty sure it
> > > > > hasn't yet but
> > > > > > >assigning a URI to a PSAP opens it up to whole new
> > > generation of
> > > > > > >"creative thinkers".....
> > > > > > >
> > > > > > >Of course we can minimize the impact on the PSAP at a
> > > > higher level
> > > > > > >gateway by throwing a huge amount of bandwidth at it and
> > > > > building in
> > > > > > >intelligent alternative routing on a robust firewall. But
> > > > > > that does not
> > > > > > >help in the interim between here and there when someone
> > > > gets their
> > > > > > >hands on the PSAP boundaries and realizes the attacks they
> > > > > > can initiate
> > > > > > >using the PSTN DoS approach.
> > > > > >
> > > > > > The problem with the proposed solution, I believe, is that
> > > > > aggregating
> > > > > > the access to a back-to-back user agent or all-knowing
> > > > > gateway is that
> > > > > > you have simply created a richer target for attack.  If I
> > > > > can marshal
> > > > > > a zombie group that takes out all of Vermont's PSAPs by
> > > > eliminating
> > > > > > the the gateway by DDoS, I have done far worse far more
> > > > > easily than I
> > > > > > could by individually attacking the PSAPs at their URIs.
> > > > > If I did it
> > > > > > in order to get at Backwater's target, I likely don't
> > > > care that the
> > > > > > general effect is larger--my purpose is met.
> > > > > >
> > > > > > Yes, it is easier to escalate the defenses at a single
> > > > > point and yes,
> > > > > > it is easier to pay for  fat pipes for that single point.
> > > > > But the bad
> > > > > > actors here aren't using their own resources to attack you;
> > > > > they are
> > > > > > stealing them before trying to steal from you.  Getting
> > > > > into an arms
> > > > > > race with someone who isn't spending their own money worries
>me.
> > > > > >
> > > > > >                   regards,
> > > > > >                           Ted
> > > > > >
> > > > > > _______________________________________________
> > > > > > Ecrit mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> > _______________________________________________
> > 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

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 11 Sep 2005 18:12:56 -0500

Hi James,

Actually that is not really the point that I am making. The point I was
making was that if the enterprise forces its remote staff to pass all
traffic through the VPN, including emergency calls, then the enterprise
is, for all intents and purposes the access provider, and is responsible
to ensure that the call will get to where it needs to go.

On the technology front I don't see why a solution shouldn't be
universal either. Change to soft-phones in firmware or software are
going to be required to get location, and if I understand the proposed
solutions correctly then, determine that the call is an emergency one
and provide location also. So I don't see that providing split tunneling
to cater for this is such a big deal. If enterprises elect not to deploy
or engage this functionality then the point of responsibility is clear.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Monday, 12 September 2005 8:44 AM
> To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard;
Marc
> Linsner (mlinsner); ECRIT
> Subject: RE: [Ecrit] Emergency [VPN issue]
> 
> James
> 
EmergencyContextRoutingofInternetTechnologies-
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 Sep 2005 10:42:04 -0500

At 06:12 PM 9/11/2005 -0500, Winterbottom, James wrote:
>Hi James,
>
>Actually that is not really the point that I am making.

that's why I asked for clarification

;-)

>The point I was

my concern here is the situation in which the client doesn't know where 
they are because their pre-VPN access provider didn't provide that info to 
the UA.  Almost no matter where the client is, they will be in a different 
PSAP jurisdiction than the corporation, meaning putting the burden on the 
corporation to provide location seems impossible to accomplish.

That said, the call should still be routed to a PSAP. This is why I believe 
<someone> needs to work on the PSAP-to-PSAP call transfer scenario, as the 
VPNd client could be inadvertantly routed to the corporate's PSAP some of 
the time too. This PSAP will ask where the person is, and then need to know 
what to do with the call. International call tranfers between PSAPs will be 
trick though.

This routing to the appropriate PSAP from a call transfer point of view 
should be addressed in ECRIT too, IMO, but it needs to be phase II of what 
we're doing here - and maybe nothing more than a short reqs ID and a 
separate short BCP.

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 14:18:28 -0500

At 10:03 AM 9/13/2005 -0400, Rodrig, Benny \(Benny\) wrote:
>My comment below was regarding the enterprise remote users connecting to
>the corporate network through a VPN from home or from e.g. some remote
>hotel. For that case, I was disagreeing with James's argument that the
>enterprise is the access provider if it requires all traffic to go
>through the VPN.

I don't believe I stated this, and if it read that way, I apologize because 
that is clearly not what I meant.  The call will go through the enterprise, 
but the caller is not connected physically to the enterprise, therefore the 
enterprise cannot know where the caller is, thus not be on the hook for 
providing location during the emergency call (which is what I was arguing 
against).

>It does not seem feasible for the enterprise to provide
>the user's location in this case.
>
>Benny

cheers,
James

                                 *******************

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Wed, 14 Sep 2005 15:42:50 -0400

James,

I meant the other James. I completely agree with you. It was a message
from James Winterbottom that seemed to suggest putting the enterprise on
the hook for that.

Benny 

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 3:18 PM
To: Rodrig, Benny (Benny); [email-masked]; Winterbottom, James; ECRIT
Subject: RE: [Ecrit] Emergency [VPN issue]

At 10:03 AM 9/13/2005 -0400, Rodrig, Benny \(Benny\) wrote:
>My comment below was regarding the enterprise remote users connecting 
>to the corporate network through a VPN from home or from e.g. some 
>remote hotel. For that case, I was disagreeing with James's argument 
>that the enterprise is the access provider if it requires all traffic 
>to go through the VPN.

I don't believe I stated this, and if it read that way, I apologize
because that is clearly not what I meant.  The call will go through the
enterprise, but the caller is not connected physically to the
enterprise, therefore the enterprise cannot know where the caller is,
thus not be on the hook for providing location during the emergency call
(which is what I was arguing against).

>It does not seem feasible for the enterprise to provide the user's 
>location in this case.
>
>Benny

cheers,
James

                                 *******************

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 Sep 2005 18:19:20 -0500

Hi Benny,

That is certainly not what I meant. I do believe that first IP in the
chain is responsible for providing location to the VEP, even if they
must acquire the information from someone else in the chain. 

The enterprise is however responsible to sure that the call gets
delivered to a suitable gateway that can handle the request, and this
latter part may include understanding PSAP filtering policies.

Cheers
James

> From: Rodrig, Benny (Benny) [mailto:[email-masked]]
> Sent: Thursday, 15 September 2005 5:43 AM
> To: James M. Polk; [email-masked]; Winterbottom, James; ECRIT