Blog
Routing Security Survey Report: Findings III
Routing Security and Operational Reality
This post, on the operational reality of routing security, is the third post in a series dedicated to sharing the results from a survey of network operators carried out by GCA in 2021. Our aim with the survey was to understand the state of concern and preparedness for security issues in routing. In this post, and with other posts in the series, we are sharing our compiled results and findings.
In our first post, we provided the background of the survey mechanics and shared the results of the demographics questions in the survey. Briefly, we had 51 responses considered valid, and they represented both technical and business decision-makers at networks across the globe. Our second post focused on the questions related to the operators’ perceptions of the scale and scope of threats to the Internet’s routing system.
Today, we are focusing on the questions related to the operators’ current efforts in routing security, shaped by their operational reality.
Remember that, if you have specific questions the data analysis might answer, we will be happy to consider them for future posts (please use our social media posts on LinkedIn and Twitter to share your thoughts, under the #RoutingSecurity hashtag). Finally, the collection of posts will be collated, polished, and published as a complete and referenceable report from the survey project.
Let’s go through our third release of questions and answers.
What are your current efforts in routing security?
Respondents were asked to select as many of these as were applicable:
- Session security (TCP MD5, IPSec, BGP TTL Security Hack, etc.)
- Defensive filtering of suspicious BGP announcements
- Use of Internet Routing Registries (IRR)
- Resource Public Key Infrastructure (RPKI)
- Other (please specify)
The ‘Other’ answers were:
- In-band, on-premise DDOS detection and mitigation system
- SDN-based enforced filtering and security policy
- RPF or traffic filtering on all incoming traffic except our IX connection
- Community and other attribute scrubbing, extensive policy unit testing
- Filtering of spoofed traffic
- IP anti-spoofing (e.g., ACLs, uRPF)
What are the internal resources you are using for addressing routing security at this time?
This was an open-ended question. Answers captured included:
- Fully redundant setup of validators (Routinator + OctoRPKI/GoRTR)
- Internal security teams
- Security best-practice reviews of network device configs, route policy reviews and updates, network monitoring, Netscout [Sightline] (routing analytics)
- Appropriate route filtering
- Just routing policy (prefix list, route map…)
- Filtering automation, anti-spoofing, and alerting
- No extra resources
- Automated configuration management
- Shared infrastructure to absorb attacks
- RPKI and prefix filters
- Tools to build prefix list for routers based on IRR data
- RPKI
- Mostly extensive documentation of procedures and configurations, well-known best practices
- Process for turn up and management of customers
- Open-source RPKI infrastructure, open-source automation, telemetry data-lake, BGP historic logs
- Internally developed SDN platform for external routing
- One network administrator
- Training team
- RIPE RPKI validator
- RPKI and IRR
- RPF-check on customer facing interconnections, proper route-objects in ARIN IRR and RADb IRR, ROAs covering all our prefixes and doing ROV with Routinator & OctoRPKI/GoRTR, BGP hijacks monitoring with BGPAlerter
- Human
- [Careful] router configuration and attention to filter/ACLs
- Properly follow[ing] the BCP38 [and] BCP194 [best practices] for route filtering
- Training, automated configuration backups and monitoring, extensive use of BGP communities for filtering and traffic engineering
- Prefix-ownership validation checks using PeeringDB, IRR records, Letter of Authority, RPKI validator
- Years of routing experience
- Standards for secure routing configurations on routers, auditing of router configs, detection/mitigation of DDoS attacks using Arbor, ACLs to prevent open vulnerable UDP services on our network from being amplified, detection of BGP hijacks using Artemis, generation and monitoring of RPKI ROAs using homegrown scripts
- Junos operating system and some tools to maintain prefix lists as-path and manual operation
- [RPKI], IRR, Routinator, UTRS, [Team Cymru]; we try to follow all the recommendations in MANRS, as many as we possibly can [this answer has been translated into English]
- Internally developed tools
- I am not aware of any internal resources we use for routing security except [that] we do use firewalls internally for AS5459
- We have one of our routers exporting BMP data to OpenBMP (SNAS) (which is unfortunately no longer maintained). I can’t say we use it to for routing security specifically, but it does [provide] useful and interesting information
- Filters in BGP to not allow ads of prefixes that are not ours
- Route filtering, ACL
- Security experts and operational teams
- For RPKI validation, we use the RIPE Validator (soon moving to another, such as RPKI-client) and [NLnet Labs] Routinator. We use the Artemis package for detection of route hijacks along with some homegrown scripts
- Filtering bogons, application of entry and exit policies
- [Too] wide topic to cover in a survey. We have about 35 people involved in various teams that [spend] more [than] 50% of their time with routing security related topics
- Filtering based on IRR and custom configs
What are the external resources you are using for addressing routing security at this time?
This was an open-ended question. Responses offered included:
- [Team] Cymru’s Bogon Route Server Project
- Blogs, RIRs
- MANRS, CiscoWorks (Network Insights), BGPMon, Route Views
- Both transit and IXPs have implemented RPKI
- Measurement props [sic], CAIDA, RIPE
- MANRS, ROA, and RPKI
- MANRS compliant, published peering policy
- Various external monitoring and RIPE PRKI alerts
- RPKI
- ISP intervention
- RPKI and prefix filters
- PeeringDB, NLNOG best practices
- RPKI Servers
- RIPE, various public Looking Glass and upstream IP transit providers’ tools
- MANRS
- External scrubbing centers for major DDoS volumetric attacks, external vendor for DDoS on-premise mitigation solution
- PeeringDB, IRR, and RPKI
- rpki.readthedocs.io
- Industry experts
- RPKI, IRR
- BGPMon
- IETF drafts
- [Team] Cymru’s bogon lists, RPKI published on our national registrar
- ROA and ROV
- MANRS
- Routing registries, RPKI, customer-facing filtering by IP and ASN
- [PeeringDB], IRR
- MANRS, ARIN, CANARIE [Routing] Registry, RADB, [PeeringDB]
- IRR data, RPKI data, RIR allocations data, PDB, various community mail lists
- ARIN’s hosted CA/publication server for RPKI ROAs, RIPE’s RIPEstat API and RIS, BGPStream Live monitoring service
- [Team Cymru’s] BGP feed
- Still looking for [this answer has been translated into English]
- IRR data, open-source tools (i.e. RPKI validators [such as] Routinator, BGPQ…)
- We use BGPQ3 to retrieve IIRDB data for AS-SETs. We also use Routinator 3000 to retrieve RPKI ROAs from RIR validators
- We subscribe[d] [to] the free tier of what used to be BMPMon (now owned by Cisco). We have an instance of BGP Alerter running. QRator as well
- RPKI and IRR
- We recently have implemented MANRS compliance
- MANRS initiative, IETF, open-source projects, vendors
- We are working on the implementation of RPKI
- Partnerships with experienced organizations to build capacity
What is the estimated cost associated with your routing security efforts?
Respondents were asked to select a cost range for their routing security efforts:
- Less than $1,000 USD
- $1,000 USD to $9,999 USD
- $10,000 USD to $50,000 USD
- Other (please specify)
And, the answers provided under ‘Other’ were:
- ~$100K
- Far more than $50K, in just employee costs
- Although we do have some [commercial] tools for NetFlow and the like, most of our routing-security efforts are procedural rather than associated with equipment or products
- 500,000
- Not easy to put a value at it. Initial development and integration had, of course, a cost, but operational day-to-day costs are low
- I am not sure what the cost of this is
- More than $50K USD
- Difficult to quantify. Most SW is freely available open source. Server VMs have minimal cost. Most of the cost relates to routing security being part of the job of several people
- If we count in ‘hiring smart people,’ [it’s] millions of dollars
Are you familiar with the Mutually Agreed Norms in Routing Security (MANRS) initiative?
The question provided the following options:
- Yes
- No
And…
- If yes, do you have thoughts about its utility or the things it ought to do (e.g., measurement, compliance, other norms)?
The responses here demonstrated a very strong reach of awareness of MANRS, across geographies and network types. The answers shared for the free form follow-up were:
- Seems to be doing just fine at present
- Seems like a good thing, but little true testing or enforcement. Needs public shaming lists
- I would like to become a fellow and bring back the experience to my CTO/CIO to get us to join
- We are a MANRS member and appreciated the guidance for getting our ducks-in-a-row for our internal configurations
- Generally agree with the initiative
- Already part of it. They do a great job on measurement and compliance
- Not really
- It’s one of the good things the community came up with
- Great initiative
- My organization is already [signed] with MANRS
- My only thought is to work towards wider adoption
- Yes
- It should encourage customers of ISPs, Internet Exchanges, cloud, and hosting companies to make sure that the vendor that they choose is MANRS-compliant
- Compliance
- Yes, but we started not long ago; now reading and studying the norms [this answer has been translated into English]
- Excellent initiative, setting commonly-accepted [minimum] measures, and measurements [thereof]
- I believe this should be sold more to online providers for compliance
- DSPA
- Very pleased with the momentum this effort is creating in the industry
- We are already part of MANRS
- We recently have implemented MANRS compliance
- Useful as a reference to describe expectations of the routing community. Also helpful in education and outreach efforts
- We are working to adhere to the MANRS recommendations
- Compliance
Next time… we will go through the questions and responses related to ‘IRRs and RPKI.’
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.
