Randy's Work Blog

 RFC 8635
 Title:      Router Keying for BGPsec 
 Author:     R. Bush,
             S. Turner,
             K. Patel
 Status:     Standards Track
 Stream:     IETF
 Date:       August 2019
 I-D Tag:    draft-ietf-sidrops-rtr-keying-06.txt
 URL:        https://www.rfc-editor.org/info/rfc8635
 DOI:        10.17487/RFC8635

BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.

Florian Streibelt, Franziska Lichtblau, Robert Beverly, Anja Feldmann, Cristel Pelsser, Georgios Smaragdakis, and Randy Bush. BGP Communities: Even more Worms in the Routing Can. Proc. Internet Measurement Conference 2018 (IMC ‘18).ACM, New York, NY, USA, 279-292.

Florian Streibelt, Franziska Lichtblau, Robert Beverly, Anja Feldmann, Cristel Pelsser, Georgios Smaragdakis, Randy Bush; BGP Communities: Even more Worms in the Routing Can; ACM Internet Measurement Conference 2018.

BGP communities are a mechanism widely used by operators to manage policy, mitigate attacks, and engineer traffic; e.g., to drop unwanted traffic, filter announcements, adjust local preference, and prepend paths to influence peer selection.

Unfortunately, we show that BGP communities can be exploited by remote parties to influence routing in unintended ways. The BGP community-based vulnerabilities we expose are enabled by a combination of complex policies, error-prone configurations, a lack of cryptographic integrity and authenticity over communities, and the wide extent of community propagation. 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. Indeed, we find 14% of transit ASes forward received BGP communities onward. Given the rich inter-connectivity of transit ASes, this means that communities effectively propagate globally. As a consequence, remote adversaries can use BGP communities to trigger remote blackholing, steer traffic, and manipulate routes even without prefix hijacking. We highlight examples of these attacks via scenarios that we tested and measured both in the lab as well as in the wild. While we suggest what can be done to mitigate such ill effects, it is up to the Internet operations community whether to take up the suggestions.

        RFC 8481

        Title:      Clarifications to BGP Origin Validation Based
                    on Resource Public Key Infrastructure (RPKI) 
        Author:     R. Bush
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2018
        Mailbox:    randy@psg.com
        Pages:      5
        Characters: 9629
        Updates:    RFC 6811
        I-D Tag:    draft-ietf-sidrops-ov-clarify-05.txt
        URL:        https://www.rfc-editor.org/info/rfc8481
        DOI:        10.17487/RFC8481

Deployment of BGP origin validation based on Resource Public Key
Infrastructure (RPKI) is hampered by, among other things, vendor
misimplementations in two critical areas: which routes are validated
and whether policy is applied when not specified by configuration.
This document is meant to clarify possible misunderstandings causing
those misimplementations; it thus updates RFC 6811 by clarifying that
all prefixes should have their validation state set and that policy
must not be applied without operator configuration.

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; SIGCOMM August 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.

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; Applied Networking Research Workshop; Montréal 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.

Tobias Fiebig, Franziska Lichtblau, Florian Streibelt, Thorben
Kru?ger, Pieter Lexis, Randy Bush and Anja Feldmann Learning from the Past: Designing Secure Network Protocols; in Cybersecurity Best Practices:
Lo?sungen zur Erho?hung der Cyberresilienz fu?r Unternehmen und Beho?rden

Network protocols define how networked computer systems exchange data. As they define all aspects of this communication, the way they are designed is also security sensitive. If communication is supposed to be encrypted, this has to be outlined in the protocol’s specification. If services implementing the protocol should allow for authen- tication, this has to be defined in the protocol. Hence, the way a protocol is designed is elemental for the security of systems later implementing it. Security by design starts with the protocol definition. Especially in today’s fast-moving environment, with cloud services and the Internet of Things, engineers constantly have to develop new proto- cols. In this chapter, we derive guidelines for designing new protocols securely, as well as recommendations on how existing protocols can be adjusted to become more secure. We base these recommendations on our analysis of how – historical – protocols were designed and which underlying design decisions made their corresponding implemen- tations susceptible to security issues.

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.

George Michaelson, Matthew Roughan, Jonathan Tuke, Matt P. Wand, and Randy Bush; Rasch analysis of HTTPS reachability; IFIP Networking 2018 Zurich, Switzerland, May 14-16, 2018

The use of HTTPS as the only means to connect to web servers is increasing. It is being pushed from both sides: from the bottom up by client distributions and plugins, and from the top down by organisations such as Google. However, there are potential technical hurdles that might lock some clients out of the modern web. This paper seeks to measure and precisely quantify those hurdles in the wild. More than three million measurements provide statistically significant evidence of degradation. We show this through statistical techniques, in particular Rasch analysis, which also shows that various factors influence the problem ranging from the client’s browser, to their locale.

        RFC 8210

        Title:      The Resource Public Key Infrastructure 
                    (RPKI) to Router Protocol, Version 1 
        Author:     R. Bush, 
                    R. Austein
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2017
        Mailbox:    randy@psg.com, 
                    sra@hactrn.net
        Pages:      35
        Characters: 78467
        Updates:    RFC 6810

        I-D Tag:    draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.txt

        URL:        https://www.rfc-editor.org/info/rfc8210

        DOI:        10.17487/RFC8210

In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache.  This document describes a protocol to deliver them.