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.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------