IRR BOF February 11, 2002 Larry Blunk, Moderator

1
IRR BOFFebruary 11, 2002Larry Blunk, Moderator

2
Agenda

• Introductions
• IRRd Update
• RADB Update
• RPSL Issues (RPSLng/Authorization)
• New RADB Billing System/Cleanup - Chris Frazier
• Merit summation - Jeff Ogden
• APNIC Update - Terry Manderson
• RIPE Update - Joao Damas
• ARIN Update - Ray Plzak
• JPNIC Update - Tomoya Yoshida

3
Introductions - Merit RADB staff

• Merit staff responsible for RADB project
• Jeff Ogden - Director for High Performance
  Networking
• Deb Evans - RADB project manager
• Larry Blunk - Lead Engineer
• Dale Fay - Engineer
• Chris Frazier - Engineer
• Aubin Chang - NOC Engineer
• Tim Howell - NOC Team Leader

4
IRRd Update

• Reviewed state of IRRd software in June 2001
• Initial goals
• Fix memory leaks
• Other significant bugs (zombie processes)
• Portability enhancements
• Linux, FreeBSD, Solaris platforms targeted
• Code clean-up
• Compiler warnings
• Removed 30 include/source files (from MRTd)
• RFC 2622 RPSL compliance
• Mandatory attributes and parsing correctness

5
IRRd Update...

• Initial goals cont'd...
• Documentation updates/improvements
• Support for GnuPG
• Performance improvements
• Threading support fixed on Linux/FreeBSD
• Addressed several locking issues which affected
  performance
• IRRd 2.1 released last September
• Several bugfixes since (now at 2.1.4)
• Available at www.irrd.net

6
RADB Status

• RPSL compliance (fixed)
• Route objects with 'withdrawn' attribute
• Aut-num objects lacking 'as-name' atttribute
• Person objects missing 'nic-hdl' attribute
• Objects without a 'mnt-by' attribute
• Bogus AS numbers (0 or gt65536) in route objects
• Orphaned objects
• Maintainers deleted, but objects remain in the
  database with mnt-by referring to maintainer
• Most of these objects were found to have invalid
  data and removed

7
RADB Status...

• Stale information
• Route objects with 'member-of' referencing old
  RS-COMM-NSFNET route-set. (about 15,000)
• mnt-nfy/upd-to/notify attributes specifying old
  ASxxxx_at_ra.net aliases
• Inet-rtr objects referring to non-existent
  routers
• Route policy inconsistencies
• Route objects with prefixes which have been
  aggregated, announced by another AS, unrouted
• Unregistered prefixes
• Aut-num objects with inconsistent import/export
  policy (compared with AS Path information)

8
RADB Consistency

• 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)

9
RADB Top 10 Maintainers

• Detail Report Route Valid
  Valid Other Other Unann
• Count Maintainer objs Exact Aggr
  Exact Aggr Prefix
• ----- --------------- ----- ----- -----
  ----- ----- -----
• 3697 MAINT-AS701 3695 891 518
  693 660 933
• 3644 INAP-MAINT-RADB 3615 1403 379
  931 715 187
• 2943 MAINT-AS174 2882 79 545
  543 650 1065
• 2680 MAINT-AS3549 2609 691 378
  547 771 222
• 2669 MAINT-AS2764 2624 1244 393
  478 253 256
• 2578 BBNPLANET 2568 642 136
  724 586 480
• 1770 MAINT-AS7474 1729 597 194
  445 236 257
• 1688 MAINT-AS1239 1685 65 547
  438 315 320
• 1416 MAINT-AS852 1412 562 3
  673 138 36
• 1383 MAINT-AS568 1378 263 396
  389 91 239
• ...
• Total 75530 26465 11907
  15245 11780 10133

10
RADB 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 summary with
  more detailed reports on Web
• Allow maintainers to easily correct discrepancies
• RIPE NCC has similar project called Route
  Registry Consistency Check. See www.ripe.net/rrcc

11
RPSLng

• IPv6/Multicast not defined in RFC2622
• RPSLng task force formed to address issue
• Mailing list - rpslng_at_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
• Avoids adding new class or attribute names

12
RPSLng cont'd...

• Syntax modified to define an 'AFI' type specifier
• Allows specification of new protocols in future
• Optional for IPv4 and IPv6 addresses since their
  syntax can uniquely identify them

13
RPSLng Ipv6 examples

• Examples showing 'afi' use with IPv4/IPv6route
  afi ipv4 198.108.0.0/16origin AS237route afi
  ipv6 3ffeffff/28origin AS1
• NOTE since afi specifier is optional for
  IPv4/IPv6, the above can be expressed asroute
  3ffeffff/28origin AS1

14
RPSLng aut-num policy

• Aut-num class specifies protocol in 'import' and
  'export' attributes
• Current specification cannot distinguish between
  IPv4/IPv6 or unicast/multicast
• RPSL dictionary expanded to include 'afi' and
  'safi' protocol attribute
• Similar to RFC2858 multiprotocol extensions to
  BGP
• Exampleaut-num AS237import protocol BGP4
  afi(IPv6), safi(unicast) from AS1 afi ipv6
  3ffeffff1 at afi ipv6 3ffeffff2 accept
  AS1RS-PROVIDER

15
RPSLng RIPE meeting discussion

• At RIPE 41 meeting, there was significant concern
  about extending existing class and attribute
  syntax
• There was consensus that an alternative proposal
  should be drafted with new class/attribute types
• e.g. Route6 3ffeffff/28
• Need to also consider interaction with other
  attributes
• e.g. Should there be 'mnt-6routes' attribute
• Additionally, will need to address command
  support in RPSL database implementations
• IRRd and RIPE can perform inverse queries to look
  up route objects based on origin AS.

16
RPSL Authentication security

• RPSL Authentication currently has several 'weak'
  mechanisms
• Auth NONE has obvious vulnerabilities
• MAIL-FROM is very weak due to ease of mail
  spoofing
• Confirmation messages provides some assurance
• But many maintainers do not update their list of
  MAIL-FROM auth's as people leave their org.
• CRYPT-PW suffers from short password support (8
  characters) and dictionary attack vulnerability
• Email submission of RPSL objects may also result
  in exposure of cleartext passwords

17
RPSL Authentication - RIPE41

• RIPE 41 meeting also spent some time on this
  issue
• RIPE NCC proposed the following
• End auth NONE support ASAP
• Gradual phase out of auth MAIL-FROM proposed
• Proposed a new MD5 hash auth type as alternative
  to CRYPT-PW
• Would allow secret strings much longer than 8
  characters
• However, still subject to cracking unless 'good'
  passwords enforced

18
RPSL Authentication - Merit

• Alternative to ending MAIL-FROM support would be
  to require confirmation of MAIL-FROM objects
• Mechanism proposed on RIPE db-wg list
• Would use a generated cookie similar to majordomo
  cookie-based auth
• Generated cookie means that no state is required
• Proposed cookie algorithm is MD5 hash of secret
  MAIL-FROM objects timestamp
• Reply message would contain cookie, timestamp and
  original objects
• Timestamp allows for possible replay detection

19
RPSL Authentication - Merit

• Update CRYPT-PW with a more secure hash function
  (proposing OpenBSD bcrypt)
• Improve existing crypt calculator to check
  password 'goodness'
• Investigate possible ways to hide hashed password
• Look into supporting SSL-based forms for making
  updates (so that cleartext password is not
  exposed)