Blog
Routing Security Survey Report: Findings V
External factors for deployment
This post, focused on the external factors that condition the deployment of routing security measures, is the fifth —and last— release of results from GCA’s global survey of network operators, carried out in 2021.
So far, we have covered a large range of topics— from the results of the survey’s demographics questions (post #1) and the operators’ perceptions of the scale and scope of threats to the Internet’s routing system (post #2) to more operational issues, such as our respondents’ actual efforts in routing security (post #3) or their use of IRRs and RPKI in the context of routing security (post #4).
Remember that, if you have specific questions the data analysis might answer, we will be happy to consider them for the analytical post(s) that we are preparing ahead of the publication of our final report. To submit your questions or comments, please simply use our social media posts on LinkedIn and Twitter, under the #RoutingSecurity hashtag.
Let’s now move to our latest release of data from the survey.
What were or would be the short-term incentives for you to deploy RPKI?
Respondents were asked to select as many of the following network realities as applicable to their motivation to deploy RPKI:
- My organization is wary of prefix hijacking and its consequences
- My customers want their network to be protected from routing hijack/misconfiguration
- My upstream provider(s) have deployed RPKI
- My peers have deployed RPKI and are signing their announcements
- I want to get my resources certified as a proof of ‘holdership’
- I can provide RPKI as value-added services to my customers
- Current routing security measures are not enough
- None of the above
Note that the first option, ‘None of the above,’ was not available in the earliest revisions of the survey. Ten of the respondents did not have that option available for choosing.
What do you think would be the most effective long-term incentives for RPKI adoption?
Respondents were asked to select one of the following as a speculation on the most effective long-term incentives for RPKI adoption:
- Routers prefer to choose secure routes as opposed to non-secure routes
- Operators develop a new business model based on routing security
- Government impose the adoption of routing security mechanisms on network operators
- IPv4 is getting depleted, RPKI might help to prevent unauthorized address-space trading
- Other (please specify)
Responses under ‘Other’ included:
- Customers becoming increasing aware of risks, and insisting on robust practises in purchasing decisions
- Industry pressure, i.e., only peering with networks that have fully adopted RPKI, etc.
- Cleanup of legacy issues, making the certification process straightforward
Note that options two and three of this question (‘Operators develop a new business model based on routing security’ and ‘Government impose the adoption of routing security mechanisms on network operators’) were inadvertently merged in our final data dump. This is why both questions, referring to market and governmental pressures, appear together on the graph, with a total score of 20%.
What are the barriers for RPKI adoption?
Having asked about motivations (experienced or proposed) to deploy RPKI to support routing security, we next asked respondents to identify the things they perceived as barriers to adoption.
We asked respondents to select as many of the following as they felt were applicable:
- Technology is not mature enough
- Lack of training and awareness
- Managing a certificate authority is not the core business of an operator
- No immediate return on investment/financial benefit
- High initial setup cost (infrastructure and human resources)
- RPKI can have major performance impact on BGP operations
- In case of key compromise, the whole routing system can be disrupted
- No trust in ICANN/IANA as RPKI root (trust anchor)
- Possibility of using RPKI as the censorship tool by governments
- In the future, traffic flowing through secure routes might cost more than traffic through non-secure routes
- Current routing security measures are sufficient
The answers are as interesting in demonstrating what is not a concern, as well as things that rank highly as barriers.
Do you implement approaches to prevent packets with incorrect source IP address from entering and/or leaving the network?
A topic that is adjacent to pure routing security is dealing with IP address spoofing in packets sent to or through a network. Respondents were offered ‘Yes/No/I don’t know.’
If you are not implementing any origin validation (OV)/anti-spoofing technology, what are the primary reasons for it?
The intention was to offer this question only to respondents who had not answered ‘Yes’ in the previous one. Unfortunately, earlier versions of the survey had logic bugs in the flow, so some of the ‘Yes’ respondents provided answers. The graph below covers only the seven responses that were not ‘Yes’ in the version of the survey with the correct logic flow:
- Lack of training or awareness
- Technically challenging
- Consumes too many resources, causes service degradation
- No immediate return on investment or financial benefit
- Other (please specify)
The one ‘Other’ response was: ‘Technically, not an easy option of IXPs.’
If yes, can you briefly state the technologies/processes you leverage and their associated costs?
For those respondents that reported they do implement measures to address source IP address spoofing, we provided a free form question response to collect their input.
Answers included:
- BCP38, basically ‘rpf-check mode loose’ on Juniper on every customer-facing (including our own services) interfaces
- Rely on my upstream for now— until Mikrotik properly supports RPKI
- We use the route map and prefix list to prevent the incorrect prefix
- Running spoofer probes + alerting; unsure on cost / time / effort to implement (NetEng owned that [project])
- Filter bogons
- uRPF is free!
- Routers with RPKI support, and Cloudflare’s ROA authentication— cost was under $1000 in time/energy
- RPF check configured on all customer interfaces prevents spoofing from within our network; currently nothing is done to avoid spoofed traffic from entering network
- Reverse path validation
- Mostly ACL on the edge and uRPF on the access towards customer connections
- uRPF on all customer connections as well as prefix filters on what routes they can announce toward us
- We deploy in-bound filters on every CPE of the customers implementing BCP38, and ACL on the edge routers; the cost was a few lines on the configurations template
- We use prefix and source-based access lists on upstream providers and route-based source validation on customers
- Router configuration, virtually no cost
- RFC1918 and BCP38
- uRPF
- Manual ACLs
- Using RPF check on every customer-facing interconnections
- BGP filtering and ACLs at our customers interfaces (almost no cost), and ACLs at upstream border (requires better [equipment])
- ACL
- BCP84, RFC8704
- RPF or firewall filters to restrict source address as appropriate on all member connections; BGP prefix lists on all member BGP sessions; $0 additional— it’s [a] standard procedure
- Strict mode uRPF for single-homed customers, where feasible loose mode uRPF + bogon; null routes everywhere
- Cable source verify on CMTSs, ACLs
- IRR: we use that of TC (free); RPKI + Routinator: we use open source software, together with our Juniper router [this answer has been translated into English]
- We have had BCP38 filters at the edge [of] our enterprise network since at least 2002; we have internal uRPF checks at select points (with a plan to expand the number of places we’re doing uRPF checking); we run the CAIDA spoofer tool
- We use uRPF in our BNG boxes; packet filters on the edge, blocking any source IP that is not ours; blocking bogons; we have BGP sessions with [Team] Cymru to block bogons and we constantly check our network with CAIDA spoofer software
- Access control lists
- When possible, uRPF; else, ACLs
- uRPF and DOCSIS source-address validation
- We have DDoS technology with our ISP, additionally work on anti-spoofing issues
- We have our own system deployed into all of our cloud regions that holds many millions of compute instances; this system makes sure we can only originate with our actual real source-[addresses]; the cost to have this built was, not surprisingly, astronomical, but totally worth it
- Open source
Do you implement any approaches not discussed above (i.e., non-RPKI, non-IRR-based) for validating more than the route origin (e.g., path validation, route filtering)?
The final question of the survey was geared towards understanding if we had covered everything we should. The ‘Other’ answers offered were:
- Prefix and ASN filtering of customers on ingress
- For our peering links, we have prefix limits set, though, at this point, we simply log when a prefix limit is violated; we’re considering instituting a policy to tear down the BGP session is a peer advertises more prefixes than expected
This concludes the review of the direct questions and answers from the survey. We still have more ground to cover by drilling down on the results— stay tuned for upcoming insights and further review of the data.
The author, Leslie Daigle, is the Chief Technical Officer and the Director of the Internet Integrity Program at the Global Cyber Alliance. You can follow her on Twitter or connect with her on LinkedIn.
