[RPSEC] Topic 1: Section 3.1 Threat Sources

[[e-mail]]

Section 3.1 Threat Sources says:

   Specifically, threats can be classified into four categories, based
   on their sources [DV-SECURITY]:

I'd like to see some changes in this categorization.

(1) The use of the term "compromised" is defined to mean faulty or
misconfigured routers.  In the first place, this leaves out subverted
routers, which is a big concern.  Secondly, to most people, the term
"compromised" means "subverted", not faulty.  So the text uses a term
with a typical meaning to mean everything except the typical meaning.
Were subverted routers left out on purpose?

(2) The outsiders are divided into "unauthorized devices" and
"masquerading devices".

(2.a) That doesn't apply to some (many?) protocols.

For some protocols, there is no sense of an authorized peer.  For
OSPF (that is, before the MD5 part got added), OSPF speaks to all
routers on the local link that answer to the AllSPFRouters multicast
address.  MANET protocols frequently speak over the broadcast link
(as mentioned earlier in the draft).  And so forth.

(2.b) There's no good reason to make the distinction.

When I spoke at the last IETF, I said that there is never a case
(i.e., I grepped and I couldn't find one) where the attacks that can
be launched by the masqueraders are different from the attacks that
can be launched by the unauthorized routers (except spoofing, which is
a tautology - if you spoof, you are a masquerader, if you are a
masquerader, you are spoofing).

(2.c) It's misleading, security wise.

When I saw this in the draft, I got to thinking about what makes a
threat source distinct.  A threat source should be considered
separately if it has a capability that gives it extra power, if it can
launch attacks that others cannot, or if there are security
defenses that work against it and not against others.  Now an
unauthorized router has the same capabilities and can perform the same
attacks as a masquerader, but it can be eliminated by doing pure
address based filtering of some sort where masqueraders cannot.

By that criterion, the unauthorized router is a separate threat source
only if one considers pure address based filtering as a "security
defense".

I don't.  In a big way, I don't.  To call such an easily circumvented
mechanism a security defense makes me extremely uneasy.

I was emboldened to speak up about this by reading the IAS security
mechanisms draft draft-iab-secmech-02.txt that came out a few weeks
ago.  Bellovin, Kaufman and Schiller list address-based authentication
as an "Insecurity Mechanism", along with plaintext passwords (emphasis
on the "In").  To quote, "Some common security mechanisms are part of
the problem rather than part of the solution."

I think if we left unauthorized routers as a distinct threat source,
we'd see claims like ".. and our ACME router's address filtering
eliminates unauthorized routers, recognized by the IETF as one of the
biggest threats to routing.."

Just so you know - faulty/misconfigured/subverted routers definitely
are distinct from the outsiders - they can do more damage because they
have access to context and timing and they can't be eliminated by the
strong authentication mechanisms that would eliminate outsiders.

(3) Compromised links terminology

[Nitpick: links never do things - it is the hosts that are
compromising the links who do things.  This terminology leads to
sentences like "Compromised links can sniff the links over which they
have control."]

As stated in the text, these threat sources are acting "without
participating in the routing exchange".  So these threats are
attacking the transport subsystem, as mentioned in Section 2.  Can we
say that routing protocol designers should do anything about these
threat sources?  Can AODV do anything to prevent jamming?  The BGP
world had a similar problem in that injected TCP RST's could break a
connection.  This was solved in the current draft by mandating that
BGP must always be used in conjunction with TCP MD5 (RFC2385) - in
other words, they mandated a use scenario, they did not solve the
problem in the protocol.

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