I guess the 'filter box' can be a number of different things, based on your
needs and preferences. At first glance CloudShield seems pretty beefy, am
reading more as we speak.
Yes, Juniper can be convinced to add things, we've asked for a few.
Part of the problem with asking for new things on an ASIC, takes time.
Anything they add in their code to help filter will likely not be done in
hardware, meaning potential impact. I know some people need to filter on
their routers for various reasons, but my thoughts are to minimize this. A
router that is working hard at just forwarding packets doesn't need to extra
overhead of looking deep into packet headers to figure out what to do with
packets. Juniper is better at this, as are some Cisco products, but the GSR
is a crappy packet filter if you put enough traffic through it. Yes certain
linecards are better than others, but the newer they are the more buggy they
are, and we're talking HW here, so bug fixes will be awhile.
The caveat to all this is obvious, these are big links and big routers, only
applies to high traffic networks..as that is the only place the expense is
justified. uRPF, however, works on (almost) any CEF capable Cisco router.
Some may have already seen this, worth a look if not.
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup in the CEF table, if the route isn't there it discards. Keep
in mind this is NOT a filter, so the impact is much less, it is simply a CEF
lookup, much more efficient than a filter. This will get rid of a HUGE
percentage of spoofed packets that hit your network, and would also work
pretty well if you are the source of an attack. There is some debate as to
whether you must not have ANY RFC1918 space for this to work. We're trying
to find this out (not a priority), if I get info I'll post.
3. How does the Internet Processor II ASIC enable service providers to
upgrade functionality without upgrading hardware? Essentially, the
Internet Processor II ASIC contains logic that implements a number of
lookup algorithms, including trees, tables, firewall programs, and a way
to chain those individual lookups together in an arbitrary sequence. The
final answer to an entire lookup, then, is the result of all the matches
that were run. By implementing complex lookups as a series of fundamental
primitives, the ASIC can support almost anything for which an application
can be described. Since the ASIC implementation is so general, new
functionality can be enabled in JUNOS software upgrades without having to
swap hardware.
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup in the CEF table, if the route isn't there it discards.
It can do much more. You can use it to get rid spoofed source addresses
from customers and peers without the need to maintain large access lists.
lookup, much more efficient than a filter. This will get rid of a HUGE
percentage of spoofed packets that hit your network,
If you just filter out anything that's not in the routing table, that's
about half the address space and it only works if the spoofers are stupid.
When you're looking at pure bandwidth that's still helpful, but it doesn't
really solve anything.
However, You can use unicast RPF as a very efficient source address
filter, by routing addresses to the null interface. This way you can get
rid of huge amounts of unwanted sources in a very clean way.
As long as we're asking for features: what I would like is a unicast RPF
check that allows everything that isn't routed to the null interface. And
of course unicast RPF period for all vendors who aren't Cisco.
On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this:
<snip>
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup in the CEF table, if the route isn't there it discards. Keep
in mind this is NOT a filter, so the impact is much less, it is simply a CEF
lookup, much more efficient than a filter. This will get rid of a HUGE
percentage of spoofed packets that hit your network, and would also work
pretty well if you are the source of an attack. There is some debate as to
whether you must not have ANY RFC1918 space for this to work. We're trying
to find this out (not a priority), if I get info I'll post.
Its not checking cef to see if a route is there.... its making sure that a packet
received on an interface came in on an interface that is the best return path
to reach that packet.
thereby explaining why multihomed customers will get borked in the event of using rpf.
RPF works by matching the source address of the packet against the CEF
table, in addition to the normal match against the destination address.
There are multiple modes of operation, ranging from "is there a route
for the source address to the specific interface it come in on" to "is
there a route to the source address for ANY interface on the box" The
former is used to stop your single homed customers from spoofing wildly
into the internet. The latter is usually used as a stopgap measure to
limit the number of spoofed packets coming into your network via transits.
The number you'd expect to filter is 50%, assuming the attacker in
question is using an evenly distributing random() function.
http://www.cisco.com/warp/public/707/newsflash.html
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup in the CEF table, if the route isn't there it discards.
We're running 6509's - both Sup1a and Sup2 - with 10, 100, and GigE links
in a large campus environment. We did have some problems with the Sup2's
running hybrid code, but the Sup1a's were fine. When we switched over to
native IOS about six months ago, both the Sup1a's and Sup2's handled it
without a problem or performance hit, even on some of our campus Gigabit links.
Its a nice feature but, as someone already pointed out, its based on routing
table entries so there is NO PROTECTION if someone on a subnet is spoofing the
IP of another system on the same subnet. Having said that, we use it more so
that we can quickly track the source of an attack if its originating on our
network rather than as a means to protect ourselves from the big, bad
Internet. Once we know the source, we know for sure what router interface
its originating from, so we just start snooping traffic from that interface to
find the offending MAC and go from there...
Another limitation that we've found with uRPF is that it doesn't
live well with multihomed systems (i.e. a host with two NIC's - each on
a different subnet) because of the way most OS'es handle their
default gateways. For anyone who is interested in our experience, drop me
a note off list. If you have a solution for this multihoming problem, PLEASE
email me off-list.
You can do this for multihomed customers to: it's just that multihomed
customers can't use it for traffic coming from their transits (= you),
because uRPF breaks asymmetric routing.
We have been working on this problem for the last two years and
have productized a practical way to deal with DDoS. Given what I have
read today, I think most people on this list would
like it. If you send me email, I will send you a white paper that is much
more
detailed than what you can find on http://www.reactivenetwork.com.
Jason described uRPF in Loose Check mode. This check to see if the source
exist in the FIB. It cuts out some of the garbage while providing you a tool
to do a remote-triggered (via BGP ) drop tool. Think of uRPF as a tool to do
source based black hole filtering.
uRPF Strict Mode is the original tool to help scale BCP38 filtering. This
checks the FIB and the adjacency - insuring the source address of the packet
coming into the interface has a patch to get back (hence checking the
validity of the packet). This is a ISP-Customer edge tool. It _does_ work
with multihomed customers for the most common multihoming configs. Just set
that BGP weight on the customer's peering session.
It is getting a little old, but check out the following:
From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
Mark Turpin
Sent: Thursday, May 02, 2002 10:05 AM
To: LeBlanc, Jason
Cc: nanog@merit.edu
Subject: Re: Effective ways to deal with DDoS attacks?
something like this:
<snip>
>
> There are some limitations as to where uRPF works, SONET only
on GSRs for
> example (thanks Cisco). I believe it will work on 65xx (SUP1A
and SUP2 I
> think) regardless of interface type. Impact should be minimal,
as it simply
> does a lookup in the CEF table, if the route isn't there it
discards. Keep
> in mind this is NOT a filter, so the impact is much less, it is
simply a CEF
> lookup, much more efficient than a filter. This will get rid of a HUGE
> percentage of spoofed packets that hit your network, and would also work
> pretty well if you are the source of an attack. There is some
debate as to
> whether you must not have ANY RFC1918 space for this to work.
We're trying
> to find this out (not a priority), if I get info I'll post.
>
Its not checking cef to see if a route is there.... its making sure that a
packet
received on an interface came in on an interface that is the best return
path
to reach that packet.
thereby explaining why multihomed customers will get borked in the event of
using rpf.
