Re: [sidr] Last Call: <draft-ietf-sidr-bgpsec-threats-06.txt> (Threat Model for BGP Path Security) to Informational RFC

["George, Wes" <[e-mail]>]

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 this 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> The IESG
> Sent: Monday, September 09, 2013 6:26 PM
> To: IETF-Announce
> Cc: [e-mail]
> 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
> [e-mail] mailing lists by 2013-09-23. Exceptionally, comments may
> be
> sent to [e-mail] 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.