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.

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.

Andreas Reuter, Randy Bush, Italo Cunha, Ethan Katz-Bassett, Thomas C. Schmidt, Matthias Wählisch; Towards a Rigorous Methodology for Measuring Adoption of RPKI Route Validation and Filtering; CCR July 2018

A proposal to improve routing security—Route Origin Authorization (ROA)—has been standardized. A ROA specifies which network is allowed to announce a set of Internet destinations. While some networks now specify ROAs, little is known about whether other networks check routes they receive against these ROAs, a process known as Route Origin Validation (ROV). Which networks blindly accept invalid routes? Which reject them outright? Which de-preference them if alternatives exist?

Recent analysis attempts to use uncontrolled experiments to characterize ROV adoption by comparing valid routes and invalid routes. However, we argue that gaining a solid understanding of ROV adoption is impossible using currently available data sets and techniques. Instead, we devise a verifiable methodology of controlled experiments for measuring ROV. Our measurements suggest that, although some ISPs are not observed using invalid routes in uncontrolled experiments, they are actually using different routes for (non-security) traffic engineering purposes, without performing ROV. We conclude with presenting three AS that do implement ROV as confirmed by the operators.

RFC 6945

Title: Definitions of Managed Objects for
the Resource Public Key Infrastructure (RPKI)
to Router Protocol
Author: R. Bush, B. Wijnen,
K. Patel, M. Baer
Status: Standards Track
Stream: IETF
Date: May 2013
Mailbox: randy@psg.com,
bertietf@bwijnen.net,
keyupate@cisco.com,
baerm@tislabs.com
Pages: 25
Characters: 52515
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-rpki-rtr-protocol-mib-07.txt

URL: http://www.rfc-editor.org/rfc/rfc6945.txt

This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for monitoring
the Resource Public Key Infrastructure (RPKI) to Router Protocol.

        Title:      The Resource Public Key Infrastructure 
                    (RPKI) Ghostbusters Record 
        Author:     R. Bush
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2012
        Mailbox:    randy@psg.com
        Pages:      8
        Characters: 15491
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sidr-ghostbusters-15.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6493.txt

In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc.  This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate.  The data in the record are those of a severely profiled vCard.

It is not that I believe strongly in this approach. But it sure is simpler than many others.

Anja Feldmann, Luca Cittadini, Wolfgang Mühlbauer, Randy Bush, Olaf Maennel, HAIR: Hierarchical Architecture for Internet Routing, in Proceedings of Workshop on Rearchitecting the Internet, December 2009.

A co-worker pointed out that I have been lax in keeping this site updated. So …

Bellovin, S.M.; Bush, R. Configuration Management and Security, IEEE Journal on Selected Areas in Communications, Volume 27, Issue 3, April 2009 Page(s):268 – 274

Robert Kisteleki proposed to use the RPKI to sign most of the IRR. I took the opposite view in the following rough proposal. Geoff Huston and I will be writing up my design in the next week.

Date: Mon, 03 Mar 2008 21:53:30 -0800
From: Randy Bush <randy@psg.com>
To: Robert Kisteleki <robert@ripe.net>
Cc: Resource Cert List <rescert@apnic.net>
Subject: Re: [Rescert] RPSL+RPKI proposals

robert,

i take a somewhat different view.

though i was hacking before ed codd, my mommy trained me to be
extremely wary when the same information is in two places.

but more important, i have a slightly different goal set.  i would ask
what we need to do in order to make the rpki helpful to isps in the
current task of configuring routing filters, but with more assurance of
correctness?

for this we do not need signed route: objects in the irr, as we have
roas and merely need to invert them, just as we do in the irr software,
to form the set of prefixes which each asn _may_ announce.

what we do not have in the rpki, which is in the irr, is the inter-asn
topology.  while josh and jrex would gather it from route-views or ris,
i am willing to stick one toe in the irr cesspool and sign the aut-num:,
probably in a fashion similar to the one you suggest.

but doing more is producing redundant data, transferring trust to a weak
sibling whose long-term survival is not required, and trying to make a
sow's ear into a silk purse when we are not in the silk purse business
anyway.

when we have s-bgp (or whatever), the irr will be completely IRRelevant
<tm>.  i see no need to try to touch it any more than we absolutely
needed to now.

randy

On the Sunday before NANOG, 17 February, an old acquaintance, Tom Pusateri stopped me and told me he had a start-up doing a new network device management appl,ication and did I want to be in the alpha test crew. As Tom had done such a great job on the Juniper configuration system, and done the netconf XML stuff in the IETF, I could not resist. Unfortunately, it was only going to run on the Macintosh, at least initially. So Monday, Joel drove me to the Apple Store a few miles away, and I got a 15″ MacBookPro to run Tom’s software.

I spent much of my spare time on Monday and Monday evening learning how to deal with the Mac. Why did they have to ‘add value’ to FreeBSD? I did manage to get enough tools installed that I could survive. A gang of Internet2 folk at NANOG were very helpful, as was Joel as usual.

Tuesday, I installed NetCannery, Tom’s application, and Tom got me started. Think of RANCID with an analytic back end. But it was clearly early in the development cycle.

The config fetcher has open source front ends for common devices, e.g. Cisco, Juniper, etc. So you can add strange new devices. And it is smart about bastion hosts, where you need to log into a control host to get to the device. But it did not have a bulk loader, which will be very necessary for any non-trivial networks. When I suggested this, Tom understood immediately and promised it for the near future.

I managed to fetch from a Cisco 7206 and some 2511s, but failed on a 1750 with VoIP. It worked for Juniper M5s, but not for a Procket 8801 or for HP ProCurve or SMC switches. Of course, Tom will fix that.

It lacked ways to group devices, e.g. North America, New York, PoP X, and type of device, e.g. infrastructure, backbone, customer-facing, etc. When I pointed this out, Tom and his friends discussed and came back with the idea of ‘smart’ folders. Not being a recent Mac person, I am not sure I understand the metaphor. So we’ll see how that turns out.