Thank you for the review & the edits! Jari
On Oct 9, 2013, at 1:27 PM, "Black, David" <[email protected]> wrote: > 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: [email protected]; [email protected]; General Area Review Team >> ([email protected]) >> Cc: Black, David; [email protected]; [email protected]; [email protected] >> 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 >> [email protected] Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
