Using the RIPE Database as an Internet Routing Registry

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
 
 

 
  upd-to:         ripe-dbm-notify@ripe
  
   .
  
  net
 
 

 
  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:        ripe-dbm@ripe
  
   .
  
  net 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' ( http://tools.ietf.org/html/draft-ietf-rps-dist-05 ). 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
 

 Ref:            http://whois.arin.net/rest/asn/AS209

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:        raimund.huber@novartis
 
  .
 
 com 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:    david.nolen@qwest
 
  .
 
 com 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:
 

 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:
 

 remarks:    209:0 Blackhole community for null routing
 

 remarks:    May need to be arranged prior to using.
 

 remarks:
 

 remarks:    =============================================
 

 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:
 

 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:
 

 remarks:    -Note that above communities currently apply only
 

 remarks:    to North America peering sessions.
 

 remarks:
 

 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:
 

 remarks:    Timezone Traffic Engineering
 

 remarks:
 

 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:
 

 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:
 

 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:
 

 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:
 

 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:
 

 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:
 

 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@team.telstraclear.co.nz
 

 mnt-by:         MAINT-NZ-TELSTRACLEAR
 

 changed:        hm-changed@apnic
 
  .
 
 net 20041209
 

 changed:        apnic.changes@team
 
  .
 
 
 
 telstraclear
 
  .
 
 co
 
  .
 
 nz 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:        sumit.rustagi@colt
 
  .
 
 net 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:        hostmaster@afrinic
 
  .
 
 net 20070125
 

 changed:        hostmaster@afrinic
 
  .
 
 net 20100406
 

 changed:        hostmaster@afrinic
 
  .
 
 net 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:
 

 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:
 

 remarks:        Please see the FAQ for this process:
 

 remarks:        http://www.ripe.net/db/erx/erx-asn/group3-faq.html
 

 remarks:
 

 remarks:        **** INFORMATION FROM ARIN OBJECT ****
 

 remarks:        as-name: FRCU-EUN
 

 descr:          Egyptian Universities Network (EUN)
 

                 FRCU Computer Center
 

                 Supreme Council of Universities
 

                 Cairo University
 

                 Giza,
 

                 EG
 

 admin-c:        EDAG1-RIPE
 

 tech-c:         EDAG1-RIPE
 

 admin-c:        EMNA1-RIPE
 

 tech-c:         EMNA1-RIPE
 

 remarks:        changed: hostmaster@arin
 
  
   .
  
 
 net 19930326
 

 remarks:
 

 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
 

 notify:         nashwa@frcu
 
  .
 
 eun
 
  .
 
 eg
 

 mnt-by:         RIPE-NCC-AN-MNT # WARNING: maintainer added to protect object
 

 changed:        nashwa@frcu
 
  .
 
 eun
 
  .
 
 eg 19940526
 

 changed:        ripe-dbm@ripe
 
  .
 
 
  
  
 
 net 19990701
 

 changed:        er-transfer@ripe
 
  .
 
 
 
 net 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 .