Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt

From: [email-masked]
Date: Tue, 08 Oct 2013 13:41:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : Threat Model for BGP Path Security
	Author(s)       : Stephen Kent
                          Andrew Chi
	Filename        : draft-ietf-sidr-bgpsec-threats-07.txt
	Pages           : 19
	Date            : 2013-10-08

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-threats-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "George, Wes" <[email-masked]>
Date: Wed, 9 Oct 2013 08:48:49 -0400

This update does not address any of my comments from my review (message sent on 9/12).

Thanks,

Wes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, October 08, 2013 4:41 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt
>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

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.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 09 Oct 2013 11:13:11 -0400

Wes,

Sorry. I was on vacation when your message was sent, and I did not see 
it when I processed all
of the messages upon return, two weeks later. I did locate it in the 
archive today, after
seeing your message. I'll treat your comments as IETF last call comments 
since, as you note,
they were posted long after WGLC.

Your comments were:

    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.

The increased sensitivity to nation-level threats is understandable.The 
threats doc lists nations as a category of adversary in Section 3; we 
have not ignored them. (Can you name any other IETF threat analysis that 
has done so?) The doc does not discuss attacks by nations against LTAM. 
The RPKI, as specified in RFCs 6480-91, is addressed for completeness, 
and because the SIDR charter mandates use of the RPKI. LTAM is still an 
I-D; it is not part of the RPKI standards. As such, I don't consider it 
to be in scope for this doc.

More to the point, as lead author of the LTAM doc, I anticipate reducing 
its scope in a way that
may remove the concern you raised. However, our new I-D, "Suspenders" 
may raise similar
concerns. I think it appropriate to discuss them if and when the WG 
elects to adopt that doc
as a work item.

    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.

As you noted, Section 5 discusses other attributes that are not 
considered in this doc, and explains
why. Unless Stewart directs us to add a forward pointer in 4.2, I don't 
plan to do so.

    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.

No one (other than you) suggested that we include a discussion of the 
history of the charter/scope discussion here. I do not recall seeing 
such a discussion in any other threat analysis doc. I don't
plan to add such a discussion here.

    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.

The latest version (-07) of the threats document added a paraphrase of 
the relevant charter text to address the concern about referencing a 
charter, an issue raised by David Black in his GENART review.

    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.

A threat analysis, in principle, identifies adversaries, their 
motivations for carrying out classes of attacks, and their capabilities 
to do so. It need not establish requirements for acceptable designs, or 
propose countermeasures to address classes of attacks. In this doc we 
went beyond those essential threat analysis elements, because there was 
no RPKI threat doc (and because the charter calls for use of the RPKI as 
a basis for BGPSEC). A requirements doc is a place where one defines 
what needs to be done by a solution, to address the threats previously 
described.

Steve

---

From: "George, Wes" <[email-masked]>
Date: Wed, 9 Oct 2013 16:29:39 -0400

In order to make this thread a bit more readable, I've added [Wes] to my original comments if I kept them, [SK] to yours, and my new replies are [WEG]

From: Stephen Kent [mailto:[email-masked]]

[SK]The increased sensitivity to nation-level threats is understandable.The threats doc lists nations as a category of adversary in Section 3; we have not ignored them. (Can you name any other IETF threat analysis that has done so?)  The doc does not discuss attacks by nations against LTAM. The RPKI, as specified in RFCs 6480-91, is addressed for completeness, and because the SIDR charter mandates use of the RPKI. LTAM is still an I-D; it is not part of the RPKI standards. As such, I don't consider it to be in scope for this doc.

More to the point, as lead author of the LTAM doc, I anticipate reducing its scope in a way that
may remove the concern you raised. However, our new I-D, "Suspenders" may raise similar
concerns. I think it appropriate to discuss them if and when the WG elects to adopt that doc
as a work item.
[WEG] That's a reasonable distinction (discuss only the standards not drafts) and an acceptable way forward.
[Wes]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.
[SK]No one (other than you) suggested that we include a discussion of the history of the charter/scope discussion here. I do not recall seeing such a discussion in any other threat analysis doc. I don't plan to add such a discussion here.

[WEG] I think I was unclear in the way that I raised the concern, and your response (below) helped me see that, so I'll try to clarify. I don't care whether it's a charter/scope issue, and I'm not asking for the summary for that reason. I care about it from the perspective of its relative risk as a threat, and I made reference to the scope/WG/charter/design discussion because I thought that would inform the discussion of the level of risk (i.e. we decided that the risk was not high enough to justify changes to the design to secure additional attributes).

[Wes]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.
[SK]The latest version (-07) of the threats document added a paraphrase of the relevant charter text to address the concern about referencing a charter, an issue raised by David Black in his GENART review.
[WEG] I've seen the addition. It's not adequate to address my concern, because the text in section 5 was not changed at all to remove the reference to charter and "changes to this document at a later time" for both route leaks and secondary attributes.

[Wes]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.
[SK]A threat analysis, in principle, identifies adversaries, their motivations for carrying out classes of attacks, and their capabilities to do so. It need not establish requirements for acceptable designs, or propose countermeasures to address classes of attacks. In this doc we went beyond those essential threat analysis elements, because there was no RPKI threat doc (and because the charter calls for use of the RPKI as a basis for BGPSEC). A requirements doc is a place where one defines what needs to be done by a solution, to address the threats previously described.

[WEG] I'm no connoisseur of threat analyses, so I don't have a large basis of comparison, but I do think that a threats document should not identify a residual threat and then hand-wave it away as "out of scope" instead of explaining the relative risk that it might be exploited. It might even perhaps draw the conclusion that the risk is negligible, but based on your explanation, WG charter and scope shouldn't figure into the discussion.

Worse yet, as this section is currently written, it's circular logic: pathsec doesn't protect non-AS_Path attributes, so there's a risk of those attributes being manipulated without pathsec detecting it, but that's ok because pathsec isn't required to protect against those things. Why isn't pathsec required to protect against those things? Because the charter says it isn't. Why does the charter say that? Because...reasons?

>From a threat analysis perspective, either the ability to manipulate unprotected attributes is a threat (a capability for an adversary to carry out an attack) to BGP Path security, or it's not. I believe the fact that you/the WG included it in the discussion means that you/the WG believe that it's a threat. I could infer based on the fact that SIDR chose not to design protections against that exploit that it's a real threat but very low risk, or extremely difficult to exploit, or whatever, but the document doesn't currently say anything about the relative level of risk for the threat being identified. You're right in that the design/requirements decisions that SIDR WG made about whether to address that threat are mostly irrelevant, but the fact that you discuss it in terms of design scope makes that confusing if one is to evaluate this text as purely a threats analysis. It goes back to a recurring issue that has happened with the order of these documents, where we're writing a threats doc and a requirements doc based on an existing design rather than the other around, and are tailoring these documents based on the current design to the exclusion of things deemed out of scope instead of documenting everything and then deciding some of the specific scope items in the requirements/design phase.

Hopefully this clarifies my concern

Wes

________________________________
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.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Oct 2013 11:33:22 -0400

Wes,

I had to extract you reply and paste it into Word to read, because the 
lines you wrote
were not properly wrapped by my e-mail reader. As a result, my reply 
adopts a slightly different
format.

OK, we agree that LTAM is out of scope for now.

Your later comments are included below, along with my responses.:

*/[WEG] /*I think I was unclear in the way that I raised the concern, 
and your response (below) helped me see that, so I'll try to clarify. I 
don't care whether it's a charter/scope issue, and I'm not asking for 
the summary for that reason. I care about it from the perspective of its 
relative risk as a threat, and I made reference to the 
scope/WG/charter/design discussion because I thought that would inform 
the discussion of the level of risk (i.e. we decided that the risk was 
not high enough to justify changes to the design to secure additional 
attributes).

I better understand your comment. Your concern appears to be that a 
reader of this doc will assume that we decided to not consider the 
security of other path attributes because they are less important than 
AS_Path. However, by stating  that securing these other attributes is 
deemed out of scope, based on the charter,  I think we  make it clear 
that we have _not_ made a value judgement about the relative importance 
of them.

*/[WEG] /*I've seen the addition. It's not adequate to address my 
concern, because the text in section 5 was not changed at all to remove 
the reference to charter and "changes to this document at a later time" 
for both route leaks and secondary attributes.

I don't see why you believe that references to the charter, augmented by 
the salient text from the charter, are not appropriate here; that's the 
reason these topics are not addressed.  I also think
the note about updating the threat doc, if and when the charter is 
changed to include these concerns,
is appropriate. It tells the reader that these topics may be addressed 
in the future.

*/[WEG]/*I'm no connoisseur of threat analyses, so I don't have a large 
basis of comparison, but I do think that a threats document should not 
identify a residual threat and then hand-wave it away as "out of scope" 
instead of explaining the relative risk that it might be exploited. It 
might even perhaps draw the conclusion that the risk is negligible, but 
based on your explanation, WG charter and scope shouldn't figure into 
the discussion.Worse yet, as this section is currently written, it's 
circular logic: pathsec doesn't protect non-AS_Path attributes, so 
there's a risk of those attributes being manipulated without pathsec 
detecting it, but that's ok because pathsec isn't required to protect 
against those things. Why isn't pathsec required to protect against 
those things? Because the charter says it isn't. Why does the charter 
say that? Because...reasons?

We fundamentally disagree on this point. A threat doc is always 
constrained by some set of contextual
assumptions. Stating that we are aware of some concerns that are not 
addressed, and that they may be
addressed in the future is a reasonable way to convey to the reader what 
some of the contextual
constraints are. Your characterization of the discussion as "circular 
reasoning" is faulty. What
the text says is that path security is the focus of the WG, and thus is 
a constraint adopted by
this threat analysis, period.

>From a threat analysis perspective, either the ability to manipulate 
unprotected attributes is a threat (a capability for an adversary to 
carry out an attack) to BGP Path security, or it's not. I believe the 
fact that you/the WG included it in the discussion means that you/the WG 
believe that it's a threat. I could infer based on the fact that SIDR 
chose not to design protections against that exploit that it's a real 
threat but very low risk, or extremely difficult to exploit, or 
whatever, but the document doesn't currently say anything about the 
relative level of risk for the threat being identified. You're right in 
that the design/requirements decisions that SIDR WG made about whether 
to address that threat are mostly irrelevant, but the fact that you 
discuss it in terms of design scope makes that confusing if one is to 
evaluate this text as purely a threats analysis. It goes back to a 
recurring issue that has happened with the order of these documents, 
where we're writing a threats doc and a requirements doc based on an 
existing design rather than the other around, and are tailoring these 
documents based on the current design to the exclusion of things deemed 
out of scope instead of documenting everything and then deciding some of 
the specific scope items in the requirements/design phase.

As noted above, every threat analysis takes place in a context, else it 
could never be complete. We have a
context defined by the WG charter, and I have chosen to use that context 
to constrain what the analysis covers. We cannot "document everything" 
any more than a scientist can "gather all the data and they form a 
hypothesis." Your criticisms about the order of doc preparation suggest 
a deeper discontent with the
WG process. I suggest you talk with the WG chairs and the cognizant AD 
about that, rather than taking
it out in this doc.

Steve

p.s. in the later parts of your comments you repeatedly use the term 
"threat" when you mean "attack" or maybe "vulnerability" or ...

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 29 Oct 2013 16:58:26 +0000

Wes

I am happy to talk to you about this at IETF, but I think the
doc addresses the problem that SIDR was chartered to
address.

I acknowledge that there are wider threats, that need to
be addressed, but as Steve says this I-D should not be
a hostage to us putting in place solutions to those problems.

- Stewart

On 10/10/2013 16:33, Stephen Kent wrote:
> and your response (below) helped me see that, so I'll try to clarify. 
> I don't care whether it's a charter/scope issue, and I'm not asking 
> for the summary for that reason. I care about it from the perspective 
> of its relative risk as a threat, and I made reference to the 
> that we have _not_ made a value judgement about the relative 
> importance of them.
>
>
> concern, because the text in section 5 was not changed at all to 
> remove the reference to charter and "changes to this document at a 
> later time" for both route leaks and secondary attributes.
>
>
> I don't see why you believe that references to the charter, augmented 
> by the salient text from the charter, are not appropriate here; that's 
> the reason these topics are not addressed.  I also think
> */[WEG]/*I'm no connoisseur of threat analyses, so I don't have a 
> large basis of comparison, but I do think that a threats document 
> should not identify a residual threat and then hand-wave it away as 
> "out of scope" instead of explaining the relative risk that it might 
> be exploited. It might even perhaps draw the conclusion that the risk 
> is negligible, but based on your explanation, WG charter and scope 
> shouldn't figure into the discussion.Worse yet, as this section is 
> currently written, it's circular logic: pathsec doesn't protect 
> non-AS_Path attributes, so there's a risk of those attributes being 
> manipulated without pathsec detecting it, but that's ok because 
> pathsec isn't required to protect against those things. Why isn't 
> pathsec required to protect against those things? Because the charter 
> says it isn't. Why does the charter say that? Because...reasons?
>
>
> addressed in the future is a reasonable way to convey to the reader 
> what some of the contextual
> the text says is that path security is the focus of the WG, and thus 
> is a constraint adopted by
> fact that you/the WG included it in the discussion means that you/the 
> WG believe that it's a threat. I could infer based on the fact that 
> SIDR chose not to design protections against that exploit that it's a 
> real threat but very low risk, or extremely difficult to exploit, or 
> relative level of risk for the threat being identified. You're right 
> in that the design/requirements decisions that SIDR WG made about 
> whether to address that threat are mostly irrelevant, but the fact 
> that you discuss it in terms of design scope makes that confusing if 
> one is to evaluate this text as purely a threats analysis. It goes 
> back to a recurring issue that has happened with the order of these 
> documents, where we're writing a threats doc and a requirements doc 
> based on an existing design rather than the other around, and are 
> tailoring these documents based on the current design to the exclusion 
> of things deemed out of scope instead of documenting everything and 
> then deciding some of the specific scope items in the 
> requirements/design phase.
>
>
> As noted above, every threat analysis takes place in a context, else 
> it could never be complete. We have a
> context defined by the WG charter, and I have chosen to use that 
> context to constrain what the analysis covers. We cannot "document 
> everything" any more than a scientist can "gather all the data and 
> they form a hypothesis." Your criticisms about the order of doc 
> preparation suggest a deeper discontent with the

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html