Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-09

[Ballot comment]

Thanks for the discussion. I've made my previous discuss
point a comment that you can handle as you choose. I do
still think that editing the draft to reduce the number of
references to the charter (and adding a URL for the
version you mean if you keep some) would be a fine
improvement.

-- old discuss

I'm not sure that arguing that some residual threat ought
not be addressed because its not defined in an RFC or
because of the current charter is really ok. Shouldn't the
underlying technical reasons be what's presented in this
document?

-- old comments

- section 3: nations might want to censor (or get others
to do that on their behalf)

- section 4, intro: shouldn't we now also consider passive
wiretapping, at least to the extent that visible BGP
traffic might assist in setting that up more efficiently?
While that might not translate into a requirement for
confidentiality, I think it may be worth considering as
part of the attack.

[Ballot discuss]


I'm not sure that arguing that some residual threat ought
not be addressed because its not defined in an RFC or
because of the current charter is really ok. Shouldn't the
underlying technical reasons be what's presented in this
document?

[Ballot comment]


- section 3: nations might want to censor (or get others
to do that on their behalf)

- section 4, intro: shouldn't we now also consider passive
wiretapping, at least to the extent that visible BGP
traffic might assist in setting that up more efficiently?
While that might not translate into a requirement for
confidentiality, I think it may be worth considering as
part of the attack.

[Ballot comment]
Stylistically: The "* are considered a threat" phrases seem singsongy and unnecessary.  The use of the verb "to effect" seems antiquated and, well, affected.

[Ballot comment]
The distinctions in the threat characterized seems somewhat arbitrary, and appear to have  conflated motivation with methodology. e.g. hacker crimnal isp nation-state and so on seem somewhat arbirary categories, nation states might easily for example employ the methodologoies of the other(s) and vice-versa.

[Ballot comment]
I support the publication of this document and I only have two quick points...

1. I agree with Barry's DISCUSS point on providing a definition of PATHSEC in the document rather than referencing the WG charter.

2. It may be worthwhile to mention in section 3 that "inaccurate" is a subjective term when discussing network operators' views of a BGP Update.  Given the flexibility noted in section 4 about local policy, it is difficult to externally judge whether the result of a network operator's action is inaccurate or simply a change in local policy.

[Ballot discuss]
This should be easy:
It seems to me that...
1. PATHSEC is a term in this document that needs a clear, concise definition.
2. The definition at the beginning of the Introduction is vague, and is, in any case, based on the SIDR WG charter.
3. I don't think it's wise to use charters as references for definitions.  Charters are mutable, and charters don't have proper community consensus. They were never intended to be cited in this way.

How hard would it really be to have a paragraph in the document, perhaps in the Introduction, that properly, concisely, and clearly defines PATHSEC?

[Ballot comment]
-- Section 3 --
"Hacker" isn't defined, and I think there are many senses that different people have about just what a hacker is.  The other threats aren't defined either, of course, but I don't think there's really a question of what a network operator is, what a criminal is, what a nation is, and so on.

As the whole purpose of this document is to discuss threats and attacks, I suggest that it's important to define what a hacker is, at least to the extent that it's clear what distinguishes a hacker from, say, a criminal.  Is a hacker a type of criminal?  Are *some* hackers criminals?  Are there hackers who are not criminals?  You see....

(This isn't a DISCUSS point, because I think we have enough agreement on the concept of a hacker that I shouldn't block the document on this issue.  Also, the discussion of the attacks don't actually seem to depend on the discussion of the types of threats.)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sidr-bgpsec-threats-06, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Threat Model for BGP Path Security) to Informational RFC


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Threat Model for BGP Path Security'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a threat model for the context in which
  (E)BGP path security mechanisms will be developed.  The threat model
  includes an analysis of the RPKI, and focuses on the ability of an AS
  to verify the authenticity of the AS path info received in a BGP
  update.  We use the term PATHSEC to refer to any BGP path security
  technology that makes use of the RPKI.  PATHSEC will secure BGP
  [RFC4271], consistent with the inter-AS security focus of the RPKI
  [RFC6480].

  The document characterizes classes of potential adversaries that are
  considered to be threats, and examines classes of attacks that might
  be launched against PATHSEC.  It does not revisit attacks against
  unprotected BGP, as that topic has already been addressed in
  [RFC4271].  It concludes with brief discussion of residual
  vulnerabilities.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ballot/


No IPR declarations have been submitted directly on this I-D.

(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
and
,
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*