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