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

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

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.