Policy Based Routing Within RIPE

RIPE Routing Working Group

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 collaborating within RIPE.

In order to achieve global connectivity, all organizations 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 international routers where mainly built on dynamic routing algorithms, using interior or exterior routing protocols. However it is believed that this "open routing" organization has reached its limits and another structure has to be used.

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]

[1] The EBONE initiative, which goal is to implement a central common backbone, will not include all the international infrastructures.

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 protocols 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 restrictions, 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 peer agreements between two routers, applying therefore a routing policy.

Even if the current network infrastructure is quite simple, with very few backdoors, and very few backup agreements, 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 possible [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 political 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 routing core routers, their routing policies, using for example 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 convenient to start with a description of the routing policies in English, collect all this information and define the Administrative Domains later on.

All the RIPE members are asked to produce the routing policies 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 implement 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 implemented 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 particular routing policy.

Policy based distribution of routing information does not solve the problem of routing loops, illegal announcements, 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.

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. Therefore, the routing-wg proposes to use policy based distribution 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 simplified by using a common database.

7. The RIPE database

The RIPE database already contains a set of useful 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 welcome.

• 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 indicates the privileges as granted by a certain networking organization. The value of the field is a mnemonic specified by the networking organization.

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

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:
The name of the flag, that can be a value in the connectivity field of a network entry.

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 Watergraafsmeer (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

8.2. bdry-gw definition

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 Watergraafsmeer (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
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.

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]

[3] line (3) is supposed to be an EUNET line to Italy

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 following statement: cy = IT && rp = GARR

Routing policy for the EUnet/Amsterdam-Dortmund line:

at EUnet/Amsterdam: Accept any network from Dortmund with the following statement: cy = DE && rp = EUNET

Routing policy for the IN2P3-CERN line:

at CERN: Accept any network from IN2P3 with the following 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 routing policy.

[4] A Beta test version of this compiler written at CERN is currently "field tested" at the CERN Routing Center.

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 Networks", RFC 1124, RIACS, September 1989

R8 D Estrin, "Policy Requirements for Inter Administrative 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

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