Randy's Work Blog

RFC 9455
Title: Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes
Author: Z. Yan,
        R. Bush,
        G. Geng,
        T. de Kock,
        J. Yao
Status: Standards Track
Stream: IETF
Date: August 2023
URL: https://www.rfc-editor.org/info/rfc9455
DOI: 10.17487/RFC9455

When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es). This memo discusses operational problems that may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix.

Romain Fontugne, Amreesh Phokeer, Cristel Pelsser, Kevin Vermeulen, and Randy Bush, RPKI Time-of-Flight: Tracking Delays in the Management, Control, and Data Planes; PAM March 2023

As RPKI is becoming part of ISPs’ daily operations and Route Origin Validation is getting widely deployed, one wonders how long it takes for the e?ect of RPKI changes to appear in the data plane. Does an operator that adds, fixes, or removes a Route Origin Authorization (ROA) have time to brew co?ee or rather enjoy a long meal before the Internet routing infrastructure integrates the new information and the operator can assess the changes and resume work? The chain of ROA publication, from creation at Certification Authorities all the way to the routers and the e?ect on the data plane involves a large number of players, is not instantaneous, and is often dominated by ad hoc administrative decisions. This is the first comprehensive study to measure the entire ecosystem of ROA manipulation by all five Regional Internet Registries (RIRs), propagation on the management plane to Relying Parties (RPs) and to routers; measure the e?ect on BGP as seen by global control plane monitors; and finally, measure the e?ects on data plane latency and reachability. We found that RIRs usually publish new RPKI information within five minutes, except APNIC which averages ten minutes slower. At least one national CA is said to publish daily. We observe significant disparities in ISPs’ reaction time to new RPKI information, ranging from a few minutes to one hour. The delay for ROA deletion is significantly longer than for ROA creation as RPs and BGP strive to maintain reachability. Incidentally, we found and reported significant issues in the management plane of two RIRs and a Tier1 network.

Victor-Alexandru Padurean, Oliver Gasser, Randy Bush, Anja Feldmann SRv6: Is There Anybody Out There?. 7th International Workshop on Traffic Measurements for Cybersecurity (WTMC June 2022).

Segment routing is a modern form of source- based routing, i.e., a routing technique where all or part of the routing decision is predetermined by the source or a hop on the path. Since initial standardization efforts in 2013, segment routing seems to have garnered substantial industry and operator support. Especially segment routing over IPv6 (SRv6) is advertised as having several advantages for easy deployment and flexibility in operations in networks. Many people, however, argue that the deployment of segment routing and SRv6 in particular poses a significant security threat if not done with the utmost care.

In this paper we conduct a first empirical analysis of SRv6 deployment in the Internet. First, we analyze SRv6 behavior in an emulation environment and find that different SRv6 implementations have the potential to leak information to the outside. Second, we search for signs of SRv6 deploy- ment in publicly available route collector data, but could not find any traces. Third, we run large-scale traceroute campaigns to investigate possible SRv6 deployments. In this first empirical study on SRv6 we were unable to find traces of SRv6 deployment even for companies that claim to have it deployed in their networks.

RFC 9255
Title: The 'I' in RPKI Does Not Stand for Identity
Authors: R. Bush,
         R. Housley
Status: Standards Track
Stream: IETF
Date: June 2022
URL: https://www.rfc-editor.org/info/rfc9255
DOI: DOI: 10.17487/RFC9255

There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the ‘holder’ of an INR. This document specifies that RPKI does not associate to the INR holder.

RFC 9234
Title: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN
Author: A. Azimov,
        E. Bogomazov,
        R. Bush,
        K. Patel,
        K. Sriram
Status: Standards Track
Stream: IETF
Date: May 2022
URL: https://www.rfc-editor.org/info/rfc9234
DOI: DOI: 10.17487/RFC9234

Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.

Nils Rodday, Italo Cunha, Randy Bush, Ethan Katz-Bassett, Gabi Dreo Rodosek, Thomas C. Schmidt, Matthias Wählisch; Revisiting RPKI Route Origin Validation on the Data Plane. TMA September 2021

The adoption of the Resource Public Key Infrastructure (RPKI) is increasing, as are measurement activities to identify RPKI-based route origin validation (ROV). Several proposals try to identify Autonomous Systems (ASes) that deploy ROV using control plane as well as data plane measurements. We show why simple end-to-end measurements may lead to incorrect identification of ROV. In this paper we evaluate data plane traceroute measurements as a mechanism to extend coverage and provide a reproducible method for ROV identification using RIPE Atlas. Moreover, we extend the current state-of-the-art by identifying ROV performed by route servers at Internet Exchange Point (IXP) and using an include list to differentiate between fully and partially ROV-enforcing ASes. Our measurements from 5537 vantage points in 3694 ASes infer ROV is deployed in 206 unique ASes: 10 with strong confidence, 12 with weak confidence, and 184 indirectly adopting ROV via filtering by IXP route servers.

John Kristoff, Randy Bush, Chris Kanich, George Michaelson, Amreesh Phokeer, Thomas Schmidt, Matthias Wählisch. On Measuring RPKI Relying Parties, ACM IMC 2020

On Measuring RPKI Relying Parties

In this paper, we introduce a framework to observe RPKI relying parties (i.e., those that fetch RPKI data from the distributed repository) and present insights into this ecosystem for the first time. Our longitudinal study of data gathered from three RPKI certification authorities (AFRINIC, APNIC, and our own CA) identifies different deployment models of relying parties and (surprisingly) prevalent inconsistent fetching behavior that affects Internet routing robustness. Our results reveal nearly 90% of relying parties are unable to connect to delegated publication points under certain conditions, which leads to erroneous invalidation of IP prefixes and likely widespread loss of network reachability.

Caitlin Gray, Clemens Mosig, Randy Bush, Cristel Pelsser, Matthew
Roughan, Thomas Schmidt, Matthias Wählisch . BGP Beacons, Network Tomography, and Bayesian Computation to Locate Route Flap Damping, ACM IMC 2020

Pinpointing autonomous systems which deploy specific inter-domain techniques such as Route Flap Damping (RFD) or Route Origin Validation (ROV) remains a challenge today. Previous approaches to detect per-AS behavior often relied on heuristics derived from passive and active measurements. Those heuristics, however, often lacked accuracy or imposed tight restrictions on the measurement methods.

We introduce an algorithmic framework for network tomog- raphy, BeCAUSe, which implements Bayesian Computation for Autonomous Systems. Using our original combination of active probing and stochastic simulation, we present the first study to expose the deployment of RFD. In contrast to the expectation of the Internet community, we find that at least 9% of measured ASs enable RFD, most using deprecated vendor default configuration parameters. To illustrate the power of computational Bayesian methods we compare BeCAUSe with three RFD heuristics. Thereafter we successfully apply a generalization of the Bayesian method to a second challenge, measuring deployment of ROV.

RFC 8893 
Title: Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export 
Author: R. Bush, 
        R. Volk,
        J. Heitz
Status: Standards Track 
Stream: IETF 
Date: September 2020 
Updates: RFC 6811 
URL: https://www.rfc-editor.org/info/rfc8893 
DOI: 10.17487/RFC8893

A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the ‘effective origin AS’ of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS.

Odnan Ref Sanchez, Simone Ferlin, Cristel Pelsser, Randy Bush Comparing Machine Learning Algorithms for BGP Anomaly Detection using Graph Features at 3rd ACM CoNEXT Workshop on Big DAta, Machine Learning and Artificial Intelligence for Data Communication Networks (Big-DAMA 2019)

The Border Gateway Protocol (BGP) coordinates the connectivity and reachability among Autonomous Systems, providing efficient operation of the global Internet. Historically, BGP anomalies have disrupted network connections on a global scale, i.e., detecting them is of great importance. Today, Machine Learning (ML) methods have improved BGP anomaly detection using volume and path features of BGP’s update messages, which are often noisy and bursty. In this work, we identified different graph features to detect BGP anomalies, which are arguably more robust than traditional features. We evaluate such features through an extensive comparison of different ML algorithms, i.e., Naive Bayes classifier (NB), Decision Trees (DT), Random Forests (RF), Support Vector Machines (SVM), and Multi-Layer Perceptron (MLP), to specifically detect BGP path leaks. We show that SVM offers a good trade-off between precision and recall. Finally, we provide insights into the graph features’ characteristics during the anomalous and non-anomalous interval and provide an interpretation of the ML classifier results.