Mutually Agreed Upon Norms for Routing Security (MANRS)
- Mutually Agreed Norms for Routing Security (MANRS)
- Internet2 Liaison(s):
- Adair Thaxton
- Group Type:
Mutually Agreed Norms for Routing Security (MANRS) is a global initiative, supported by the Internet Society, that provides crucial fixes to reduce the most common routing threats.
The Internet2 community is increasing participation in MANRS because routing security is a growing area of concern for network operators around the globe.
Whether from accidental misconfiguration or malicious hijack, the results are often more than just inconvenient. As academic and business critical functions are hosted or off-prem, the internet is no longer a nice to have, but a key component of an organization's IT infrastructure. How long can your organization handle not being able to reach email, a learning management system, your ERP system?
Colleges and universities have a long history of being connected to the internet, and there was a time when connecting to the internet was nearly "set it, and forget it".
But, today, this shared and critical infrastructure needs our attention. Routing Security is vital to the future and stability of the Internet.
The internet is a shared resource; securing it is a shared responsibility.
Participating in MANRS consists of four simple but concrete actions that network operators should take.
Joining MANRS and the Internet2 community’s efforts also connects you with a community of security-minded professionals and organizations committed to making the global routing infrastructure more robust and secure.
MANRS stands for Mutually Agreed Norms for Routing Security. Internet2 is a MANRS participant, as are several of our member institutions. MANRS outlines four simple but concrete actions that network operators should take.
"Ensure the correctness of your own announcements and of announcements from your customers to adjacent networks with prefix and AS-path granularity"
- "Prevent propagation of incorrect routing information."
- Define a clear routing policy, reflected in your IRR information.
- Use prefix-lists to filter announcements from your customers.
- Use AS-PATH filters to help prevent route leaks.
- Verify that your customers own the ASNs and routes they are advertising to you.
- You can use IRRs and RPKI (recommended) to produce prefix lists.
- You can use RPKI and validators to tag valid, unknown, and invalid routes. Invalid routes that are signed by Network A but advertised by Network B.
"Enable source address validation for at least single-homed stub customer networks, your own end-users, and infrastructure"
- Run Spoofer.
- Use uRPF, IP verify source, and/or access-lists.
- Follow BCP38/84 and use prefix-filters at your border.
- Block all traffic sourced from your IPs from entering your border via the internet.
- Prevent all traffic that is not sourced from your IPs from leaving your network.
- Prevent all RFC1918 addresses from entering or leaving your network. (Extra points for blocking bogons!)
- If you have customer networks, use an IRR or internal documentation to only allow inbound traffic sourced from that customer's IPs.
- Don't forget IPv6!
"Maintain globally accessible up-to-date contact information"
Update your contact information in ARIN, RADb, etc. How long has it been since you checked your phone number? Is one of your contacts retired by now? Has your office moved? Would it be a good thing to put a listserv email address instead of a single person's email? Update your Admin-C, Tech-C, and Zone-C!
Also, remember to update your contact info in PeeringDB!
"Publish your data, so others can validate routing information on a global scale"
MANRS requires the following updated information in the following places.
Using an IRR to register your routes is a good thing. As major peers like Google and Hurricane Electric begin to use IRR information to inform their routing policies, this piece becomes more important. We encourage each of our members to work with their regional provider to ensure their information is correctly reflected in an IRR.
However, having your objects registered in an IRR does not mean you have provided irrefutable proof that you own these networks. Only signing your routes by creating ROAs, as part of the RPKI system, can provide irrefutable proof.
IRR Q&A / Office Hours
Be Ready for Google’s New Peering Requirements!
Internet2 is hosting a Q/A session, with advisors from the community and Internet2 staff, to address questions and comments related to new requirements to document routing policies via IRRs. Internet2 staff will provide an introduction to the topic during the first 15 minutes.
(Anyone is welcome to attend. The first 15 mins will provide background on the issues related to the need to document prefixes in an IRR to comply with Google's new requirements. The remainder of the hour will be dedicated to answering questions)
Wednesdays at 3pm ET | 12pm PT
October 2, 2019
Send questions about IRR entries to email@example.com
To participate in the IRR Slack Channel, please email Linda Roos.