Minutes of the RPS session 40th IETF - Thursday, 11/12/97, 9:00am - 11:30am Chairs: Cengiz Alaettinoglu, Daniel Karrenberg (DK58) Minutes: 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. Security of Routing Info Curtis Villamizar 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: - Section must be added regarding security - security considerations not needed as it is not a protocol definition, but this must be mentioned explicitly. - mntner, person and role examples added - inet-tunnel class removed as it is going in a separate document New AS Path Regular Expressions: - perl-like brace repetition syntax {m}, {m,}, {m,n} - -* and -+ like * and + but the repeated pattern must be the *same* Route flap dampening parameters: - penalties per flap, then what to do - examples - defaults 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: - components : route used to form route - subset of more-specific - aggregation boundary - aggregation method : inbound/outbound aggregate - export-comps : some components outside boundary - inject attribute : upon condition - holes You can now create a very powerful route object: - interaction with aut-num policies - filter twice - once based on route object - once based on import/export in aut-num object - usually these filters are the same or compatible in practice - overlapping aggregates - evaluate most specific to least specific - only the aggregates and export-comps are available for next level 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 - current position - working on RPSL parsers, User Documentation, Transition coordination, Transition Software, RIPE Database changes - Phase 2 : Write RIPE-181, Read Both - Expected to move in 1st Quarter 1998 - IRRs would run a mirror in RPSL of their data - must make users aware of RPSL - web-based training, public workshops, 1-2 day course - Phase 3 : Write Both, Read RPSL - Pre-requisites: - solid documentation - user training - see that RPSL db has been running stable on a test-site ( RIPE NCC will set up a test-site, maybe other IRRs as well ? ) - can submit in RIPE-181, but database returns RPSL - there should be a 'flag day' for the transition to Phase3, when all the routing registries agree everyone is ready to go. It is not expected that all registries will transition on the same day, but hopefully close together. - 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 & their attributes: Maintainer, Person, Role, Route & 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 Info ( 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: - Application Document - Transition Document - Specifying the RIPE Database server, and converting documentation to RPSL - Security as just discussed. 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.