Subject: [RPSEC] DDoS of routing ?

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Thu, 13 Mar 2003 06:47:57 -0600

while a DoS attack of routing pkts by a peer can lead to RT 
exhaustion, is DDoS of routing pkts observed previously? 
Actually, i had an offline discussion with sandy long back and she 
mentioned that it doesn't exist.

context: zinin-rtg-dos-00 
I guess, zinin draft talks only about DDoS of data traffic.
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Mar 2003 14:58:00 +0100 (CET)

> exhaustion, is DDoS of routing pkts observed previously?

I think attacks on port 179 of routers have been observed in the wild.

> mentioned that it doesn't exist.

You're not saying we should wait to fix holes until someone falls in
them, are you?

At the same time, IGPs are somewhat hard to attack as they use
multicasts that routers aren't going to forward.

> I guess, zinin draft talks only about DDoS of data traffic.

Doesn't look that way to me. One point we should all take to heart:

  "It is interesting to observe that as security
   mechanisms in routing protocols become more sophisticated and
   computationally expensive, it becomes easier for an attacker to mount
   a CPU-exhaustion-based attack against a router."

---

From: Alex Zinin <[email-masked]>
Date: Thu, 13 Mar 2003 18:55:21 -0800

Iljitsch, Senthil-

<AD hat off wrt this draft>

> I think attacks on port 179 of routers have been observed in the wild.

This is what I have heard second hand too.

Note, btw, that user-level attacks against routers are not limited to
those using routing protocols or targeted to CPU/queue exhaustion.
Vulnerabilities related to various forms of buffer overflow, and other
implementations bugs/suboptimalities have been known for long time.
Those can be potentially exploited too.

And the attacks are getting more and more sophisticated, an example
is the recently announced OSPF exploit where an attacker can make
a router execute malicious code.

> multicasts that routers aren't going to forward.

This is not entirely true.

IS-IS is indeed not susceptible to user-level attacks, as, in its
original form it uses L2 encapsulation for its PDUs, and because those
are unroutable, a user can't sent an IS-IS packet to a router.
However, I'm hearing that some vendors have actually implemented
ISIS-over-IPv4 though it wasn't accepted by the IS-IS WG. This could
leave a potential backdoor for an attacker if the implementation just
listens to this IP protocol or has it enabled on a set of interfaces.
It would be as good/bad as in the OSPF case, no extra.

OSPF, on the other hand, uses unicast quite extensively. First, on
broadcast media all neighbor-to-neighbor OSPF packet exchanges from
ExStart and higher are done in unicast. Plus we have virtual links
that are exclusively unicast. Besides, the specification suggests to
treat both unicast and multicast packets equally, which is what many
implementations do, especially if they allow manually configured
neighbors. So, it is very possible for an attacker to send a packet to
a router and it will be allowed to go all the way up to the OSPF
process (unless MD5 is done on the LC, of course).

> Doesn't look that way to me.

Right.

In fact, it does not talk at all about data traffic DDoS. It is all
about protecting routers' control plane from user-level attacks.

Alex

---

From: John Ioannidis <[email-masked]>
Date: Thu, 13 Mar 2003 23:49:46 -0500

DoS attacks on the BGP port are apparently fairly common, at least
according to what I heard at the last NANOG.  The problem is that the
pipe *to* the RP in many current routers is not all that fat, and even
a small flooding attack against port 179 can take out the RP, and
hence the router.

That particular vulnerability is fairly easy to fix; just deny
anything *to* port 179 that's not coming from an adjacent router (that
is, with TTL 255 or 254, depending on exactly what you are running),
and that can stop all simple attacks.  Obviously, this doesn't work
against multihop BGP; there you need crypto that's actually terminated
at the line card (or outside the router); again, you don't want the
cryptographic verification of your packets happening on the RP, for
obvious reasons.

/ji

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Mar 2003 06:30:51 +0100 (CET)

> and that can stop all simple attacks.

Overloading the path to the CPU can be done using any service that must
be terminated on the CPU, which is much more than routing protocols:
telnet/ssh, ICMP, any packet with TTL 1... Unfortunately, there is no
one size fits all solution here as far that I'm aware of.

> Obviously, this doesn't work
> at the line card (or outside the router);

When fighting DoS, crypto is NOT your friend. In nearly all cases, it
just makes the problem worse. I haven't heard of any vendor who includes
line rate MD5 processing on the linecard (good luck doing this at 10
Gbps anyway...) _just_ to protect ebgp-multihop BGP sessions.

A better way to deal with this is use some kind of magic cookie in each
packet that can be precomputed and easily checked. For instance, each
segment includes an MD5 over the previous segment and a secret key.
Since the MD5 operation needs to be done only after processing a valid
segment rather than after each segment, an attacker can't trigger
unnecessary MD5 operations, just some 16 byte compare operations. These
are somewhat less costly to implement in a linecard than even the
fastest crypto...

Iljitsch

---

From: Alex Zinin <[email-masked]>
Date: Thu, 13 Mar 2003 21:38:28 -0800

JI,

> a small flooding attack against port 179 can take out the RP, and

The problem is actually not BGP specific. BGP (as well as OSPF, or
LDP) just opens a generic queue and CPU exhaustion vulnerability.
Whenever a potentially forged packet (be that OSPF, RIP, or BGP)
shares resources with a valid packet (any type again), an attack is
possible.

Strictly speaking, the attack is not even MD5-specific, MD5 just
makes its success chances higher because it reduces the rate of
queue draining and increases CPU utilization.

> against multihop BGP;

Correct. BTSH solves a very focused problem--eBGP. The TTL hack
principle could be described using the notion of "trust radius", which
is (255-TTL). When it is 0 or 1, you're fine, because you don't expect
an attacker to be so close to your eBGP speaker. Once you increase it,
the probability of an attacker being within the trust proximity grows
very fast. So, this does not work for iBGP, or OSPF VLs (as well as
other multihop protocols used within a SP's network such as SSH or
SNMP).

> there you need crypto that's actually terminated

draft-zinin-rtg actually tries to solve a generic problem of attacks
from users (the iBGP and OSPF included) without the need for
additional HW, which should allow it to be implemented even on already
installed routers.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Fri, 14 Mar 2003 12:26:10 -0800

Iljitsch,

> one size fits all solution here as far that I'm aware of.

BTW, a little unrelated, but still within the topic: from the router
DoS protection point of view, a big difference between ICMP plus
traceroute's UDP packets and others (routing, ssh, etc.) is that rate
limiting the combined (trusted + untrusted) ICMP stream is fine
because even if we loose some valid ICMP packets when an attack is
going on, we do not loose the network or ability to control it. While
for other packets (routing included) we need very strict separation of
resources for trusted and untrusted packets. Basically the difference
is in the criticality of packets.

> just makes the problem worse.

Not sure what you mean here. If it is able to parse data at line rate,
why would it make the problem worse?

> I haven't heard of any vendor who includes

I think a quick google search would reveal some developments in this
field, even for gige speeds, don't remember about 10G, and no idea
about how expensive this is. What would really be needed is a chip
that would be able to identify packets that need to be checked (such
as BGP's TCP sessions, IPSec SAs, etc) and do the required
authentication checks, all at line rate.

I actually think that vendors should go in this direction.

On the other hand, the time required to upgrade sufficient number of
routers to substantially increase security of the Internet routing
infrastructure can be quite long, that's why I was thinking about
an interim solution that would minimize the chances for HW upgrades
required...

> are somewhat less costly to implement in a linecard than even the

Hmmm... not sure if I understand this correctly... Do you mean that
the control plane would calculate the needed signature for the next
expected packet and inform the line cards about it, so the line card
can do a quick != check for the next packet?

If this is what you mean, this won't solve a problem. We need to
remember that valid packets should not be punished. This means that
the line card should have the signature for the next packet ready
right after it has checked the previous one. Which means that a)
signature calculation still has to happen at line rate, and b) you
can't allow the delays of sending packets to the control plane
and waiting for the signature to come back.

Alex

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Mar 2003 00:35:20 +0100 (CET)

On Fri, 14 Mar 2003, Alex Zinin wrote:

> going on, we do not loose the network or ability to control it.

True.

> why would it make the problem worse?

Ok, if the crypto can be done at line rate then there is no problem.
However, my assertion is that doing crypto line rate at the highest
available line rates is always going to be so expensive that won't be
supported widely.

> about how expensive this is.

Even if this could be done in the future without significant additional
expense, it still means a fork lift upgrade for *everything* that's
deployed right now. We can't simply assume line rate crypto because it
makes our life easier.

> What would really be needed is a chip

> I actually think that vendors should go in this direction.

I think this is indeed a very useful capability (I'm working on a draft
for proxy AH verification in service provider networks to protect
end-user networks from DoS that needs exactly this) but I don't see it
happening for each and every linecard in each and every router in each
and every network any time soon.

> an interim solution that would minimize the chances for HW upgrades

Ok then.

> can do a quick != check for the next packet?

Yes, more or less. (Obviously this wouldn't be the _signature_ for the
next packet but just an opaque value that can be predicted by the other
end but not by an attacker. You'd still need a signature against MitM.)

> and waiting for the signature to come back.

A problem that occurred to me after writing this that I'm more concerned
with it the state that may be needed. If the line card can't be set up
to receive the next packet at line rate: too bad, send them slower.
We're talking about control traffic here, this doesn't have to be line
rate.

Iljitsch

---

From: Alex Zinin <[email-masked]>
Date: Fri, 14 Mar 2003 16:01:07 -0800

Iljitsch,

> available line rates is always going to be so expensive that won't be

Hmmm... Yes, good point. I suspect that the router vendors would
then need to always own crypto HW they put on the LCs so they can
scale it together with throughput.

> deployed right now. We can't simply assume line rate crypto because it

I think we agree here.

> end but not by an attacker. You'd still need a signature against MitM.)

Right. It is not the signature _of_ the n+1'st packet, but of the n'th
packet _for_ n+1'st.

What about the very 1st packet in the connection, btw?

And, of course, Man-in-the-Middle attacks would still be open, as
you mention... I think we should avoid this...

> with it the state that may be needed.

Seems that the amount of state would be approx the same as if you did
actual MD5. And, btw, you still need to do flow identification to
know which value to check the packet against.

> If the line card can't be set up

I am not sure I would be that optimistic about this. This may really
affect TCP performance--I expect slow restart would be kicking in
continuously, and this will affect BGP convergence...

Alex

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Mar 2003 02:26:24 +0100 (CET)

> What about the very 1st packet in the connection, btw?

Both ends must negotiate a session key anyway, so an initial value for
the first cookie shouldn't be much of an (extra) problem. However, if
the DoS is already in effect at this point, this negotiation will be
hard to complete. Or maybe preshared with a fixed seed for the initial
key would be the way to go.

> you mention... I think we should avoid this...

Regular authentication that's still in place should take care of this.

> actual MD5.

Good point. However, this probably means the number of sessions that can
be protected in this manner will always be fairly limited.

> continuously, and this will affect BGP convergence...

Hm, maybe doing this based on the last packet isn't the best way. Ok,
how about this: we use a stream cipher to come up with a random-looking
data stream on both ends and use the IPsec anti-replay counter as a
pointer to the part of the data stream that is used as a magic cookie in
the current packet. We can then program the line card with enough data
to be able to check a certain number of packets per session without
having to wait for the CPU to come up with more cookie data. This also
removes the TCP limitation, it could now be a generic IP level
mechanism.

---

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

>key would be the way to go.

As I noted in my previous message on this thread, this seems awfully 
premature. But, note that there are ways to generate a series of 
values that can be quickly verified by a receiver, if that's what we 
decide that we need, and if we are doing this for only a 
point-to-point link.

>removes the TCP limitation, it could now be a generic IP level
How about if we don't play cryptographer here? As I said, the 
literature has lots of options for what may be a solution if we come 
to agreement on the problem, which we have yet to do ...

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Mar 2003 18:15:41 +0100 (CET)

On Tue, 18 Mar 2003, Stephen Kent wrote:

> premature.

So why not take your own advice?

> But, note that there are ways to generate a series of

Why would we only want to do this on a point-to-point link?

> literature has lots of options for what may be a solution

So why doesn't IPsec have something like this already?

> if we come to agreement on the problem, which we have yet to do ...

Defining the problem isn't a goal in its own right.

---

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

>So why not take your own advice?

because I was catching up on your messages :-)

>Why would we only want to do this on a point-to-point link?

I thought that was the context you were describing, since otherwise 
the mechanisms you suggested are not very secure, in general ...

>So why doesn't IPsec have something like this already?

IPsec includes some features to facilitate rapid discard of "bad" 
traffic, including the ordering of the checks performed for integrity 
and authentication. IPsec is algorithm independent, and so one could 
choose to employ an algorithm that emphasizes fast checking, 
consistent with the protocol design. The IPsec WG has not focused on 
developing such algorithms, perhaps because the context in which the 
implementations operate do not generally view this as a major problem.

>Defining the problem isn't a goal in its own right.

defining the problem is an essential first step, unless one wants to 
waste time proposing solutions absent agreement on the problem being 
solved.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Mar 2003 00:06:11 +0100 (CET)

> waste time proposing solutions absent agreement on the problem being

I see no dichotomy here.

At some point the added value in continuing to work on the requirements
no longer outweighs the delay in getting a working solution.

---

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

>no longer outweighs the delay in getting a working solution.

If we don't have agreement on the requirements, we can't evaluate 
proposed solutions. We'll just argue about relative merits based on 
different criteria.

Your comment has a sort of "ready, fire, aim" quality that is not 
likely to yield good results in the long run.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Mar 2003 22:29:32 +0100 (CET)

> likely to yield good results in the long run.

It was never my intention to make a huge debate out of this.

Spending some time on requirements is good, but that doesn't mean
spending lots of time on requirements is even better. If that were the
case, we'd all be running CLNS today.

Sometimes "ready fire aim" is the right approach.

Having said that, I want to make clear I don't have a problem with the
current approach of this wg, other than that I think lumping together
IGPs and EGPs is probably not the most efficient way to handle things
but who cares about efficiency.