Randy's Work Blog

Josh Bailey, Dean Pemberton, Andy Linton, Cristel Pelsser, Randy Bush. Enforcing RPKI-Based Routing Policy on the Data Plane at an Internet Exchange Poster at HotSDN 2014.

Over a decade of work has gone into securing the BGP routing control plane. Through all this, there has been an oft repeated refrain, ”It is acknowledged that rigorous control plane verification does not in any way guarantee that packets follow the control plane.” We describe what may be the first deployment of data plane enforcement of RPKI-based control plane validation. OpenFlow switches providing an exchange fabric and controlled by a Quagga BGP route server drop traffic for prefixes which have invalid origins without requiring any RPKI support by connected BGP peers.

RFC 7353

Title: Security Requirements for BGP Path
Validation
Author: S. Bellovin, R. Bush, D. Ward
Status: Informational
Stream: IETF
Date: August 2014
Mailbox: bellovin@acm.org,
randy@psg.com,
dward@cisco.com
Pages: 9
Characters: 18148
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-bgpsec-reqs-12.txt

URL: https://www.rfc-editor.org/rfc/rfc7353.txt

This document describes requirements for a BGP security protocol
design to provide cryptographic assurance that the origin Autonomous
System (AS) has the right to announce the prefix and to provide
assurance of the AS Path of the announcement.

RFC 7196
Title: Making Route Flap Damping Usable
Author: C. Pelsser, R. Bush,
K. Patel, P. Mohapatra,
O. Maennel
Status: Standards Track
Stream: IETF
Date: May 2014
Mailbox: cristel@iij.ad.jp,
randy@psg.com,
keyupate@cisco.com,
mpradosh@yahoo.com,
o@maennel.net
Pages: 8
Characters: 15202
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-idr-rfd-usable-04.txt
URL: http://www.rfc-editor.org/rfc/rfc7196.txt

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes’ normal convergence process.

Nejc Skoberne, Olaf Maennel, Iain Phillips, Randy Bush, Jan Zorz, and Mojca Ciglaric, IPv4 Address Sharing Mechanism Classification and Tradeoff Analysis, IEEE/ACM Transactions On Networking April 2014.

The growth of the Internet has made IPv4 addresses a scarce resource. Due to slow IPv6 deployment, IANA-level IPv4 address exhaustion was reached before the world could transition to an IPv6-only Internet. The continuing need for IPv4 reachability will only be supported by IPv4 address sharing. This paper reviews ISP-level address sharing mechanisms, which allow Internet service providers to connect multiple customers who share a single IPv4 address. Some mechanisms come with severe and un- predicted consequences, and all of them come with tradeoffs. We propose a novel classification, which we apply to existing mechanisms such as NAT444 and DS-Lite and proposals such as 4rd, MAP, etc. Our tradeoff analysis reveals insights into many problems including: abuse attribution, performance degradation, ad- dress and port usage efficiency, direct inter-customer communication, and availability.

RFC 7128

Title: Resource Public Key Infrastructure (RPKI) Router Implementation Report
Author: R. Bush, R. Austein,
K. Patel, H. Gredler,
M. Waehlisch
Status: Informational
Stream: IETF
Date: February 2014
Mailbox: randy@psg.com,
sra@hactrn.net,
keyupate@cisco.com,
hannes@juniper.net,
waehlisch@ieee.org
Pages: 11
Characters: 19348
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-rpki-rtr-impl-05.txt

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

This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the “YES” answer if the feature had at least been tested in the lab.

Title: Origin Validation Operation Based on
the Resource Public Key Infrastructure (RPKI)
Author: R. Bush
Status: Best Current Practice
Stream: IETF
Date: January 2014
Mailbox: randy@psg.com
Pages: 11
Characters: 26033
See Also: BCP 185

I-D Tag: draft-ietf-sidr-origin-ops-23.txt

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

Deployment of BGP origin validation that is based on the Resource
Public Key Infrastructure (RPKI) has many operational considerations.
This document attempts to collect and present those that are most
critical. It is expected to evolve as RPKI-based origin validation
continues to be deployed and the dynamics are better understood.

The first problem was a pre-release kernel. I used LuCI, the web interface, to flash openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin, and needed to be patient with 15 minutes of twirly. The flash lost my ssl package, so I also had to

opkg install uhttpd-mod-tls

Thanks for Chris Adams for all clue, and John Brzozowski for diagnostics and support, I loaded the necessary packages

opkg install ip6tables radvd wide-dhcpv6-client ip

Then I hacked /etc/config/dhcp6c

config 'dhcp6c' 'basic'
        option 'enabled' '1'                            # 1 = enabled; 0 = disabled
        option 'interface' 'wan'                        # This is the interface the DHCPv6 client will run on
        option 'dns' 'dnsmasq'                          # Which DNS server you run (only dnsmasq currently supported)
        option 'debug' '0'                              # 1 = enable debugging; 0 = disable debugging

        # Send options (1 = send; 0 = do not send)
        option 'pd' '1'                                 # Prefix Delegation
        option 'na' '1'                                 # Non-Temporary Address
        option 'rapid_commit' '1'                       # Rapid Commit

        # Request options (1 = request; 0 = do not request)
        option 'domain_name_servers' '1'
        option 'domain_name' '0'
        option 'ntp_servers' '0'
        option 'sip_server_address' '0'
        option 'sip_server_domain_name' '0'
        option 'nis_server_address' '0'
        option 'nis_domain_name' '0'
        option 'nisp_server_address' '0'
        option 'nisp_domain_name' '0'
        option 'bcmcs_server_address' '0'
        option 'bcmcs_server_domain_name' '0'

        # Override the used DUID, by default it is derived from the interface MAC
        # The given value must be uppercase and globally unique!
        #option 'duid' '00:03:00:06:D8:5D:4C:A5:03:F2'

        # Script to run when a reply is received
        option 'script' '/usr/bin/dhcp6c-state'

# Define one or more interfaces on which prefixes should be assigned
config 'interface' 'loopback'
        option 'enabled' '0'                            # 1 = enabled; 0 = disabled
        option 'sla_id' '1'                             # Site level aggregator identifier specified in decimal (subnet)
        option 'sla_len' '0'                            # Site level aggregator length (64 - size of prefix being delegated)
                                                        # e.g. /60 from ISP -> 64 - 60 = 4
config 'interface' 'lan'
        option 'enabled' '1'
        option 'sla_id' '1'
        option 'sla_len' '0'

Then /etc/init.d/dhcp6c start and see what you get. You should have an RA-assigned IP on your wan interface and a PD-assigned /64 on the LAN. If you configure radvd (just set it with no prefix listed), dhcp6c will automatically re-configure it to give out addresses from the /64.

Now get Router Advertisement working, hack /etc/config/radvd to

config interface
        option interface        lan
        option AdvSendAdvert    1
        option AdvManagedFlag   0
        option AdvOtherConfigFlag 0
        option ignore           0

config prefix
        option interface        lan
        # If not specified, a non-link-local prefix of the interface is used
        list prefix             ''
        option AdvOnLink        1
        option AdvAutonomous    1
        option AdvRouterAddr    0
        option ignore           0

config rdnss
        option interface        lan
        # If not specified, the link-local address of the interface is used
        list addr               ''
        option ignore           0

config dnssl
        option interface        lan
        list suffix             rg.net
        option ignore           0

Then
/etc/init.d/radvd start
/etc/init.d/dhcp6c start

At this point, we had the /128 on our WAN interface, and the /64 on the LAN interface. But, from the OpenWRT, we could not ping an external IPv6 address. Hours were spent chasing various ghosts, when we found the fix,

sysctl -w net.ipv6.conf.eth1.accept_ra=2

From a hint in New Zealand, accept_ra=1 means “only accept RAs if forwarding is disabled”. Turns out to be documented in the 3.12.4 kernel source clue pages. Once you have forwarding enabled, you have to have accept_ra=2 to override that.

:~# ping6 psg.com
PING psg.com (2001:418:1::62): 56 data bytes
64 bytes from 2001:418:1::62: seq=2 ttl=52 time=70.286 ms
64 bytes from 2001:418:1::62: seq=3 ttl=52 time=70.090 ms
64 bytes from 2001:418:1::62: seq=4 ttl=52 time=71.169 ms
64 bytes from 2001:418:1::62: seq=5 ttl=52 time=77.020 ms


Simon Knight presented our paper, An Automated System for Emulated Network Experimentation, at CoNEXT 2013 in Santa Barbara.

Emulated networks and systems, where router and server software are run in virtual environments, allow network op- erators and researchers to perform experiments at large scale more economically than in testbeds. Running real code pro- vides a greater level of realism than simulation.

However, large scale comes with a problem: running real software means each test needs at least as much configura- tion as a real network. To recognise the true value of emula- tion at scale, we need to reduce the complexity of building, configuring, deploying, and measuring emulated networks.

We present a system to facilitate emulation by provid- ing translation from a high-level network design into a con- crete set of configurations that are automatically deployed into one of several emulation platforms. Our system can be used to construct multi-domain networks in minutes, and is scalable to networks with over a thousand devices. It is modular, allowing support for different protocols, topology designs, and target platforms: Quagga, JunOS, IOS, etc. Users, from both the research community and industry, have already demonstrated its value in research and education.

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.

RFC 6811

Title: BGP Prefix Origin Validation
Author: P. Mohapatra, J. Scudder,
D. Ward, R. Bush,
R. Austein
Status: Standards Track
Stream: IETF
Date: January 2013
Mailbox: pmohapat@cisco.com,
jgs@juniper.net,
dward@cisco.com,
randy@psg.com,
sra@hactrn.net
Pages: 10
Characters: 20082
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-pfx-validate-10.txt

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

To help reduce well-known threats against BGP including prefix mis-
announcing and monkey-in-the-middle attacks, one of the security
requirements is the ability to validate the origination Autonomous
System (AS) of BGP routes. More specifically, one needs to validate
that the AS number claiming to originate an address prefix (as
derived from the AS_PATH attribute of the BGP route) is in fact
authorized by the prefix holder to do so. This document describes a
simple validation mechanism to partially satisfy this requirement.
[STANDARDS-TRACK]