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.

Reply via email to