Internet Architecture Board


IAB Minutes 2009-06-03

Home»Documents»Minutes»Minutes 2009»IAB Minutes 2009-06-03

IAB Teleconference


1. Roll-call, agenda-bash, approval of minutes, administrivia

1.1. Agenda

1.2. Attendance

  Marcelo Bagnulo
  Gonzalo Camarillo
  Stuart Cheshire
  Aaron Falk (IRTF Chair)
  Vijay Gill

* Russ Housley (IETF Chair)

  John Klensin
  Olaf Kolkman (IAB Chair)
  Gregory Lebovitz
  Andy Malis
  Danny McPherson
  David Oran
  Jon Peterson
  Dow Street (IAB Executive Director)
  Dave Thaler

* Randy Bush

  Lars Eggert (IESG Liaison to the IAB)
  Sandy Ginoza (RFC Editor Liaison)
  Lynn St. Amour (ISOC Liaison)

Note 1: Russ joined the call midway through the discussion. Note 2: Randy participated in the techchat discussion but not the business topics that followed.

1.3. Administrivia

Several business items were added to the meeting agenda.

1.4. Meeting Minutes

No meeting minutes were reviewed during this call.

2. Techchat on Routing Security

The IAB invited Randy Bush to present an overview of the SIDR RPKI work, and the larger topic of Inter-domain routing security. This topic is an ongoing work area of the IAB. Danny introduced the talk, and noted that operational and deployment concerns were of primary interest. Randy then walked through a series of slides that summarized the use of ROAs, publication points, and cert delegation.

Dave Thaler asked if there was any relationship between the delegation of ROAs and the keys for the DNS reverse tree. Randy explained that although there is no direct relationship, an administrative decision could result in a common organizational signing hierarchy. In both cases, you would be following the hierarchical allocation of address space. The current assumption is that administrative procedures would drive cert issuance, just like DNS delegation.

Randy then described a set of mechanisms for achieving a consistent version of the RPKI, namely the Rcynic gatherer protocol and the accompanying publication protocol. There is a separate business key that is used to sign business transactions between ISPs and RIRs. Danny asked if this would be used only for BGP end sites, or if it would also replace SWIPs. Randy responded that it could replace SWIPs, but he thought it unlikely that an ISP would issue a cert for small sites not speaking BGP. However, he then added that one might do this if the structure becomes the driving operational force rather than the administrative relationship. He then walked though additional material covering the expected scaling properties of the publication points and the types of exchanges between devices (e.g., signing module, PKI engine) located at an exchange point.

Dave Thaler asked if the signing module was a piece of hardware, and whether the signing key was in fact not as secure as the RPKI. Randy acknowledged that this was the case, and noted that it had been worked out with Russ and Steve Bellovin. Randy then described the remaining protocol pieces, using examples from the prototype code that has been developed.

In closing out the session, the group considered three potentially contentious elements. First, there is a long history of debate as to whether ROAs alone really solve the routing security problem, or if path validation is also needed. As it currently stands, most have now agreed that ROAs are an important first step, even if perhaps not a complete solution. As such, most of the present work focuses on ROAs.

The second area of debate concerns whether BOAs, or BOGON attestations, are needed to describe space that should not be announced by anyone. It was Randy’s impression there is a consensus forming that BOAs will not be necessary to achieve the desired behavior, but the debate is not yet closed.

The third question involves the nature of the trust anchors for the RPKI, specifically, whether the system would operate with a single authoritative root or multiple trust anchors. This particular question has been discussed within the IAB previously, but the Board has not yet established a position on the matter. Randy laid out the technical advantages of a single root approach, but acknowledged the administrative, political, and operational concerns of a single root. This led to a lively debate within the IAB as to the merits and problems of the two strategies. There was general agreement that the base RPKI mechanisms should be designed so as to allow, but not require, single root operation. The IAB will continue to coordinate with various parties on this matter, and will decide at some future point whether to take a position on single vs. multiple roots.

3. NTIA NOI response

Danny summarized the latest draft, and stated that he intends to re-spin the document to clarify the roles of the IAB and IETF. He will distribute a new version later today. John and Olaf will assist with finalizing the text after Danny’s next revision is complete.

Editor’s note (added 30 July 2009): The correspondence is now available here:

4. RFC editor, RSE Description, ISE Description

Olaf pointed members to the latest, synchronized versions of the RFC Editor Model, RSE Description, and ISE Description. He then asked for concurrence that these were ready to publish to the community. Russ and Dave Thaler indicated they thought that they were ready. John said they looked ok based on the diffs, and he agreed to read them in detail immediately after the meeting. Barring new objections, Olaf will post these to the various distribution channels later today.

5. MPLS-TP / Uncoordinated Protocol Development Considered Harmful

There was a short discussion about the latest version of the harmful draft. Russ and Olaf verified that the draft should use RFC 5378 copyright markings. The Board will work with the document authors to review and submit a -00 draft to the repository by the end of the week.

6. IAB Liaison to NOMCOM

Jon Peterson agreed to act as IAB liaison to the upcoming NOMCOM. Danny, Olaf, and Dave Oran took an action to update the “advice to NOMCOM liaisons” section of the IAB internal wiki. The wiki also contains an “IAB job description” which is used by the NOMCOM when identifying and selecting candidates. Olaf asked all Board members to review this description so as to ensure it accurately describes the role.