draft minutes from RIPE 30

Dear all,

please find enclosed the draft of the minutes of the Routing WG
session at RIPE 30. Thanks to the detailed notes of Ambrose
Magee, I am able to distribute them in such detail even at this
late a time - the delay is entirely on me to blame.
Comments, additions, corrections are welcome.
The draft of the agenda for our session during RIPE 31 will be
distributed shortly.
Regards
   Joachim
-----
Draft Minutes: Routing Working Group. RIPE 30
---------------------------------------------

Chair:       Joachim Schmitz (JS395-RIPE)
Minutes:     Ambrose Magee (AMRM1-RIPE)
Attenders:   96

A. Preliminaries (Joachim Schmitz)

   Joachim Schmitz opened the working group, passed the attenders' list around
   and asked for a volunteer scribe. Ambrose Magee 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.

   Joachim Schmitz then told that Carol Orange has left the RIPE NCC and has
   returned to the US. She has been closely working together with the Routing
   WG. He thanked her for her continuous support, her valuable ideas, and her
   numerous contributions. Part of her work has been taken over by Joao Luis
   Silva Damas of the RIPE NCC who has already proven his interest in our
work.
   
   Review of actions RIPE 29

   o 29.R1 G.Winters, J.Schmitz, RIPE NCC
           Definition of the IRR and an AUP
     -open-
           The IRR up to now exists just for convenience, however a new role
           evolves with new developments. Some basics had been prepared, but
           not yet sufficient to be presented. Work will proceed during
summer.

   o 29.R2 RIPE NCC, JLS Damas
           Implementation of cross notification and aut-num authorization
     -half done-
           Cross notification is implemented in the test database and expected
           to be moved to production phase in a few weeks. Work for autnum-
           authorisation is on hold because of the staffing situation.

   o 29.R3 RIPE NCC, JLS Damas
           Implementation of PGP
     -open-
           There has been work done on the specification. A draft will become
           available 2 weeks after this RIPE meeting. Implementation is
planned
           to be finished around RIPE31

B. Recent Developments (Joachim Schmitz)

   o RPSL implementation
     RPSL is the Routing Policy Structured Language developed by the IETF
     RPS WG (http://www.ietf.org/html.charters/rps-charter.html). The
     definition of RPSL is Proposed Internet Standard now (RFC2280).
     It allows detailed description of routing policies.
     It is on the way of being implemented at the routing registries. Some
     of it was presented in the Database WG session. According to a recent
     announcement by JLS Damas, an implementation has also been installed
     at RIPE. David Kessens later on gave a presentation about progress on
     the transistion to RPSL (http://www.isi.edu/ra/rps/transition)

   o Routing Registry Security
     Approximately one year ago, the issue of database security led to the
     RIPE Database Security Task Force being founded. In the IETF RPS WG this
     topic has been taken up for the IRR. A draft is already available from
     them (http://www.ietf.org/internet-drafts/draft-ietf-rps-auth-01.txt).
     David Kessens summarized the most important items later in this session.

   o IRTF Routing Research Group founded
     There is not only the IETF with the focus on "E"ngineering but also
     the IRTF focusing on "R"esearch. A routing research group has recently
     been founded. They are just in the beginning and welcome input. Those
     who are interested may want to look at their web resources
     http://www.irtf.otg/irtf/charters/routing.html

   o BGP AS Origin Authentication with DNS
     A presentation was given later on during the session by Randy Bush, one
     of the authors of the corresponding draft
     http://www.ietf.org/internet-drafts/draft-bates-bgp4-nlri-orig-
verif-00.txt

C. Report from the RIPE NCC (Joao Luis Silva Damas)

   In general, the report from the RIPE NCC consisted of the comments given
   regarding status of the actions, and implementation of RPSL at RIPE.

D. Progress report on the transition to RPSL (David Kessens)

   To implement RPSL at the IRR a transition occurs in three phases
   (for details also see
    http://www.ietf.org/internet-drafts/draft-ietf-rps-transition-02.txt)
   - development of server software
   - tool development and testing, education of users
   - switch over to RPSL
   These phases were then discussed in more detail.

   o Phase 1:

     The server software development is finished. The RIPE database software
     based on RPSL is ready for phase 2.

   o Phase 2:

     RADB and RIPE have moved to phase 2. The RPSL database can be tested at
     RIPE queries:       whois -h rpslii.ripe.net  (usual port)
          submissions:   
	    
	    

     ISI/RADB queries:   whois -h whois1.avalon.rs.net
          submissions:   
	    
	    


     The RAToolSet is developed to be compliant with RPSL needs. There are
     already some service providers who make use of RPSL (Telstra and Connect
     in Australia, several major ISPs in the US are also eager to start
     with RPSL).

     Due to questions from the audience the current state of phase 2 was
     then described in more detail: Phase 2 is experimental. Two sets of the
     database coexist now, one in the old RIPE-181 style, the other in
     RPSL style. Currently, only autnum objects are different.
     Queries to the standard whois host display the RIPE-181 style; queries to
     the RPSL host display RPSL style. If only RIPE-181 objects are present,
     queries to the RPSL host will result in display of the RIPE-181 object
     tranformed to RPSL style.
     Similarly, updates to the corresponding hosts only affect the related
     style. An RPSL update will not affect the RIPE-181 object and vice versa.

   o Phase 3:

     In phase 3 all RIPE-181 objects will be transformed to RPSL objects.
     A meeting was held where all registries participated to coordinate the
     transition to phase 3. There is no schedule yet for several reasons:
     - The RIPE NCC will need more time and documentation to run a stable
       production environment
     - The RPSL database software must be tested
     - The tools development is not yet finished, i.e. they are not yet
       capable of handling RPSL in full
     - People must be able to adapt
     Autumn is considered the earliest date when these preliminaries may be
     finished. However, it is more likely that phase 3 will start during
     winter.

     In order to facilitate the transition for all users of the IRR, tutorials
     are held. This is alrady done at Nanog meetings in the US. For Europe
     there will also be corresponding tutorials. One is planned for the next
     RIPE meeting. Details will be announced well in advance.

E. Interdomain Routing Tools and Analysis (Craig Labovitz)
   (http://www.merit.edu/ipma/docs/presentations/ppt/RIPE30/index.htm)

   Craig Labovitz first introduced the IPMA project (Internet Performance
   Measurement and Analysis, http://www.merit.edu/ipma/). Probe machines are
   locatd at IXPs and throughout the backbone, providing real-time inter-
domain
   problem diagnostics. A map with the locations was shown.

   Originally, the focus was on routing stability. Lately, more attention was
   on latency and losses. Most recently, issues related to visualization of
   the measured data are worked on.

   Then, Craig showed several graphs and results from earlier routing
   stability investigations. The most prominent ones were related to BGP
   updates (up to 60 million per day). The vast majority of the updates
   consisted of withdrawals, most of them being repeated and obsolete.
   It turned out that they resulted from implementation decisions of BGP
   by the vendors which had to be considered bugs.

   Besides these reasons problems in BGP result from
   - BGP/IGB misconfiguration
   - CSU/DSU oscillation (interaction of CSU/DSU with router interface which
     is not configured down)
   - SEP ("someone elses problem", i.e. blaming others)
   - self-synchronisation

   Due to corrected software the number of BGP updates has dropped by one
   order of magnitude. In addition, announcements and withdrawals are now
   approximately the same. Most announcements today result from oscillations
   in attributes. In addition there are still duplicates. It turns out that
   most of them are related related to MED and AS-path changes.

   These were investigated more closely for MICHnet which is a small network
   which is considered stable. It propagates only approximately 100 routes to
   the outside Internet. Surprisingly, there were still roughly 1000 BGP
   updates per day to the outside world. Looking for the reasons they did
   not only find those mentioned in the list above but were also able to
   identify a pattern related to certain periodic OSPF updates inside the
   network. Having those explained they are now investigating for causes of
   the remaining "noise".

   The IPMA tools used for the investigations described above are now leaving
   the alpha phase. They are now starting to work together with other ISPs.
   For further investigations and tests they need help from other ISPs, and
   kindly ask for support. References are
   information: 
      http://www.merit.edu/ipma
   mailto:
      ipma-support@localhost

   The presentation was very interesting and Joachim Schmitz strongly
   recommended that the IPMA tools and analysis should be used to improve
   overall network stability. Several questions were triggered by the
   presentation.

   Randy Bush wanted to know whether it was common for ISPs to redistribute
   IGP to BGP. Craig replied that he is unaware of how common this is on the
   Internet. However, they found it with one of the small ISPs which is
   connected to their backbone. Actually, the more recent versions of the
   Cisco manuals contain a warning about it.
   Yakov Rekhter asked on the impact of different internal routing protocols.
   However, only OSPF was analyzed in detail.
   With most of the BGP instabilities resolved it makes now sense to also
   look at IGP instabilities.
   The BGP updates were measured at route servers. Probably not all updates
   are propagated beyond one peering AS because they are only important for
   the direct peering. Some could be captured by multihop sessions.
   It seems that most updates really result from pure usage and load.
   Nonetheless, maintenance windows with operator interference are visible.
   
F. Comments on IRR Security (David Kessens)

   David Kessens showed transparencies from Curtis Villamizar who was not able
   to attend this RIPE meeting. He is one of the authors of two new RPS drafts
   - rps auth (http://www.ietf.org/internet-drafts/draft-ietf-rps-auth-01.txt)
   - rpsl dist (in preparation)
   The focus of the presentation was on RPS Security. The IRR is more than
   just a mapping of routing prefixes to AS numbers. It includes hierarchical
   address and route allocation. An authentication model is discussed which
   introduces various new objects and attributes to objects, in order to
   meet the desired objectives. As means for authorization/authentication
   PGP is suggested.

   The draft is subject to additional reviews. Nonetheless, deployment of
   the model is under consideration. The authors claim that changes to the
   database and operational procedures are simple. They also estimate that
   their proposal is sufficient to provide authorisation and authentication
   to secure the IRR.

   David Kessens urged the WG to supply comments on this document because
   implementation is planned soon.

   The most important question was related to PGP as secure mechanism. To
   use it for RPS Security commercial copies are needed, leading to the
   question of license costs. Actually, this is not a problem in the RIPE
   community due to the distribution license acquired by the RIPE NCC.
   Moreover, licences would only be needed for updates; read access to
   registry data does not require a PGP license. In addition, Open PGP is
   currently under development at IETF. It must also be noted that the
   proposal is not limited to PGP and does not exclude other means of
   authorization/authentication. PGP is just the method which currently
   is readily available.
   
G. BGP AS Origin Authentication with DNS (Randy Bush)
   (http://psg.com/~randy/980519.ripe/
   http://www.ietf.org/internet-drafts/draft-bates-bgp4-nlri-orig-
verif-00.txt)

   As motivation for the work they have been doing, Randy Bush gave several
   examples of BGP disasters in the last months (e.g. the BGP to RIP to BGP
   reinjection killing all aggregates, or UUnet's 128/9 leak). The source of
   the problem is not that much that misconfigurations occur - of course this
   is a problem, but the real source behind it is that any AS may inject any
   prefix into worldwide routing tables. Not only misconfigurations cause
   problems but this may also be used maliciously.

   While the IRR is an "ideal" solution, the authors see several drawbacks
   which they propose to solve by a pragmatic solution. The approach is based
   upon encoding address space allocation in DNS by expanding the RR
definition
   accordingly. The data included is prefix/length and AS for each route.
   BGP speakers could then look up received prefixes on nameservers. The
   possible results are
   - authenticated: found and AS matched
     This route is accepted as valid and preferred above unauthenticated
routes
   - failed: found and AS does not match
     This route is withdrawn
   - unauthenticated: not found, unknown
     This route is accepted as long it is not superseded by an authenticated
     route. This situation is the same as today for all routes, and would also
     occur at startup before the routes could be verified.
   Several other issues had also been thought of. Nonetheless, the proposal
   led to a series of questions.

   An issue was the amount of DNS queries. It turns out that these can easily
   be several millions. Depending on the load on a nameserver reading this
   information may take in the order of magnitude of an hour. During this
   time most routes are still unauthenticated which is also the case if DNS
   was down. However, this is the situation today. Additional authentication
   improves the overall situation.
   Concerns regarding router performance are considered to be unimportant
   because the CPU power needed is negligible. Estimates also do not see a
   problem if a "routing bomb" with e.g. 200,000 routes is sent to the
   router. It just eats through the entries in its idle time.
   For presentation of classless IP routes the Jan de Groot / Eidnes DNS hack
   can be used.

   As Randy Bush pointed out there are still some open issues, e.g. usage of
   DNSSEC, or which namespace to use. Therefore, input to the proposal is
   welcome.

H. General Input from Other WGs

   There was no input from other working groups at this time.

I. AOB

   Randy Bush asked for a new version of the route flap damping paper.
   Christian Panigl as leading author answered that he is collecting
   additional input and welcomes contributions.

Agenda
------

 R I P E  3 0   S T O C K H O L M
 Routing  Working  Group  Session
 19-May-98           Draft Agenda

 A. Preliminaries (Joachim Schmitz)
    - introduction
    - participants' list
    - volunteering of scribe
    - agenda bashing
    - RIPE 29 minutes
    - actions from earlier meetings

 B. Recent Developments (Joachim Schmitz)
    - Changes in RIPE NCC
    - RPSL implementation
    - Routing Registry Security
    - IRTF Routing Research Group founded
    - BGP AS Origin Authentication with DNS

 C. Report from the RIPE NCC (Joao Luis Silva Damas)

 D. Progress report on the transition to RPSL (David Kessens)

 E. Interdomain Routing Tools and Analysis (Craig Labovitz)
    - Research on Routing Instability
    - Routing Statistics and Measurements
    - Tools

 F. Comments on IRR Security (David Kessens)
    - Routing Policy System Security

 G. BGP AS Origin Authentication with DNS (Randy Bush)

 Y. General Input from Other WGs

 Z. AOB

Summary of Actions
------------------

   Action 29.R1: G. Winters, J. Schmitz
      Definition of the IRR and an AUP

   Action 29.R3: RIPE NCC, JLS Damas
      Implementation of PGP

   Action 30.R1: RIPE NCC, JLS Damas
      Implementation of autnum authorization

   Action 30.R2: RIPE NCC, J. Schmitz, W. Woeber
      Organize RPSL tutorials for RIPE 31


Ambrose Magee, Joachim Schmitz, 8 September 1998
-----