Internet2 Routing Working Group Merit Route Registry Update July 30, 2002 Larry Blunk

1. Internet2 Routing Working GroupMerit Route Registry UpdateJuly 30, 2002Larry Blunk

2. Agenda • Introductions • I2RR Status • IRRd Update • RADB Status • RPSL Issues (RPSLng/Authorization) • Web interface for Registry • Timelines • Web interface demo • Questions

3. Introductions - Merit staff • Merit route registry staff • Deb Evans -project manager • Engineers • Larry Blunk - lead engineer • Jake Khuon - lead architect • Not present - Dale Fay, Chris Frazier • University of Michigan NOC provides 24x7 frontline support

4. I2RR Status • I2RR introduced in September 2000 • Web page at www.radb.net/i2rr • Has not been actively embraced by Internet2 community • Merit staff departures in 2000/2001 led to lack of responsiveness • Has restaffed project over the last 12 months • Merit would like to get clarity regarding the role of the I2RR in the Internet2 community. Merit believes the service is important, but needs to understand Internet2's commitment to using it going forward

5. IRRd Update • Reviewed state of code in June 2001 • Initial goals • Fix memory leaks and other significant bugs (zombie processes) • Portability enhancements • Targeted Linux and FreeBSD in addition to Solaris • Code clean-up (compiler warnings, etc.) • RFC 2622 RPSL compliance • Mandatory attributes and parsing correctness

6. IRRd Update... • Initial goals cont'd... • Documentation updates • Support for GnuPG • Performance issues • IRRd 2.1 released in September 2001 • Several releases since (now at 2.1.4) • Next release to support inverse lookups on maintainer names and performance improvements • Available at www.irrd.net

7. RADB Status • RPSL compliance has been addressed • Objects missing mandatory attributes • Attributes with invalid values • Orphaned objects cleaned up • Maintainers deleted, but objects remain in the database with mnt-by referring to maintainer • Approximately 1600 paid maintainers • Around 3000 maintainers at start of year • Source of stale data (defunct/acquired companies) • New maintainers continue to be added daily

8. RADB Consistency • RADB consistency checks currently an ongoing project • Route objects with prefixes which have been aggregated, announced by another AS, unrouted • Announced prefixes not registered in RADB • Aut-num objects with import/export policy which does not match observed policy in annouced prefixes (for example, AS PATH)

9. RADB Consistency Analysis • Recent analysis of route object consistency with global routing tables • 75530 route objects - compare prefix/originAS • 50.8% exact or less specific prefix/match AS • 35.8% exact or less specific prefix/different AS • 13.4% no match (exact or less specific prefix)

10. Registry Maintainer reports • Developing per maintainer reports • Details number and type of objects • Consistency with observed routing policy • Route object prefix/originAS correctness • Aut-num policy compared with AS Path info • Provide an optional monthly email report as well as web based reports • Allow maintainers to easily correct discrepancies • Working with RIPC NCC to coordinate development efforts on consistency checking tools

11. RPSLng • Ipv6/Multicast support not defined in RFC2622 • RPSLng task force formed to address issue • Mailing list - rpslng@ripe.net • Archive - www.ripe.net/ripe/mail-archives/rpslng • Internet Draft submitted by Florent Parent in January (draft-parent-multiprotocol-rpsl-00.txt) • Draft addresses the following classes: route, route-set, peering-set, aut-num, inet-rtr, filter-set • Attempted to extend the syntax of existing attributes rather than creating new attribute names

12. RPSLng ... • There was considerable concern that simply extending attributes may break existing tools • Informal meeting held at March 2002 IETF • Consensus reached on RPSLng attributes • Will create new attribute names to avoid breaking tools

13. RPSLng examples • Example of new route object for IPv6mp-route: afi ipv6 3ffe:ffff::/28origin: AS1 • Example of aut-num objectaut-num: AS2mp-import: afi ipv6.unicast from AS1 accept {3FFE:FFFF::/35};

14. RPSL Authentication security • PGP is currently strongest mechanism • MAIL-FROM is very weak due to ease of mail spoofing • Confirmation messages provides some assurance • CRYPT-PW suffers from short password support (8 characters) and dictionary attack vulnerability • Email submission of RPSL objects protected by CRYPT-PW requires sending cleartext password

15. RPSL Authentication updates • RIPE 41 meeting addressed current weaknesses in RPSL authentication • RIPE to phase out support of MAIL-FROM • New password-based auth mechanism based on FreeBSD's MD5-CRYPT • Allows passwords much longer than 8 characters and more dictionary attack resistent • Merit to move to Web-based form with SSL encryption and phase-out of MAIL-FROM • Considering hiding password hashes to prevent dictionary attacks • Will continue to support PGP for mail based updates

16. Registry Web interface • Augment existing mail update process with a web based interface • Provides a more intuitive interface (particularly for new users unfamiliar with email based submissions) • Security improvement for maintainers with password based authentication (SSL encryption instead of cleartext in email)

17. Timelines • Web interface to be completed by August 31 • RPSLng to be discussed at RIPE 43 meeting in early September and should be finalized by end of September • Merit targeting RPSLng implementation by the end of October • Consistency checking tools being coordinated with RIPE. Ongoing effort with initial maintainer reports to be available in November