Mario,
It all depends on which platform you are using.
Also, it is important to say whether the 100Mbps attack is using 64 byte
packets or larger packets. This is the case as routers usually care more
about packet per second than bits per second.
I would say that uRPF would be much more efficient if its possible to
implement it, as it is done in a more early stage of packet processing.
Also, if you can avoid ACL lookups, and use uRPF (which uses the CEF
tree structure), you gain performance.
This all changes a bit when we talk about hardware based platforms which
use TCAM. There both options may present the same performance.
Arie
________________________________
From: Mario Spinthiras [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 15:31 PM
To: Arie Vayner (avayner)
Cc: [email protected]
Subject: Re: [c-nsp] Surviving denial of service from certain
IPs
Arie hello and thank you for your feedback.
What I want to know is how would route-map methods effectively
help stop such attacks and what the resource usage comparison is when
putting ACLs and other methods on the scale. uRPF is all very nice but
what about something along the lines of a 100 Mbps stub network?
Regards,
Mario
On Fri, Jul 25, 2008 at 2:04 PM, Arie Vayner (avayner)
<[EMAIL PROTECTED]> wrote:
Mario,
There is a more elegant way.
You could use loose mode uRPF on your ingress
interfaces.
If you want to block a specific source prefix, you just
set a route to
null0 for that prefix, and uRPF would block it in the
most efficient way
possible on a Cisco router.
The generic uRPF guide:
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg
_unicast_rpf_ps6441_TSD_Products_Configuration_Guide_Chapter.html
<http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cf
g_unicast_rpf_ps6441_TSD_Products_Configuration_Guide_Chapter.html>
Loose mode uRPF:
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_uni
cast_rpf_loose_ps6441_TSD_Products_Configuration_Guide_Chapter.html
<http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_un
icast_rpf_loose_ps6441_TSD_Products_Configuration_Guide_Chapter.html>
The command reference:
http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_i3.ht
ml#wp1033222
<http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_i3.h
tml#wp1033222>
This solution can be integrated together with Remote
Triggered Black
Holing for a distributed solution using BGP communities:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642
/prod_white_paper0900aecd80313fac.pdf
<http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps664
2/prod_white_paper0900aecd80313fac.pdf>
Let me know if you require further info.
Arie
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Mario Spinthiras
Sent: Friday, July 25, 2008 12:21 PM
To: [email protected]
Subject: [c-nsp] Surviving denial of service from
certain IPs
Greetings to everyone,
I recently looked into the minimal resource usage of a
Cisco router in
the case of a denial of service attack. In such cases
what is the
minimal configuration one can apply to a router to make
sure that a
certain range of IPs attacking you keeps the router
alive and uses much
less resources. Two things I came up with (one of which
everyone
probably does on a normal
basis) is access lists and another would be a route-map
to point all
unwanted sources to null0. Would a route-map hurt the
router less than
an access list plain out ? What I'm referring to is
basically PBR
pointing matches to null0. An example configuration
would be:
!
interface FastEthernet0/0
ip policy route-map unwanted
!
!
ip access-list extended unwacl
deny ip any any
permit ip 192.168.1.0 0.0.0.255 any
!
!
route-map unwanted permit 10
match ip address unwacl
set default interface Null0
!
Is this more optimal than a plain old access list? Is
this used in any
way?
Regards,
Mario
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
--
Warm Regards,
Mario A. Spinthiras
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
