As discussed in the BCOP TF meeting on Monday, we want to inform the Routing WG on the status of the MANRS (https://www.manrs.org/manrs/) and the MANRS Abstract BCOP.
MANRS have been presented a number of times at the BCOP TF and at the Routing WG. The actual MANRS guidelines are published on the manrs.org website, but the BCOP TF had the opinion that a RIPE series document has value as a static reference to the MANRS. With the community input and feedback an extended abstract has been written down (see attachment). Last year August the BCOP TF announced and closed the last call for comments on the MANRS Extended Abstract on the BCOP mailing list b...@ripe.net. Somewhat delayed, we want announce on the Routing WG mailing list the last call for this document with a time window of two weeks (until June 1st). Thank you and best regards, Jan Zorz & Benno Overeinder -------- Forwarded Message -------- Subject: Re: [bcop] Abstract of the MANRS BCOP Date: Tue, 22 Aug 2017 15:44:12 +0200 From: Benno Overeinder <be...@nlnetlabs.nl> To: BCOP Task Force <b...@ripe.net> CC: Jan Zorz - Go6 <j...@go6.si> This reminder is directed to the BCOP TF mailing list subscribers. In the BCOP TF meeting we announced a period of last comments on the extended MANRS BCOP abstract draft and to publish this as a RIPE document. We want to close the comments period in two weeks and move the draft further in the process to make it a RIPE document. Note that the draft is an abstract of the MANRS BCOP and references the full MANRS BCOP that includes examples and can be extended in the future. The MANRS extended abstract published as a RIPE document will be a stable document. Best regards, — Benno > On 8 May 2017, at 13:31, Andrei Robachevsky <robachev...@isoc.org> wrote: > > Hi, > > The final version of the MANRS BCOP has been published on the MANRS > website: https://www.manrs.org/bcop/. Both a PDF and an online versions > are available. > > However, to bring the bcop process to an official closure, chairs > suggested that instead of publishing the MANRS BCOP as a RIPE document, > that might be too constrained, we publish just an abstract. And once the > BCOP global repository is in place, we can put it there in whatever > format is most convenient. > > I am attaching the abstract for your review and comments. > > Regards, > > Andrei > <20170508-MANRS-BCOP-abstract.txt><20170508-MANRS-BCOP-abstract.docx> -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/
Mutually Agreed Norms for Routing Security (MANRS) Implementation Guide Abstract, BCOP series Publication date: 1. What is a BCOP? A Best Current Operational Practices (BCOP) document describes best current operational practice on a particular topic, as agreed by subject matter experts and periodically reviewed by the Internet community. 2. Summary The "Mutually Agreed Norms for Routing SecurityÓ (MANRS, https://www.manrs.org) BCOP provides guidance to ease deployment of measures required by MANRS and is targeted at stub networks and small providers. The document should also assist in checking if the network setup is compliant with MANRS. 3. MANRS Throughout the history of the Internet, collaboration amongst participants and shared responsibility for its smooth operation have been two of the pillars supporting the tremendous growth and success of the Internet, as well as its security and resilience. Technology solutions are an essential element here, but technology alone is not sufficient. To stimulate visible improvements in this area, a greater change toward a culture of collective responsibility is needed. With this goal in mind an industry driven initiative called the ÒMutually Agreed Norms for Routing Security (MANRS)Ó was launched in November 2014. The initiative has 4 objectives: ¥ Raise awareness and encourage actions by demonstrating commitment of the growing group of supporters ¥ Promote the culture of collective responsibility for resilience and security of the InternetÕs global routing system ¥ Demonstrate the ability of the industry to address issues of resilience and security of the InternetÕs global routing system in the spirit of collective responsibility ¥ Provide a framework for ISPs to better understand and help address issues related to resilience and security of the InternetÕs global routing system 3.1 The MANRS Principles ¥ We (the ISP/network operator) recognize the interdependent nature of the global routing system and our own role in contributing to a secure and resilient Internet. ¥ We will integrate best current practices related to routing security and resilience in our network management processes in line with the Actions. ¥ We are committed to preventing, detecting and mitigating routing incidents through collaboration and coordination with peers and other ISPs in line with the Actions. ¥ We encourage our customers and peers to adopt these Principles and Actions. 3.2 The MANRS Actions Many different recommendations exist to improve the security and resilience of the inter-domain routing system. Some of the advice can even appear somewhat contradictory and often the key decision can come down to understanding what is most important or appropriate for a given network considering its size and resources, the number of external connections, customers and end-users it has, the size and expertise of its staff, and so forth. The MANRS Actions underline a set of recommendations that are definitely valuable to the overall security and resilience of the global routing system, as well as to the network operator itself. They address three main classes of problems: ¥ Problems related to incorrect routing information; ¥ Problems related to traffic with spoofed source IP addresses; and ¥ Problems related to coordination and collaboration between network operators. The Actions are: 1. Filtering - Preventing propagation of incorrect routing information. ¥ Network operator defines a clear routing policy and implements a system that ensures correctness of their own announcements and announcements from their customers to adjacent networks with prefix and AS-path granularity. ¥ Network operator is able to communicate to their adjacent networks which announcements are correct. ¥ Network operator applies due diligence when checking the correctness of their customerÕs announcements, specifically that the customer legitimately holds the ASN and the address space it announces. 2. Anti-Spoofing - Preventing traffic with spoofed source IP addresses. ¥ Network operator implements a system that enables source address validation for at least single-homed stub customer networks, their own end-users and infrastructure. Network operator implements anti-spoofing filtering to prevent packets with an incorrect source IP address from entering and leaving the network. 3. Coordination - Facilitating global operational communication and coordination between network operators. ¥ Network operator maintains globally accessible up-to-date contact information. 4. Global Validation - Facilitating validation of routing information on a global scale. ¥ Network operator has publicly documented routing policy, ASNs and prefixes that are intended to be advertised to external parties. 3.3 Becoming a MANRS Participant Network operators who agree to the Principles and implement at least one of the Actions (though not solely the Coordination Action) can become a MANRS Participant. This entitles you to use of the MANRS badge, you will be listed on the routingmanifesto.org website, and you can contribute to this document and others like it. The proposed recommendations, referred to as Actions in the MANRS document and in this BCOP, address the most common cases and are designed to incur minimum cost and risk when implementing them. Any particular Action is not a comprehensive solution to the outlined problems. 4. Implementation guidelines for the MANRS Actions The selection of actions was based on an assessment of the balance between small, incremental individual costs and the potential common benefit. They define a minimal security baseline. Any particular Action is not a comprehensive solution to the outlined problems. In order to facilitate the implementation of MANRS Actions a set of guidelines has been developed in the framework of the BCOP activity. The full guidelines are provided here: https://www.manrs.org/bcop/ 5. Information checklist Effective implementation of routing security relies on the availability of up-to-date information, such as contact information, routing policies and specifically networks that are being originated by a network operator. Being a responsible network operator requires both publishing contact and routing policy information, and using the information published by others to validate the routing announcements received from others. 5.1. Publishing information - checklist There are many places where information can be published. This summary can be used as a checklist when publishing and updating information, and can be included in your organisationÕs processes and procedures. - For the AFRINIC, APNIC and RIPE NCC region: ¥ Publish contact information for roles/departments as ROLE objects Optionally: create PERSON objects for staff members and link from the ROLE ¥ Create IRR objects and refer to the correct POCs from those objects and document your routing policy: ¥ INETNUM and INET6NUM . admin-c: refer to your IPAM administrators . tech-c: refer to the administrators of the systems on this network ¥ AUT-NUM . admin-c: refer to your peering coordinators . tech-c: refer to your NOC . mp-import/mp-export: document your BGP connections ¥ ROUTE and ROUTE6 . remarks: document contacts for your NOC, abuse desk, etc. . ping-hdl: refer to your NOC ¥ Create RPKI ROAs for all prefixes that you announce from your ASNs ¥ Publish your peering locations, policy and contacts in PeeringDB ¥ Publish your peering locations, policy and contacts on your website ¥ Publish your NOC and abuse contacts on your website - For the LACNIC region: ¥ Publish contact information for roles/departments as POC objects ¥ Publish contact information for the Organizations holding resources (directly allocated by LACNIC or re-allocated by a LIR) ¥ Publish the DNS that provides the reverse resolution for IP blocks ¥ Refer to the correct POCs for you resources: . tech-c: refer to your IPAM administrators . abuse-c: refer to your network abuse desk ¥ Create RPKI ROAs for all prefixes that you announce from your ASNs ¥ Publish your peering locations, policy and contacts in PeeringDB ¥ Publish your peering locations, policy and contacts on your website ¥ Publish your NOC and abuse contacts on your website - For the ARIN region: ¥ Publish contact information for roles/departments as POC objects ¥ Refer to the correct POCs from your resources ¥ NET . NOC POC: refer to your NOC and optionally sysadmins . Tech POC: refer to your IPAM administrators . Abuse POC: refer to your systems abuse desk ¥ ASN . NOC POC: refer to your NOC and peering coordinators . Tech POC: refer to your IPAM administrators . Abuse POC: refer to your network abuse desk ¥ Create IRR objects and refer to the correct POCs from those objects and document your routing policy: ¥ INETNUM and INET6NUM . admin-c: refer to your IPAM administrators . tech-c: refer to the administrators of the systems on this network ¥ AUT-NUM . admin-c: refer to your peering coordinators . tech-c: refer to your NOC . mp-import/mp-export: document your BGP connections ¥ ROUTE and ROUTE6 . remarks: document contacts for your NOC, abuse desk, etc. ¥ Create RPKI ROAs for all prefixes that you announce from your ASNs ¥ Publish your peering locations, policy and contacts in PeeringDB ¥ Publish your peering locations, policy and contacts on your website ¥ Publish your NOC and abuse contacts on your website 5.2. Validating information - checklist Operating a network in a responsible way requires the validation of the traffic you and your customers send to the rest of the Internet, and validation of the routes that your upstreams, peers and customers announce to you. Failing to validate any of this makes your network vulnerable to route hijacks and a potential source of DDOS attack traffic. ¥ Apply ACLs and/or uRPF filtering to your customersÕ connections ¥ Apply ACLs, uRPF and/or SAVI filtering to your own networks ¥ Use the information in the IRRs to filter routes that your customers announce to you ¥ Validate the announcements from your customers against the RPKI ROAs 6. Acknowledgements The main authors of this document are David Freedman, Brian Foust, Barry Greene, Ben Maddison, Andrei Robachevsky, Job Snijders and Sander Steffann. We also thank Will van Gulik, Jakob Heitz, Aris Lambrianidis, Kevin Meynell and Massimiliano Stucchi for their review and contributions to this document.