engineering --> ddos and flooding

I came up with a solution for networks with ISP connections to deal
quickly with DDOS attacks without having to be able to work with a
network technician at the ISP for immediate relief. If the ISP agrees,
install a second low speed connection to the same router your primary
router BGP peers with. Through this low speed connection you run a
second bgp session advertising the /32 that is being attacked by the
DDOS. You mark the /32 as NO-ADVERTISE so the route doesn't leave the
border router.

If you can't bgp peer with the same router as the primary connection you
advertise the attacked /32 with the NO-EXPORT community so the route
stays within the ISP's AS.

This second low speed connection thus becomes a lightning rod for the
DDOS traffic most of which will be discarded and not even delivered due
to congestion on the slow speed link, the slower the better for you.
This of course kills all traffic to the attacked node but the rest of
the network remains usable. Then at least if the attack can be further
defined you can contact your ISP for a port specific or source address
specific filter so that more legitimate traffic can be accepted.

Another approach might be for the ISP to take a low end router like a
cisco 2600 and run multihop bgp with their customers who want this kind
of service. The router would remap the next hop information for all
routes it receives to null0 or perhaps a 100 Mb/s ethernet with nothing
on it. It would also mark all the routes NO-EXPORT. Then only the
single connection to the customer is needed. Two possible Achilles
heal with this approach is that the multihop bgp session between the
customer and the ISP's low end router may die under the flood of the
attack. Also the low end router could drop it's IBGP peering if it
becomes too flooded with the now redirected traffic. Of course
appropriate route filtering would be essential so your customer could
only advertise his own routes to be routed to a black hole.

Walt

Walter Prue wrote:

I came up with a solution for networks with ISP connections to deal
quickly with DDOS attacks without having to be able to work with a
network technician at the ISP for immediate relief. If the ISP agrees,
install a second low speed connection to the same router your primary
router BGP peers with. Through this low speed connection you run a
second bgp session advertising the /32 that is being attacked by the
DDOS. You mark the /32 as NO-ADVERTISE so the route doesn't leave the
border router.

Or, without adding an extra connection, negotiate a NULLROUTE community with
your upstream provider. This would be a wonderful addition to the
well-known BGP communities. I'll bring this up on IDR.

Mark

Ooh, a good idea (or is it just late on Friday?)

Two possible Achilles heal with this approach is that the multihop bgp

session between the

customer and the ISP's low end router may die under the flood of the
attack.
Also the low end router could drop it's IBGP peering if it
becomes too flooded with the now redirected traffic.

I think an appropriately secured web-based interface would be better than
multihop-BGP trickery, for the 'death of the customer connection' reason.
I'd hope every responsible noc operator has at least 5 backup dialup
accounts on other people's networks to access the webpage through.

Perhaps the low-end router (or Zebra running box)on the ISPs side could
advertise the routes internally to the ISP network with an next-hop of a big
router that can take the pain (or a security box that can log the packets).
Alternatively, a route-map on each router in the network could null route
any route advertisement with a nullroute community (curses, thought of it a
couple of seconds too late :slight_smile:

Cheers,

Phil Sykes, Network Engineer
Cable & Wireless European IP Engineering
p: +49 89 92699 204 m: +49 172 89 79 727

Walter Prue wrote:
>I came up with a solution for networks with ISP connections to deal
>quickly with DDOS attacks without having to be able to work with a
>network technician at the ISP for immediate relief. If the ISP agrees,
>install a second low speed connection to the same router your primary
>router BGP peers with. Through this low speed connection you run a
>second bgp session advertising the /32 that is being attacked by the
>DDOS. You mark the /32 as NO-ADVERTISE so the route doesn't leave the
>border router.

Or, without adding an extra connection, negotiate a NULLROUTE community with
your upstream provider. This would be a wonderful addition to the
well-known BGP communities. I'll bring this up on IDR.

Assuming not adding the extra connection, this means that upstream prefix filtering, so that one can't mistakenly inject 255 /24s rather than a single /16, would go out the window. Now think about /32s and what the routing tables will start to look like. Now consider that the upstream would also want to send to its upstream Tier-1 the NULLROUTE /32 as well so that his bandwidth is not eaten up as well and we have a situation whereby routing table size will triple in size every year.

-Hank

Assuming not adding the extra connection, this means that upstream prefix
filtering, so that one can't mistakenly inject 255 /24s rather than a
single /16, would go out the window. Now think about /32s and what the
routing tables will start to look like. Now consider that the upstream
would also want to send to its upstream Tier-1 the NULLROUTE /32 as well

so

that his bandwidth is not eaten up as well and we have a situation whereby
routing table size will triple in size every year.

This is a stop gap measure for customer networks. Those null routed /32s
are not
meant to be permanently advertised, they are meant to free the customer's
pipe from
smurf/fraggle until the SP can do something about it. What would be the
point of permanently
blackholing a host on your network?

I would imagine that most tier 1's are going to filter anything longer than
a /24 whether
you advertise it or not. The question isn't about route table size, it is
whether
your SP will go the extra mile to give you a proactive option to deal with
attack and has
someone clueful to implement it that will take responsibility for it (not
that it is hard).

This is a very limited measure that only helps in a very particular
situation for a small subset of
customer networks. I think it is a very useful tool for that particular
situation... it is not meant as
a principle that SP networks should apply to their upstream as well.

Geoff Zinderdine
CCNP CCA MCP
MTS Communications Inc.