Using Policy Routing to stop DoS attacks

Looking for advice.

I am sorry if this was discussed before, but I cannot seem to find this.
I want to use source routing as a way to stop a DoS rather than use access-lists.

In other words, lets say I know the source IP (range of IPs) of an attack and they do not change.

If the destination stays the same I can easily null route the destination, but what if the destination constantly changes. So I have to work based on the source IP.

Depending on the router and the code, if I implement an access-list then the CPU utilization shoots through the roof.
What I would like to try and do is use source routing to route that traffic to null. I figured it would be easier on the router than an access-list.

Has anyone else tried this successfully on ciscos and junipers?
Is it easier on the CPU than access-lists?
Is there a link I cannot find on cisco or google?

Thanks
Christian Liendo

I dunno how you want to implement this; but as far as I know, the way most
people generally do policy routing on cisco thru routemap is they define
the source IP's via access-list... Does that make a huge difference than
regular access lists? I dunno...

I've kinda tested it in the lab with two 7206's and CPU load seems to be
about the same when done with regular access-list and done with policy
routing.. But, I don't have the true real data to back up my claims..

-hc

## On 2003-03-25 09:06 -0500 Christian Liendo typed:

[snip]

Depending on the router and the code, if I implement an access-list then
the CPU utilization shoots through the roof.
What I would like to try and do is use source routing to route that traffic
to null. I figured it would be easier on the router than an access-list.

Has anyone else tried this successfully on ciscos and junipers?
Is it easier on the CPU than access-lists?

Details ?

Which Cisco router ? IOS ?
HW/SW/CEF/netflow/<whatver> "IP switching" ?

As you seem to have noticed these "little details" matter ...

I dunno how you want to implement this; but as far as I know, the way most
people generally do policy routing on cisco thru routemap is they define
the source IP's via access-list... Does that make a huge difference than
regular access lists? I dunno...

Well yes, It seems that an IP deny is more process intensive than an IP permit. I do not claim to know why. I have just seen it myself.

Anyway depending on the attack with large numbers of packets sometimes the CPU is so high you can get knocked off the router.
I wanted to see if policy routing is less taxing on the router.

With the access-list for a policy route map you have a access-list permit, so I figured it might be less taxing.

Which Cisco router ? IOS ?
HW/SW/CEF/netflow/<whatver> "IP switching" ?

While I have had this problem on different routers the ones I constantly have it on are Cisco Cat 5000s with RSMs(RSP4). I have tried different codes, I am currently at 12.04. But it's not a code issue. It's just a limitation of the router. I just need something less taxing on the router.

I just need to know if anyone has already done this.

If you fooled the router into thinking that the reverse path for the
source is on another another interface and then used strict unicast RPF
checking, that may accomplish what you want without using ACLs. I don't
know what impact it would have on your CPU however, you'll have to
investigate or provide more details.

Note, depending on the platform and configuration, filters/ACLs may have
an insignficant impact on the CPU. If they don't, don't forget to
complain to your vendor. :slight_smile:

John

uRPF will certainly save a bit of CPU cycles than access-lists or policy
routing.. it would be intertesting to know any kind of 'common practice'
ways people use to fool the router so that it will think such offensive
source IP's are hitting uRPF.

i am not really sure what kind of traffic we are talking about,
but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just
fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1)

-hc

uRPF will certainly save a bit of CPU cycles than access-lists or policy
routing.. it would be intertesting to know any kind of 'common practice'
ways people use to fool the router so that it will think such offensive
source IP's are hitting uRPF.

null route? even with a loose check, if you implement some kind of
blackhole system, send the miscreant source adress to say, 172.1.1.1 and
have 172.1.1 routed to null 0, uRPF should kill any src/dst packets for
the host/block if i'm not mistaken.

Looking for advice.

I am sorry if this was discussed before, but I cannot seem to find this.
I want to use source routing as a way to stop a DoS rather than use
access-lists.

you can null route it also.

In other words, lets say I know the source IP (range of IPs) of an attack
and they do not change.

if you know the source, walk back to the source ingress and stop it there?
Unless its a large number of sources in which case the null route should
be applied.

If the destination stays the same I can easily null route the destination,
but what if the destination constantly changes. So I have to work based on
the source IP.

if the destination changes? Can you clarify that? You have attacks in
which the destination changes inside a /24 or inside some larger netblock?

Depending on the router and the code, if I implement an access-list then
the CPU utilization shoots through the roof.

Given your description of the problem so far I'm going to say you are
using router vendor !J so policy routing (source routing) is guaranteed to
do more harm than a simple acl would. Additionally, how large an acl are
you trying to implement for this attack scenario? 'less is more'
especially with DoS attack filtering.

What I would like to try and do is use source routing to route that traffic
to null. I figured it would be easier on the router than an access-list.

How so? The same basic processing must be done for each packet if you
policy route or acl... each packet must be pushed through an acl to an
unnatural next-hop (null in the case of an acl or 'wrong interface' for
policy routing)

Has anyone else tried this successfully on ciscos and junipers?

you theoretically COULD do this on a juniper, its making the problem much
harder though.. .the juniper could just as easily filter it. POlicy
routing on the cisco gear I've tried it on doesn't work well for high
packetrate streams.

Is it easier on the CPU than access-lists?

no, not in anyway is it better than an acl.

Is there a link I cannot find on cisco or google?

for policy routing sure... http://smlnk.com/?MTAQBMRI
there were a bunch more links as a result of: "Policy route" entered in
the cisco.com search tool.

uRPF will certainly save a bit of CPU cycles than access-lists or policy

that is HIGHLY dependent on the platform in question. For the stated
'router' (5500+rsm) I'd think the impact would be about the same as for an
acl. 7500+RSP or 5500+RSM (which is pretty much a 7500+RSP) has to process
switch all acl'd traffic, this includes uRPF traffic. There isn't the
hardware processing available for this in these platforms. The 12000 or
6500 both (among others) have hardware acceleration for forwarding and
route lookups. These are harnessed to make the uRPF work 'better' in said
platforms.

routing.. it would be intertesting to know any kind of 'common practice'
ways people use to fool the router so that it will think such offensive
source IP's are hitting uRPF.

you could hold blackhole routes for these destinations in your route table
(local or bgp) So long as the destination for the source is bad (null for
instance) the traffic would get dropped. I believe the proper terms from
cisco for this are: "So long as the adjacency is invalid" ...

i am not really sure what kind of traffic we are talking about,
but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just
fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1)

most likely the pps would kill the 5500 long before the bps :frowning: especially
if you want to route/acl it.

>
> i am not really sure what kind of traffic we are talking about,
> but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just
> fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1)

most likely the pps would kill the 5500 long before the bps :frowning: especially
if you want to route/acl it.

yea you're right.. for that "100Mbits/sec" bps i mentioned, the pps at
that rate was around 20,000 pps inbound as well as 18,000 pps outbound.

-hc

Haesu wrote:

I dunno how you want to implement this; but as far as I know, the way
most people generally do policy routing on cisco thru routemap is
they define
the source IP's via access-list... Does that make a huge difference
than regular access lists? I dunno...

I've kinda tested it in the lab with two 7206's and CPU load seems to
be about the same when done with regular access-list and done with
policy routing.. But, I don't have the true real data to back up my
claims..

On a live production network under DOS attack, access-lists applied to the
inbound interfaces is less CPU load than switching the packet on a 7206
running 12.0(x)S code. Policy routing, even with ip route-cache policy is an
increase in load. This is especially true when using extended access lists
for say port 80 redirects. This was noted when doing special caching
policies before our load exceeded what the ArrowPoint and the 7206 cpu's
could handle. FYI: one of my DOS attacks was a PPS attack, and since the
packets were small and not using bandwidth, blocking via access-list
recovered the network completely with little notice of CPU load over normal
traffic. Apparently a 7206 can block more PPS than it can switch.

is there a way to make this source-blackhole-routing work
on J's too (does this work with discard-routes too)?

   tschuess
             Stefan

I believe someone from Juniper should likely answer this question :slight_smile: As I
understand the setup from a Cisco perspective (and someone from Cisco can
correct me if I get it wrong). uRPF works in such a way that if the source
address's destination has an invalid FIB entry (or no entry, or Null0) the
packets are dropped.

Perhaps Juniper implemented it this way? I have not checked anymore
closely than this. Sorry. :frowning:

just if I got this right: On both, Juniper and Cisco, if the
source OR destination address is reachable via [NULL0|Discard],
the packet gets dropped if RPF is enabled on the interface.

Does this work in loose mode too?

Thanx &&
   tschuess
             Stefan Mink

Stefan Mink wrote: