Using the RIPE Database as an Internet Routing Registry

Denis Walker — Aug 22, 2013 02:55 PM
Filed under: , ,
The RIPE Database operates as an open, public database for routing information. This information is not restricted to the RIPE NCC service region or to resources administered by the RIPE NCC.


1. Introduction

As an open routing registry, the RIPE Database is available for anyone to use to document their routing policy and information. The level of authentication, authorisation and validation varies depending on the resources that routing information relates to.

2. Scenarios

There are four different scenarios concerning the resources used to create route objects. We refer to route objects throughout this document, but all information also applies to route6 objects.

2.1. RIPE NCC-administered IP address space, RIPE NCC-administered ASN

This is the most validated scenario. In this case there is an exact matching, or less specific, address space object in the RIPE Database, as well as an aut-num object matching the "origin:" value in the route object. Authorisation is required from both the address space and the Autonomous System Number (ASN) to create a route object. All these objects relate to resources administered by the RIPE NCC. Therefore authorisation checks were performed on the address space and aut-num objects when they were created in the RIPE Database. Everything is tightly coupled and authorised across different areas of the registry.

2.2. RIPE NCC-administered IP address space, non-RIPE NCC-administered ASN

In this scenario the RIPE Database still has the related address space object. Since this object is administered by the RIPE NCC, it was authorised on creation. However, the ASN is not a RIPE NCC-administered resource and is not contained in the RIPE Database. The software still requires authorisation from this ASN. A workaround, introduced with the first design of the RIPE RPSL Database (deployed in 2001), is to allow creation of aut-num objects in the RIPE Database that duplicate the ASN information from other RIR-administered resources.

To create any aut-num object, authorisation is required from an as-block in the RIPE Database. For all as-blocks covering RIPE NCC-administered ASN resources, this is restricted so that only RIPE NCC Registration Services can create such aut-num objects. For all other RIR-administered ASN resources the as-blocks have the "mnt-lower:" set to RIPE-NCC-RPSL-MNT

mntner:         RIPE-NCC-RPSL-MNT
descr:          This maintainer may be used to create objects to represent
descr:          routing policy in the RIPE Database for number resources not
descr:          allocated or assigned from the RIPE NCC.
admin-c:        RD132-RIPE
auth:           MD5-PW # Filtered
remarks:        *******************************************************
remarks:        * The password for this object is 'RPSL', without the *
remarks:        * quotes. Do NOT use this maintainer as 'mnt-by'.     *
remarks:        *******************************************************
mnt-by:         RIPE-DBM-MNT
referral-by:    RIPE-DBM-MNT
changed: 20040427
source:         RIPE

This has a public password to allow the required authorisation to be provided when creating the duplicate aut-num objects which are not administered by the RIPE NCC, i.e. AS Numbers allocated to other RIRs by IANA. Anyone can create one of these duplicates. There is no validation against the authoritative RIR's database to check if it is the resource holder creating the duplicate or if the data matches. Anyone creating a route object in the RIPE Database that is authorised by a duplicated aut-num object should keep this in mind.

2.3. Non-RIPE NCC-administered IP address space, RIPE NCC-administered ASN

In this scenario the RIPE Database still holds the originating aut-num object. This object is part of the RIPE NCC-administered resources and again authorisation from the aut-num is required on creation. However the address space is not a RIPE NCC-administered resource and is not contained in the RIPE Database. The software still requires authorisation from the address space, so the workaround, again introduced with the first design of the RIPE RPSL Database (deployed in 2001), is to include the RIPE-NCC-RPSL-MNT mntner as the "mnt-routes:" on the 0/0 and 0::/0 objects in the RIPE Database. The authorisation heuristics look for exact matching address space first, then look for less specific address space. For any non-RIPE NCC-administered address space these root objects will be the less specific objects found. Again, this method allows the authorisation to be passed for address space.

2.4. Non-RIPE NCC-administered IP address space, non-RIPE NCC-administered ASN

In this scenario none of the resources required for authorising the creation of a route object exist in the RIPE Database. So authorisation is passed by combining the two scenarios above. Duplicate the aut-num object in the RIPE Database and authorise against the root address space object.

3. Required authorisation 'provided' or 'bypassed'?

By using mntner objects with public passwords the software requirement for two authorisations can be provided in all cases. Another way to view this is to allow the required authorisation to be bypassed, since authorisation is not against the authoritative resource administered by one of the other RIRs. This workaround bypasses true authorisation to satisfy a mandatory business rule in the RIPE Database. It was a design decision made with the original RIPE RPSL Database and still applies today. If the RIPE Database only acted as a routing registry for RIPE resources then this would not be needed. Since it provides IRR services for any global resource, decisions/compromises/workarounds must be made. Bypassing the authorisation in this way can be achieved by anyone. No validation is possible with the current process. No notifications are sent to the contacts from the authoritative resources in other RIR regions when any of these objects are created in the RIPE Database.

There are, however, other options to the one currently in use.

3.1. Only require authorisation from RIPE NCC-administered resources

We could drop the requirement for authorisation from non-RIPE NCC-administered resources. That would mean that authorisation is (by)passed by default, eliminating the need for any public passwords. It would also eliminate the need for users to duplicate aut-num objects when required only for authorisation purposes. However, for resources administered by RIRs that do not operate a routing registry, the RIPE Database IRR may still contain duplicates of aut-num objects put there to document the resource holder's routing policy. Over time these duplicates can, and often do, get out of sync with the authoritative resource.

3.2. Only require authorisation from address space

Currently route creation requires authorisation from both the address space and the originating ASN. But the existence of a route object in the RIPE Database only confirms that an agreement WAS made at the time the route object was created. Instead of requiring authorisation from the ASN we could notify the ASN holder (from any RIR region) when a route object is created specifying their ASN as origin. We could also provide a revocation option, allowing a RIPE NCC-administered ASN maintainer to delete any route object that they originate, even if they don't maintain it. With the reclaim functionality already deployed for resource holders, this would allow either party to delete a route object (for all RIPE-administered resources) regardless of who maintains it.

3.3. Cross-registry authorisation

If it is considered important to have the authorisation from both the address space and ASN holder, we could extend that to require authorisation from any authoritative resource holder even if that resource is in another RIR's database. We would require agreement from all the RIRs to design, implement and deploy a mechanism to do this.

3.4. Cross-registry notifications

Regardless of any other options considered, we can look at notifying non RIPE NCC-administered resource holders when routing data is created/modified/deleted in the RIPE Database related to their resource.

3.5. Related service: RPKI

As the take up of certification of resources and creation of ROAs increases, that may eventually take over from the route object as the primary declaration of routing agreements between parties.

3.6. Routing Policy System Replication

Past discussion of this issue has made some reference to 'rps dist' ( This is a draft RFC that expired in 2000. It seems to be an early idea involving mirroring, cross registry (repeated) authorisation and some form of certifying validity of data by referencing transactions and reviewing history of authorised changes for objects relied on for authorisation back to the point when a route object was first created. Taking a quick look at this draft, it looks like all the features and benefits proposed have been superseded by RPKI.

4. Example scenarios

To illustrate what can happen with these scenarios let's look at some examples:

4.1. Routing RIPE NCC-administered address space with an ARIN-administered ASN

ARIN is the authoritative registry for AS209. The ARIN Database holds this information:

ASNumber:       209
ASName:         ASN-QWEST
ASHandle:       AS209
RegDate:        1998-11-13
Updated:        2012-02-24

To create a route object in the RIPE Database originating from this ASN a user created a copy of this ASN registration information in the RIPE Database:

aut-num:        AS209
as-name:        ASN-QWEST-US
descr:          NOVARTIS-DMZ-US
admin-c:        NOVN1-RIPE
tech-c:         NOVN2-RIPE
mnt-by:         NOVARTIS-MNT
changed: 20120927
source:         RIPE

Neither of these objects show any routing policy. This is shown in another copy of this ASN in the Routing Assets Database (RADb):

aut-num:    AS209
as-name:    Qwest
descr:      Qwest Communications AS 209
admin-c:    Dave Nolen
tech-c:     Dave Nolen
mnt-by:     MAINT-QWEST
changed: 20121205
source:     RADB
remarks:    =============================================
remarks:    Qwest BGP Local Preference
remarks:    ---------------------------------------------
remarks:    Customer default = 100
remarks:    Peer default     = 80
remarks:    =============================================
remarks:    Communities allowed from customers to alter
remarks:    default local preference
remarks:    ---------------------------------------------
remarks:    209:90 = Set Local Pref to 90
remarks:    209:80 = Set Local Pref to 80
remarks:    209:70 = Set Local Pref to 70
remarks:    209:999 used for announcing routes greater
remarks:    than /24 (will not be passed to peers)
remarks:    May need to be arranged first
remarks:    209:0 Blackhole community for null routing
remarks:    May need to be arranged prior to using.
remarks:    =============================================
remarks:    Traffic Engineering communities allowed from
remarks:    customers to alter advertisements to
remarks:    selected peers.  Advertisements can be
remarks:    suppressed or pre-pended.
remarks:    ---------------------------------------------
remarks:    209:888 = Do not announce to peers
remarks:    209:64520       All peers
remarks:    209:64530   ATT                   7018
remarks:    209:64540   Sprint                1239
remarks:    209:64550   Verizon (UUNet)        701
remarks:    209:64560   Level 3               3356
remarks:    209:64570   Savvis                3561
remarks:    209:64580   NTT Verio             2914
remarks:    209:64590   XO                    2828
remarks:    209:64600   Global Crossing       3549
remarks:    209:64610   AboveNet              6461
remarks:    209:64630   France Telecom        5511
remarks:    209:64640   China Telecom         4134
remarks:    209:64650   Tata (Teleglobe)      6453
remarks:    209:64660   Cogent                 174
remarks:    209:64680   LG U-Plus (DACOM)     3786
remarks:    209:64690   TeliaSonera           1299
remarks:    209:64700   Reach                 4637
remarks:    209:64710   Reach Japan           9225
remarks:    209:64720   Tinet (Tiscali)       3257
remarks:    209:64730   PCCW                  3491
remarks:    209:64740   Deutsche Telekom      3320
remarks:    209:64750   Telefonica           12956
remarks:    209:64760   TW Telecom            4323
remarks:    209:64770   China Unicom          4837
remarks:    209:64780   PACNET               10026
remarks:    209:64790   Reliance Globalcom   15412
remarks:    209:64800   Cable Wireless        1273
remarks:    209:64810   Telecom Italia        6762
remarks:    -Note that above communities currently apply only
remarks:    to North America peering sessions.
remarks:    209:64xx0 do not announce to this peer
remarks:    209:64xx1 prepend 209 once to this peer
remarks:    209:64xx2 prepend 209 twice to this peer
remarks:    209:64xx3 prepend 209 three times to this peer
remarks:    209:64xx9 leak route to that peer. This is to be used in
remarks:    conjunction with 209:888
remarks:    Timezone Traffic Engineering
remarks:    209:64990 do not announce to PST peers
remarks:    209:64991 prepend once to PST peers
remarks:    209:64992 prepend twice to PST peers
remarks:    209:64993 prepend three times to PST peers
remarks:    209:64980 do not announce to CST peers
remarks:    209:64981 prepend once to CST peers
remarks:    209:64982 prepend twice to CST peers
remarks:    209:64983 prepend three times to CST peers
remarks:    209:64970 do not announce to EST peers
remarks:    209:64971 prepend once to EST peers
remarks:    209:64972 prepend twice to EST peers
remarks:    209:64973 prepend three times to EST peers
remarks:    =============================================
remarks:    Communities customers receive from Qwest
remarks:    ---------------------------------------------
remarks:    209:209 = Qwest route/Qwest Customer
remarks:    209:209 and 209:888 together = Customer learned route not
remarks:    passed to peers
remarks:    209:888 = Peer learned route
remarks:    POP origin communities
remarks:    North America 209:1[1-4]..0_
remarks:    PST      209:11..0_
remarks:    MST      209:12..0_
remarks:    CST      209:13..0_
remarks:    EST      209:14..0_
remarks:    ASIA   209:2[2-5]..0_
remarks:    Singapore 209:22..0_
remarks:    Hong Kong 209:23..0_
remarks:    Japan     209:24..0_
remarks:    Sydney    209:25..0_
remarks:    Europe   209:41..0_
remarks:    London    209:41010
remarks:    =============================================
remarks:    For questions or requests please consult with our NOC at
remarks:    1-877-886-6515.
remarks:    =============================================

4.2. Routing RIPE NCC-administered address space with an APNIC-administered ASN

APNIC is the authoritative registry for AS4768. The APNIC Database holds this information:

aut-num:        AS4768
as-name:        CLIX-NZ
descr:          TelstraClear Ltd
descr:          Private Bag 92143
descr:          Auckland
country:        NZ
import:         from AS3561
                action pref=10;
                accept ANY
import:         from AS4763
                action pref=10;
                accept ANY
import:         from AS6453
                action pref=10;
                accept ANY
import:         from AS681
                action pref=10;
                accept AS681
import:         from AS4648
                action pref=10;
                accept AS4648
export:         to AS3561
                announce AS4768 AS681
export:         to AS4763
                announce AS4768 AS681
export:         to AS6453
                announce AS4768 AS681
export:         to AS4648
                announce AS4768
admin-c:        IG1-AP
admin-c:        TAC3-AP
tech-c:         TTC7-AP
remarks:        Please raise network issues by phone 24 hours, 7 days
remarks:        via TCL Technical Assistance Group on +64 9 912-4990
notify:         apnic.changes _at_ _dot_ nz
changed: 20041209
changed: 20050217
source:         APNIC

To create a route object in the RIPE Database for RIPE NCC address space originating from this ASN, a user created a copy of this ASN's registration information in the RIPE Database:

aut-num:        AS4768
as-name:        ECCETERRAM-AS
descr:          ECCE TERRAM Internet Services GmbH
import:         from AS8220 accept ANY
export:         to AS8220 announce AS4768
tech-c:         COS11-RIPE
admin-c:        FS21
mnt-by:         DE-COLT-MNT
mnt-routes:     DE-COLT-MNT
changed: 20080703
source:         RIPE

The documented routing policies are totally different. Looking back at the history of AS8220 (using --list-versions and --show-version #n) it did not have any corresponding import and export attributes matching the above around the time of the creation of this copy.

The RADb has a copy matching the authoritative APNIC Database version.

4.3. Routing AFRINIC-administered address space with an AFRINIC-administered ASN

AFRINIC is the authoritative registry for AS2561. The AFRINIC Database holds this information:

aut-num:        AS2561
descr:          Egyptian Universities Network (EUN)
admin-c:        EDAG1-AFRINIC
tech-c:         EDAG1-AFRINIC
admin-c:        EMNA1-AFRINIC
tech-c:         EMNA1-AFRINIC
as-name:        EUN
descr:          Egyptian Universities Networks
descr:          Egypt
admin-c:        NA29
tech-c:         NA29
org:            ORG-EUN1-AFRINIC
mnt-by:         AFRINIC-HM-MNT
changed: 20070125
changed: 20100406
changed: 20130321
source:         AFRINIC

To create route objects in the RIPE Database for AFRINIC address space originating from this ASN, a user needs to have a copy of this ASN's registration information in the RIPE Database:

aut-num:        AS2561
remarks:        This aut-num has been transfered as part of the ERX.
remarks:        It was present in both the ARIN and RIPE databases, so
remarks:        the information from both databases has been merged.
remarks:        If you are the mntner of this object, please update it
remarks:        to reflect the correct information.
remarks:        Please see the FAQ for this process:
remarks:        **** INFORMATION FROM ARIN OBJECT ****
remarks:        as-name: FRCU-EUN
descr:          Egyptian Universities Network (EUN)
                FRCU Computer Center
                Supreme Council of Universities
                Cairo University
admin-c:        EDAG1-RIPE
tech-c:         EDAG1-RIPE
admin-c:        EMNA1-RIPE
tech-c:         EMNA1-RIPE
remarks:        changed: 19930326
remarks:        **** INFORMATION FROM RIPE OBJECT ****
as-name:        UNSPECIFIED
descr:          Egyptian Networks
descr:          Egypt
import:         from AS1717
                action pref=100;
                accept ANY
export:         to AS1717
                announce AS2561
default:        to AS1717
                action pref=10;
                networks ANY
admin-c:        NA29
tech-c:         NA29
mnt-by:         RIPE-NCC-AN-MNT # WARNING: maintainer added to protect object
changed: 19940526
changed: 19990701
changed: 20020919
source:         RIPE

This is still the combined data version after the ERX transfer from ARIN to RIPE before the creation of AFRINIC. The AFRINIC authoritative version has been 'cleaned up'. But the RIPE copy still has the uncertain information. This originates many route objects in the RIPE Database. The RADb has a copy matching the RIPE Database combined data version.

This example highlights two further issues. As AFRINIC does not operate a routing registry, when AFRINIC took over administrative control of these resources in 2005, copies of their ASNs that were previously in the RIPE Database remained in the RIPE Database as a routing reference. But over time these copies have diverged from the authoritative data now held in the AFRINIC Database. There are also many of the old ERX transferred resources that held two versions of the data, from RIPE and ARIN, that have still not been 'cleaned' up.

Examples summary

In most cases these are perfectly valid scenarios. But as no validation is done between registries it is a process that may be open to abuse. Given the information contained in the RIPE Database duplicated versions, which in some cases does not match the authoritative versions, does it provide any useful additional information? They were created using public passwords in order to bypass required authorisation. Is that useful or misleading?

5. Conclusion

Having address and routing information in the same database can provide for extra authorisation checks. This may give an increased validity to those route objects. But to maintain an open, global routing registry requires either enhanced cooperation between the five RIRs, or compromises or to rely on external processes like certification.

Users should also always keep in mind that the RIPE Database serves two distinct purposes:

  • As the authoritative registry for Internet number resources in the RIPE NCC service region, all registry data regarding resources located in the RIPE NCC service region are properly protected by their appropriate maintainers. 
  • As an open, global routing registry, there are objects, like the aut-num objects shown above, that any users can create as duplicates, as described in the scenarios 2 and 4 above. In those cases the data might be completely wrong or misleading or out of sync with what the authoritative RIR holds and provides.
    • Data objects created in the RIPE Database based on these duplicates (like the route objects described in some of the examples above) may also be completely wrong or misleading.

Comments are welcome either below or on the Routing Working Group mailing list.


Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Related Items
Deprecating the "changed:" Attribute in the RIPE Database

The RIPE Database Working Group requested the RIPE NCC to replace the “changed:” attribute in ...

Building The Next Generation RIS Route Collectors

This is the second part of a research project investigating the possible replacement of the current ...

Visualising Bandwidth Capacity and Network Activity in RIPEstat Using M-Lab Data

As a result of the cooperation between the RIPE NCC and Measurement Lab (M-Lab), you can now ...

Call for Input: RPKI Browser

The RPKI Browser is a graphical user interface to the objects of the distributed RPKI repository. ...

Time Warner Cable Outage

The Time Warner Cable network suffered an outage on 27 August 2014 between approximately 9:40 and ...

more ...