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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
