[Top] [All Lists]

RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architectur

Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations
From: "Winterbottom, James"
Date: Thu, 8 Sep 2005 18:36:18 -0500
Hi Ted,

My assumption would be that a large gateway box that services 20 or 100
PSAPs will require any attacker to mass several orders of magnitude more
zombies to launch a successful attack, than they would require to attack
a single PSAP. Maybe this is easy, I don't know, but it does up the anti

All this aside, I think that there are economies of scale, and
functionality reasons why including a gateway such an ESRP are
desirable, but these are more implementation details. Somewhere,
something has to have sufficient knowledge to use location to route the
signal to the next hop.


> -----Original Message-----
> From: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] On Behalf
> Ted Hardie
> Sent: Friday, 9 September 2005 3:55 AM
> To: wilcox@xxxxxxxxxxxxxxxxxxxx; br@xxxxxxxxxxxxxx; Andrew Newton;
> Richard; ECRIT
> Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-
> Architecture Considerations
> After reading the thread, I wanted to come back to Nate's original
> and call something out:
> >Here is the PSAP concern:
> >
> >An enterprising thief could figure out that a business (without an
> >system) in Backwater, Vermont is served by a PSAP located 25 miles
> >If one creates an IP-based denial of service attack on that PSAP then
> >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
> >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
> 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
> >located in the same proximity as the target of opportunity however,
> >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
> the area
> from which the attack can originate is larger but because it is easier
> create a
> Distributed Denial of Service, largely because of zombie networks and
> spoofing.
> That is, if the attack is coming from Europe while the attack is
> 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
> 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
> >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
> >the boundaries of the Derby PSAP, I could create a PSTN based DoS
> >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
> >help in the interim between here and there when someone gets their
> >on the PSAP boundaries and realizes the attacks they can initiate
> >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 gateway by DDoS, I have done far worse far more easily than I
> by individually attacking the PSAPs at their URIs.  If I did it in
> 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,
> is easier to
> pay for  fat pipes for that single point.  But the bad actors here
> 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

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.

Ecrit mailing list

<Prev in Thread] Current Thread [Next in Thread>