Routing Registry Consistency Check Joachim Schmitz AOL Inc Engin Gunduz Shane Kerr Andrei Robachevsky Joao Luis Silva Damas RIPE NCC Document ID: ripe-201 Date: 4 December 2001 ABSTRACT This document describes a project to crosscheck European Internet routing against data registered in the RIPE Routing Registry. This project was proposed as a new activity by the RIPE Routing Working Group. The document gives an overview of the project, discusses the implementation, and mentions some points that have to be addressed in future design documents. This document is intended to solicit input from interested parties. Table of Contents 1.0 Introduction 2.0 Motivation 3.0 Goals 3.1 Types of Routing Data in the IRR 3.2 Types of Routing Data on the Internet 3.3 Comparing Registry and Internet Data 3.3.1 Route Advertisements 3.3.2 RPSL Policy and AS Paths 3.3.3 Allocation Registry Checks 4.0 Reporting and Tool Development 4.1 General IRR Consistency Report 4.2 Specific IRR Consistency Report 4.3 IRR Correction Wizard 4.4 Router Configuration Checker 4.5 Other Tools 5.0 Side-Note on Data Privacy 6.0 Timeline References 1. Introduction For quite some time, the RIPE Database has been part of a global system known as the Internet Routing Registry (IRR). It consists of a set of online databases that offer the possibility to store routing policy information that may be used in network verifications or configurations. Other databases in the IRR include the RADB, ARIN, and a growing number of databases operated by Internet Service Providers (ISPs). Practical applications of the IRR have ranged from simple registration of Internet resources, such as autonomous system (AS) numbers, to registration of routing policies, and complete routing configurations. However, the IRR is not generally considered to form an essential or even adequate tool for network operations. Sometimes, it has been viewed as a somewhat obscure system that was difficult to use and its potential benefits have not become available to a wider audience. Over time, the degree of usage and attention to data maintenance has varied among users resulting in a situation where the quality of data stored is mixed. This project aims at correcting that situation by establishing a stronger link between routing data as seen on the Internet and as stored in the RIPE Database. It is also a goal of this project to address the causes that led to the current unsatisfactory situation by providing tools and information that enhance the usefulness of the IRR to ISPs. 2 Motivation As previously described, the IRR stores Internet routing information that can be used by ISPs to configure and debug their connectivity. This information is stored in the RIPE Database as route, aut-num, inet-rtr, route-set, as-set, and other RPSL objects containing information such as the intended AS origin of an announced prefix, peering information between different ASes, etc. The quality of these data varies widely, while it is supposed to be a representation of what is actually seen in the Internet Routing system. During the initial stages of RIPE Database development, two major drawbacks existed. On one hand, the limitations of the RIPE-181 representation of routing policies became obvious over time, resulting from growing demands and evolving routing protocols. To a significant extent, this has been amended by the introduction of RPSL[1]. On the other hand, mechanisms for data protection within the Database were not strong, and unauthorised (usually accidental) modifications of data occurred. In addition, there was no authorisation mechanism for registration of data in the Database and any user could essentially store any information in the Database (e.g. a new origin for a prefix already registered in another route object). Nowadays, the available protection mechanisms are strong and users can ensure that their data may only be modified by themselves. Regarding authorisation, the RPSL version of the RIPE Database (version 3.0) implements the Routing Policy System Security (RPSS) specification [2], which enables security mechanisms for object creation. Thus a major concern regarding reliability of data has been removed. As a result of the two factors described above, and due to the highly dynamic nature of the Internet, a significant amount of data in the Routing Registry is incorrect, out of date, or simply missing. With a sound basis in place from which to start, this situation may now be remedied. It is worthwhile to note that existence of incorrect data in the IRR does not necessarily make it unusable in its entirety. For example, ISPs that ask their customers to register in the IRR can still configure their routers from the IRR because the subset of data that is of interest for this purpose would be complete and accurate, even if other data in the IRR might not be. While improvements to the Database system will help prevent erroneous registrations in the future, there is a need to correct the inaccurate data currently stored in the Database. Moreover, development of support mechanisms is required to enable ISPs to maintain data and keep it up to date as the Internet evolves. The RIPE Routing Working Group identified these needs and requested that the RIPE NCC addressed them. This document describes the corresponding RIPE NCC project. 3. Goals From the previous considerations, the main goals of the project can be outlined as follows: To track, report on, and increase the accuracy of IRR data To track and report IP allocation usage in the Internet To develop tools to improve user interaction with the IRR; in particular, to increase ease of use of the IRR and to benefit from its resources To disseminate tool and user information The following sections discuss how to attain these goals. 3.1 Types of Routing Data in the IRR The current IRR exhibits two types of data IP routes routing policies These are tied to the following objects in the Database route objects, describing which AS originates each prefix aut-num objects for routing policies inet-rtr, as-set, route-set, and other RPSL objects supporting the description of routing policies. 3.2 Types of Routing Data on the Internet In general, routing data on the Internet is distributed via BGP announcements between peering partners. A full set of Internet routes is available by analyzing the full set of BGP announcements. The set will vary depending on where in the Internet the BGP feed is collected. BGP announcements contain the route prefix and its length; the AS path under which the announcement is visible and its originating ASes; additional BGP attributes that propagate through the routing system. Any of these data items are available by establishing appropriate BGP peerings. The main source of live routing data for this project will be the Routing Information Service (RIS) project [3] being carried out by the RIPE NCC. 3.3 Comparing Registry and Internet Data The two sources of data (IRR and live Internet routing data) have quite different formats. Tools that can understand both sources and make comparisons will be developed. 3.3.1 Route Advertisements A route, which is the combination of network addresses with an originating AS, may be: recorded in the RIPE Database and advertised on the Internet (which is the optimum case) recorded in the RIPE Database but not advertised on the Internet, and advertised on the Internet but not recorded in the RIPE Database. The latter two describe mismatches that may be detected by comparing the data sets. These mismatches may be caused by errors in aggregation (e.g. recording 193.0.0.0/22 in the Database when advertising 193.0.0.0/21), errors in origin (e.g. an advertisement from an old provider), simple omissions, or other reasons. Initially, no attempt will be made to classify errors. They will just be recorded. 3.3.2 RPSL Policy and AS Paths Routing data collected in the Routing Information System (RIS) includes AS path information. It can be used to verify whether the policies recorded in corresponding aut-num objects allow the AS path seen in the live routing data. This means that missing "import:" and "export:" attributes in the aut-num objects may be detected. It is not possible to detect unnecessary "import:" and "export:" attributes, due to the limitations of the RIS data imposed by the nature of BGP. Some routes will not get advertised to any of the route collectors, but still be used on the Internet. This may occur, for example, if a slow or expensive link is used for backup purposes that are activated only in case the regular connection breaks. Another example is upstream route aggregation, which removes longer prefixes from the routing table. 3.3.3 Allocation Registry Checks By including data from the IP allocation registry, it will be possible to track address space usage and detect announcements of space that should not be advertised on the Internet. This is not limited to the use of private address space or AS numbers, but also reveals usage of unallocated AS numbers and IP addresses. 4 Reporting and Tool Development Information produced by this project will be made available at the RIPE NCC web site and/or through e-mail subscription. This will include the following: 4.1 General IRR Consistency Report The report will present general statistical data regarding the size of the IRR, amount of inconsistencies of different types, and delegated address space usage. 4.2 Specific IRR Consistency Report This type of report will present detailed information about IRR inconsistencies for specific portions of the IRR. A specific portion may be defined by the user based on: AS number or as-set, AS information: In this case, the report will list deviations in AS numbers (missing or extra) and AS paths from registered routing policies. AS number or as-set, route information: In this case, the report will contain a list of inconsistent routes originated by the specified AS or ASes. IP address space as defined by inetnum, route, or route-set objects. In this case, the report will contain a list of inconsistent routes concerning this address space. mntner object name, which is referenced by "mnt-routes:" attribute in aut-num, inetnum, or route objects. In this case, the report will contain a list of inconsistent routes related to address space or autonomous systems covered by this attribute. mntner object name, which is referenced by "mnt-lower:" attribute in as-block, aut-num, inetnum, or route objects. In this case, the report will contain a list of inconsistent routes related to address space or autonomous systems covered by this attribute. mntner object name, which is referenced by "mnt-by:" attribute in aut-num, inetnum, or route objects. In this case, the report will contain a list of inconsistent routes related to address space or autonomous systems specified by these objects. Two types of the reports may be requested: periodic report and monitoring report sent when an inconsistency appears. 4.3 IRR Correction Wizard In the event that registrations in the IRR require updating, any user today must set up the corresponding objects by hand, which often is cumbersome and subject to human error. To improve ease of use on the IRR, the project will introduce an IRR correction wizard. This tool will take the routing policy as found on the Internet and provide the user with a set of corresponding objects which can be applied to update the IRR. This includes additions and deletions. The user must verify correctness of the information presented, add the corresponding authorisation information, and forward the objects in a message to the Database update mechanism (). The "correction wizard" is a supplementary tool to be used along with reports produced in section 4.2. 4.4 Router Configuration Checker It will be possible to identify some potential problems in the parts of a router configuration built from the IRR using tools like RtConfig. Normally, the automatic router configuration generators generate only parts of the configuration using IRRs, rather than a complete configuration. Similarly, this tool will check subsets of configurations and identify the statements that are inconsistent with the real state of the Internet. It can be used as router configuration debug help. 4.5 Other Tools Tools developed in the framework of this project will not be limited to the ones described above. Feedback from the community may identify demand for other tools. 5 Side-Note on Data Privacy Due to business confidentiality or other considerations, several service providers do not want to register their routes or policies in a public Routing Registry. However, it should be noted that in order to reach a certain IP address, routing information regarding this IP address must be public. If it were not public, this IP address would not be reachable on the Internet. As a matter of fact, any site that wants to be reachable on the Internet must have or be part of one active public route in the Internet routing table. If a service provider chooses to route certain networks only on limited parts of the Internet (if not using private address space anyway; also in conjunction with NAT) there is no immediate need to feed these data into a public Routing Registry. As an example, we may consider a private peering between two service providers where the corresponding routes are not propagated outside their own autonomous systems. It is obvious that private agreements on routes and policies do not need to be registered in the public IRR because they do not show up on the Internet. Consequently, private or special agreements that are a result of mutual consent among the parties involved do not need to show up in the public IRR. As soon as coordination becomes impractical due to mere size, or if a guaranteed authoritative reference is needed, the public IRR comes in. 6 Timeline Work on this project started during the year 2000. Initial results of this project are available at http://www.ripe.net/ripencc/pub-services/db/rrcc. An initial prototype of this system was presented at the RIPE 38 Meeting In April 2001, the RIPE Database migrated to version 3.0, which supports RPSL. Having the new Database in production will enable faster development of this project and more convenient use for ISPs. References [1] C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. [2] C. Villamizar, C. Alaettinoglu, D. Meyer and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999. [3] A. Antony, H. Uijterwaal. "Routing Information Service. Design Note", RIPE-200, October 1999.