Using the RIPE Database as an Internet Routing Registry
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.
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
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.
auth: MD5-PW # Filtered
remarks: * The password for this object is 'RPSL', without the *
remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. *
changed: firstname.lastname@example.org 20040427
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:
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:
changed: email@example.com 20120927
Neither of these objects show any routing policy. This is shown in another copy of this ASN in the Routing Assets Database (RADb):
descr: Qwest Communications AS 209
admin-c: Dave Nolen
tech-c: Dave Nolen
changed: firstname.lastname@example.org 20121205
remarks: Qwest BGP Local Preference
remarks: Customer default = 100
remarks: Peer default = 80
remarks: Communities allowed from customers to alter
remarks: default local preference
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: Traffic Engineering communities allowed from
remarks: customers to alter advertisements to
remarks: selected peers. Advertisements can be
remarks: suppressed or pre-pended.
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: Communities customers receive from Qwest
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: For questions or requests please consult with our NOC at
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:
descr: TelstraClear Ltd
descr: Private Bag 92143
import: from AS3561
import: from AS4763
import: from AS6453
import: from AS681
import: from AS4648
export: to AS3561
announce AS4768 AS681
export: to AS4763
announce AS4768 AS681
export: to AS6453
announce AS4768 AS681
export: to AS4648
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_ team.telstraclear.co _dot_ nz
changed: email@example.com 20041209
changed: firstname.lastname@example.org 20050217
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:
descr: ECCE TERRAM Internet Services GmbH
import: from AS8220 accept ANY
export: to AS8220 announce AS4768
changed: email@example.com 20080703
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:
descr: Egyptian Universities Network (EUN)
descr: Egyptian Universities Networks
changed: firstname.lastname@example.org 20070125
changed: email@example.com 20100406
changed: firstname.lastname@example.org 20130321
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:
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
remarks: changed: email@example.com 19930326
remarks: **** INFORMATION FROM RIPE OBJECT ****
descr: Egyptian Networks
import: from AS1717
export: to AS1717
default: to AS1717
mnt-by: RIPE-NCC-AN-MNT # WARNING: maintainer added to protect object
changed: firstname.lastname@example.org 19940526
changed: email@example.com 19990701
changed: firstname.lastname@example.org 20020919
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.
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?
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.