Randy's Work Blog

RFC 9632
Title: Finding and Using Geofeed Data
Author: R. Bush,
        M. Candela,
        W. Kumari,
        R. Housley
Status: Standards Track
Obsoletes: 9092
Stream: IETF
Date: August 2024
URL: https://www.rfc-editor.org/info/rfc9632
DOI: 10.17487/RFC9632

This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the geofeed data files. This document obsoletes RFC 9092.

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.

RFC 9324
Title: Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh
Author: R. Bush,
        K. Patel,
        P. Smith,
        M. Tinka
Status: Standards Track
Stream: IETF
Date: December 2022
URL: https://www.rfc-editor.org/info/rfc9324
DOI: 10.17487/RFC9324

A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with respect to new RPKI data.

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.

Clemens Mosig, Randy Bush, Cristel Pelsser, Thomas C. Schmidt, Matthias Wählisch; Revisiting Recommended BGP Route Flap Damping Configurations. TMA September 2021.

BGP Route Flap Damping (RFD) is recommended to suppress BGP churn. Current configuration recommendations for RFD, however, are based on a study from 2010. Since then, BGP churn increased by one order of magnitude, which may lead to outdated RFD parameters and introduce more loss of reachability of stable networks. In this paper, we revisit current recommendations to configure RFD. First, we develop an accurate and scalable emulation of Cisco and Juniper RFD implemen- tations and make it publicly available. Second, we successfully reproduce the 2010 measurement study that justified the current RFD recommendations using current data. Third, we consider the RFD implementation of an additional major router vendor (Juniper), which penalizes BGP churn differently compared to the previously studied Cisco implementation. Fourth, we include IPv6 data from 2020. Our results show that the recommended RFD configuration parameters from 2010, though seemingly rarely used, still hold today in IPv4 and IPv6 and across vendors, even though BGP churn increased significantly. Our study revises metrics to assess the impact of incorrectly configured RFD, discusses collateral damage, and gives insights into sweet spots when damping routes.

Nils Rodday, Lukas Kaltenbach, Ítalo Cunha, Randy Bush, Ethan Katz-Bassett, Gabi Dreo Rodosek, Thomas C. Schmidt, Matthias Wählisch: On the Deployment of Default Routes in Inter-domain Routing. TAURIN@SIGCOMM August 2021: 14-20

In this paper, we argue that the design of a responsible Internet requires a clear understanding of the current state of deployment. This work sheds light on default routing in the Internet, a routing strategy that reduces control but may help to increase availabil- ity when forwarding packets. We revisit and extend two common methodologies based on active measurements to increase coverage and accuracy. Our results show larger differences in the results between the methodologies. We confirm that default route deploy- ment strongly correlates with the customer cone size of autonomous systems and that smaller networks are more likely to deploy a de- fault route. Our data will help to better assess the deployment of other protocols such as RPKI route origin filtering.