Let’s look at what’s happening in the Internet Engineering Task Force (IETF) and the upcoming IETF 104 meeting in the area of Internet infrastructure resilience. As usual, my focus here is primarily on the routing and forwarding planes, and specifically routing security and unwanted traffic of Distributed Denial of Service Attacks (DDoS) attacks. There’s interesting and important work underway at the IETF that can help addressing problems in both areas.
This time there are a lot of new ideas, especially of an operational nature, that people bring to the IETF in the form of Internet Drafts that aim to improve the security and resilience of the Internet infrastructure. So I’d like to introduce some of them to you, but keep in mind that an Internet Draft (I-D) does not necessarily indicate IETF endorsement. It also does not constitute a standard and may even not result in any work at the IETF.
So let’s look at what’s happening in BGP land.
Can BGP Communities be harmful?
In the recent paper “BGP Communities: Even more Worms in the Routing Can“, the authors demonstrated that Border Gateway Protocol (BGP) communities can be exploited by remote parties to influence routing in unintended ways. Due in part to their ill-defined semantics, BGP communities are often propagated far further than a single routing hop, even though their intended scope is typically limited to nearby ASes. As a consequence, remote adversaries can use BGP communities to trigger remote blackholing, steer traffic, and manipulate routes even without prefix hijacking.
The problem of ill-defined semantics is aggravated by the fact that BGP communities, and especially well-known communities, are manipulated inconsistently by current router implementations. There are differences in the outcome of the “set” directive in several popular BGP implementations. For example, in Juniper Network’s Junos OS, “community set” removes all received communities, well-known or otherwise, whilst in Cisco Systems’ IOS XR “set community” removes all received communities except a few.
An I-D “Well-Known Community Policy Behavior” describes the current behavioural differences in order to “assist operators in generating consistent community-manipulation policies in a multi-vendor environment, and to prevent the introduction of additional divergence in implementations.”
The document also urges network operators never to rely on any implicit understanding of a neighbor ASN’s BGP community handling. For instance, “before announcing prefixes with NO_EXPORT or any other community to a neighbor ASN, the operator should confirm with that neighbor how the community will be treated.”
BGP Large Communities in the IXP environment
Some networks peer at multiple IXPs in order to improve redundancy and geographical optimization. It is also common that, in the case of using a Route Server (RS) to implement multilateral peering relationships, Large Communities are used to instruct the RS on how to handle an announcement (e.g. not to advertise to a particular ASN), or to send additional information to the peer, e.g. the status of the validation.
The I-D “BGP Large Communities applications for IXP Route Servers” attempts to document commonly used Large Communities to facilitate consistency of use across multiple IXPs.
Building a more robust routing policy with maximum prefix limits
Has your network experienced a situation where a peer suddenly floods your border router with many more routes than expected, sometimes causing resource exhaustion and other troubles?
The I-D “BGP Maximum Prefix Limits” describes mechanisms to reduce the negative impact of these types of misconfigurations. Instead of a general limit on the number of prefixes received from a BGP neighbour, as defined in the BGP specification, it proposes a more granular scheme with three control points to mitigate the impact:
- Pre-Policy Inbound Maximum Prefix Limits – when the limit is checked before any policy is applied (e.g. filtering). These limits are particularly useful to help dampen the effects of full table route leaks and memory exhaustion when the implementation stores rejected routes.
- Post-Policy Inbound Maximum Prefix Limits – checked after the import policy is applied. They are useful to help prevent FIB exhaustion and prevent accidental BGP session teardown due to prefixes not accepted by policy anyway.
- Outbound Maximum Prefix Limits – trigger termination of a BGP session with a neighbor when the number of address prefixes to be advertised to that neighbor exceeds a locally configured upper limit. These limits are useful to help dampen the negative effects of a misconfiguration in local policy. In many cases, it would be more desirable to tear down a BGP session rather than flooding the neighbors with misconfigured announcements.
These recommendations are distilled from a broader framework, presented by Job Snijders at the RIPE 77 meeting last year.
Leveraging RPKI for proven operational practices
A common best practice to ensure that one’s customers only announce their own networks and the networks of their customers, is to build prefix filters.
In the case there are only direct customer relationships (i.e. the network operator’s customers are ‘stub networks’), the task is relatively easy. One needs to collect prefixes, legitimately originated by these networks, and this is most commonly done by using an IRR of choice and collecting corresponding “route” objects. But with the proliferation of RPKI, it can become a more robust alternative, providing a cryptographically verifiable ROA object that serves a similar purpose.
If you are a bigger network and some of your customers also provide transit services for smaller networks, the task is more difficult. How to determine who are the customers of your customers and so on?
To help with this task, there is a special IRR object – “as-set”. This object is a list of ASNs or other “as-sets” that defines the customer cone of a particular AS.
However, when it comes to RPKI, there is no way for an operator to assert the routes for its customer networks, making it difficult to use the information carried by RPKI to create meaningful prefix filters without relying on RPSL “as-sets”.
The I-D “RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering” attempts to fix that problem by introducing a new attestation object called an AS-Cone. An AS-Cone is a digitally signed object with the goal of enabling operators to define a set of customers that can be found as “right adjacencies” or transit customer networks, facilitating the construction of prefix filters for a given ASN, thus making routing more secure.
By leveraging RPKI, AS-Cone also addresses two fundamental problems with the RPSL “as-set”. The same AS-SET name can exist in multiple IRRs, and a relying party does not necessarily know which “as-set” belongs to which ASN, and which as-set to use.
Improving AS-PATH validation
The Border Gateway Protocol (BGP) was designed with no mechanisms to validate BGP attributes. The ability to manipulate one of them – AS_PATH – creates one of the most serious vulnerabilities of the Internet routing system. BGPsec was therefore designed to solve the problem of AS_PATH correctness.
But according to the authors of a new I-D “Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization” even leaving aside the complexity, its backward support for ‘insecure’ BGP allows an attacker to mount a downgrade attack to nullify all the work of AS_PATH signing.
The authors suggest a more pragmatic approach that can help leveraging the benefits of RPKI without the need for the ubiquitous deployment of BGPsec. The idea is that any AS can declare its upstream providers and peers – the networks that can propagate its prefix announcements. The more networks that do that, the more chances to detect misconfigurations whether malicious or not.
The draft defines the semantics of Autonomous System Provider Authorization (ASPA) objects that should become part of RPKI. ASPAs are digitally signed objects that bind in a selected AFI Provider AS number to a Customer AS number (in terms of BGP announcements not business), and are signed by the holder of the Customer AS. An ASPA attests that a Customer AS holder (CAS) has authorized a particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6 announcements onward, e.g. to the Provider’s upstream providers or peers.
Mitigating DDoS attacks
DDoS attacks are a persistent and growing threat on the Internet. As they evolve rapidly in the terms of volume and sophistication, a more efficient cooperation between the victims and parties that can help mitigate such attacks is required. The ability to quickly and precisely respond to a attack when it begins, and communicate precise information to a mitigation service provider is crucial.
Addressing this challenge is what keeps the DDoS Open Threat Signaling (DOTS) Working Group busy. The aim of DOTS is to develop a standards based approach for the real-time signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. Specifications outlining the requirements, architecture and the use cases for DOTs are maturing, and there is a hackathon planned at IETF104 to conduct further interoperability testing of DOTS protocols.
Another interesting case getting more importance, especially with the advent of consumer IoT devices, is mitigation of outbound DDoS attacks originating in a home network. The I-D “Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home” proposes a solution to these cases by proposing a DOTS signal channel Call Home extension that enables the DOTS server to initiate a secure connection to the DOTS client. The DOTS client then conveys the attack traffic information to the DOTS server.
In a typical deployment scenario, the DOTS server is enabled on a CPE, whilst a client resides in an ISP network. In this case the DOTS server in the home network initiates the Call Home during peace time, and subsequently the DOTS client in the ISP environment can initiate a mitigation request whenever the ISP detects there is an attack from a compromised device in the DOTS server’s domain. Subsequently, the DOTS server would use the DDoS attack traffic information to identify the compromised device in its domain launching the DDoS attack, notify the network administrator, and take appropriate mitigation action such as quarantining the compromised device or block its traffic to the attack target until the mitigation request is withdrawn.
The meeting in Prague is certainly going to be interesting regarding Internet infrastructure security and resilience, and will hopefully have a positive impact in this area.
Relevant Working Groups at IETF 104
SIDROPS (SIDR Operations) WG
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-sidrops
Charter: https://datatracker.ietf.org/wg/sidrops/charter/
GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-grow
Charter: https://datatracker.ietf.org/wg/grow/charter/
IDR (Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-idr
Charter: https://datatracker.ietf.org/wg/idr/charter/
DOTS (DDoS Open Threat Signaling) WG
Agenda: https://datatracker.ietf.org/meeting/104/materials/agenda-104-dots
Charter: https://datatracker.ietf.org/wg/dots/charter/