After discussion with the authors, the -07 version of this draft resolves
the two issues in the Gen-ART review of the -06 version. In summary:
- Text has been added to explain the relationship of the PATHSEC and BGPsec
terms.
- Citations have been added to the RFCs that explain the RPKI RP caching
requirements.
Thanks,
--David
> -----Original Message-----
> From: Black, David
> Sent: Monday, September 23, 2013 8:25 PM
> To: k...@bbn.com; a...@cs.unc.edu; General Area Review Team (gen-...@ietf.org)
> Cc: Black, David; stbry...@cisco.com; ietf@ietf.org; s...@ietf.org
> Subject: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-sidr-bgpsec-threats-06
> Reviewer: David L. Black
> Review Date: September 23, 2012
> IETF LC End Date: September 23, 2012
>
> Summary: This draft is on the right track, but has open issues
> described in the review.
>
> This draft describes the threat model for BGP Path Security. The
> draft generally reads well, but does contain quite a bit of serious
> security analysis of an important routing protocol and hence requires
> both security and routing expertise to fully understand.
>
> Major issue:
>
> This draft contains more than just a threat model. It also contains
> a high level security analysis of the security architecture/approach
> that applies the RPKI to secure use of BGP. 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.
>
> 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:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> david.bl...@emc.com Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
