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

[Stephen Kent <[e-mail]>]

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