RE: [emergency] CAP and DDoS

[Art Botterell <acb@incident.com>]

Emergency managers have been waiting since the '70s for an ideal 
armor-plated communications infrastructure... much longer than that 
if we consider the civil defense/military precursors to modern 
emergency management.  Even if such a virtual Maginot Line is 
possible... and there's both historical and theoretical evidence to 
suggest that it may not be... we've waited a couple of decades 
already and suffered many terrible losses.

The integrated-diversity model is a viable, demonstrated, 
theoretically sound and... most important... already-deliverable 
approach to the problems of reliability.  While we certainly want to 
see improvements in the infrastructure... and our Infrastructure 
Subcommittee has already been working on that problem for almost a 
year now... that's no excuse not to do what we can to enhance public 
safety and homeland security in the meantime.

- Art


At 12:15 PM -0600 2/7/04, Bullard, Claude L (Len) wrote:
>The DDoS problem has been known since the eighties.
>This isn't not noticing, Art.  This is ignoring.
>This is dangerous.  As you note, the forces to
>deploy on 80/20 engineered solutions are powerful
>but they are resistable.  
>
>It is time for a consortium of companies to form
>with a mandate to create the network infrastructure
>capable of safe and reliable network communications
>for mission critical services.  It may not be cheap,
>but cheap and 'running code', the whole 80/20
>nonsense are too risky for mission critical services.
>
>We cannot let the golem run the village.  We risk
>too much when we couple Federal dollars to the
>agendas of 'cheaper, faster, better'.  Evolving
>TCP/IP may not be an option.  That is the first
>problem to solve, not the last one.
>
>len
>
>
>From: Art Botterell [mailto:acb@incident.com]
>
>Len, Rex, et al. -
>
>What you're rightly describing is a broad, deep and enduring
>challenge in emergency management generally.  Obvious near-term
>efficiencies frequently come with hidden costs to resilience and
>adaptability that are only noticed once it's too late.
>
>Whether we're talking about structural vulnerabilities in
>sophisticated works of engineering (e.g., WTC/Space Shuttle),
>economic and logistical brittleness caused by just-in-time inventory
>practices (West Coast Longshoremen strike), foreseeable hazards
>resulting from poor land-use choices (many if not most floods),
>operational vulnerabilities that accompany application and
>operating-system monoculture in IT (MyDoom, Slammer, et al.), or the
>perils of putting all our eggs in one telecommunications basket...
>and the list of examples can go on and on... the pattern is that
>apparent convenience and economy can easily distract our attention
>from the strategic implications of our choices.
>
>Emergency management professionals are only too aware of this
>fundamental trade-off, but they also know that the policy-makers they
>work for are under relentless pressure from the obvious and the
>immediate.  For example, TCP/IP networks can be made highly reliable,
>but they're usually engineered for profitability more than
>reliability.  And any single technology is a potential
>single-point-of-failure, but the costs of diversity are seen daily
>while the rewards appear only occasionally.  It's a constant struggle
>to stretch the horizons of corporate or governmental decision-making
>beyond the immediate and the familiar.
>
>(Frequently... tragically... the only time we see decision-makers
>achieve a clear focus on issues of preparedness, hazard mitigation
>and systemic resilience is right after the community suffers some
>serious loss.  It's a hell of a way to make progress,  but sometimes
>it's the only way it happens.  Thus public safety and security has
>advanced in fits and starts over the years, too often punctuated by
>horror.)
>
>So yes, this is an issue I hope we'll all strive to communicate,
>clearly and consistently.  It certainly features prominently in the
>briefing PPW will be providing at NEMA next week... although again
>that's mostly preaching to the choir.  The EIC will have an even more
>important audience during the March session on the Hill.
>
>- Art
>
>
>At 12:42 PM -0600 2/6/04, Bullard, Claude L (Len) wrote:
>>And that message should be communicated.  Otherwise,
>>good intentions over flaky protocols will filter
>>into the infrastructure.  A problem of the current
>>environment is that too many in the Beltway and
>>elsewhere are drinking the HTTP/REST/IP kool-aid and
>>not taking into account the unreliability and
>>vulnerabilities of the base TCP/IP infrastructure.
>>So Federal dollars will be attached to agency
>>procurements based on those technologies.
>>
>>Some will understand and refuse to build it
>>for mission critical applications; some won't.
>>
>>Be sure the message is clear and the risks
>>are well-explained.  An XML document doesn't buy
>>them security or protection.  Being agnostic
>>and failing to explain the need to completely
>>assess the risk of the transport are different.
>>
>>Thanks!
>>
>>len
>>
>>
>>From: Art Botterell [mailto:acb@incident.com]
>>
>>At 5:09 PM -0600 2/5/04, Bullard, Claude L (Len) wrote:
>>>Perhaps out of scope, but of interest:  how  would Distributed
>>>Denial of Service (DDoS) attacks affect the capabilities of systems
>>>using CAP?  Pretty much as it would affect  any IP server, yes?
>>
>>Right.  In fact, any transport mechanism is vulnerable to some sort
>>of denial-of-service attack, be it Internet-based DDOS,
>>radio-frequency jamming or even plain old-fashioned "backhoe fade."
>>
>>This is one of the reasons we've all worked so hard to keep CAP
>>transport-independent.  Technical diversity, through the integrated
>>use of a combination of distinct transport technologies, is one of
>>the best ways to mitigate the risk of DoS attacks and accidents.
>>It's a lot harder to jam every technology at once than it is to jam
>>any one at a time.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgro
>up.php.