[sidr] Gen-ART review of draft-ietf-sidr-bgpsec-threats-07

["Black, David" <[e-mail]>]

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: [e-mail]; [e-mail]; General Area Review Team ([e-mail])
> Cc: Black, David; [e-mail]; [e-mail]; [e-mail]
> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>