Subject: [RPSEC] Topic 1: Section 3.1 Threat Sources

From: [email-masked]
Date: Tue, 11 Mar 2003 17:34:29 -0500 (EST)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Mar 2003 10:39:48 +0100 (CET)

On Tue, 11 Mar 2003 [email-masked] wrote:

[This may be stupid... but I'm not sure which document you're talking
about here.]

> mechanism a security defense makes me extremely uneasy.

We should first say what we mean by "address based filtering". Addresses
show up in many places performing many different roles in routing
protocols. But phrased along the following lines I fully agree:
"filtering based on the unauthenticated source address in the IP header
of routing protocol messages can never be considered to provide any
security at all; this functionality, if implemented, should be
assumed to protect only against accidental configuration errors".

---

From: Yi Yang <[email-masked]>
Date: Fri, 14 Mar 2003 16:40:28 -0500 (EST)

Sandy,

> (as mentioned earlier in the draft).  And so forth.

You are right. IMHO, however, this is because in most IGPs, authentication
(such as MD5) is used a mechanism of authorization, instead of
identication. And current implementations just don't care the
identification in most cases.

But in the future, we might also want to care about the identification as
well.

> biggest threats to routing.."

I agree w/ you using a pure address filtering mechanism is insecure. But I
don't think it is the only mechanism to seperate masqueraders from the
unauthorized. For example, digital signature can be used for
identification while MD5 can be used for authorization.

Yi

---

From: Russ White <[email-masked]>
Date: Sat, 15 Mar 2003 08:18:57 -0500 (Eastern Standard Time)

> Were subverted routers left out on purpose?

I think we talked about this before, but I still think we should probably
seperate the idea of a compromised router and a faulty router, even if the
impact is the same. It's just confusing to the reader.

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

Yes, I can see the tautology here--if you're not expecting authorization,
then there's no such thing as an unauthorized device. If there is
authorization, there's no way in but to masquerade. I'd probably agree with
taking these out, at first glance.

> sentences like "Compromised links can sniff the links over which they

Agreed, this should be cleaned up.

> 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?

I think we can mention these attacks, since the RP designers should/could
look at thes transport they are using, and try to help the designers of
those transports build better security into them. It's also helpful to
analyse these to make certain there's nothing you can do in your protocol
design to try and make these sorts of attacks harder in any way.

But we certainly can't lay any requirements on the rp designer in relation
to transport attacks.

:-)

Russ

--
[email-masked] CCIE <>< Grace Alone
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: "Dijiang Huang" <[email-masked]>
Date: Sat, 15 Mar 2003 09:56:38 -0600

Russ,

> taking these out, at first glance.
I think the terms "authorized" and "unauthorized" are a little bit confuse.
For example, in ospf, suppose if a router is an eligible routing exchanger,
when it modifies or forges
other routers' routing information, is it masquerading or not? It is
authorized
to send and receive routing information, but it is not authorized to changed
others
routing information. I think the authorized region should be clarified. But,
somehow,
this will make is complicate. Cause different protocols have different
behaviors, such
as link state and distance vector.

--Dijiang

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Mar 2003 10:22:31 -0500

>identification while MD5 can be used for authorization.

MD5 is an un-keyed integrity mechanism. Hashed MACs, like HMAC, can 
be used for authentication to the extent that the key used with them 
is associated with known entities. The keyed MD5 checksum sometimes 
used with BGP is a cryptographically poor example of a hashed MAC.

In no case should one consider MD5 to be an authorization mechanism.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2003 11:50:22 -0500

>as link state and distance vector.

Masquarading is asserting an identity other than one's own, and thus 
it is an attack against authentication.  Changing data passed on by 
another router, outside the constraints allowed by a routing 
protocol, is an integrity attack against that data, more than an 
authentication attack.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2003 11:50:22 -0500

>impact is the same. It's just confusing to the reader.

It's appropriate to note that both benign and malicious failures of 
routers are of concern. As you note, they are separable in that there 
are different paths by which each of these problems arises. From a 
security perspective, Byzantine failures are indistinguishable from 
benign failures, so we do tend to lump them together from the 
perspective of what we need to do to deal with both forms of failures.

>But we certainly can't lay any requirements on the rp designer in relation

Routing protocol designers get to choose the transport protocols that 
they employ, and so it is appropriate to discuss the implications of 
different choices of transport protocols, right?

Steve

---

From: "Dijiang Huang" <[email-masked]>
Date: Tue, 18 Mar 2003 11:08:06 -0600

> protocol, is an integrity attack against that data, more than an

I agree Changing data passed on by another router should be the problem
targeted
by integrity check. But, when this router sends the modified/forged routing
data
out, it also impersonates other routers for those routing
data belongs to.

--Dijiang

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2003 12:42:21 -0500

>out, it also impersonates other routers for those routing

One can distinguish between masquerading as a router (an 
authentication issue) vs. making unauthorized changes to routing data 
(an integrity or authorization issue) and we ought not confuse the 
two.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 18 Mar 2003 20:31:14 -0500 (EST)

> routers are of concern. As you note, they are separable in that there are
> different paths by which each of these problems arises. From a security
> perspective, Byzantine failures are indistinguishable from benign
> failures, so we do tend to lump them together from the perspective of
> what we need to do to deal with both forms of failures.

Yes, I agree. It seems to me that it's worth defining the difference, but
then treating them as the same after explaining why the doc treats them the
same, after that explaination (?). I think that made sense, anyway.

> different choices of transport protocols, right?

Right.... So, maybe there should be at least some area in the threats doc,
and a corresponding area in the requirements (suggestions) doc, which talks
about the choice of transport, and the security implications of that
choice.

Hmmm... Perhaps that section should actually be split off and made into a
seperate doc, since it could be argued, as above, that it's not a part of
the "protocol?"

Thoughts?

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Mar 2003 12:46:17 -0500

At 8:31 PM -0500 3/18/03, Russ White wrote:
>	<SNIP>

One could separate the transport protocol security issues, but I 
don't think the threat analysis will be so big as to warrant that.

Steve