Minutes Routing-wg RIPE 29

[Joao Luis Silva Damas <]

Please find enclosed the draft minutes for the Routing Working Group meeting 
during RIPE 29 (Amsterdam, 28-30 Jan. 1998)

******************************************************

Draft Minutes: Routing Working Group. RIPE 29
---------------------------------------------

Chair:      Joachim Schmitz (JS395-RIPE)
Minutes:    Joao Luis Silva Damas (JLSD1-RIPE)
Attenders:  46

A. Preliminaries (Joachim Schmitz)

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

   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 (http://www.rsng.net/pair)

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

 R I P E 2 9 A M S T E R D A M
 Routing Working Group Session
 28-Jan-98        Draft Agenda

 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