I've reviewed this document and have some comments.
First, an apology, because although I'm an active participant in the SIDR WG,
I'm pretty sure I missed the WGLC on this, so these comments shouldn't
necessarily be construed as me taking my argument to ietf@ietf because I felt
that SIDR ignored my concerns.
Now, my actual comments:
Maybe I'm hypersensitive to such in light of recent accusations of national
actors subverting supposedly secure infrastructure to behave badly, but I find
it odd that this threats document doesn't discuss the interaction between a
national actor and the machinery provided by draft-ietf-sidr-ltamgmt. i.e. a
national actor imposes upon SPs that operate inside their borders to use their
own Local (and compromised) Trust Anchor to subvert the protections provided by
RPKI. While this is primarily a concern for origin validation, I view it as
distinct from the existing discussion of attacks on a CA covered in 4.5, and
there is no equivalent Origin Validation threats document. It may be that the
right path is to augment the discussion of this issue in the LTA management
draft, and simply reference it from this draft, but I don't think that this is
discussed suitably in the security considerations of either draft.
Section 4.2 is missing any discussion regarding manipulation of other route
attributes that may be used to affect a BGP route's selection, such as MED,
Local Pref. It's covered in section 5, but since this occurred to me whilst
reading section 4.2, perhaps some mention in 4.2 would be useful, I don't know.
That said, I also think that the discussion of this topic at the end of session
5 is inadequate for a document in IETF LC. The SIDR WG made a conscious
decision to secure *only* the AS_Path attribute, and leave other attributes
insecure, but there is no summary of the underlying rationale supporting this
choice. Pointing to a WG charter as the sole explanation, and noting that this
document should be changed if the charter is updated is unacceptable, as it
provides no context to a reader that was not privy to the discussion leading to
that charter/scope decision. It also makes reference to something fairly
ephemeral (a WG and charter) in a permanent document. Fine for a draft in WG
discussion to have that sort of placeholder, but not anymore. There is a brief
(and IMO incomplete) discussion of this matter to be found in section 2.3 of
draft-sriram-bgpsec-design-choices that could be referenced, but since that
document's future is unclear, some standalone discussion within th!
is document might be more appropriate. At a minimum, a threats document should
discuss why these threats are not considered high enough risk to justify the
added complexity of securing them using the RPKI.
Thanks,
Wes George
-----Original Message-----
From: sidr-bounces(_at_)ietf(_dot_)org
[mailto:sidr-bounces(_at_)ietf(_dot_)org] On Behalf Of
The IESG
Sent: Monday, September 09, 2013 6:26 PM
To: IETF-Announce
Cc: sidr(_at_)ietf(_dot_)org
Subject: [sidr] Last Call: <draft-ietf-sidr-bgpsec-threats-06.txt>
(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'
<draft-ietf-sidr-bgpsec-threats-06.txt> 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(_at_)ietf(_dot_)org mailing lists by 2013-09-23. Exceptionally, comments
may
be
sent to iesg(_at_)ietf(_dot_)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.
Anything below this line has been added by my company's mail server, I have no
control over it.
-----------------
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.