ecrit@ietf.org
[Top] [All Lists]

RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-Architecture C

Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-Architecture Considerations
From: "Rodrig, Benny \(Benny\)"
Date: Thu, 8 Sep 2005 19:13:53 -0400
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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] 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:Richard.Stastny@xxxxxxxx]
> 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: ecrit-bounces@xxxxxxxx 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: ecrit-bounces@xxxxxxxx
> > [mailto:ecrit-bounces@xxxxxxxx] On Behalf
> > > Of Michael Hammer (mhammer)
> > > Sent: Thursday, September 08, 2005 3:12 PM
> > > To: Ted Hardie; wilcox@xxxxxxxxxxxxxxxxxxxx;
> > br@xxxxxxxxxxxxxx; 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: ecrit-bounces@xxxxxxxx
> > > [mailto:ecrit-bounces@xxxxxxxx] On Behalf
> > > > Of Ted Hardie
> > > > Sent: Thursday, September 08, 2005 1:55 PM
> > > > To: wilcox@xxxxxxxxxxxxxxxxxxxx; br@xxxxxxxxxxxxxx;
> > 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
> > > > Ecrit@xxxxxxxx
> > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@xxxxxxxx
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-Architecture Considerations, Rodrig, Benny \(Benny\) <=