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

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

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:[e-mail]]

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