The US FCC Asked About Routing Security. Here’s what MANRS Participants Had to Say.

This week, the Internet Society submitted comments in response to a United States Federal Communications Commission (FCC) Notice of Inquiry (NOI) on routing security. It asked about how data is routed around the Internet, what kinds of security controls, standards, and efforts exist to protect those routes, and what the US government might be able to do to decrease BGP incidents and increase routing security. For an overview of our full comments, you can read Dr. Joseph Lorenzo Hall’s post “Routing Security Goes to Washington”, and the full filing (PDF).

That post nicely summarizes our comments:

“Ultimately, we recommended against any hard mandates in this area given the early state of the technology and discipline of secure routing. We recommended that any action by the FCC focus on:

• Incentives to deploy routing security measures
• Encouraging procurement requirements that give preference to support for routing security
• A staged approach to any harder requirements in routing security, beginning with critical infrastructure sectors”

A few weeks ago, we surveyed MANRS participants in relation to this inquiry. Our survey aimed to better understand the use of various routing security measures, how effective they are perceived to be by MANRS participants, and what kinds of obstacles prevent participants from putting them in place.

We received 84 responses with an 88% completion rate—10.3% of current MANRS participants. We note that the survey is biased in that we polled a community of security-conscious MANRS participants, so the results should be seen as indicative of routing security proponents who are predisposed to answering online surveys, and in no way representative of the larger routing ecosystem. Still, the results are interesting, and we’d like to discuss them a little more here.

Routing Security Measures in Use

First, we asked what routing security measures participants employ:

Anti-spoofing protections are the most common with both IRR-based and RPKI-based filtering being almost equally popular and peer-locking being the least implemented of routing security measures. Many respondents were unfamiliar with peer-locking and therefore unsure if they implement it.

An average of about 96% of network resources are covered by IRR based route objects, and about 81% are covered by RPKI Route Origin Authorizations (ROAs). For respondents with lower numbers, we asked why:

While most implement IRR and/or RPKI, many find it difficult or complicated to maintain their data. Several participants said IRR data is unreliable for filtering. For RPKI, several participants listed ‘other’ reasons including lack of vendor support, lack of experience, and legal barriers from RIRs.

Barriers to Implementation

Next, we asked about perceived barriers to implementing and deploying routing security measures:

Again, we should note that we are asking a community of routing security afficionados about barriers to routing security measures that many have already implemented, so the number of respondents answering these questions that focus on non-implementation is low. We see some evidence of risks being poorly understood, and some concerns with associated costs. Many survey respondents were unfamiliar with peer-locking and therefore did not know the risks or costs that might be involved with deploying it. (A good place to start is this presentation slide deck from Job Snjiders from NANOG 67, “Practical everyday BGP filtering with AS_Path filters: Peer locking”). 

BGPsec

BGPsec has not seen wide adoption and deployment for a variety of reasons, the most important being that BGPsec does not protect against route leaks. It is susceptible to a downgrade attack—if one network on the path does not implement BGPsec the whole path cannot be protected and any party deploying it will suffer a performance hit. In our survey, over 60% of respondents were somewhat, very, or extremely familiar with BGPsec. We then asked three follow-up questions related to implementation.

A significant number of respondents don’t have test (beta) implementations of BGPsec in the routing operating systems they use, and a similar number simply don’t have plans to examine BGPsec further in the future. 

We see general disinterest from respondents in that 76% said they haven’t even asked their vendor about BGPsec. It seems this is not something that these respondents are demanding from the market.

Here we see a relatively even split in terms of need to update equipment to handle BGPsec. Clearly many would have to have more substantially performant routing equipment to support BGPsec. And for the respondents that don’t need to make investments in new equipment, it still appears that there is little interest in or demand for BGPsec.

What’s Next?

In such a large and complex interdependent system as the Internet, there are no low-hanging fruit or singular approaches that can easily or comprehensively secure Internet routing. However, as routing security evolves and more participants join MANRS, we’re seeing fewer routing security incidents and more care taken to implement things like RPKI. Routing security requires individual network operators to implement and adhere to routing security practices with collective responsibility for the resilience and security of Internet infrastructure in mind.

We highly recommend reading the Internet Society’s NOI comment (PDF) including the appendix (pages 32-63) with the full survey results. And, of course, if you haven’t already, please join the MANRS community to be part of the solution.