Welcome to the Packet Pushers Priority Queue. On today’s show we’re going to talk about BGP flowspec, an RFC that can be used for DoS mitigation.
But before we dive in, let’s level set on BGP, the border gateway protocol. BGP is the routing protocol that glues the Internet together. Big, huge companies and service providers use complex BGP policies to govern traffic flowing across their networks. BGP lets you perform some clever routing tricks that you can’t really do with an interior gateway routing protocol like OSPF or EIGRP.
And all of that is, more or less, true. To quote RFC 4271, “The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability, from which routing loops may be pruned and, at the AS level, some policy decisions may be enforced.”
Okay. So RFC 4271 tells us that BGP is, primarily for telling BGP speakers what networks are reachable via what autonomous systems. And if you dig a little deeper, you find that information is learned via the exchange of NLRIs – network layer reachability information messages.
Now, here’s the big deal with BGP. An NLRI could contain any sort of information. An NLRI doesn’t have to contain an IP prefix with reachability information. You know, a route. For instance, RFC 4684 defines NLRIs that contain route-target information. RFC 4760 talks about NLRIs for multi-protocol BGP. RFC 7432 defines NLRIs for EVPN.
Once you realize this, BGP becomes more than just a routing protocol. BGP can be used to share all sorts of information between BGP speakers to influence their forwarding decisions.
The topic of our conversation today is RFC 5575, BGP flowspec. BGP flowspec defines a specific BGP NLRI defining a flow. What do BGP speakers do with this flow information?
Our guest today is Justin Ryburn, who’s going to talk us through BGP flowspec and how it can be used to mitigate DoS and DDoS attacks.
Justin is a Consulting Engineer with Juniper Networks. He’s been with Juniper for about 9 years in both pre-sales and post-sales Engineering roles, and has about 20 years experience in networking with a primary focus on service providers and carriers.
Section 1 – Setting Up The problem: DoS Attacks
- Briefly, what’s a DoS attack?
- High Level – Denial of Service attack is any attack that denies (blocks) the legitimate use of a resource.
- There is also a term DDoS. The extra D stands for distributed and it refers to the type of attack with a widely distributed source.
- What are the chief ways DoS attacks are defended against (and their issues)?
- Manual call – help me, I’m being attacked!
- D/RTBH – victim announces RTBH
- S/RTBH – victim calls for help, NOC initiates RTBH + uRPF
- The big deal? Every flow dies in the blackhole in destination-based filtering. A lack of granularity that kills useful traffic along with the DoS traffic. Even source-based with uRPF is not a perfect answer, although it’s better that destination-based.
- It is better in the sense that it does not “complete the attack” like you mentioned with destination-based filtering. However, it is impractical for a truly distributed attack as the source can be hundreds or thousands of hosts.
Section 2 – Introducing BGP Flowspec For DoS Mitigation
- What is BGP flowspec?
- IETF standard for advertising attack flow information in BGP
- Standard defines a new NLRI for describing the flow parameters (src IP, dest IP, src port, dst port, etc.)
- Also defines the actions that can be taken on matching traffic. These are communicated using BGP communities attached to the NLRI. Actions are rate limit (0 is drop), change COS markings, or redirect to a VRF.
- How do we detect DoS flows and inject them into the BGP system using flowspec?
- Most network operators are detecting DoS flows using a tool that looks at sFlow or Netflow/IPFIX data. Usually you baseline what you consider “normal” traffic in your network and then monitor for spikes or anomalies. Once an attack is detected, how you convert that BGP Flowspec NLRIs depends on the tool you are using. Most of the commercially available flow collection tools can do this automatically if you have a BGP session configured between the server and your BGP edge routers. Another option is to have a script running that logs in to a router server, creates a static flow route, and injects that in to BGP. Obviously all of your BGP edge routers have to be talking to this route server to receive that route.
- When a BGP speaker receives a flowspec NLRI, what happens?
- The device converts the flowspec route into an ACL or firewall filter and applies it to all of its interfaces. In the case of dropping traffic, this it pretty straightforward. If the action specified in the communities is to redirect traffic then this becomes FBF/PBR. If the action is to rate limit then this essentially becomes a policer.
- Can a customer announce flowspec NLRIs to their upstream providers?
- There is nothing technical to stop this from happening. Flowspec NLRIs can be passed between autonomous systems just like any other NLRI type. The reality is that today there are very few providers who allow that. I am hopeful as the technology continues to mature that will change. I think it makes the solution much more useful.
- BGP flowspec is a standard (RFC 5575), but is it commonly available?
- For the most part, yes. Juniper has been supporting it in Junos since 7.3. Cisco and ALU/Nokia both support it now as well. In my mind, those are really your big 3 when it comes to provider edge routers.
- Flowspec communication (the NLRI part) seems easy enough. But shoving that learned flow + an action into silicon is a bit harder. Fair?
- That is a fair point. It does require support in the chip/silicon to do this. Historically you had to have a customer ASIC to be able to do this. I am not sure if any of the commodity ASIC vendors are adding support for this but that would be one thing that would definitely help lower the entry cost for the solution.
- This reminds me a lot of OpenFlow, and I know of at least one DoS mitigation tool based on OpenFlow. Not to conflate flowspec with OpenFlow, but is that a fair comparison?
- To some degree. There are some solutions out there that use OpenFlow to directly program the forwarding plane to drop attack traffic. One problem with that solution is it will be difficult if not impossible to make it an inter-AS solution. If providers are scared to let their customers send them flowspec routes, imagine their reaction if you ask to be able to modify their router’s forwarding plane with an OpenFlow controller. I would also argue that BGP flowspec is more mature than OpenFlow at this point.
Section 3 – How Does BGP flowspec See Wider Adoption?
- What hardware implementations do we see today?
- What software implementations do we see today?
- Do customers need to ask for flowspec support?
- Of their vendors? Yes
- Of their providers? Yes
- The only way we are going to get more traction with this technology is for more people to ask their providers for it and more providers to ask their vendors for it. For better or worse, that is how the networking industry works when it comes to new things.
- Is BGP flowspec done? Or does development continue?
- Not at all. Like most things in networking, the work is never done. We are continually learning from our mistakes so to speak. As people implement solutions, we figure out what works and what does not work. That information is fed back through vendors and improvements are being made. Flowspec is no exception. There is a very active working group in the IETF. A few specifics that are being finalized now are IPv6 support, IP redirect (instead of VRF), and Interface Sets which allows you to specify what set of interfaces you want the filter applied to (edge only for example).
- Where can folks find out more about BGP flowspec?
- Books and other resources
- How to follow Justin Ryburn