North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Effective ways to deal with DDoS attacks?

  • From: Iljitsch van Beijnum
  • Date: Fri May 03 16:21:58 2002 
On Fri, 3 May 2002, Stephen Griffin wrote:

> 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