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.
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
