Minutes of the RPS session 39th IETF - Thursday, 08/14/97, 9:00am - 11:30am Chairs: Cengiz Alaettinoglu, Daniel Karrenberg (DK58) Reported by: Joachim Schmitz (JS395-RIPE) * Agenda - Updates to RPSL specification (Cengiz Alaettinoglu) - Ideas for RPSL extensions (Cengiz Alaettinoglu) - RPSL transition draft (David Kessens) - RPSL application draft (David Meyer) - Security extensions for RPSL (David Meyer) - autnum authorization and cross notification (Carol Orange) - BIRD - will it fly? (Cengiz Alaettinoglu) - RAToolSet news (Cengiz Alaettinoglu) - roe working experience (Joachim Schmitz) - Multicast additions to RPSL (Susan Hares) The agenda is more detailed than the one previously posted. There were no changes to this agenda. * Updates to RPSL specification (Cengiz Alaettinoglu) Most changes to the RPSL specifications were editorial. They include semantic changes in the structured policies section, and cleaning up a misspecification there; "mnt-by" is now a list of maintainers, route set members now contain operators. To distinguish from newer BGP versions, the term "BGP" was replaced by "BGP4"; "RIPv6" is now called "RIPng". Some dictionary elements which were easy to add include new rp-operators and new data types. The current version is draft-ietf-rps-rpsl-03.txt and will be put forward to IESG as proposed standard. * Ideas for RPSL extensions (Cengiz Alaettinoglu) The work defining RPSL extension procedures was done by Cengiz Alaettinoglu, David Meyer, David Kessens, and Randy Bush). One major element is that extensions will not carry version numbers. Extensions should be done systematically on 1. extend dictionary 2. new classes 3. new attributes to existing classes 4. extend existing attributes while taking into account that everything must stay backward compatible. There is no precedence on points 2 and 3 - this depends on the special case. Finally, extensions must be published as an IETF document. RPSL is a powerful language. It covers to areas: configuration of routers and description of policies. Whether these two shall be better distinguished or even separated was not a major issue. For the time being the general feeling was to keep it together. * RPSL transition draft (David Kessens) There was a new version of the transition draft available as draft-ietf-rps-transition-01.txt. It describes three stages for the transition from old RIPE-181 style policy representations in routing registries to the RPSL representation: - testing and playing The database software will be installed with RPSL extensions on a test database for testing purposes. Actually, some of it has already happened. - RPSL database server mirrors RIPE-181 server Two copies of the databases are kept in parallel. Updates will be possible to both servers. Small banners on the output distinguish the difference for the users. The RAToolSet will be ready to use with RPSL. Tutorials how to use RPSL will be held at NANOG, RIPE, APRICOT - RPSL is default in the IRR While RIPE-181 updates will still be possible they will be automatically converted to RPSL, all servers apply RPSL. The conversion tools are also separately available at http://www.isi.edu/ra/rps/transition/ where other functionality (eg query of old and new database) can be tested. After the Munich IETF meeting the mirror frequency of the test database will be daily from real life registries, later on it will be turned into a real time mirror (regarding the test database). It was suggested to add a remark to a converted RPSL object notifying of the fact that the object shown was converted from RIPE-181, and when the conversion occured. Stage 2 of the transition process will occur in December '97, for stage 3 there is no specific date yet because the time to educate users is unpredictable. The question whether the converter between policy descriptions runs 100% secure was answered that from 120,000 objects only 15 could not be converted with automated tools. Changes to details of the transition plan are sure to happen, depending on the outcome of discussions with the routing registries. A new version will be prepared after the Munich IETF meeting by David Kessens and Carol Orange. The transition document will remain internal to the RPS working group and not enter the standards track. * RPSL application draft (David Meyer) There were not too many comments on the current version of the RPSL application draft draft-ietf-rps-appl-rpsl-01.txt, the most notable one being on the use of communities. Input from NANOG on RPSL was whether syntax "" compared to simply "AS1" is not a bit overloaded. This is more a language issue than an application issue, and was not considered important. From the audience usage of terminology was criticized - terms like schemes, classes, attributes, values and others are seemingly used without clear definition. This must be cleaned up. Input will be provided to the authors of the application draft. In the current state the application draft will not be submitted to IESG because it could not yet be tested on fresh people in practice. Therefore it will remain a working group document until spring '98 incorporating experience from the tutorials (as described in the transition process). Then it should become an informational RFC. * Security extensions for RPSL (David Meyer) According to D.Meuer the provider community asks for better security measures with regard to RPSL. Main objectives are - data origin authentication - data origin integrity - data privacy All of this should be supplied as simple as possible. D.Meyer suggests to add a new field to the maintainer object, denoted "key". It contains the public key of this maintainer. On every object a signature field is added (including the maintainer itself) which contains the signature for the object. The object as a whole is signed. An issue is the initial verfication of the maintainer to get the process started. D.Meyer then described a possible implementation using the MD5/RSA algorithm, and showed how it may work in operation. Data privacy is still an open question. Discussion in the audience showed that storing private data in the registries opens a can of worms - the registries do not have any control about what is stored (implications are similar to anonymous ftp) - the database is meant to be public, storing private data there is contrary to the original purpose - it should probably not be ruled out completely but then be left to the implementors This falls in with the topics and discussions in the RIPE security task force which asked D.Meyer to join in. The RPS working group decided that the presentation by D.Meyer will become a document of the working group. It is currently available from http://www.antc.uoregon.edu/IETF/Munich97/RPSL/ * Autnum authorization and cross notification (Carol Orange) C.Orange presented some new developments in the RIPE database software initiated by the RIPE Routing working group. These new developments even though they are not directly related to RPSL include changes or additions to existing objects, namely the autnum object and route objects which are also elements of RPSL. However, these changes are not related to routing policies but to schemes enhancing security for the database. Autnum objects will carry a new "mnt-route" attribute which has a maintainer as value. Only those maintainers are allowed to create/delete/change route objects for the origin this autnum object describes. In addition, notification is extended for route objects describing overlapping IP ranges. Notification occurs on creation and deletion of overlapping route objects. The submitter of the according database changes is always notified. Owners of existing route objects may get notified if they add a new "crs-notify" attribute to their autnum or route objects. The cross notify attribute takes maintainers as value. This raised the question about a registered default route (RADB). Anyone will be notified of overlaps because all routes overlap with the default. If there are changes to the default route object all maintainers in the routing registry will be notified! This can however easily be avoided by treating the default route separately in the database software. People shall be referenced via NIC handles alone. Yet, person objects do not require a mail address. In this case notification will not work. However, users are supposed to be intelligent enough to only reference person objects for notification purposes if they contain a mail address. It may also be an issue to find a person object from another database. This was referred to the RIDE working group. Further possible extensions with regard to RPSL may include a cross notify attribute in route-sets and AS-sets, or route-sets may be used as parameters for the cross notification field. Cross notification may also be extended to hierarchical sets. This is an ongoing discussion in the RIPE working groups. * BIRD - will it fly? (Cengiz Alaettinoglu) BIRD is a suggestion for a distributed database system developed by Cengiz Alaettinoglu, Ramesh Dovindan, David Kessens, and Wee San Lee. IRD stands for Internet Registry Daemon, and the letter B was added for convenience. BIRD consists of several parts: - user interface: here queries (whois, RAToolSet) occur, updates are made, etc. Some kind of legitimation is desirable (sign on, challenge, cookies) but details are yet to be discussed. - registry interface "RPM" (reliable policy multicast): a reliable mechanism to distribute policy data via multicast ensures consistency among single registries participating in the IRR. Talkers and listeners will be hard coded in the BIRD software sharing the same group address. All participants using BIRD must trust each other, the data sent among them however will be authenticated. Object keys will be globally unique, integrity be checked locally first, then objects will be sent out, and in case of clashes all conflicting objects deleted. In a whole to achieve consistency is a nontrivial problem, as discussion in the audience showed. Issues will be written up and further discussed in the mailing list. - scheduler, syntax checker, object storage, indexer: the scheduler distributes work among the different elements of BIRD. The syntax checker is not limited to registry objects but distinguishes e.g. classes, attributes, privileges, schema and dictionary objects. The object storage keeps the data including caching to improve performance. With the indexer there are many open issues which are not yet resolved. The indexer gdbm currently used needs way too much time to create an index of the database. Therefore, other mechanisms or improvements must be considered taking crash recovery into account. For BIRD, security is also a major issue. This is not limited to communication among participants in the IRR using BIRD, but extends to the user interface as well. Objects submitted to the IRR must be signed at least. The discussion about the earlier presentation of D.Meyer already showed that this involves several issues. To come to a definite solution, it should first be thought about what is wanted and then how to accomplish it by signing or other methods. In addition, the participants of BIRD must somehow be selected. In principle, anybody could become a registry. To keep data consistent and reliable some checks must be built in. Discussion revealed that not everybody should be able to reveive registry data via BIRD (on the RPM interface) but anybody should be allowed to send data (on the user interface). However, a mechanism to select participants in the IRR must still be found. With all the open questions and issues it can not yet be told whether BIRD will ever fly but work is continuing. A very limited demo already exists today. The alpha release is planned for December '97. * RAToolSet news (Cengiz Alaettinoglu) C.Alaettinoglu intended to have RAToolSet version 4.0.0 available beyond the current alpha release before the Munich IETF meeting. Time constraints prohibited this early distribution. It is now considered to become available around mid September. The most important changes include extensions to roe (route object editor), and general RPSL support (especially import/export attributes in RIPE-181 type registries). * roe working experience (Joachim Schmitz) J.Schmitz presented his working experience with roe, the route object editor, being part of the RAToolSet. roe is a C++/Tcl/Tk program to view and manipulate route objects registered at any routing registry, and to compare them to real life routes. Route objects are taken from the routing registries, real life routes are supplied by the output of "show ip bgp " from Cisco routers. roe is easy to install and very easy to use. It could have more configurable parts, and should be more verbose in what it does in each phase. Depending on the AS studied, roe might need quite some resources. Performance of roe depends on the amount of data, availability/load of routing registry servers, and network performance. In a whole roe is found to be particularly useful to check for consistency of routes and corresponding object entries in routing registries, to synchronize route object entries in different registries, to find erroneous route objects, or to detect missing or superfluous routes or route objects. These tasks are very easily performed because roe compares large sets of data in a clear presentation, while working on registry data is simplified by easy selection and the usage of templates. As a final conclusion roe is considered a "must" for any ISP working with routing registries. * Multicast additions to RPSL (Susan Hares) S.Hares presented a number of transparencies where she explained and clarified the things earlier said and discussed in the RPS working group (either on the IETF, or in the mailing list) and the Multicast working group. One of the major topics definitely was the question: what is a policy? She then distinguished between published and unpublished policies and detailed her thoughts about what a multicast policy is, e.g. referring to RPF checks, or to tree building. In the end she wants to identify where the current draft fits in, whether it is still unpublished policy, and whether it shall be published. In a whole this presentation has built a base for further discussions. * Work items The following work items exist for the RPS working group - the RPSL definition draft is going to proposed standard - the RPSL application document will be kept waiting until further experience is gained in spring '98 with the usage of RPSL. Then it will be proposed as informational RFC - the transition document from RIPE-181 to RPSL will remain internal to the RPS working group, and will be reworked - the security document will be treated as a working group document and will be discussed in the working group - the multicast topic will be revisited next time A separate document on a minimum set required to satisfy a policy definition is not needed because this is already part of the RPSL definition document. J.Schmitz 08/20/97