Subject: Re: [RPSEC] a link to my threat draft

From: [email-masked]
Date: Wed, 13 Nov 2002 09:53:01 -0500 (EST)

>Building an ultrasecure protocol and running it on flimsy boxes doesn't
>help. Building extremely secure routers and then run vulnerable
>protocols on them doesn't either. There must be an integrated approach.

Well, sure, but nothing we require of routing protocols can effect
whether the box is flimsy or not.

>One very important question is: what amount of damage do we think is
>acceptable when an attack is launched from the inside, either by someone
>with legitimate access to a router, or when a router is compromised? Ie
>do we want our cops to walk around in their bullet proof vests at the
>police station in case another cop starts shooting, or are they supposed
>to be safe inside? Both approaches have their advantages, but this
>question exists on a more fundamental level than just routing _protocol_
>security.

You can't prevent all damage, all the time.  But that doesn't mean
you shouldn't try to prevent any damage, any time.  And routing protocols
are in a special category, since decisions locally can cause damage
over a wide spread area.  Kind of like a country deciding not to
vaccinate its citizens as too costly - diseases spread across borders.

When the damage to the rest of the universe caused by a legitimate
participant is severe, you need to provide as much protection as you
can in the protocol.  If that is impossible or deemed too costly, then
you have to consider other non-protocol mechanisms for reducing the
risk.  These are usually administrative controls - which gets into
scary territory real quick, like regulatory agencies deciding who can
be a player in a protocol based on configuration management and
quality controls and security.  There already are registries, sure,
but their use is voluntary.

>About the rest of the draft: it is a good enumeration of all possible
>bad things that can happen, but each exists in a vacuum. Which threats
>are so easy to eliminate that we shouldn't waste time focussing on them?
>Which are so hard to eliminate we shouldn't even bother trying? What
>kind of damage can we expect?

[What do you mean by "threat" - "threat consequence" (i.e., damage),
"threat action" (i.e., attack), "threat source" (i.e., attacker)?]

The damages I list as the threat consequences.  One of the reasons
why I listed them is I've seen proposed security solutions for some
routing protocols that addressed just one type of damage to the net,
not the underlying attack or vulnerability.  So the other types
of damage would still be possible even with the security solution
in place.

One attack (threat action) can be used to bring about lots of
different kinds of damage, so we can't just focus on one type of
damage.  And the damage that can be caused by an attack varies a
whole lot by protocol.  And the cost of preventing the attacks
vary a whole lot by protocol, so eliminating an attack (threat
action) or attacker (threat source) from an overall discussion
is premature.

--Sandy
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec