2.4.16 Routing Policy System (rps)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97

Chair(s):

Daniel Karrenberg <daniel.karrenberg@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:

Jul 95

  

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

Jul 95

  

Submit draft specification of tools and the database model 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 Routing Policy System (RPS) WG

Chairs: Cengiz Alaettinoglu, Daniel Karrenberg (DK58)

Reported by: Maldwyn Morris

Copies of the agenda and some of the presentations are kept at: ftp://ftp.isi.edu/rps/dc-ietf/

Agenda

1. Dave Meyer Extending RPSL
2. Cengiz Alaettinoglu Changes to the RPSL draft
3. Cengiz Alaettinoglu New Aggregation Specification
4. Carol Orange Transition Draft
5. Bernard Aboba LDAP Schema for RPSL
6. Curtis Villamizar Security of Routing Information
7. AOB

1. Extending RPSL (David Meyer )

David presented a summary and described the extension methods. They are forward and backward compatible and old tools can work with data in the new format. Attributes have been added to existing classes. There was no need seen to change the syntax.

He asked if the WG thought it should go to Last Call on the way to becoming a BCP, and there were no objections.

2. Changes to the RPSL draft - Cengiz Alaettinoglu

Editorial Changes:

New AS Path Regular Expressions:

Route flap dampening parameters:

After some discussion, it was decided that the attributes suggested for route flap dampening parameters cannot be used to model flap dampening as it is implemented in practice. It was therefore decided that the attributes should be modified to reflect practice, which Daniel Karrenberg offered to do.

3. New Aggregation Specification ( Cengiz Alaettinoglu )

Cengiz said there had been feedback on the mailing list from Curtis and Tony Przygienda.

There is a new Route class.

Attributes:

You can now create a very powerful route object:

It is slightly too complicated for the users but this is probably not avoidable.

Question "can one export overlapping routes" Cengiz said you could.

4. Transition Draft ( Carol Orange )

Carol described the deployment phases of the transition from RIPE-181 to RPSL that are designed to minimize the disruption to the IRR.

Phase 1 : Read RIPE-181, Write RIPE-181

Phase 2 : Write RIPE-181, Read Both

Phase 3 : Write Both, Read RPSL

Phase 4 : Write RPSL, Read RPSL

There were no questions.

5. LDAP Scheme for RPSL (Bernard Aboba)

Outline - Why use LDAP for RPSL, Approach, Benefits.
What a directory is and is not
RPSL Schema overview
Design Issues
Classes and their attributes: Maintainer, Person, Role,
Route and Route-Set, Aut-Num & AS-Set, Dictionary Class
Summary: RPSL can be replicated in LDAP.

Cengiz asked if there were hooks for a syntax checker in the dictionary. Bernard answered that LDAP has pointers to code which could be used for syntax checkers.

Cengiz asked about replication. Bernard answered that a WG has been formed and there were various schemes, some time-based and some using sequence numbers.

Daniel asked about accessing methods based on structure. Bernard answered that they are not currently part of the search and it was deficient in this regard.

6. Security of Routing Information ( Curtis Villamizar )

There has been a discussion in idr over the security of routing information and authentication and notification in the RRs.

There are two parts to security - Authentication of queries and replies and Authorization of routing info. He said Sandy Murphy pointed out exposures in BGP. Bad routes get into ASes from border Ases, there can be malicious injection.

The IRR can be used for filtering on prefixes. A weakness is that anyone can add a route object under their own AS. Thus one can announce a subnet of an enemy and black-hole their traffic.

Authentication of Queries and Replies:

mail-from - no good
password from - better
merit use pgp-from and maintain a private key-ring
sign objects - not needed. A registry is just a clearing house
some info is secure, some not.
sign queries/response - so you know you are talking to a clearing house. Response includes query.

Authorization:

Needed on more specific.

If you want to move a more-specific to another AS you need overlapping permissions - Current provider must register on your behalf giving two maintainers - one for the more-specific, one for the AS. The old one can be deleted. Issue of renumbering and grace periods was not resolved.

Daniel said that Authentication is currently being tackled by the RIPE Database Security Task Force which includes people from a number of Routing Registries. He also said that there is a relationship between the routing announcements made by an AS and the address assignment data. In the current model, an AS takes responsibility for the routing announcements, independent from the address space allocation/assignment structure. This relationship should be clearly documented.

Curtis: An ISP having been allocated a CIDR block must have authority over the aggregate and any more specifics that might be registered. This is to prevent black-holing other peoples traffic. With regards to advertising garbage, one should look to inetnums if no less specific routes have been registered. This means, of course that the inetnum data must be immediately accessible. While this is not a problem in Europe where both the inetnum and routing data are maintained in the RIPE database, it will require cooperation from ARIN and APNIC to make it work in the Americas, and in the Asian Pacific region.

Curtis stated specifically that ARIN must register inetnums in one of the routing registries and we should tell ARIN this will be necessary.

Wilfried asked how you knew who you were talking to when your received a whois reply. A pre-requisite was to be able to treat number and routing registry as one coordinated effort, difficult to implement sanity checks when you don't have the inetnum objects in the same registry Need to move from an independent distributed registry to a coordinated global registry.

Curtis asked if there was a need for a WG item on authentication and authorization and exposure given certain authentication and authorization models.

Cengiz said this discussion could go to the mailing list and it was agreed.

7. AOB

Cengiz said the IESG has approved RPSL as a proposed standard and we need to push it through to a full standard.

Other things WG should do:

He asked if there was anything to add - no.

Co-Chair resigning (Daniel Karrenberg ). Daniel said that he could no longer devote enough time to the working group and resigned. He proposed Carol Orange of the RIPE NCC (orange@ripe.net) as his successor. There were no objections so Carol Orange is the new co-chair of the RPS WG.

Slides

Agenda
Changes
Guidelines for Extending RPSL
LDAP Schema for RPSL
RPS Aggr
RPS Transition

Attendees List

go to list

Previous PageNext Page