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:
Technical Summary
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.
Document Quality
The document is clearly written and well organized.
Personnel
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?
No.
(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?
No.
(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.
N/A
(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.
N/A