Internet2 DDoS Mitigation Update
Distributed Denial of Service (DDoS) attacks continue to plague organizations and be on the list of worrisome threats for many campuses, especially after the recent Dyn DDoS attack and Brian Kreb’s investigation into his DDoS attacks. As noted in the October 2016 Internet2's DDoS Mitigation Strategy blog posting, there are different types of DDoS attacks (i.e., volumetric, application layer, multi-vector) that can adversely affect research and education institutions with no clear single best method for combating the different types of DDoS attack. The most robust defensive approach involves selecting the most effective method designed to minimize the negative effects of a particular type of DDoS attack.
In some of our discussions, we realized that even to many technical people, the differences between the types of DDoS attacks and corresponding mitigation methods can be confusing. And when you start adding marketing language provided by DDoS attack mitigation providers, it can become even more confusing! To help reduce possible confusion, it may be helpful to review this chart from US-CERT. The chart below lays out by Open Systems Interconnection (OSI) network layer the different characteristics for DDoS attacks along with options for mitigation:
(Above) Attack Possibilities by OSI Layer - Click image to view larger version
The focus of the research and education community has been on two primary types of DDoS attacks, volumetric attacks targeting infrastructure that cover OSI layers 3 (network) and 4 (transport), and application-layer attacks targeting web applications that cover OSI layers 6 (presentation) and 7 (application). While generally called DDoS attacks due to the intended denial and/or degradation of a service, each kind of attack targets a different layer of the operational environment. These different kinds of attacks are usually best dealt with using different solutions optimized for the unique characteristics of the attack.
The Internet2 community has been actively exploring options and discussing potential solutions to combat these different types of DDoS attacks. The remainder of this article takes a closer look at the optimal methods for dealing with application-layer attacks and several methods for dealing with volumetric attacks.
Mitigation of Application-Layer Attacks
To best deal with application-layer attacks, the mitigation method is usually integrated with the application / web services themselves including potentially decrypting Transport Layer Security (TLS) traffic and inspect the plaintext for malicious content and subsequent scrubbing of the attack traffic. This method generally requires appliances on-premise with the web services being protected or the use of a Domain Name System (DNS) entry that points your web service to a provider's solution where the inspection and scrubbing of an attack occurs.
Identifying a potential NET+ service directed at application layer DDoS mitigation is underway. The NET+ team has been contacted by several campuses regarding an application-layer DDoS mitigation service including the identification of a sponsor campus for one particular application-layer DDoS mitigation provider, CloudFlare. The sponsor campus had deployed CloudFlare for their main website while it was under attack. The NET+ team and the campus have discussed usage of CloudFlare, how it was technically implemented, operational details, and what the campus thought of the service. An area to be discussed with CloudFlare is potentially peering with the Internet2 Network as the return path for clean traffic. Work has begun with CloudFlare to be a pilot service in the Internet2 Services Hub. We are planning a webinar for CloudFlare to go over their service and how it fits with the other DDoS activities with the Security Working Group on March 30th at 4pm ET / 1pm PT.
Mitigation of Volumetric Attacks
Volumetric attacks that target the infrastructure can be of sufficiently large bandwidth so as to be more than an organization’s network connections can sustain. In such an attack, any on-premise solution is ineffective since it’s limited by the network capacity of the organization. Instead, these types of DDoS volumetric attacks are best dealt with by the ISP or transit networks carrying the attack. There are several solutions that Internet2 is considering, both which can be used either separately or together.
An RFP for DDoS volumetric cloud scrubbing service is underway. A pilot group of universities and regional networks are reviewing the vendor submissions with a decision possibly being made in time for Global Summit. There will be a more public announcement about this in the near future.
Another solution though that is often employed by transit networks is called BGP FLow Specification Rules (FlowSpec) is discussed next.
BGP Flowspec, defined in RFC 5575, is a signalling method for packet filtering. It is similar to blackholing but more refined and precise. Instead of dropping all packets destined to a host or sourced from an IP address (source based blackholing), flowspec can match on various fields in the IP and transport headers. In the case of source based filtering, flowspec doesn’t relying on unicast reverse path forwarding and dynamic alteration of next hops.
BGP Flowspec uses Multiprotocol BGP to disseminate flow specifications - instructions to the router on how to alter a specific traffic flow. The use of BGP allows flowspec routes to be quickly disseminated within a BGP domain and, where appropriate, across BGP domains. Similar to IPv4, IPv6, and multicast address families in MP-BGP, flowspec defines a new NLRI format and associated address families for carrying the filter conditions and leverages BGP extended communities to signal the actions.
A flowspec rule can match on:
- Destination / source prefix
- IP protocol
- Destination and/or source port
- ICMP Type and Code
- TCP flags
- Packet length
- Fragment encoding
Flowspec actions are:
- Traffic-rate (rate to discard)
- Traffic-action (sample)
- Redirect to VRF (redirect to next-hop IP is in progress)
- Traffic-marking (DSCP)
By default, flow routes are validated based on the originator of the best unicast route; i.e., the flow route originator must also be the best route for the destination prefix defined in the flow route. Validation prevents someone from accidently or maliciously injecting a flow route that drops traffic to a destination that they don’t control. Additionally, operators can use routing policy to enforce restrictions on flow routes.
How the flowspec route is implemented is determined by the vendor. Internet2 uses Juniper MX routers in our backbone and Juniper creates firewall filters based on the flow route. Those filters are automatically applied to every interface.
Internet2 is currently exploring two options for supporting BGP flowspec. These options are not mutually exclusive and, in all likelihood, based on community feedback, we will support both options.
The obvious option is to support flowspec directly via BGP announcements. Internet2 and its members add the flow family to their existing BGP sessions. Internet2 will use flow validation in addition to our standard routing policies to ensure that a member doesn’t create a flow route that targets another member’s destination prefixes. Through collaboration with the community and testing in a lab, we will determine appropriate policy and configuration so flowspec does not adversely affect the Internet2 network.
The second option for support flowspec is via a web portal. Members will use the portal to inject flowspec routes into the Internet2 backbone. We are currently investigating the use of Firewall on Demand (FoD) which is a project used and supported by GÉANT. FoD will rely on InCommon for authentication and maintain an internal authorization table for users and the network prefixes they are allowed to create flowspec routes for. FoD also supports a REST API for programmatic administration of flowspec.
As you can see, there different types of DDoS attacks and their corresponding optimal mitigation methods can be a bit confusing. Future articles will describe the capabilities of each method in more detail as well as scenarios for using a particular mitigation method or several mitigation methods in combination.