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

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:
> 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 ...
>
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

-- 
For corporate legal information go to:

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