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

From: "George, Wes" <[email-masked]>
Date: Mon, 14 Oct 2013 16:07:45 -0400

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] That's part of the problem. I think you *should* be making a value judgment as to their importance (more accurately, their risk of being exploited) for the sake of completeness of the vulnerability analysis.

[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.
[WEG] There is no "salient text from the charter" augmenting section 5. And I don't think that a paraphrase in the intro is nearly as helpful as actual quotes where appropriate.
  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] Your horizon for "future" and the lifecycle of this document don't match up. Assuming that this document proceeds to RFC, "this document should be revised" is impossible - it would require an entirely new document. As I said, that wording is fine as a placeholder for a document in active discussion, but is far too ephemeral for something as carved in stone tablets as an RFC. Dropping the last sentence from each of the first 2 bullets in section 5 pathsec residual vulnerabilities would help to address this concern.

[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.
[WEG] whether you agree with my characterization or not, I stand behind it. I believe the scope of a threat analysis should be limited by the likelihood of a given vulnerability to be exploited for an attack, not the arbitrary charter of a WG.

>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."
[WEG] "everything" was a poor choice of word, but I think you're being pedantic rather than responding to my actual issue that you've failed to categorize the risk of these residual vulnerabilities. The absence or presence of items in charter/scope has nothing to do with the level of risk of a given vulnerability, and I don't think it's asking a lot to add this.
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.
[WEG] I have nothing personal against the doc. I think ultimately this comes down to a disagreement over scope - I think it's been too tightly constrained to the charter (which in itself was constrained to neatly fit with an already-underway design (BGPSec) ) instead of being an actual threats analysis of BGP Path security. Though more than likely we are at an impasse and I will have to address my concerns to the relevant AD(s).

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: Wed, 16 Oct 2013 17:08:06 -0400

Wes,

The following text extracted from your response provides a good basis 
for what will be my
final reply in this exchange.
> ... I believe the fact that you/the WG included it in the discussion 
> means that you/the WG believe that it's a threat. 
first, its an attack, not a threat. second, the topic was added to 
acknowledge that we are aware of
such attacks, even though we have chosen to not address them now. period.
> 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.
and, as I noted, such inferences would be unfounded.
> 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. 
I didn't say what you suggest immediately above. Route leaks and 
protection for other path
attributes are included because they were discussed by the WG, and the 
WG chairs felt it was
important to acknowledge that discussion, and note briefly why these 
topics will not be addressed.

> 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. 
This seems to be the telling issue. You seem to be unhappy with the 
scope of the WG charter, and
refuse to accept it as bounding for the work that is being performed. 
Your earlier comment
refers to the charter as "arbitrary" suggesting an unwillingness to 
accept a charter as a
a way to bound the scope of a WG.

Steve

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 28 Oct 2013 17:17:55 +0100

Stephen Kent wrote on 10/16/13 11:08 PM:
>> 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.
> This seems to be the telling issue. You seem to be unhappy with
> the scope of the WG charter, and refuse to accept it as bounding
> for the work that is being performed. Your earlier comment refers
> to the charter as "arbitrary" suggesting an unwillingness to accept
> a charter as a a way to bound the scope of a WG.

I think formally you are absolutely right, Steve. The charter and the
name of the document leave these issues outside the scope. But I see
and agree with the points brought up by Wes. Since the ultimate goal
of the SIDR effort is to secure interdomain routing, a threat analysis
with a wider scope, not constrained by somewhat arbitrary limitation
of the charter, could have been helpful. Not to call for a re-charter,
but rather to put the proposed solutions in the overall security context.

draft-ietf-sidr-bgpsec-threats could be that document.

Andrei