RIPE 29

Report of Meeting, 28th January 1998

A. Preliminaries

Joachim Schmitz opened the working group, passed the attenders' list around and asked for a volunteer scribe. Joao Luis Silva Damas volunteered as scribe. There were 46 participants in the session.

The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list.

Review of actions RIPE 28

Action 27.R1: Carol Orange, RIPE NCC

To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG.

Action 27.R2: Carol Orange, RIPE NCC

To implement aut-num authorisation in the RR

Both actions were still open. The reason for this are the project of rewriting the whole database software, and preparation for the transistion to RPSL. Due to shortage of staff these two actions could not be dealt with.

Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl).

To write up the results on route flap damping in a RIPE document

The final draft of the paper was circulated on the mailing list (see below). This action was therefore closed.

Action 28.R1: Carol Orange, RIPE NCC

Contact other RR on the topic of distributed authorization

Carol Orange met with representatives from other RR (see below). This action was therefore closed.

B. Current Developments

RIPE Document on Route Flap Damping (Christian Panigl)

Input has been gathered from the community, and a report on bugs in the Cisco IOS has been added (regarding improper counting of flaps and early onset of damping). The final draft of the paper was circulated on the mailing list shortly before this RIPE meeting, with a last call for comments. If there are no further additions from the community this final draft will be published as a RIPE document after the meeting (now available as RIPE-178 from the RIPE ftp/web servers).

Most of RIPE considerations on route flap damping have been taken into account and put in the internet draft currently being written by Curtis Villamizar, Ravi Chandra, and Ramesh Govindan. However, the scope of their draft goes beyond the RIPE document. Their paper is available from http://engr.ans.net/route-damp/

RPSL Update and Report from IETF 40 (Carol Orange)

Unfortunately, there is a delay in implementation of RPSL due to unforeseable circumstances. Nonetheless, implementation will continue, just as other work around RPSL does:

• There is a new version of the RAToolset at ISI with partial support for RPSL and there will soon be a new one with full RPSL support.
• The RPSL draft has moved to proposed standard.
• A draft from David Meyer regarding extension of RPSL was accepted.
• A new routing class has been defined providing alternate ways of specifying policy.

Another major topic at the IETF was security for the IRR. This arises from the fact that if IRR information is going to be used for configurations on routers, e.g. for filters. The IRR information must be trusted and a clear authorization scheme must exist.

The main issues seem to be data integrity, prevention of accidental or malicious misconfiguration and prevention of improper use of adress space. In order to base the BGP filtering scheme on the data in the routing registry, the data must be properly tied to the IP assignment data maintained by the IP registries. In the RPS WG of the IETF where this was discussed, it was noted that this will be more diffucult in the ARIN and APNIC regions where the routing and IP registries are separate.

With these requirementes the need arises for communication between IP registries and routing registries. The European internet community has an advantage here.

C. IRR Authorization (Carol Orange)
(swapped in order with Gerald Winters' presentation due to problems with the overhead projector)

The goal of IRR authorization is to make BGP routing in the Internet more secure which depends on proper registry data. This is meant to prevent accidental or malicious misconfigurations. Under this prerequisite it is mandatory to define a scheme which allows an ISP to decide which routes they may trust.

This calls for a definition of the IRR: A proposal is: "The IRR is a place that reflects what is announced in the Internet and what is permitted to be announced."

With AS numbers the path of authority is clear.

IANA -> Regional registries -> ISPs

This works in Europe but not elsewhere. Actually, it is possible to look for free AS numbers, just use them and register them in the IRR. The authority of AS numbers is not checked by the other routing registries. There have been several occasions when this lead to routing problems.

The distribution of IP numbers works similarly. There seems to be agreement in that nonallocated IP numbers should not be routed. However, there is not yet an accpeted mechanism for providing this.

One solution could be to delegate authority for a block of IP numbers in the routing registry at the time of IP allocation by creating an object for the full block that can then be subdivided by the ISP. However, this would tie IP allocation to routing entries.

Joachim Schmitz noted that people should be aware that this imposes restrictions on what can be registered and is a big change from current practice. Comments on this paradigm shift are welcome.

D. Using Internet Routing Announcements to Identify Incorrect IRR Data (Gerald Winters)

Most of the results presented here are based upon PAIR. PAIR is the Policy Analyzer of Internet Routing.

One goal is to compare policies stored on IRRs versus real BGP information in real time. Several tools have been developed for looking at announcements

• route search tool
• route collation tool
• AS path analyzer

among others. These tools and a few others provide opportunities to identify inconsistencies, and to clean up the routing registries from obsolete or wrong data.

The next question arises as to how easy it would be to do this clean up. First it must be known which information should be stored on the IRR. However, this depends on the definition of the IRR. Several have been proposed:

• a repository of current internet policy
• a repository also for private routing information
• a place to experiment

In the following, a series of examples of actual objects stored on RADB were shown:

• objects with very short prefixes, e.g. 0.0.0.0/1
• private/non routable space, e.g. 10.0.0.0/24
• withdrawn routes several years old
• non aggregated (but aggregatable) routes
• holes in "non owned" aggregates (either reasonable or mailicious)
• registration of all subblocks of an aggregate to prevent the above
• extremely old objects
• empty policy AS objects (39% of those on RADB)

Some of this may look inadequate to some and actually be perfectly reasonable.

The question is: What to do with these objects?

As a first step a definition for the IRR is required. Any further action can then be based upon this definition. However, to come to this definition consensus must be found that cleaning is needed, and we must define what can be done. The IRR will probably need some power over object removal to clean up data. Yet, the IRR can not decide on its own - community approval is needed.

The presentation triggered some discussion. Miguel Angel Sanz asked whether any coordination or contact exists between the different Routing Registries regarding this topic. Gerald Winters replied that RIPE, RADB, and ANS are coordinating, but MCI and CANET are not. Carol Orange added that closer coordination has started recently and is being promoted. There have been discussiones about the authorization scheme. However, we need to take into account that different registries serve different purposes: RIPE and RADB are publicly available but MCI runs a RR for their own purposes.

There were remarks regarding the fact that the importance of the correctness of data in IRRs depends on them being used for router configuration and for that to happen better tools are needed. Joachim Schmitz replied that large ISPs currently tend do so and request their peers to do so as well.

There were questions regarding the licensing of RADB code and Gated code. Gerald Winters and Jake Kuhon from Merit replied that the funding scheme for Merit is changing right now. Work on Gated has been resumed at Merit. The details on licensing will depend on the final scheme for Merit. Information will be available from Merit soon.

Richard Almeida made remarks on the differences in registering procedures between Europe and the US and a general comment on the situation being better in Europe.

Questions about followup on aggregation work from previous meeting met the reply there has been no progress recently.

E. Reports from other WGs

There was no current input from other WGs.

F. AOB

Since there was no AOB the meeting was closed.

Agenda

- Routing Working Group Meeting -

Agenda for RIPE-29, January 1998, Amsterdam

A. Preliminaries (Joachim Schmitz)

• introduction
• participants' list
• volunteering of scribe
• agenda bashing
• RIPE 28 minutes
• actions from earlier meetings

B. Current Developments

• RIPE document on route flap dampening (Christian Panigl)
• progress on rpsl implementation (Carol Orange)

C. Using Internet Routing Announcements to Identify Incorrect IRR Data (Gerald Winters)

• progress on PAIR
• indentifying incorrect IRR data
• examples of "interesting" IRR usage
• role of the IRR

D. IRR Authorization (Carol Orange)

Y. General Input from Other WGs

Z. AOB

Summary of Actions

Action 29.R1: G. Winters, C. Orange, J. Schmitz

Definition of the IRR and an AUP

Action 29.R2: RIPE NCC, C. Orange

Implementation of notification and autnum authorization

Action 29.R3: RIPE NCC< C. Orange

Implementation of PGP

Joao Luis Silva Damas, Joachim Schmitz
7-May-1998