Re: 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:
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.
Including the BGP session, I would think, thus causing it to reset and drop the route, sending all the traffic back to the primary, which unfloods the smaller link, which re-advertises, which... Flappage, anyone? -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://www.lightbearer.com/~lucifer
> > This of course kills all traffic... > Including the BGP session, I would think, thus causing it to reset and > drop the route, sending all the traffic back to the primary, which unfloods > the smaller link, which re-advertises, which... Which in turn can be fixed by adding a _third_ connection between the two routers, dedicated to advertising /32s, which the upstream/recipient then route-maps to set-next-hop to the second connection... :-) Sounds to me like we need itrace soon. -Bill
Including the BGP session, I would think, thus causing it to reset and drop the route, sending all the traffic back to the primary, which unfloods the smaller link, which re-advertises, which...
Flappage, anyone?
Why not just advertise the host route with an unreachable next hop from your main peering session? Best regards, ==================== Geoff Zinderdine CCNP CCA MCP MTS Communications Inc. ==================== "I'd rather route than switch."
Geoff Zinderdine wrote:
Why not just advertise the host route with an unreachable next hop from your main peering session?
Maybe your upstream sets the NEXT_HOP to your side of the point-to-point for you, just in case you neglected to do so. Even if they don't, who's to say what's unreachable? If the NEXT_HOP is truly unreachable, in that there is no route to it, the BGP path won't be marked as valid and won't make it to the IP routing table (Loc-RIB.) I've long felt that IP should have come with a provision for an address that is never routed. It would be great if we could get something like 127.0.0.2 for this very task. Mark
Geoff Zinderdine wrote:
Why not just advertise the host route with an unreachable next hop from your main peering session?
Maybe your upstream sets the NEXT_HOP to your side of the point-to-point for you, just in case you neglected to do so.
Even if they don't, who's to say what's unreachable? If the NEXT_HOP is truly unreachable, in that there is no route to it, the BGP path won't be marked as valid and won't make it to the IP routing table (Loc-RIB.)
I've long felt that IP should have come with a provision for an address
Agreed. Still you could just throw up a box at the end of that low speed line and have your main peering session set it as NEXT_HOP for the host route without needing it to be running a BGP session itself, no? ----- Original Message ----- From: "Mark Mentovai" <mark-list@mentovai.com> To: "Geoff Zinderdine" <geoff.zinderdine@mts.mb.ca> Cc: <lucifer@lightbearer.com>; <nanog@merit.edu> Sent: Friday, June 01, 2001 2:07 PM Subject: Re: engineering --> ddos and flooding that
is never routed. It would be great if we could get something like 127.0.0.2 for this very task.
Mark
Easy... ip route 127.254.254.254 255.255.255.255 null0 BGP sees this as a valid route, straight to the bit bucket. -C
Even if they don't, who's to say what's unreachable? If the NEXT_HOP is truly unreachable, in that there is no route to it, the BGP path won't be marked as valid and won't make it to the IP routing table (Loc-RIB.)
I've long felt that IP should have come with a provision for an address that is never routed. It would be great if we could get something like 127.0.0.2 for this very task.
Mark
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
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
At 14:36 01/06/01 -0400, Mark Mentovai wrote:
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
Mark
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. ================================================================ The views expressed here are not necessarily those of my employer.
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 :-) Cheers, Phil Sykes, Network Engineer Cable & Wireless European IP Engineering p: +49 89 92699 204 m: +49 172 89 79 727
participants (8)
-
Bill Woodcock -
Christopher A. Woodfield -
Geoff Zinderdine -
Hank Nussbacher -
lucifer＠lightbearer.com -
Mark Mentovai -
Sykes, Phil -
Walter Prue