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

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Mon, 12 Sep 2005 09:54:13 -0400

James,

I don't see how the enterprise, even with a VPN policy, can be
considered an access provider. The concept of the access provider, as
opposed to the application service provider, implies some sort of
locality and hence knowledge of user's location. These do not shift from
the local Internet access provider to the remote enterprise headquarters
just because the endpoint is connecting through a VPN. 

Benny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Winterbottom, James
Sent: Sunday, September 11, 2005 7:13 PM
To: James M. Polk; ECRIT
Subject: RE: [Ecrit] Emergency [VPN issue]

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

> -----Original Message-----
> 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
> 
> 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.

------------------------------------------------------------------------
------------------------
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: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Sep 2005 07:07:59 -0400

Benny

There are some authentication issues with who is the source of location
information, but in general, I believe the enterprise IS the access
provider, it simply has an upstream access provider to it.  This is not
unlike a tier 2 or tier 3 ISP.  The point is that if an enterprise is large
enough, we need it to supply room-level location, and the access network to
it cannot do that.  In very large enterprises, the access provider may only
be at the headquarters location; remote sites may be served by private
networks.  In such cases we are wholly reliant on the enterprise to provide
accurate location.

Brian
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rodrig, Benny (Benny)
Sent: Monday, September 12, 2005 9:54 AM
To: Winterbottom, James; ECRIT
Subject: RE: [Ecrit] Emergency [VPN issue]

James,

Benny

-----Original Message-----

Hi James,

Cheers
James

Marc
over
people
this
Behalf
the
no
Behalf
e.g.
to
DDoS
when
PSAP in
also
PSAP in
local
(mhammer)
make
call
be
drop
was a
the
for

25
that
the
PSAP
distance
prevents
create
opportunity
actor
by
counter-measure
connectivity
another
they
you;
worries
--
--