RIPE Routing Working Group Policy based routing within RIPE ripe-60 May 1992 Jean-Michel Jouanigot Antonio Blasco Bonito Francis Dupont Stefan Fassbender Anders Hillbo Ferdinand Hommes Lothar Klein Willi Porten Don Stikvoort Marten Terpstra Ruediger Volk Author's address: Jean-Michel Jouanigot, jimi@dxcoms.cern.ch 1. Introduction RIPE, Reseaux IP Europeens, is a collaboration between Regional networks. RIPE is not a network in itself, and has therefore no Network Operation Center. One of the most important issues in such a collaboration is the inter-regional routing between the networks colla- borating within RIPE. In order to achieve global connectivity, all organiza- tions have to collaborate with each other, and create a "coordinated routing core". This coordinated routing core exists de facto for more than one year now, but the current setups have been built on case by case basis, and have never been published. At the very beginning, the routing between the interna- tional routers where mainly built on dynamic routing algorithms, using interior or exterior routing protocols. However it is believed that this "open routing" organiza- tion has reached its limits and another structure has to be used. - 1 - Policy based routing within RIPE May 1992 2. Interior vs Exterior routing protocols Whilst a single interior routing protocol would be easier to manage, this approach is currently unrealistic, mainly because: * An interior routing protocol between international routers would mean that an European Backbone exists, with shared lines and routers, and with a common routing policy for all the routers and the lines in this backbone. * If such a backbone would exist, a central entity should take care of it, and organize the interior routing protocol within the backbone, as well as the Exterior routing protocols between this backbone and the National and disciplinary networks connected to it. This organization would obviously manage the routers within this backbone, as well as the lines connecting these routers. As there is no such "global" backbone, and no such network operation center, this approach is not applicable. [1] The current collaboration is built on a set of lines and routers, managed by different organizations, without real general supervision. The RIPE internetwork is built on a set of Administrative Domains, (every RIPE member organization has its own) which can have multiple Routing Domains internally. Therefore, at the borders, the only applicable routing scheme is to use External Routing proto- cols between the different Administrative Domains (using different Autonomous systems numbers), each Administrative Domain applying its own routing policy. 3. Current routing structure A routing core member mainly collaborates with its "neighbors", using an Exterior routing protocol (or an interior routing protocol used as an Exterior one in some cases). Unless a router applies a set of res- trictions, it routes all the European networks, using the shortest path algorithm. Most of the routers filter the routes on one criteria: all the networks they propagate should be registered in the RIPE database, with a "non LOCAL" flag in the connected field [R1,R2]. A few others use filters according to peer to _________________________ [1] The EBONE initiative, which goal is to im- plement a central common backbone, will not in- clude all the international infrastructures. - 2 - Policy based routing within RIPE May 1992 peer agreements between two routers, applying therefore a routing policy. Even if the current network infrastructure is quite sim- ple, with very few backdoors, and very few backup agree- ments, care must be taken to avoid routing loops and unpredictable routing paths. This is avoided on a case by case basis, using routing announcement filtering. Finally, a general default route mechanism is being used to access the US backbones. Most of the routers point to a default router (or a default network) in Europe or in the US. This does not prevent European traffic to cross the Atlantic twice, even if this is avoided as much as pos- sible [R1]. The current number of European networks routed within RIPE is more than 1200. 4. Policy based routing Every router within RIPE is applying a routing policy, even if it has never been published. These routing policies were implemented in order to: * Protect a private line from carrying unwanted traffic, * Enforce a certain path to a network, * Avoid incorrect network announcements. These routing policies have been implemented for politi- cal and/or technical reasons, and many of them have never been documented and are still evolving. Policy based routing is currently under study in the networking community, and several documents have already been published [R3,4,5,6,7,8]. All these proposals try to resolve the issue of expressing policies, and implementing them. Even if some "simple" models have proved their efficiency, it is believed that these studies are not yet finalized, and that a lot of work need to be done. A good starting point would be to publish, for all the rout- ing core routers, their routing policies, using for exam- ple the description proposed in [R3]. However, these policy statements would require a precise definition of the Administrative Domains they refer to, the definition of the User Class Identifiers... It would be more con- venient to start with a description of the routing policies in English, collect all this information and define the Administrative Domains later on. - 3 - Policy based routing within RIPE May 1992 All the RIPE members are asked to produce the routing poli- cies their routers apply. These routing policies will be collected by the RIPE routing-WG, and published as soon as possible. 5. Implementation of the Policy based routing Lots of theoretical solutions exist in order to imple- ment routing policies between IP networks. Some of them resolve the problem in general, and others only a few aspects of it. The main issue is to find an imple- mented mechanism which is able to deal with the problem we want to solve. Proposals like [R3] imply developments of servers, routers and sometimes modification of the end-nodes, which is impossible in the near future. The routers we have today all share a common specification: * Only one routing space, * Routing on destination address. Therefore, only two solutions exist to implement routing policies [R5]: * Policy based distribution of routing information * Policy based packet filtering/forwarding. The second solution cannot be seriously used, because of its impact on the performance of the routers. Policy based distribution of routing information is the only solution in our environment right now. In some cases however, packet filtering can be used to enforce a particu- lar routing policy. Policy based distribution of routing information does not solve the problem of routing loops, illegal announce- ments, and security issues. However, if we can concentrate in one place all the routing information, it is expected that we can avoid most of these drawbacks. 6. Autonomous systems organization One way to implement this policy based distribution of routing information is to use the well-known concept of Autonomous System and protocols such as BGP[R6]. Because it is expected that we can use such a protocol, a BGP pilot project has been proposed within RIPE, and is currently progressing. - 4 - Policy based routing within RIPE May 1992 For many reasons Autonomous System numbers have not been used in the RIPE community to distinguish different Administrative Domains with their own lines, routers and policies. Many routers within RIPE do not really use Autonomous Systems for routing. They are rather used only at the AD border to implement some routing filtering. Therefore, for the time being, the Autonomous systems organization is not currently suitable for routing purposes. Once the Autonomous systems have been reorganized in Europe, the Autonomous Systems Numbers and BGP could be used to implement routing policies. However, BGP is unable to avoid incorrect and illegal routing announcements. There- fore, the routing-wg proposes to use policy based distri- bution of routing information using route announcement filtering. The issue is therefore to obtain reliable network lists. This would require administrative tasks to be performed in all the routing centers. These tasks would be greatly sim- plified by using a common database. 7. The RIPE database The RIPE database already contains a set of use- ful informations on networks. These informations are described in [R2]. An example of information one can find about networks is: *in: 192.16.184.0 *na: CWI-ETHER *de: CWI Ethernet (Classical) *de: Amsterdam *de: Netherlands *tc: Piet Beertema *tc: Daniel Karrenberg *co: RIPE Internet NSFnet *de: CWI, Amsterdam *ch: dfk@cwi.nl 900802 *so: RIPE The current definition for the "co" field is: The definition of this is arbitrary and should be replaced by something more rational as e.g. AS's that may be traversed or some such. Suggestions wel- come. - 5 - Policy based routing within RIPE May 1992 LOCAL local only This means routing updates will be blocked in RIPE routers. RIPE European. This means RIPE routers will distribute routes for this net. NSF NSFnet. This means the net is in the NSFnet database ICS Internet Connected Status EU member of InterEUnet NORDU member of NORDUnet BLOCK for local purposes (not in RIPE database) It is proposed to add a new field named 'rout-pr' (rp), similar the actual 'co' field. The new field indi- cates the privileges as granted by a certain networking organization. The value of the field is a mnemonic specified by the networking organization. - 6 - Policy based routing within RIPE May 1992 Possible values of this field can be: LOCAL local only (This means routing updates will be blocked in RIPE routers.) EUNET member of InterEUnet NORDUNET member of NORDUnet HEPNET member of HEPNET GARR member of GARR EASINET member of EASINET NSFNET This network has the NSFNET connected status. The complete list of these attributes will be defined later on, as well as the organizations/persons that can grant a privilege . Procedures to collect attributes and to authorize the use of attributes with the organization/person when networks are added to the RIPE database, are being defined by the NIC coordination working-group. These connectivity flags can only be set if agreed by the organizations that can grant them. This field can contain several tags. EXAMPLES: rp: HEPNET EASINET NSFNET rp: GARR NSFNET In addition to this field, a new field 'bdry-gw' (bg) should indicate the origin of the announcement for this network in the international routing core. This 'bdry-gw' field indicates the site name which is allowed to announce this network. Should this field contain more than one value, this means that the network described has more than one connection point to the international infrastructure (for backup purposes for example). This field should contain "routing center names" and not router's names in order to limit the number of possible values for this field. Possible values can be :[2] _________________________ [2] The complete list of these attributes is to be defined later on - 7 - Policy based routing within RIPE May 1992 CEA CERN CIEMAT CNAF CNUCE CNUSC EUNET/Amsterdam DESY DFNGATE DIST EASIGATE FORTH GMD ILAN IN2P3 INRIA IRIS JKU KTH LEUVEN NIKHEF SARA SWITCH UKC ULCC UNIDO VIENNA 8. Database object definition 8.1. rout-pr definition _______________________________________________________________________________________________________________ || || || rout-pr [flag] [mandatory]|| || descr [text] [multiple] [mandatory]|| || authority [text] [mandatory]|| || guardian [email-address] [mandatory]|| || admin-c [person] [multiple] [mandatory]|| || tech-c [person] [multiple] [optional] || || changed [text] [mandatory]|| || source RIPE [mandatory]|| ||||_______________________________________________________________________________________________________________|||| rout-pr: The name of the flag, that can be a value in the con- nectivity field of a network entry. - 8 - Policy based routing within RIPE May 1992 Format : one textual flag Example: rout-pr: WCW status : mandatory descr:A short description of what the rout-pr is. Format : text, multiple. Example: description: Wetenschappelijk Centrum Water- graafsmeer (WCW) status: one line mandatory, multiple lines optional authority: Formal authority for this rout-pr. This can be an institute, committee etc. Format : text Example: authority: WCW LAN committee status: mandatory guardian: Email address of the guardian authorizing requests for this rout-pr. It is expected that this email address is present in the returning authorization message. Format : one email address Example: guardian: wcw-guardian@nikhef.nl status: mandatory admin-c: Person administratively responsible for this rout-pr. Format: person, multiple Example: admin-c: John Doe status: mandatory tech-c: person technically responsible for this rout-pr. Format: person, multiple Example: tech-c: Jon Doe status: optional changed: Field containing the person (email) who made the change and the date of last change. Format : mailbox yymmdd Example: changed: dfk@cwi.nl 910129 status: mandatory source: Source of this information. This will normally be RIPE. Format : text Example: source: RIPE status: mandatory - 9 - Policy based routing within RIPE May 1992 8.2. bdry-gw definition _______________________________________________________________________________________________________________ || || || bdry-gw [flag] [mandatory]|| || descr [text] [multiple] [mandatory]|| || location [text] [multiple] [mandatory]|| || authority [text] [mandatory]|| || guardian [email-address] [mandatory]|| || admin-c [person] [multiple] [mandatory]|| || tech-c [person] [multiple] [mandatory]|| || changed [text] [mandatory]|| || source RIPE [mandatory]|| ||||_______________________________________________________________________________________________________________|||| bdry-gw: Name of the boundary gateway. This is not the name of the actual physical router since that may change. Format: one textual flag Example: bdry-gw: NIKHEF Status: mandatory descr:Short textual description of the bdry-gw. Format: text, multiple Example: description: IP over IXI links Status: one line mandatory, multiple lines optional location: Short textual description of the location of the brdy- gw. Format: text, multiple Example: location: Wetenschappelijk Centrum Water- graafsmeer (WCW) Status: one line mandatory, multiple lines optional admin-c: Person administratively responsible for this bdry-gw. Format: person, multiple Example: admin-c: Marten Terpstra Status: one line mandatory, multiple lines optional tech-c: Person technically responsible for this bdry-gw. Format: person, multiple Example: tech-c:Marten Terpstra Status: one line mandatory, multiple lines optional authority: Formal owner of this bdry-gw. Format: text - 10 - Policy based routing within RIPE May 1992 Example: authority: NIKHEF status: mandatory guardian: Mailbox of the guardian of the bdry-gw. Usage as in the rout-pr object. Format: mailbox Example: guardian: terpstra@nikhef.nl Status: mandatory changed: Field containing last change date and person who made the change. Format : mailbox yymmdd Example: changed: dfk@cwi.nl 910129 status: mandatory source: Source of this information. This will normally be RIPE. Format : text Example: source: RIPE status: mandatory 8.3. Objects Examples Please note that these are examples, they may not represent the real values for these objects. rout-pr: NIKHEF-IXI descr: IP over IXI to NIKHEF authority: NIKHEF guardian: terpstra@nikhef.nl admin-c: Rob Blokzijl tech-c: Marten Terpstra changed: 911001 dfk@cwi.nl source: RIPE bdry-gw: NIKHEF descr: IP over IXI gateway location: NIKHEF location: Wetenscappelijk Centrum Watergraafsmeer (WCW) location: Amsterdam authority: NIKHEF guardian: terpstra@nikhef.nl admin-c: Rob Blokzijl tech-c: Marten Terpstra change: 911001 dfk@cwi.nl source: RIPE rout-pr: HEPNET descr: High Energy Physics Network authority: HEPnet Technical Committee IP (HTC-IP) - 11 - Policy based routing within RIPE May 1992 guardian: hip-adm@frcpn11.in2p3.fr admin-c: HTC-IP Chairman tech-c: HTC-IP Chairman change: 911001 dfk@cwi.nl source: RIPE 9. Implementation of the routing policies 9.1. Principle The routing policies are implemented in each routing center using the information contained in the database. The routing announcements are filtered according to local rules that are widely published. As an example, we will consider a routing center composed of 3 routers, and connecting 5 international lines. The lines 1,2,3,4,5 are international connections to other routing centers, whereas A,B,C are "intra-domain" connections between routers inside the routing center. The routing announcements on A,B,C cannot generally be described using the the information found in the database. Each network in the database is tagged with a set of flags (i.e. rout-pr, bdry-gw, cy ...) which could be used by the routing center to accept or refuse network announcements comming from other routing centers on the international lines 1,2,3,4,5 according to the local routing policy. The database does not describe any "global" routing policy for a network. Examples : on line (1) accept any network with cy=PL on line (2) accept any network with cy=IT except those with rp=EUNET on line (3) accept any network with cy=IT and rp=EUNET [3] 9.2. Practical examples one can easily implement the (non published) routing policy on the GARR-CERN line by: at CERN: Accept any network from INFN with the follow- ing statement: cy = IT && rp = GARR Routing policy for the EUnet/Amsterdam-Dortmund line: at EUnet/Amsterdam: Accept any network from Dortmund with _________________________ [3] line (3) is supposed to be an EUNET line to Italy - 12 - Policy based routing within RIPE May 1992 the following statement: cy = DE && rp = EUNET Routing policy for the IN2P3-CERN line: at CERN: Accept any network from IN2P3 with the follow- ing statement: cy = FR && bg = IN2P3 9.3. Rules Compiler The policy based routing statements should be listed in a common format. A 'Rules Compiler' [4] processes these rules and extracts, from the database, the lists of networks that have to be downloaded in the routers to implement the rout- ing policy. 10. References R1 Bernhard Stochman, "8th RIPE meeting minutes", (ripe-m-8), March 1991 R2 R.Blokzijl, "RIPE Databases (ripe-13)", RIPE, 28 August, 1990 R3 D. Clark, "Policy Routing in Internet Protocols", RFC 1102, M.I.T., May 1989 R4 J. Rekhter, "EGP and Policy Based Routing in the New NSFNet backbone", RFC 1092, February 1989 R5 H-W. Braun, "Models of Policy Based Routing", RFC 1104, Merit/NSFNET, June 1989 R6 J. Honig & all, "Application of the Border Gateway Protocol in the Internet", RFC 1164, Merit/NSFNet, June 1990 R7 B. Leiner, "Policy Issues in Interconnecting Net- works", RFC 1124, RIACS, September 1989 R8 D Estrin, "Policy Requirements for Inter Adminis- trative Domain Routing", RFC 1125, U.S.C. Computer Science Dpt., November 1989 R9 H-W. Braun, "The NSFNET routing architecture", RFC 1093, Merit, February 1989 _________________________ [4] A Beta test version of this compiler written at CERN is currently "field tested" at the CERN Routing Center. - 13 - Policy based routing within RIPE May 1992 R10 K. Lougheed, "A border gateway protocol", RFC 1163, Cisco Systems, June 1990 R11 Scott Brim, "IP routing Between U.S. Government Agency Backbones and Other Networks", Internet Draft, Cornell University, January 1990 R12 M. Lepp and M. Steenstrup, "An Architecture for Inter-Domain Policy Routing", Internet Draft, BBN Communication Corporation, February 1990 - 14 -