Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06

Stephen Kent <kent@xxxxxxx> · Mon, 30 Sep 2013 14:08:33 -0400

    David,

      Major issue:

This draft contains more than just a threat model. 

    agreed.

       It also contains
a high level security analysis of the security architecture/approach
that applies the RPKI to secure use of BGP.  

    yes. we didn't create a threat model doc for the RPKI, and this
    seemed

    like a good time to address that omission, since the SIDR charter
    mandates

    use of the RPKI as a basis for the path security design.

      That analysis appears to
be good, but it's somehow disconnected from the rest of the sidr WG's
work, by what I hope is simply a terminology problem:
	- This draft refers to the security architecture/approach for
		BGP as PATHSEC.
	- Many of the other sidr WG draft refer to that security as
		BGPsec
In effect, the PATHSEC security architecture/approach appears to be
implicit in this draft.

    The term PATHSEC is used to refer to a generic path security
    solution

    approach, consistent with the WG charter, rather than to the
    specific

    solution approach, BGPsec, that has been developed. The rationale
    for 

    using the different term is that this threat doc should precede the

    requirements doc, which should precede the solution design. In
    reality,

    the requirements doc was generated before the threat analysis, and
    the

    BGPSEC design was well along before this doc was finalized. Earlier
    versions

    of the doc did refer to BGPsec, but the term was changed for the
    reasons

    cited above. This doc does embed assumptions about what a general
    path security architecture would entail, e.g., based on prior work
    on such architectures, e.g, S-BGP.

      Something's missing - if those two terms were meant to be the same,
BGPsec should probably be used in this draft, otherwise, the relationship
should be described.  I've tagged this as a major issue, as it makes
text like the following in Section 4.2 rather unclear:

    I hope my explanation above explains why the terminology was
    adopted.

            Stale Path Announcement: If PATHSEC-secured announcements can
      expire, such an announcement may be propagated with PATHSEC data
      that is "expired".  This behavior would violate the PATHSEC goals
      and is considered a type of replay attack.

What is "PATHSEC data"?  What are "the PATHSEC goals"?  The statement
in the abstract that " We use the term PATHSEC to refer to any BGP
path security technology that makes use of the RPKI" doesn't seem to
answer these questions.

    PATHSEC data is whatever data is sent via a path security design to
    enable

    an AS to verify that the UPDATE has traversed the indicated set of
    ASes. The

    goals for PATHSEC are the ones stated in the SIDR WG charter . (The
    relevant

    charter text used to appear up front, but was removed at the request
    of the

    WG chairs and the cognizant AD. The relevant text appears in this
    version on

    page 16, as part of the residual vulnerabilities discussion.)

      Minor Issue:

Section 4.4 seems somewhat loose on caching by RPs, considering the
importance of that caching in countering a number of the attacks described
in that section - in multiple cases, RP detection of an attack relies
upon the RP noticing that something has changed at the publication point
wrt the RP's cached copy in a fashion that should not have happened.

      Statements such as "the RPKI calls for RPs to cache" and "RPs are
expected to make use of local caches" strike me as a weak foundation
for the level of security dependence on that caching.  A pointer to a
SHOULD or MUST requirement for caching by RPKI RPs in another document
would alleviate this concern; surely that language exists somewhere.

    The RPKI mandates caching (see RFCs 6480 and 6481), and since use of
    the RPKI 

    as a basis for PATHSEC is mandated by the SIDR charter, I didn't
    feel it was 

    necessary to repeat that here. But we can include a cite:

       Note first that the RPKI calls for RPs to cache the data they
    acquire

       and verify from the repository system [RFC6480, RFC6481].

      Nits/editorial comments:

Also in Section 4.4:

   (The RP would be very unhappy if
   there is no CRL for the CA instance anyway.)

Please rewrite to describe how the RP reacts to failure to find a CRL
- the RP surely does something in addition to becoming "very unhappy" ;-).
Some of that may already be in the sentence immediately following the
"very unhappy" text.

    I'll remove the flippant parenthetical. You're right that it isn't
    useful.

      idnits 2.12.17 complains about a missing reference:

  == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined

That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5]
should be informatively referenced here - it was RFC 2385, which has been
obsoleted by RFC 5925, which is referenced here.  The fact that RFC 2385
is obsolete will generate a different idnits warning, which is ok to ignore.

    I disagree, and I discussed this with Stewart previously. The
    reference appears in a

    quote and was appropriate at the time the quoted text was generated.