Routing Considerations in DDoS Protection Environments

Lately I have done some studying for the CCDE and one of the things I was
looking at is how to protect against DDoS attacks. I’m not expecting it
to be a big topic for the CCDE but it has some interesting concepts relating
to routing. Take a look at the following topology:

There is an attacker at the top left. R1 is the edge device and then there are a
few more routers, all peering BGP with the RR, which is R5. The server of interest
is 100.100.100.100 and there is a scrubbing device to the far right. All routers
peer iBGP from their loopbacks to the RR, including the scrubbing device.

Normally traffic to 100.100.100.100 would flow through R1 to R4 and then to the
server.

The attacker now starts to flood the server with malicious traffic. This is detected
by the DDoS scrubbing device which starts to announce via BGP a more specific route
than the one advertised by R4. R4 normally advertises 100.100.100.0/24 but the
scrubbing device advertises 100.100.100.100/32. All the other routers will start
to forward traffic to 100.100.100.100 towards the scrubbing device. The traffic flow
is then like this:

The scrubbing device does it job, sends the traffic towards R3 and BAM!
Traffic is looped… Why? R3 has a route to 100.100.100.100/32 pointing at 6.6.6.6.
When the scrubbing device sends the traffic to R3 it gets looped back.

So this is what I find interesting. What can we do to bypass normal forwarding rules
and to keep the traffic from looping?

One method is to apply policy based routing. Put a route-map on the interface that
is facing the scrubbing device with an ACL for traffic that needs special treatment.

Create an extended ACL called “PBR_SPECIAL_TRAFFIC” where traffic that is destined
for 100.100.100.100 gets a next-hop of 2.2.2.2. The problem is though that this
would not work in this case because R2 has a route back towards R3. For this to
work, R2 would have to be excluded from the forwarding path and the server would
then be connected to R2. R2 would need a static route to override the BGP /32 route.

This solution is a bit of a kludge and traffic can easily get looped if you are
not careful. Also, PBR always has the risk of becoming CPU forwarded if you configure
unsupported actions in the route-map.

Another solution is to create a GRE tunnel between the scrubbing device and the router
where the server resides.

The traffic would then be tunneled from the scrubbing device to the attaching router.
Because R4 has a /32 route in BGP, a static route should be added to overcome this.
Make sure that GRE is forwarded in hardware and account for the increased packet
size which could lead to fragmentation of not careful. Make sure that the MTU
supports GRE tunneling and a payload of at least 1460 bytes.

There is also the possibility of reinjecting the traffic into another VRF.
The VRF can have other routing than the global table. Either VRF Lite or
MPLS would be needed to support this solution.

The final solution seems like the best to me but it requires that you have
an infrastructure supporting the use of VRFs.

This post gives you a brief overview of how a DDoS protection appliance works
and how we sometimes must overcome the normal forwarding rules of the network.