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:
|Route filtering based on IRR data||66.22%||49||33.78%||25||0.00%||0||74|
|Route filtering based on RPKI (Route Origin Validation)||67.11%||51||28.95%||22||3.95%||3||76|
|Anti-spoofing (implementation of BCP38)||85.53%||65||9.21%||7||5.26%||4||76|
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:
|It is difficult to maintain up to date route objects||66.67%|
|There are several IRR database and many of them filled with incorrect data making accuracy impossible||66.67%|
|The process to maintain/create route objects is somewhat complicated||33.33%|
|Not everyone can maintain/create route object in the organization due to access issue||0.00%|
|Lack of automation provided by RIRs to help the process||33.33%|
|It is difficult to maintain up to date ROA||13.33%|
|The process to maintain/create ROA is somewhat complicated||33.33%|
|Creating an invalid ROA has very significant consequences (outage) therefore we avoid frequent updates||26.67%|
|Not everyone can maintain/create ROA in the organization due to access control issues||20.00%|
|Lack of automation provided by RIRs to help the process||6.67%|
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:
|What is the main reason for not implementing ‘Route filtering based on IRR data’?|
|The protection that it offers is not worth the costs to implement||36.36%||8|
|The associated risks are too low to justify the costs||9.09%||2|
|The risks associated with it are not fully understood||36.36%||8|
|Other (please specify)||18.18%||4|
|What is the main reason for not implementing ‘Route filtering based on RPKI (Route Origin Validation)’?|
|The protection that it offers is not worth the costs to implement||25.00%||5|
|The associated risks are too low to justify the costs||5.00%||1|
|The risks associated with it are not fully understood||20.00%||4|
|Other (please specify)||50.00%||10|
|What is the main reason for not implementing ‘Anti-spoofing (implementation of BCP38)’?|
|The protection that it offers is not worth the costs to implement||40.00%||2|
|The associated risks are too low to justify the costs||0.00%||0|
|The risks associated with it are not fully understood||40.00%||2|
|Other (please specify)||20.00%||1|
|What is the main reason for not implementing ‘Peer-locking’?|
|The protection that it offers is not worth the costs to implement||13.33%||4|
|The associated risks are too low to justify the costs||0.00%||0|
|The risks associated with it are not fully understood||53.33%||16|
|Other (please specify)||33.33%||10|
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 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.
|Have you reviewed/tested any beta implementation of BGPsec?|
|No, there is no beta implementation available from any vendor||6.38%||3|
|No, I’m not aware of any beta implementation||40.43%||19|
|No, because it’s not in our roadmap to deploy in near future||36.17%||17|
|No, Other (please specify)||2.13%||1|
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.
|Have you asked your preferred vendor about their roadmap to ship workable code to implement BGPsec?|
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.
|Would you need to replace existing routers and network equipment to support BGPsec?|
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.
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.