[Sidr] Minutes of the SIDR WG meeting @ ietf 71

[Geoff Huston <[e-mail]>]

Thanks to Russ Mundy for these minutes.

   Geoff & Sandy



SIDR - IETF 71
Securing Inter-Domain Routing (SIDR) WG Meeting

10 Mar 2008, 1740 - 1950

CHAIRS:
  Geoff Huston &; Sandy Murphy

NOTE TAKER:
  Russ Mundy

AGENDA:

  1. Administrivia
      Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html
      Blue Sheets
      Agenda Bashing


  2. SIDR and Origin Validation - Geoff Huston

  3. Certificate Policy and CPS drafts -  Steve Kent
        Certificate Policy
          http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-03.txt
        CPS for ISPs
          http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-02.txt
        CPS for Registries
          http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-03.txt

  4. RPKI Architecture Update - Matt Lepinski
        http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-03.txt

  5. Route Originations - Matt Lepinski
        http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-02.txt

  6. Repository Structure  - George Michaelson
        http://www.ietf.org/internet-drafts/draft-huston-sidr-repos-struct-01.txt

  7. ROA Validation  -  George Michaelson
        http://www.ietf.org/internet-drafts/draft-huston-sidr-roa-validation-00.txt

  8. Bogon Origin Attestations - Geoff Huston
        http://www.ietf.org/internet-drafts/draft-huston-sidr-bogons-00.txt



SUMMARY:

  The WG agenda items covered the overall approach being used by the
  WG to address the issues of origin validation and then examined a
  number of specific aspects of routing origination attestations in
  relation to a Resource PKI.

  Following a report to the WG from RPSEC on requirements for BGP
  routing security, it was noted that no clear guidance on the topic
  of AS Path validation was forthcoming. SIDR should undertake a
  solution for AS Path validation. The AD suggested that the charter
  revision should be done by IETF72.

  One general comment at the end of the meeting was that it would be
  useful to have a roadmap for the relationship and anticipated timing
  of completion of the various work items discussed during the
  meeting.  The co-chairs acknowledged that this might be useful, but
  should be discussed further on the WG mailing list.

  

NOTES:

  SIDR and Origin Validation

    Geoff Huston presented a status report on the SIDR Working Group
    activities relating to origination validation in inter-domain
    routing.

    The presentation provided a summary of the reason for creation of
    SIDR and set of requirements for the working group.  The main
    focus of the working group is the specification of a PKI that
    supports validation of origination information contained in the
    routing system, and the manner in which validation tools could be
    incorporated into the routing architecture.
  
    Questions / Comments:

    There was no controversy related to the presentation but the AD
    asked where the information was described.  Geoff acknowledged
    that he needed to write an RFC to document much of what he
    presented in his summary.

    During the presentation, there was also a discussion about the
    SIDR requirements and work being "locked to RPSEC".  The general
    sense of the room was that this should be changed in the SIDR
    charter - no one in the room objected to this change.  Part of
    this discussion of SIDR working group scope was taking on solving
    the problem of path validation.  The sense of the room was that
    SIDR should undertake a solution for path validation.  The AD
    suggested that the charter revision should be done by IETF 72.

    ACTIONS:

    - Chairs to propose a revised charter for the SIDR WG to address
      the topic of measures to support validation of the AS Path.

    - Draft to be proposed to the WG on the overall approach to
      Origination validation. Geoff Huston will work on this draft.

  Certificate Policy and CPS drafts

    Steve Kent presented on three CP and CPS drafts. The most
    significant changes since the previous WG meeting has been with
    the CPS template for RIRs.  The majority of this work focused on
    enhancing the template so that less work will be needed on the
    part of RIRs using the templates.  Steve has worked with APNIC in
    completing their CPS, which they were able to do in two days.  One
    important aspect pointed during the presentation was that a
    business PKI that is separate from the resource PKI will be
    required.

    Questions / Comments:

    During the discussion from the floor, there was a suggestion that
    a complete template be created that could be used by ISPs. This
    was accepted as a good suggestion.

    Another comment was that it would be useful to have a template that
    says the ISP has no liability of any sort.

  RPKI Architecture Update
  
     Matt Lepinski presented on the RPKI architecture. The opening
     request is for everyone to read and comment on the draft.  Matt
     considers the current text is to be inadequate in certain areas,
     and requests inputs with specific, new text.

    Questions / Comments:

    There was some discussion about changing the scope of this
    document so that it would align with the expected charter changes.
    The general sense of the room was to keep the current scope and
    focus on completing the document. The document probably needs some
    clarification regarding intended scope. Additionally, the document
    is intended to provide examples rather than explicit directions so
    some words need to be updated.

    ACTIONS:

    - Draft to be revised to clarify intended scope
      regarding the architecture of the RPKI and reference related
      documents concerning further details of the use of Manifests,
      ROAs, BOAs and the forms of potential use in supporting routing
      activities.
    
  Route Originations
     	
    Matt Lepinski presented on the current ROA specification document
    and the current issue relating to whether to add the capability for
    multiple signatures into a ROA or not. A specification as to how
    multiple signatures could be included in the ROA was presented.

    Questions / Comments:

    There was a significant discussion about the ROA format and number
    of signatures on a ROA. There were generally two (opposing) views
    expressed there were largely the same as have been expressed on
    the mail list. The minute takers' general summary of the issue is:

      Supporters of multiple signatures: SIDR work should not
      constrain or restrict the way in which the routing system and
      resource assignments operate currently or in the future.

      Opponents of multiple signatures: This is an effort to solve a
      problem that is extremely small (or non-existent) which
      introduces significant complexity of the validation
      implementations (and possibly all validations).
 
    During the discussions, some new ideas such as specifying the use
    of multiple signatures on a ROA but defining that only one
    signature will be used initially on a ROA - a request was made for
    Jeffrey Hass write up this idea for the WG.

    There was also a suggestion that if multiple signatures were used,
    they should only be applied when multiple parties were involved.

    Geoff suggested that it might be useful to specify that validation
    of a ROA would not be done over any larger address space than
    contained in the ROA. A ROA cannot be used to validate any object
    that is larger than the span of the address in the ROA. The
    implication of this limitation is that if it is required to sign an
    aggregate address object where the components are drawn from
    distinct validation paths, then multiple signatures in the ROA would
    be necessary.
 
    ACTIONS:

    - Jeffrey Hass to describe an approach to multiple signatures on a
      ROA where the case of multiple signatures is defined, but note
      intended use to be constrained to single signatures.

    - Multiple signatures in a ROA to be taken to the WG mailing list.
   
  Repository Structure
  
    George Michaelson next presented on the Repository Structure
    draft. The draft has been pretty much rewritten since the -00
    draft, in response to a batch of inputs.  The slides provide a
    summary of the changes from the 00 version.
  
    The authors believe that the 01 version incorporates the comments
    they received to date.  They would also like to have further
    review and comments on the draft.
      
    Questions / Comments: 

    During this presentation, a member of the
    working group asked if this was the right time to discuss the
    issues around the use of rsync as defined in the specification.
    There have been discussions about this on the WG list but they
    have not been conclusive.  After some discussion in the meeting,
    Sandy took an action to write a description and summary of the
    rsync related issues and send it to the WG list and AD.  At this
    point, it sounds like the working group members in the room see
    the need to have specific agenda time to discuss these issues at
    the IETF72 SIDR WG meeting.

    ACTIONS:

    - Sandy Murphy to write a description of the issues in the use of
      RSYNC in the RPKI specification, and circulate this to the AD
      and the WG.

  ROA Validation

    George Michaelson presented on ROA Validation.  The list of issues
    in the last slide of the presentation may not be complete but are
    likely the ones that need to be worked on first - comments are
    solicited.

    Questions / Comments:

    Some of the substantive comments that were raised from WG members
    in the room related to operational timeliness and the amount of
    time needed to effect changes to signed originations, e.g., an ISP
    moves all traffic from one link to another (changing origination
    point and issuing a new ROA) but their traffic is not being
    delivered everywhere since some places are validating on the old
    ROA - a 24 hour cycle to get the new information in place is not
    operationally acceptable.  Geoff & Steve both pointed out that
    relying parties can update information more frequently than 24
    hours but there is no way to force people to update information on
    any particular period of time. The generic response to this was to
    pre-provision the necessary security credentials in the RPKI in
    advance of the use of a particular origination arrangement in the
    routing system.

    There was also discussion about approaches that were needed during
    the transition period of particular adoption, when ROAs are being
    issued for some but not all originations. Some ideas are included
    in the draft and summarized in the slides. The working group was
    asked to think about transition and contribute additional ideas.

  Bogon Origin Attestations

    Geoff Huston presented on Bogon Origin Attestations. The concept
    motivating the BOA idea is to provide a mechanism for legitimate
    holders of resources to make an authenticatable statement the
    certain resources should not be appearing in the routing system.
    In general, BOAs are modelled after ROAs but if a relying party
    encounters both a ROA and a BOA for a given space, the ROA will
    always override a BOA.

 
_______________________________________________
Sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr