Effective ways to deal with DDoS attacks?

[Stephen_Griffin]

In the referenced message, Christopher L. Morrow said:

> In the referenced message, Christopher L. Morrow said:
> > I was hoping someone else might mention this, BUT what about the case of
> > customers providing transit for outbound but not inbound traffic for their
> > customers? We have many, many cases of customers that are 'default
> > routing' for their customers that get inbound traffic down alternate
> > customers or peers or wherever... uRPF seems like a not so good solution
> > for these instances especially since some of these are our worst
> > abusers
> >
> > -Chris
>
> Tell them they will need to register their routes in the IRR, even if they
> don't necessarily advertise all or any of them. Build your exceptions
> based upon the irr, as for all bgp-speaking customers.

I'm not really sure how one customer IRR filtered (one example customer)
is going to matter here, this is the equivalent of a customer connected
via 2 t1's one to AT&T and one to UUNET, not announcing EVER his ATT
routes to UU nor his UU routes to ATT. How would you know what traffic to
expect from this customer at any point in time? He could just push all
traffic over his ATT link outbound and only pull in UU on UU and ATT on
ATT. Route filters aren't really a solution to this problem.

not route-filtering. You use the irr-data to populate the exceptions
to strict-mode rpf. The irr is more of a flight-plan of possibility.
If the customer registers both sets of routes, and you use that
data to build the acl, then it doesn't matter what the customer announces
to you. Anything which fails the actual rpf check, will then be
passed through the acl to selectively override the rpf check.

>
> ---rant removed---
>
> If there was some particular situation where neither IRR-based
> exceptions, or customer-specific exceptions just couldn't work, then
> do what you _can_ do. loose RPF checks based upon matching _any_ prefix, and
> interface filter inbound and outbound on known bogons. this, at least,
> constrains the area of ipv4 which can be used for spoofing, which
> is better than where you started.
>

Access-lists on interfaces?? This does not scale, puts my network at risk
and will certainly break some 'legitimate' traffic. Additionally, as I've
said before, spoofed attacks don't really bother me, they are more easily
stopped and tracked.

The object is to keep the interface acls short, and use the rpf
logic to get rid of as much as you can. Rather than using interface
acls themselves to emulate a strict rpf check. If you filter only
known bogons (RFC1918, as an obvious example) I don't see what will be
broken, except that which was broken to begin with.

Along with things like compiled access-lists, the impact can be kept
quite small. You can even add in performance circuit-breakers to speed
things up. For example, allowing established TCP sessions, will (without
even compiling the acls) allow a first-match circuit breaker on a large
percentage of traffic.

While spoofed traffic may not be a concern for as701, I know I, at least,
would prefer not to get spoofed traffic via that network. I'm sure
other paying customers probably feel similarly.

I don't see how access-lists on edge interfaces don't scale, if they
are all the same short anti-bogon acl. Junipers should be able to handle
this ok, Cisco Engine3 (Edge) should be able to handle fine for GSR.
I thought AS701 was moving towards vendor-J on the edge, as it was, but
maybe I'm misremembering.

Even if it isn't possible for as701 to rpf check/filter in every
possible scenario, whatever _is_ possible would be appreciated
(by me at least).

"Progress, not perfection" as the saying goes...

[Christopher_L_Morrow]

In the referenced message, Christopher L. Morrow said:
>
>
> > In the referenced message, Christopher L. Morrow said:
> > > I was hoping someone else might mention this, BUT what about the case of
> > > customers providing transit for outbound but not inbound traffic for their
> > > customers? We have many, many cases of customers that are 'default
> > > routing' for their customers that get inbound traffic down alternate
> > > customers or peers or wherever... uRPF seems like a not so good solution
> > > for these instances especially since some of these are our worst
> > > abusers
> > >
> > > -Chris
> >
> > Tell them they will need to register their routes in the IRR, even if they
> > don't necessarily advertise all or any of them. Build your exceptions
> > based upon the irr, as for all bgp-speaking customers.
>
> I'm not really sure how one customer IRR filtered (one example customer)
> is going to matter here, this is the equivalent of a customer connected
> via 2 t1's one to AT&T and one to UUNET, not announcing EVER his ATT
> routes to UU nor his UU routes to ATT. How would you know what traffic to
> expect from this customer at any point in time? He could just push all
> traffic over his ATT link outbound and only pull in UU on UU and ATT on
> ATT. Route filters aren't really a solution to this problem.

not route-filtering. You use the irr-data to populate the exceptions
to strict-mode rpf. The irr is more of a flight-plan of possibility.
If the customer registers both sets of routes, and you use that
data to build the acl, then it doesn't matter what the customer announces
to you. Anything which fails the actual rpf check, will then be
passed through the acl to selectively override the rpf check.

Perhaps I'm confused (which is likely in this case) but if the traffic is
being transitted by 2 or 3 as's before it gets to me through 'default'
routing how am I to know it was coming?

> >
> > ---rant removed---
> >
> > If there was some particular situation where neither IRR-based
> > exceptions, or customer-specific exceptions just couldn't work, then
> > do what you _can_ do. loose RPF checks based upon matching _any_ prefix, and
> > interface filter inbound and outbound on known bogons. this, at least,
> > constrains the area of ipv4 which can be used for spoofing, which
> > is better than where you started.
> >
>
> Access-lists on interfaces?? This does not scale, puts my network at risk
> and will certainly break some 'legitimate' traffic. Additionally, as I've
> said before, spoofed attacks don't really bother me, they are more easily
> stopped and tracked.

The object is to keep the interface acls short, and use the rpf
logic to get rid of as much as you can. Rather than using interface
acls themselves to emulate a strict rpf check. If you filter only
known bogons (RFC1918, as an obvious example) I don't see what will be
broken, except that which was broken to begin with.

Any access-list of any length severly impacts edge performance, if it
works at all, and puts the network at risk. This is not dogma, this is
proven time and again on a large operational network. They are never
placed for 'permanent' reasons. It is expected that customers will
properly handle their traffic... yes they don't always do it, but it is
expected.

Along with things like compiled access-lists, the impact can be kept
quite small. You can even add in performance circuit-breakers to speed
things up. For example, allowing established TCP sessions, will (without
even compiling the acls) allow a first-match circuit breaker on a large
percentage of traffic.

Compiled access lists? Wow, you are a braver man than I. My experience
with them has been 'sub optimal' to say the least. Where known traffic
flows and known patterns, with reasonable route table sizes, are
available compiled acls work fine. The internet is none of these

While spoofed traffic may not be a concern for as701, I know I, at least,
would prefer not to get spoofed traffic via that network. I'm sure
other paying customers probably feel similarly.

I don't see how access-lists on edge interfaces don't scale, if they
are all the same short anti-bogon acl. Junipers should be able to handle
this ok, Cisco Engine3 (Edge) should be able to handle fine for GSR.
I thought AS701 was moving towards vendor-J on the edge, as it was, but
maybe I'm misremembering.

How large is your edge? Do you have routers with +900 interfaces?
Management of acls on interfaces, even if the gear were to support it,
isn't feasible, nor is just dropping in an E3 card a solution, acls don't
work reliably on E3 cards E2 cards are just as fun the really fun
part comes with the 'limited' route table incurred with PSA acls on E2
cards!

Anyway, the point here is acls on interfaces are not a solution at the
backbone level. At the individual provider level its sure a nice thing,
and likely it should be done, but not on the backbone.

As to randomly filtering 1918 address space, at your edge that's fine, I'm
not sure breaking things for those places that use 1918 internally and
thus originate 'legitimate' 1918 address sources for 'error conditions' is
a great plan. (please see last 16 flame-fests on martian filtering)

-Chris

[Richard_A_Steenbegen]

Perhaps I'm confused (which is likely in this case) but if the traffic is
being transitted by 2 or 3 as's before it gets to me through 'default'
routing how am I to know it was coming?

You're talking about packets received from the internet, he's talking
about packets received from your customers.

Any access-list of any length severly impacts edge performance, if it
works at all, and puts the network at risk. This is not dogma, this is
proven time and again on a large operational network. They are never
placed for 'permanent' reasons. It is expected that customers will
properly handle their traffic... yes they don't always do it, but it is
expected.

It all depends on a) whats your equipment, and b) what do you define as an
edge. If your edge is a T1 things are a lot different than if your edge is
GigE and you have to use "core" (for the definition of core which means
not providing features to compete on performance, and explaining it by
telling you that you shouldn't need those features) equipment to provide
it.

Compiled access lists? Wow, you are a braver man than I. My experience
with them has been 'sub optimal' to say the least. Where known traffic
flows and known patterns, with reasonable route table sizes, are
available compiled acls work fine. The internet is none of these

If everyone who had been burnt by a Crisco bug in a certain feature never
used that feature again, there would be no features. That said, compiled
access-lists work fine for me.

How large is your edge? Do you have routers with +900 interfaces?
Management of acls on interfaces, even if the gear were to support it,
isn't feasible, nor is just dropping in an E3 card a solution, acls
don't work reliably on E3 cards E2 cards are just as fun the
really fun part comes with the 'limited' route table incurred with PSA
acls on E2 cards!

If your vendor isn't providing you with working products, find a new
vendor.

I'm not going to touch that config with a 10ft cattle prod though, it
better be automatically generated. That brings it down to the same level
of distasteful tolerance for the good of the internet as script generated
prefix lists.

[Raymond_Steven]

Stephen Griffin wrote:

> > Tell them they will need to register their routes in the IRR, even if they
> > don't necessarily advertise all or any of them. Build your exceptions
> > based upon the irr, as for all bgp-speaking customers.
>

not route-filtering. You use the irr-data to populate the exceptions
to strict-mode rpf. The irr is more of a flight-plan of possibility.
If the customer registers both sets of routes, and you use that
data to build the acl, then it doesn't matter what the customer announces
to you. Anything which fails the actual rpf check, will then be
passed through the acl to selectively override the rpf check.

What about existing customers that don't yet use the IRR? Say you
filter some BGP customers' route announcements using manually-built
prefix-lists. Have found that by using distribute-list in (instead of
prefix-list), one can simply refer the distribute-list # in the strict
uRPF configuration and accomplish both functions (route filtering +
uRPF) easily with one ACL.
e.g.:
ip verify unicast source reachable-via rx 49
access-list 49 permit x.x.x.x 0.0.0.255
access-list 49 permit y.y.y.y 0.0.0.252
access-list 49 deny any log

Prefix-lists are preferable over ACL-based distribute-lists. Hey Cisco,
please make uRPF configuration accept either distribute-lists or
prefix-lists for the exception branching. I realize that to IOS ACLs
and prefix-lists are not the same, but the benefits of prefix-lists vs.
distribute-lists are many.

It sounds that a lot of networks rely on IRRs for building BGP customer
route filters. What method then is used for the cases where a customer
is not already using the IRR? Forced IRR registration before BGP
turnup? Or do you fallback on filtering by using prefix- or
distribute-lists?

What's NANOG's opinion: assuming that uRPF is implemented on all
customer interfaces, are there any legitimate purposes for a customer to
forward packets with source IP addresses not currently routed by the
transit provider towards the customer (either static or BGP)?

[Ralph_Doncaster]

What's NANOG's opinion: assuming that uRPF is implemented on all
customer interfaces, are there any legitimate purposes for a customer to
forward packets with source IP addresses not currently routed by the
transit provider towards the customer (either static or BGP)?

IP Tunneling - it often makes more sense to send packets out that have a
source address reachable only through the tunnel.

[Valdis_Kletnieks]

But aren't those source addresses hidden *inside* the encapsulation, and
what's visible to routers are the source/dest IPs of the tunnel itself?

[Ralph_Doncaster]

What I'm saying is that if something comes in through the tunnel, the
shortest route to the destination is often not to go back out through the
tunnel.