Randy's Work Blog

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.

Romain Fontugne, Emile Aben, Cristel Pelsser, Randy
Bush; Pinpointing Delay and Forwarding Anomalies Using Large-Scale Traceroute Measurements; IMC 2017

Understanding data plane health is essential to improving Internet reliability and usability. For instance, detecting disruptions in distant networks can identify repairable connectivity problems. Currently this task is difficult and time consuming as operators have poor visibility beyond their network’s border. In this paper we leverage the diversity of RIPE Atlas traceroute measurements to solve the classic problem of monitoring in-network delays and get credible delay change estimations to monitor network conditions in the wild. We demonstrate a set of complementary methods to detect network disruptions and report them in near real time. The first method detects delay changes for intermediate links in traceroutes. Second, a packet forwarding model predicts traffic paths and identifies faulty routers and links in cases of packet loss. In addition, we define an alarm score that aggregates changes into a single value per AS in order to easily monitor its sanity, reducing the effect of uninteresting alarms. Using only existing public data we monitor hundreds of thousands of link delays while adding no burden to the network. We present three cases demonstrating that the proposed methods detects real disruptions and provides valuable insights, as well as surprising findings on the location and impact of the identified events.

        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.

        BCP 211        
        RFC 8207

        Title:      BGPsec Operational Considerations 
        Author:     R. Bush
        Status:     Best Current Practice
        Stream:     IETF
        Date:       September 2017
        Mailbox:    randy@psg.com
        Pages:      10
        Characters: 21086
        See Also:   BCP 211

        I-D Tag:    draft-ietf-sidr-bgpsec-ops-16.txt

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

        DOI:        10.17487/RFC8207

Deployment of the BGPsec architecture and protocols has many
operational considerations.  This document attempts to collect and
present the most critical and universal.  Operational practices are
expected to evolve as BGPsec is formalized and initially deployed.