Effective ways to deal with DDoS attacks?

Mailman List Mirror (Read Only)
1

In the referenced message, Eric Gauthier said:
<snip>

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.

Eric :slight_smile:

Most Cisco boxes have 3 related modes of uRPF:
1) pure RPF, if forwarding path back to source doesn't go via interface
packet received from, then dump. I believe, but am not positive, that
it will handle equal-cost-multipath ok in situations where that exists.
2) acl exceptions, if source matches the acl, allow the packet
3) not-so-pure RPF, if there is _any_ forwarding path back to the source
via _any_ interface, then accept.

for single-homed customers, simple uRPF
for multihomed customers, acl exceptions based upon their registered
IRR-policy, since the customer should already be registering in the IRR
you have a list of all networks reachable via the customer, regardless of
the actual real-time announcements or policy applications (prepending,
localpref tweaks, etc)
for peers that are clued-in, again acl exceptions based upon the peers
registered policy
for non-clued peers, accept based upon any available forwarding path
[hopefully, by the 100th time you beat on the peer about spoofed crud
coming from them, they'll get religion and register, since you'll have
less overall spoofing to track down, you can devote it to slapping
them around more]

you should also in/egress filter known bogons at all borders, like
src/dst in rfc1918
src/dst in class e
src in class d (not dest, however)
etc

2

for single-homed customers, simple uRPF
for multihomed customers, acl exceptions based upon their registered
IRR-policy, since the customer should already be registering in the IRR
you have a list of all networks reachable via the customer, regardless of
the actual real-time announcements or policy applications (prepending,
localpref tweaks, etc)

This doesn't make any sense. If you use uRPF on a customer interface, it
will check the packets coming in from the customer to see if they match
the prefixes you route to that customer. So as long as what you route to
them and what they use as source addresses are identical, you don't have a
problem.

For multihomed customers, these sets of prefixes should be identical, just
like with single homed customers. The only time when those sets of
prefixes is NOT the same is for a backup connection. But if a connection
is a pure backup for incoming traffic, it's reasonable to assume it's a
pure backup for outgoing traffic as well, so as long as the backup is
dormant, you don't see any traffic so no uRPF problems.

Using an exception access list is pretty silly: if you're going through
the trouble of listing all a cutomer's prefixes in a list, you might as
well just apply this acl to the interface rather than uRPF with the acl as
exceptions.

There is another way to handle backups: you can also set the weight to a
higher value for customer routes. This way, the router connecting to the
customer will always use the routes announced by the customer, even if the
rest of the network deems them inferior to another route to this customer
because of a lower local pref, a higher MED or a longer AS path.

This mechanism is also useful for peering: because of the higher weight,
the border router will always prefer the exchange (or private peering
link) for all traffic to the customer, so uRPF works. The rest of the
network can still decide to send the traffic to another exchange point.

for non-clued peers, accept based upon any available forwarding path
[hopefully, by the 100th time you beat on the peer about spoofed crud
coming from them, they'll get religion and register, since you'll have
less overall spoofing to track down, you can devote it to slapping
them around more]

If people stop peering with those network polluters they'll clean up their
act soon enough.

you should also in/egress filter known bogons at all borders, like
src/dst in rfc1918
src/dst in class e

Why? That doesn't buy you much except job security because someone
spending so much time on those impressive filters can't be missed of
course.

src in class d (not dest, however)

Some multicast apps set the source to the group address as well.

Iljitsch van Beijnum

3

Has anyone used /31 mask addresses on their network?

Toan

4

Yes, works fine (on an all Cisco network).

We're starting to use /31's on internal links. Links to third parties
are still /30's, as most other people are still wary.

Simon

5

Hi Simon,
What IOS are you using /31s with ?
Andr�

6

Typically 12.0(x)S on GSR and VXR (where x is 10ish upwards)

Simon

7

Andre Chapuis wrote:

  For what purpose can this be used? Can a point to point link function with this subnet mask? It would be ok if the requirement for a network and broadcast IP were removed.

Regards,

  Mannu

8

Do you really need broadcasts on your p2p links ? I do not..
Andr�

9

hmmm, as long as you allow directed broadcast on the interfaces... it
should work...

10

Simon Lockhart <simonl@rd.bbc.co.uk> writes:

11

> Has anyone used /31 mask addresses on their network?

Yes, works fine (on an all Cisco network).

Maybe not interesting for an ISP, but I'm using it on a vlan interface on
a 6500/7600. It works fine with IOS 12.1.8-EX5, but 12.1.11-E1 refused the
configuration because it's not a p2p interface. I know, documentation only
talks about p2p, but sometimes I don't like when a "feature" gets fixed...

Andras

12

Indeed, I found this on Saturday! GSR would let me put a /31 on the ethernet
port, but the 6509 at the other end of the ethernet wouldn't.

Simon