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
([email protected]) as his successor.  There were no objections so Carol
Orange is the new co-chair of the RPS WG.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.