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 Tue, 25 Mar 2003, Christian Liendo wrote:
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... Well yes, It seems that an IP deny is more process intensive than an IP
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
At 09:21 AM 3/25/2003 -0500, Haesu wrote: 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. limitation of the router. I just need something less taxing on the router. I just need to know if anyone has already done this.
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. -- Jack Bates Network Engineer BrightNet Oklahoma
## On 2003-03-25 09:06 -0500 Christian Liendo typed: [snip] CL> CL> Depending on the router and the code, if I implement an access-list then CL> the CPU utilization shoots through the roof. CL> What I would like to try and do is use source routing to route that traffic CL> to null. I figured it would be easier on the router than an access-list. CL> CL> Has anyone else tried this successfully on ciscos and junipers? CL> 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 ... -- Rafi
On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo <cliendo@globix.com> wrote:
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.
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. :-) 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 On Tue, 25 Mar 2003, John Kristoff wrote:
On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo <cliendo@globix.com> wrote:
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.
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. :-)
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.
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.
On Tue, 25 Mar 2003, Haesu wrote:
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 :( especially if you want to route/acl it.
-hc
On Tue, 25 Mar 2003, John Kristoff wrote:
On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo <cliendo@globix.com> wrote:
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.
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. :-)
John
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 :( 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
-hc
On Tue, 25 Mar 2003, John Kristoff wrote:
On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo <cliendo@globix.com> wrote:
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.
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. :-)
John
On Tue, Mar 25, 2003 at 04:58:59PM +0000, Christopher L. Morrow wrote:
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" ...
is there a way to make this source-blackhole-routing work on J's too (does this work with discard-routes too)? tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA
On Mon, 12 May 2003, Stefan Mink wrote:
On Tue, Mar 25, 2003 at 04:58:59PM +0000, Christopher L. Morrow wrote:
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" ...
is there a way to make this source-blackhole-routing work on J's too (does this work with discard-routes too)?
I believe someone from Juniper should likely answer this question :) 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. :(
On Tue, 25 Mar 2003, Christian Liendo wrote:
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.
Thanks Christian Liendo
participants (8)
-
Christian Liendo
-
Christopher L. Morrow
-
fingers
-
Haesu
-
Jack Bates
-
John Kristoff
-
Rafi Sadowsky
-
Stefan Mink