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

[Stephen Kent <[e-mail]>]

Wes,

Sorry. I was on vacation when your message was sent, and I did not see 
it when I processed all
of the messages upon return, two weeks later. I did locate it in the 
archive today, after
seeing your message. I'll treat your comments as IETF last call comments 
since, as you note,
they were posted long after WGLC.

Your comments were:

    Maybe I'm hypersensitive to such in light of recent accusations of
    national actors subverting supposedly secure infrastructure to
    behave badly, but I find it odd that this threats document doesn't
    discuss the interaction between a national actor and the machinery
    provided by draft-ietf-sidr-ltamgmt. i.e. a national actor imposes
    upon SPs that operate inside their borders to use their own Local
    (and compromised) Trust Anchor to subvert the protections provided
    by RPKI. While this is primarily a concern for origin validation, I
    view it as distinct from the existing discussion of attacks on a CA
    covered in 4.5, and there is no equivalent Origin Validation threats
    document. It may be that the right path is to augment the discussion
    of this issue in the LTA management draft, and simply reference it
    from this draft, but I don't think that this is discussed suitably
    in the security considerations of either draft.

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.

    Section 4.2 is missing any discussion regarding manipulation of
    other route attributes that may be used to affect a BGP route's
    selection, such as MED, Local Pref. It's covered in section 5, but
    since this occurred to me whilst reading section 4.2, perhaps some
    mention in 4.2 would be useful, I don't know.

As you noted, Section 5 discusses other attributes that are not 
considered in this doc, and explains
why. Unless Stewart directs us to add a forward pointer in 4.2, I don't 
plan to do so.

    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.

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.

    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.

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.

    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.

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.

Steve