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:

Main

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.

Normal_flow

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:

Bad_flow1

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.

Loop

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.

PBR

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.

PBR2

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.

GRE

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.

VRF

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.

Routing Considerations in DDoS Protection Environments
Tagged on:                         

5 thoughts on “Routing Considerations in DDoS Protection Environments

  • July 9, 2014 at 1:57 pm
    Permalink

    The setupĀ“s i have seen is all based on Vrf except 2 with Gre as mentioned above , and yes the Gre setup was due to hardware / vrf incompability

    Reply
    • July 9, 2014 at 4:15 pm
      Permalink

      Thanks for posting Karl-Oskar.

      Flowspec looks very interesting and has the capability of injecting traffic into a VRF. I will try to run this scenario with the new XRv 5.2.0 that was just released.

      Reply
  • January 9, 2016 at 12:07 am
    Permalink

    just a word of thanks for the articles Daniel. Topical subject for me at the moment..

    Reply
  • June 25, 2016 at 4:54 pm
    Permalink

    Hi Daniel, What about Remotely Triggered Black Hole Filtering as an additional option? Any SP’s doing it or is it legacy?

    Reply
    • June 26, 2016 at 7:39 pm
      Permalink

      It’s definitely stil used, especiall S/RBTH which is the null routing of packets based on the source address.

      Works well as long as you don’t have a lot of sources. You need uRPF deployed to use it.

      Reply

Leave a Reply to Neil Morris Cancel reply

Your email address will not be published. Required fields are marked *