NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 03-Mar-98
Chair(s):
Cengiz Alaettinoglu <cengiz@isi.edu>
Carol Orange <orange@ripe.net>
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:
· RIPE-181 to RPSL Transition Plan
· Application of Routing Policy Specification Language (RPSL) on the Internet
· Guidelines for Extending RPSL
· Routing Policy System Security
Request For Comments:
RFC |
Status |
Title |
RFC2280 |
PS |
Routing Policy Specification Language (RPSL) |
Minutes of the Routing Policy System (rps) Working Group Minutes
Reported by Bill Norton.
The slides for rps wg are at:
ftp://ftp.isi.edu/rps/la-ietf-98
http://psg.com/~randy/980402.idr
The meeting was brought to order by Cengiz at 3:30PM starting with a group hug, and a round of British Toasting Songs. John Curran danced a jog; photos will be up on the web shortly after he meeting. Cengiz Allaettinoglu announced that he changed his name to the single word "Angus," since it was easier to pronounce and spell. Needless to say, it was April Fool's Day.
About 85 or so people in the room.
I. Transition Phases - David Kessens
David Kessens spoke about the phases of the transition plan as described in the RFC and the RPSL server from ISI.
RPSL mirrors available at whois1.avalon.rs.net. Merit's IRRD will be available and expected to be a bit faster.
Server will give hints that could be resolved by other registries (e.g., person objects) APNIC, ARIN, RIPE, MCI/RA, ANS folks present at the meeting at ISI to discuss the transition plan and scheduling. It was agreed that approx. mid-May the registries would transition to Phase 2 with RIPE-181/RPSL running in parallel. More discussion required to determine a date for phase 3 transition.
II. RAToolSet Update - Cengiz Alaettinoglu
Version 3.5.7 is the latest version of the toolset. Version 4 is still under development and has been for a year. Alpha code is available upon request.
Tools include RtConfig, roe, aoe, rpslcheck for 4.0*. prtraceroute, prpath, CIDRAdvisor, peval, pmatch will come later.
Version 4.0 architecture includes a separation of policy modules and irr query modules. The code has been modified to include compatibility with a variety of servers: RAWhoisD and RIPE server.
How much is complete? RPSL range operators, community, aspath, dictionary are all supported under RPSL implementation today. Still to complete is structured policy specification, range operators applied to ASes, as-sets, route sets, and new regular expression are still to be done.
roe is almost complete. aoe is complete. rtconfig is complete for Cisco. Bay, Gated, and RSd are not done yet.
Features for later versions? Configuration based on inet-rtr, configuration of aggregations, and scripting extensions for tcl, perl, or scheme.
III. RPSL Implementation Experience - Cengiz Alaettinoglu
David and Cengiz have been working on RPSL implementation.
Issues:
1) List valued vs. multi-valued
Problem with spaces for multi-line entries in the db. Proposed: members: AS1, AS2, AS3, ...
to be equal to members: AS1, AS2 members: AS3
2) Dictionary typedef attribute. Propose to simplify the typedef attribute
3) export-comps: <filter> proposed export-comps: to <peering> action <action> filter <filter>
Summary: Cengiz will compile these changes into a new draft RPSL IMPLEMENTATION EXPERIENCE. Before coming a draft standard, incorporating into RPSL.
IV. Distributed Authorization - Curtis Villamizer
ftp://engr.ans.net/pub/slides/ietf/mar-1998/rps-auth-ietf.ps
New requirements placed on the routing policy system:
1) routing prefixes of many organizations
2) overlapping prefixes
3) integrity of data whose authority is spread
4) integrity of data whose storage is distributed
Two drafts - RPS Auth - authentication that we are talking about, and RPS Dist. This talk is to cover the Routing Policy System Security Draft
Problems to address:
1) localizing the impact of accidental misconfiguration
2) reduce the potential of malicious attacks
3) reduce the announcements of unallocated prefixes
Curtis spoke about authentication versus authorization and a variety of operational cases to be accommodated.
Authentication models: mail-from, crypt-pw, pgp-from
Authorization models: many listed.
Curtis spoke about a variety of new objects. For example, a repository object to allow discovery of additional repositories, and delegation objects to allow for other registries handling more specifics.
Summary: The Routing Policy System Security Draft was designed to provide an authentication and an authorization model. Consideration of how data is entered and used and the business and political relationships are reflected in the authorization model. The model is general though very specific operational conditions and procedures have been considered as a sanity check.
Deployment including ongoing support for existing data has been carefully considered.
The database changes are relatively simple, the operational changes are relatively minor. Though simple, these changes provide a sufficient authentication and authorization model to accomplish the goals stated earlier.
V. Multicast Policy Distribution - Ramesh Govindan
"Full Replication in the Distributed Routing Registry"
How do you implement the distributed routing registry? What are the issues there?
Each ISP maintains its objects locally. ISP objects are fully replicated. Three problems exist:
1) Update propagation
2) object dependency consistency
3) authorization and authentication
Replication - flooding technologies exist to flood across a sparse mesh over TCP or Multicast update propagation - like wb
Ramesh talked through loss detection and loss recovery across the multicast fabric.
VI. Providing IRR Consistency - Cengiz Alaettinoglu
Distributed Consistency is different from distributed and auth issue. Problem is demonstrated by same aut-num objects registered in two registries with different policies. Problem exists today, so problem will exist with a more distributed model. Solution: first come first serve. Allow to be registered in first registry, disallow in 2nd.
Summary: Not a replication service; no 2-phase commit. A solution does not hold down local registry. Promotes objects of an ISP->same registry.
VII. BGP Origin Authentication - Randy Bush
This talk will be repeated at IDR Thursday. The problem is that any AS can inject any prefix. 7007 had 7007-BGP->RIP->BGP reinjection for example. The ideal solution is the IRR, but: slow, not distributed, unreliable, not hierarchical yet another iRR is the solution? Seems silly.
Pragmatic solution - DNS is known to be reliable - everything goes to the DNS It is distributed and scales well, it is fast with local servers, it is hierarchical. Encode the address space allocation in the DNS. BGP speakers look up received prefixes. Results are authenticated, failed, unauthenticated. Use DNSSEC to provide authentication.
This is written up in: draft-bates-bgp4-nlri-orig-verif-00.txt
The claim of speed was questioned since in both the IRR and DNS mechanism involve caches, so speed is less of an issue. The question of deployment speed was questioned since the deployment for both solutions will take time. Even though the DNS could be populated, the routers need to implement new code to check.
Additional Comments: (originator: Cengiz Alaettinoglu)
Curtis Villamizar on Thursday, 23 Apr 1998 23:00:10 -0400 said:
There is a substantial error here.
In message <199804230135.SAA06400@cat.isi.edu>, Cengiz Alaettinoglu writes:
Authentication models: mail-from, crypt-pw, pgp-from
These are authentication methods not authentication models. One authentication model was discussed with three methods implemented today. After the meeting it was agreed that pgp-from would be deprecated in favor of pgp-key, where the public key was stored in the maintainer object auth attribute rather than an external key ring.
Authorization models: many listed.
Only one authorization model was discussed. There were a few new database objects, and a few new attributes, and a few changes to attribute semantics.
Curtis spoke about a variety of new objects. For example, a repository object to allow discovery of additional repositories, and delegation objects to allow for other registries handling more specifics.
Cengiz - are you passing on Bill's notes as is or do you agree with the flowing?
I made minor editing of Bill's notes, but I did not change the content.
Providing IRR Consistency - Cengiz Alaettinoglu
Distributed Consistency is different from distributed and auth issue.
Problem is demonstrated by same aut-num objects registered in 2 registries with different policies. Problem exists today, so problem will exist with a more distributed model. Solution: first come first serve. Allow to be registered in first registry, disallow in 2nd.
I thought first come first serve was brought up as a apparent solution that under closer inspection was flawed. [BTW- the issue of aut-num objects registered in 2 registries is covered in rps-auth.
The delegated attribute in the as-block objects determine which one registry an aut-num within a given range should be in. A range can be as small as one AS number but the aut-num can only be entered in one registry. There is no issue of who got there first.]
A delegation can be to multiple registries. There is an example of this in the rps-auth. By first come first served, it was meant that once an object is created in a repository, other registries can not create the same object (with identical key). To create an object, you have to follow the rules in rps-auth. It was not meant that if an object does not exist, and I am not the legitimate person/maintainer/registry, if I am fast enough I can create it.
Summary: Not a replication service; no 2-phase commit. A solution does not hold down local registry. Promotes objects of an ISP->same registry.
I don't follow this. Could this be stated more clearly.
Full Replication in the Distributed Routing Registry
RPS Working Group Agenda
Providing IRR Consistency
RPSL Implementation Experience
RPSL Implementation in RAToolSet
RPSL Transition