2.4.16 Routing Policy System (rps)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

Chair(s):

Daniel Karrenberg <dfk@ripe.net>
Cengiz Alaettinoglu <cengiz@isi.edu>

Operations and Management Area Director(s):

John Curran <jcurran@bbn.com>
Michael O''Dell <mo@uu.net>

Operations and Management Area Advisor:

John Curran <jcurran@bbn.com>

Mailing Lists:

General Discussion: rps@isi.edu
To Subscribe: rps-request@isi.edu
Archive: ftp://ftp.isi.edu/rps

Description of Working Group:

The Routing Policy System Working Group will (1) define a language, referred to as Routing Policy Specification Language (RPSL), for describing routing policy constraints; (2) define a simple and robust distributed registry model for publishing routing policy constraints; and (3) define a set of tools for analyzing registered policy constraints, for checking global consistency, for generating router configurations, and for diagnosing operational routing problems. It is expected that RPSL will enter the standards track.

The RPSL will be routing protocol independent as well as router configuration format independent to support various routing protocols such as BGP, IDRP, SDRP, and various router technologies. The RPSL will be backward compatible with RIPE-181 whenever possible; the registry model will be based on the RIPE database.

The working group will focus on inter-domain routing protocols, but will also instigate, review, or (if appropriate) produce additional RFCs to support other protocols such as multicasting and resource reservation.

Goals and Milestones:

Done

  

Hold BOF to discuss scope of work and working group creation.

Jul 95

  

Submit draft specification of tools and the database model as an Internet-Draft.

Jul 95

  

Submit initial draft specification of RPSL as an Internet-Draft.

Sep 95

  

Submit revised Internet-Draft.

Dec 95

  

Submit document on RPSL and Experiences to IESG to be considered for publication as an RFC.

Jan 96

  

Submit RPSL specification to IESG for consideration as a Proposed Standard.

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the RPS Meeting

Chairs: Cengiz Alaettinoglu, Daniel Karrenberg (DK58)

Reported by: Joachim Schmitz (JS395-RIPE)

Agenda

I. Updates to RPSL Specification (Cengiz Alaettinoglu)
II. Ideas for RPSL Extensions (Cengiz Alaettinoglu)
III. RPSL Transition Draft (David Kessens)
IV. RPSL Application Draft (David Meyer)
V. Security Extensions for RPSL (David Meyer)
VI. Autnum Authorization and Cross Notification (Carol Orange)
VII. BIRD - Will It Fly? (Cengiz Alaettinoglu)
VIII. RAToolSet News (Cengiz Alaettinoglu)
IX. Roe Working Experience (Joachim Schmitz)
X. Multicast Additions to RPSL (Susan Hares)

The agenda is more detailed than the one previously posted. There were no changes to this agenda.

I. 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; "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 that 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.

II. Ideas for RPSL extensions (Cengiz Alaettinoglu)

Cengiz Alaettinoglu, David Meyer, David Kessens, and Randy Bush did the work defining RPSL extension procedures. 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 two and three - this depends on the special case. Finally, extensions must be published as an IETF document. RPSL is a powerful language. It covers two 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 is to keep it together.

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

· RPSL database server mirrors RIPE-181 server

· RPSL is default in the IRR

The conversion tools are also separately available at http://www.isi.edu/ra/rps/transition/ where other functionality (e.g., 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 occurred. Stage 2 of the transition process will occur in December 1997. 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.

IV. 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 "<AS1>" 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 1998 incorporating experience from the tutorials (as described in the transition process). Then it should become an informational RFC.

V. 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, and data privacy.

All of this should be supplied as simply as possible. D. Meyer suggests adding 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 verification 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 become a document of the working group. It is currently available from http://www.antc.uoregon.edu/IETF/Munich97/RPSL/

VI. 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 although 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 that 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! However, this can 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.

VII. 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 legitimization 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; however, the data sent among them will be authenticated. Object keys will be globally unique, integrity will 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. For example, 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 that 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 receive 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 1997.

VIII. 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).

IX. 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 <AS reg exp>" 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 using templates. As a final conclusion ROE is considered a "must" for any ISP working with routing registries.

X. 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. Definitely, one of the major topics was the question: what is a policy? She 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.

XI. 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 1998 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.

Slides

RPS - Agenda
RPSL Transition (Draft)
Bird - Will it Fly?
RAToolSet News
Working Experience with ROE (Route Object Editor)
RPSL Changes
RPSL Extension Procedures

Attendees List

go to list

Previous PageNext Page