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: mailto:auto-rpsl@ripe.net ISI/RADB queries: whois -h whois1.avalon.rs.net submissions: mailto:auto-dbm@isi.edu 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@merit.edu 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 -----