As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
This is an Informational document. It provides a threat model for the BGP path security problem that SIDR has been chartered to address.
is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Yes, it is specified correctly in the title.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. The approval announcement contains the following sections:
SIDR was re-chartered to develop solutions for a specific BGP security problem, i.e., how to enable an AS to verify that the AS_Path represented in BGP route is the same as the path through which the NLRI travelled. This document examines threats and attacks on BGP relative to this goal. It begins with a brief characterization of threats (motivated, capable adversaries) and then describes classes of attacks. The attack characterization focuses on elements of the routing system, including the RPKI and likely approaches to path security. (The current SIDR charter calls for building upon the RPKI, hence its inclusion in this document.) The document ends with a brief discussion of residual vulnerabilities, e.g. routing security concerns that are outside the scope of SIDR’s charter.
Working Group Summary
SIDR was initially chartered to develop standards to enable network operators to verify route origin assertions propagated via BGP. It published a set of RFCs (6480-93) that addressed this initial problem statement. Initial versions of the threat document and the requirements document were published at about the same time (June 2011). A threat document is nominally a precursor for a requirements document, but there was an informal understanding of the threats to be addressed, which permitted parallel development of these documents, by different sets of authors.
The -01 version of the threat document was published in February 2012, in response to comments from a variety of WG members. The -02 version was published later that month, to incorporate SIDR RPKI RFC references. The -03 version included a number of significant revisions made in response to on-list discussions during the summer of 2012. A minor wording change yielded the -04 version.
The document is clearly written and well organized.
Alexey Melnikov is the Document Shepherd, and Stewart Bryant is the Responsible Area Director.
(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I have read the document to check for consistency, correct information in the IANA considerations section, etc. It is ready for IESG review.
(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
There has been considerable discussion of the first 3 versions of the document on the list. Initially comments were received from several sources, but the latter comments emanated from only 2-3 individuals. These individuals are still not satisfied that "route leaks" are discussed only as a residual vulnerability. Route leaks are clearly outside the scope of the SIDR charter. Moreover, there is no approved document that even defines the term in a fashion that can be distinguished from BGP local policy.
Editors incorporated a couple of minor wording changes to better address these comment as instructed by WG chairs.
Chairs declared consensus on two outstanding issues in <http://www.ietf.org/mail-archive/web/sidr/current/msg06014.html> and <http://www.ietf.org/mail-archive/web/sidr/current/msg06013.html>, declaring that no further changes are needed to the document.
(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
There is no need for a broader review.
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
I anticipate that there may be comments during IETF LC from the individuals who have expressed unhappiness that the document does not address route leaks to their satisfaction.
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
I contacted the authors and they confirmed that there are no relevant IPR disclosures, to the best of their knowledge.
(8) Has an IPR disclosure been filed that references this document?
Not to the best of my knowledge, based on a check of the IETF IPR disclosure database.
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
As noted above, I believe that most SIDR WG members that this document is ready, and has been some for a while. But, 2-3 very vocal individuals have continued to comment.
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
I am aware of no threatened appeals based on the processes we have followed.
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
ID-nits reports one error about a missing reference:
== Missing Reference: 'TCPMD5' is mentioned on line 128, but not defined
This is a reference in a quoted text. The reference was removed
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
None apply here.
(13) Have all references within this document been identified as either normative or informative?
Yes. There are only informative references.
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
(15) Are there downward normative references (see RFC 3967)?
There are no down references.
(16) Will publication of this document change the status of any existing RFCs?
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
No IANA actions are required.
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.