MANRS Implementation Guide


4.2. Global Validation – Facilitating validation of routing information on a global scale

Relevant MANRS expected and advanced actions:

  • Network operator is able to communicate to their adjacent networks which announcements are correct;
  • Network operator has publicly documented routing policy, ASNs and prefixes that are intended to be advertised to external parties.

Routing information should be made available on a global scale to facilitate validation, which includes routing policy, ASNs and prefixes that are intended to be advertised to third parties. Since the extent of the internet is global, information should be made public and published in a well known place using a common format.”

MANRS participants should maintain updated public information in order
to facilitate the validation of routing information. This includes the following data:

ObjectSourceDescription
aut-numIRRPolicy documentation
route/route6IRRNLRI/origin
as-setIRRCustomer cone
ROARPKINLRI/origin

4.2.1. Valid Origin documentation

The goal of origin validation is to verify that the rightmost – also called the originator – ASN in an AS_PATH is correct. This can be verified by correlating address space (or prefixes) and ASNs, and to facilitate this, all MANRS participants should make this information publicly available in databases such as the IRRs. They should also encourage (or possibly insist) that its IP transit customers do the same for their own address space.

The two most widely used methods for communicating origin authorisation are:

  • route/route6 objects registered in one of the IRR databases and
  • ROAs published in the RPKI system

Since the resource holder does not know ahead of time which information source may be used for validation by a 3rd party, resource holders should utilise both methods.

4.2.1.1. Providing information through the IRR system

The approach to this will differ depending on which RIR region your network mainly sits in, or is operated from. In regions where the RIR provides an IRR (everywhere except LACNIC) we recommend use of this IRR.

Provider aggregatable (PA) and provider independent (PI) resources allocated to your organisation(s) should be registered in the RIR IRR. Associated route objects (with your organisation’s assigned ASN) should also be created.

An AS-SET object should also be created for your LIR or network using a meaningful name and placed in the same IRR. AS-SETs are meant to group ASNs in meaningful ways. For example create an AS-SET AS64500:AS-CUSTOMERS which contains all customers of AS64500 (AS64501 and AS64502) and create an AS-SET AS64500:AS-ALL which contains both the ASN itself and its customers. This makes it easier for yourself and others to specify routing policy.

For the LACNIC region, the authors recommend use of RADB or NTTCOM’s IRR since LACNIC do not provide one of their own (however it should be noted that for the former, a commercial relationship with Merit is required, and for the latter, at time of writing, a customer relationship with NTT is required).

The table below summarises the recommended route of registration:

RegionPreferred IRRAlternative IRR
ARINARINRADB/NTTCOM
AFRINICAFRINICRADB/NTTCOM
APNICAPNICRADB/NTTCOM
RIPERIPE NCCRADB/NTTCOM
LACNICRADBNTTCOM

We also recommend complementary registration in NIRs where national data quality is an issue (for example, the use of the JPNIC NIR for LIRs within Japan).

4.2.1.1.1. Registering expected announcements in the IRR

For documenting which ASN is allowed to announce which address prefix, ROUTE/ROUTE6 objects are used. Their purpose is to link an AUT-NUM to an INETNUM/INET6NUM.

The following example documents that AS64500 is allowed to announce prefix 2001:db8:1000::/36:


    route6:           2001:db8:1000::/36
    descr:            Provider 64500
    origin:           AS64500 
    mnt-by:           MAINT-AS64500
    created:          2012-10-27T12:14:23Z
    last-modified:    2016-02-27T12:33:15Z
    source:           RIPE

You should create ROUTE/ROUTE6 objects for each exact prefix and ASN you want to see in the routing table.

4.2.1.2. Providing information through the RPKI system

The RPKI repository can store information about prefixes originated by your network in the form of Route Origin Authorization (ROA) objects. Note, that these do not include your customer announcements, but only prefixes that belong to your ASN. Only the origin ASN is verified, not the full path.

4.2.1.2.1. RIR Hosted Resource Certification service

All Regional Internet Registries offer a so-called hosted Resource Certification service where keys are kept and managed by the RIR and all operations are performed on the RIR’s servers.

The procedure of signing up and using the ROA management portal are different for each RIR. The pointers below will provide necessary information:

Each RIR is different, but common requirements for obtaining a certificate include:

  • valid membership with the RIR
  • access to the resource management portal
  • agreement with the Terms and conditions of the service

4.2.1.2.2. RIR portal

An RIR portal offers an interface for performing various operations with ROAs: creation and publication, modification, deletion. Some portals provide tools to generate ROAs from the observed BGP announcements, compare created ROAs with existing BGP announcements and determine the impact that publication of ROAs will have on the existing BGP announcements.

This is the RIPE NCC RPKI ROA Dashboard as an example:

When creating a ROA, pay special attention to the “maximum length” field. If set to the length of the prefix, such an ROA may invalidate announcements of more specific prefixes, unless other ROAs are also created for them. An issuer of a ROA SHOULD advertise all prefixes covered by the ROA, all the way down to the maximum length. If it does not, then an adversary can advertise the most specific with the authorized ASN prepended. Then the adversary will draw the traffic, intercept it (sending to the legitimate destination afterwards) or, more commonly, simply blackholing it causing a DoS attack.

4.2.1.2.3. Using the RPKI and require the customers to register ROA

The basic idea for automating validation of customer announcements with RPKI is the same as for the IRR. However using RPKI in such cases requires that the customer fully manages their address space in whatever system is supported by the RIR they received their address blocks from. For smaller customers, or customers that received their address space as an assignment from their provider, the provider may decide to do RPKI management on their behalf.

4.2.1.2.4. Ensure that the RPKI certificate(s) and ROAs are kept up to date

Establish a process that ensures that every time you originate a new prefix from your network, a corresponding ROA is created or modified to reflect this change. This should become a normal process integrated in the procedures of your NOC.

4.2.1.3. Additional reading

Informational:

4.2.2. Routing policy documentation

While ROUTE/ROUTE6 objects are most commonly used to collect the information required to build filters for origin validation, a starting point for many existing toolkits is the routing policy for an ASN expressed in the aut-num object.

Such routing policy may be made available by describing it using the Routing Policy Specification Language (RPSL – RFCs 4012, 2622 and others), in the “mp-import” and “mp- export” attributes of an aut-num object registered in an IRR database.

The choice of how best to represent policy in RPSL will vary between ASNs, and there often exists more than one way to describe a given policy. However, most policy statements include the use of as-set objects to group customer ASNs together.

4.2.2.1. Basic policy documentation

The following example illustrates the policy of AS64500 from figure 1.


    aut-num:          AS64500
    descr:            Provide 64500
    remarks:          ++ Customers ++
    mp-import:        from AS64501 accept AS64501[AR2]    
    mp-export:        to AS64501 announce ANY
    mp-import:        from AS64502 accept AS64502
    mp-export:        to AS64502 announce ANY
    remarks:          ++ Peers ++
    mp-import:        from AS64511 accept AS64511:AS-ALL       
    mp-export:        to AS64511 announce S64500:AS-ALL
    remarks:          ++ Transit ++
    mp-import:        from AS64510 accept ANY except FLTR-BOGONS
    mp-export:        to AS64510 announce AS64500:AS-ALL
    mnt-by:           MAINT-AS64500
    created:          2012-10-27T12:14:23Z
    last-modified:    2016-02-27T12:33:15Z
    source:           RIPE

A common approach, usually applied to peers and less often to transit providers, is using aut- num, as-set and other object sets derived from AS policy documentation and then expanding them into route objects, explicit filter expressions, etc. to build the required filters.

A third party, AS64511 for instance, could take the AS64500 aut-num object, collect the customer cone (AS64500:AS-CUSTOMERS), collect related route/route6 objects (sometimes expanding other included sets and explicit filters) and obtain a list of prefixes that represent legitimate announcements from AS64500 to its peers.

It is not always clear from the policy in an aut-num object which as-set object should be used to build the above filters. It is therefore recommended that MANRS participants additionally insert the name of this as-set in the “IRR Record” field of their peeringDB record.

4.2.2.2. Advanced policy documentation

Although RPSL is a rich language, and can be used to express complex policy constructs, doing so in a usable (human-readable or machine-parsable) fashion can be challenging. Some examples of what is possible:


    mp-import:    afi ipv4.unicast
                  from AS64510 192.0.2.1 at 192.0.2.2
                  action pref = 10; med = 0;
                  community.append(64500:10);
                  aspath.prepend(AS64500, AS64500)
                  accept ANY except FLTR-BOGONS          
    mp-export:    protocol BGP4 into OSPF
                  to AS64500 announce ANY
    default:      to AS64510 192.0.2.100 at 192.0.2.101

Whether you keep it simple or whether you document every last detail of your configuration depends mostly on your organisation’s policies. MANRS participants with unusual or complicated policies may also choose to describe these separately in a human-readable document, and make that available to other operators by providing links to the document’s location in the “remarks” attribute of their aut-num object and/or in the “Notes” field of their peeringDB record.

4.2.2.3. Summary

RPSL can also be used to document every single router, interface, peering session, filter and route-map. In practice there are very few organisations that publish such extensive data though. The reasons for that are the maintenance effort involved but also for example confidentiality of the details of peering agreements and reluctance of management to allow publicly documenting business practices. As a minimum it is recommended to document at least every peering between ASNs with a reasonable definition of what routes are exchanged.

4.2.3. Additional reading

  • Using RPSL in Practice https://tools.ietf.org/html/rfc2650
  • Routing Policy Specification Language https://tools.ietf.org/html/rfc2622
  • Routing Policy Specification Language next generation https://tools.ietf.org/html/rfc4012
  • Routing Policy System Security https://tools.ietf.org/html/rfc2725