Draft Minutes: Routing Working Group. RIPE 31 --------------------------------------------- Chair: Joachim Schmitz (JS395-RIPE) Minutes: Miriam Kuehne (MK16-RIPE), Julia Edwards (JE316-RIPE) Attenders: 99 A. Preliminaries (Joachim Schmitz) Joachim Schmitz opened the working group session, passed the attenders' list around, and asked for a volunteer scribe. Miriam Kuehne volunteered as scribe. During the session Julia Edwards took over. 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 30 o 29.R1 G.Winters, J.Schmitz, RIPE NCC Definition of the IRR and an AUP -in progress- Gerald Winters is giving a presentation in this session on work done so far on this topic o 29.R3: RIPE NCC, JLS Damas Implementation of PGP -to be closed- The action may be considered closed because it will be moved to beta in the next two weeks o 30.R1: RIPE NCC, JLS Damas Implementation of autnum authorization -postponed- Implementation has been postponed because this is one special feature within the more general scope of the RPS Authorization draft o 30.R2: RIPE NCC, J. Schmitz, W. Woeber Organize RPSL tutorials for RIPE 31 -done- The RPSL tutorial has been held. B. Report from the RPSL Tutorial - (Joachim Schmitz) RPSL is the "Routing Policy Specification Language" developed by the IETF RPS Working Group. For those who are not familiar with this topic the following pointers may be of interest: http://www.ietf.org/html.charters/rps-charter.html http://www.isi.edu/ra RPSL is in the stage of deployment phase 2 with the final transition phase from RIPE-181 in sight. Part of the transition is education to make it easier for users to apply RPSL. After some tutorials in the US we had the first RPSL tutorial in Europe just prior to this RIPE meeting. There were approximately 90 participants. The training materials are available electronically at http://www.isi.edu/ra/rps/training Future tutorials will be held at the next RIPE meeting, and plans to offer them as part of the LIR tutorials are currently considered. Joachim Schmitz then thanked the trainers Cengiz Allaetinoglu, David Kessens, and the RIPE NCC, for preparing and performing this tutorial. C. Report from the RIPE NCC (Joao Luis Silva Damas) (http://www.ripe.net/meetings/ripe/ripe-31/pres/ncc-upd/index.html) The report included a general update on NCC activities. In the database software, cross notification was added, making use of the two tags "cross-nfy" and "cross-mnt". The functionality follows the specifications developed by the Routing WG in earlier sessions, both regarding the notification in relation to "autnum" and "route" objects. In addition, PGP authentication will also become available in approximately two weeks for production after this RIPE meeting. This method is supplied in parallel to "none", "e-mail address", "UNIX style password", but offers significantly better security. This method may currently be tested at queries: beta-whois.ripe.net submissions: auto-beta@ripe.net in beta status. The implementation follows the Internet draft http://www.ietf.org/internet-drafts/draft-ietf-rps-dbsec-pgp-authent-00.txt developed in the RIPE Database Security Taskforce, and written up by its members Janos Zsako. D. Reports on RPSL Deployment at Registries o RIPE NCC (Joao Luis Silva Damas) (http://www.ripe.net/meetings/ripe/ripe-31/pres/routing-wg- rpsl/index.html) Phase II of the transition has been completed, meaning that a mirror of the production database is installed and running. The mirror according to definition of transition phases is one-way only (RIPE-181 -> RPSL). The phase II database is accessible at - rpslII.ripe.net - auto-rpsl@ripe.net Submissions in RIPE 181 format are still possible and will be translated into RPSL. At the same time straight RPSL submissions are possible. Only autnum objects are currently handled in RPSL format. The database is running using ISI's code written by David Kessens. The usage is still low (which is no wonder because the server just became available). In the future, as part of the database reimplementation, the RPSL capable database will support the full set of RPSL features, and also support the RAToolSet. o ISI (David Kessens) There are three phases proposed in the transition from RIPE-181 to RPSL: phase 1: software development done phase 2: tool development, testing, training real time mirror of IRR in RPSL format special RPSL update path for "autnum" objects *status of today* phase 3: switch over incoming RIPE-181 objects are automatically converted to RPSL during 1999 RIPE, ANS, and Merit are currently in phase 2. MCI and CANET are testing RPSL software. Telstra moved to RPSL, and Connect (AU) is already configuring their routers using the alpha RAToolSet for RPSL. A set of others is know to evaluate. Regarding training and education the following tutorials were held so far - Jun 1998, NANOG in Detroit - Sep 1998, Ripe-31 Edinburgh - Mar 1999, APNIC, Apricot (planned) To make use of RPSL, the following software is available: - RAToolSet - RIPE database with RPSL extensions which is compatible to RIPE db 2.1.3. The full RPSL support will move to beta soon. - R181 to RPSL database objects converter The software is available at http://www.isi.edu/ra/rps/transition o RADB (Gerald Winters) Merit offers a public RPSL server rpsl.merit.edu 43 since spring/summer 1998. Usage is on the rise, and comments from users are focusing on two items - why is the system rejecting my AS object - here is a bug I see In Gerald's personal opinion, a large number of RADB users has not yet logged on to the RPSL server because - the old software works and still seems to satisfy their needs - a steady influx of users exist who do not know RPSL - there is a group of "regular" registry users who think the ISP will do it all Therefore, Gerald lists the following suggestions: - continue the current education strategy - include informative footer messages in email transaction responses - I do not see things as bleak - registry admin's will certainly be putting in extra email consulting hours. Usage and involvement by ISPs at this time is not much. Most of it comes from specialists, or users already interested having discovered the potential in RPSL. Usage outside the US, especially in Europe is still low. It is obvious that more training is needed, and work to make it more useful. Users will definitely change their attitude if usability is better. E. Do we need a Routing Registry for IPV6? (Joachim Schmitz) (http://www.ripe.net/meetings/ripe/ripe-31/pres/ to come soon) In the introduction, a short review was given of what currently is part of the IPv4(!) routing registries, and what benefits its users have from it. It is obvious that today no IPv6 registry exists, and the question was raised whether on is needed. Then the current situation regarding IPv6 was described, and the expected development of IPv6 "Inter6net" with its interaction towards IPv4 listed. Looking at the benefits the IPv4(!) IRR offers, it seemed obvious that they are also applicable to an IPv6 routing registry. Consequently, the conclusion was drawn that a need for an IPv6 routing registry exists, which may even add more value by easing the coexistence of IPv4 and IPv6, and may help in transition to IPv6. The time to raise the topic is not too early because during the 1st quarter of 1999 the IPv6 address allocation is likely to begin. The presentation was finished with a call for participation to explore the idea and to define the requirements. F. An AUP for the IRR (Gerald Winters, Pierre Thibaudeau, Joachim Schmitz) The authors feel that a need exists to build an acceptable use policy for the IRR. To start with the question was discussed what an AUP is. It may simply be defined as a document which lists acceptable IRR practices and data, covering topics for the users like - what purposes should the IRR be used for? - what types of data would I register? - Are there important relationships between objects I should be aware of? - Can I find suggestions for maint. my data? The goals of the AUP may be summarized as - add value to the IRR - address the concerns of (the user and db admin) - provide an easy to understand single point of reference - prevent abuse The AUP may then be used - as reference point, especially for new users - by registry admins signing the AUP to declare the data as conformant with it - by users (eg, comparable to the implied consent from the RIPE copyright in the RIPE.db) The AUP is still under development. The work on it is not yet complete, and some of the suggestions require further detailed discussion. The talk was given to make the community aware of the AUP, to solicit feedback, and to ask for support. The IRR AUP will definitely acknowledge other efforts. Others are currently defining relevant policy rules or have already done so - RPS (rps-auth) - RIPE NCC - Merit Some of the ideas to follow overlap or duplicate existing policies. This is not a bad thing, and it shows consistency with out goal to provide a single point of reference. In the following part of the presentation, a starting framework for an AUP was shown: - Contact information should be kept up to date "Contact information is important data which facilitates communication between network parties. Therefore it is encouraged to keep role and person object data up to date as well as all tech-c and admin-c references." - Commercial uses of the IRR "All commercial uses are stricly forbidden. Contact information must not be used for commercial purposes, advertising purposes, or any other purpose beyond the scope of activities relating to the successful operation of the Internet." - Old objects Old objects are a matter of concern. They are not necessarily invalid. However, current does not imply up to date. So aging out objects based on a "changed:" time stamp (even machine generated) is a probably a bad idea. Using global routing data with IRR information is a better solution. A suggestion may build on read time stamps, because it shows that even old data is still accessed, and therefore most likely still valid. Yet, it must be explored whether this approach is practical. Obviously, there is a series of items which needs further discussion. This includes the concept of cross notification and whether it is recommendable or not. The following discussion did not very much enter this area but focused on the abuse of data in the registry, including contact information by spammers, reluctance of service providers to disclose their policies (company policy and possible business impact), and security of data in the database. G. Routing Policy System Security (Cengiz Allaettinoglu) Due to time constraints the presentation on this topic was moved to the Database Working Group session. Joachim Schmitz apologized to the Cengiz, and thanked Wilfried Woeber for accepting the transfer. Y. I/O with other WGs The presentation on whether a Routing Registry for IPv6 is needed was also given as input at the IPv6 Working Group. Z. AOB There were no additional comments or issues. Agenda ------ R I P E 3 1 E D I N B U R G H Routing Working Group Session 23-September-98 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 30 minutes - actions from earlier meetings B. Recent Developments (Joachim Schmitz) - RPSL tutorial C. Report from the RIPE NCC (Joao Luis Silva Damas) D. Report on RPSL Deployment at the Registries - ISI (David Kessens) - RIPE NCC (Joao Luis Silva Damas) - RADB (Gerald Winters) E. Do we need a Routing Registry for IPv6? (Joachim Schmitz) F. An AUP for the IRR (Gerald Winters) G. Routing Policy System Security (David Kessens, Cengiz Allaettinoglu) 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 31.R1: RIPE NCC, J. Schmitz, D. Kessens Basic Design for an IPv6 IRR Miriam Kuehne, Julia Edwards, Joachim Schmitz, 21 January 1999