Subject: [sidr] comments on BGPsec rollover

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Mar 2015 13:44:07 -0400

The text needs a lot of work, i.e., odd English constructs are very 
common, and there are a number of typos, some of which I have noted 
below. I thought the current acronym is BGPsec. not BGPSEC. Also the 
document has too many instances of “could” and “would” where more 
normative statements ought to appear. I suggest the authors adopt (and 
clearly state) some of the assumptionsthey cite, then revise the 
document based on those assumptions. This I-D says it’s Standards Track, 
but it doesn’t read that way.

Section 2:

Comceptually -> conceptually

Router certificate rollover is only superficially similar to key 
rollover a per RFC 6489; that process deals with CA certificates. Not EE 
certificates.

“…routing information may be lost after the rollover process is 
finished.” How about “may be treated as unauthenticated …”

the discussion of distribution of a stale BGPsec_Path attribute 
shoulddescribe this as part of an attack, explicitly.

“The Security Requirements for BGP Path Validation [RFC7353] also

describes the need for protection against a replay attack, …”

What 7353 says is:

4.3Replay of BGP UPDATE messages need not be completely prevented, but a 
BGPsec design SHOULD provide a mechanism to control the window of 
exposure to replay attacks.

I think the text in this document should be a bit closer to that in 7353.

Section 3:

propogated -> propagated

correspondent -> corresponding

certificate key may be compromised -> router private key …

suchas EST-> such as EST

BGP speaker that hold -> BGP speaker that holds

This chose will -> This choice will

The text refers to “New Certificate Pre-Publication” but it’s just 
publication of a certificate prior to beginning to make use of the 
corresponding private key. I suggest you remove the “pre” here.

I think step 4 should describe the circumstances under which revocation 
is required or recommended.

I’m a bit confused about step 5 here. Do we have a RTR withdrawal 
message? I would expect the normal process would be to issue an update 
with the new signatures an have it replace the current update that was 
signed under the old key. We have no way to ensure that this implicit 
withdrawal will propagate (in the context of a malicious router) but 
that’s why the revocation of the old certificate is needed.

Section 4:

mitigate mitigate -> mitigate

If pre-provisioning done ahead of time …

if it isn’t done “ahead of time”, it’s not pre-provisioning J!

“ … if there have been no topology changes, then no security threat 
comes from a replay …” I think the vulnerability is even more narrowly 
constrained. Only if there are topology changes that make the route 
associated with the old BGPsec_Path attribute preferable to the route 
associated with the new one, right?

“For a very small but critical fraction of the prefixes, the requirement 
may be in the order of hours.” This assertion needs to be explain with 
some examples or further explanatory text.

I disagree with statement #2 in the Advantages text (page 10). I woud 
argue that many of the costs are borne by the RPs who have to fetch and 
validate the new router certificates and then provide the new keys and 
ASN information to their routers.

I also disagree with item #4 under disadvantages. I think the increased 
burden on RPKI caches is analogous to the burden on repositories.