Re: [sidr] about "beaconing" and the bgspec-protoocol

["Sriram, Kotikalapudi" <[e-mail]>]

>>  "For  this reason, it is recommended that routers in this scenario been
>>   provisioned with two certificates: one to sign BGP UPDATES in transit
>>   and a second one to sign BGP UPDATE for prefixes originated in its
>>   AS.  Only the second certificate (for prefixes originated in its AS)
>>   should be rolled-over frequently as a means of limiting replay attach
>>   windows.  The transit BGPSEC certificate is expected to be longer
>>   living than the origin BGPSEC certificate."
>
>Note: There are two grammatical errors / typos in _that text fragment.

The quote was from [draft-ietf-sidr-bgpsec-rollover] which is authored by Roque/Keyur/BrianW.
Hopefully, they will make note of your comment.

>
>> In the PKR method, the "current" origination cert (and key pair)
>> expires at periodic intervals and updates are re-originated signed by the "next"
>origination cert.
>
>OK, this IS _the new added churn I was referring to.  This doesn't occur in BGP
>today.
>
>> Just to clarify, *transit* prefixes are not beaconed (i.e., not
>> "periodically" re-propagated) by *transit routers* in any of the key rollover
>methods.
>> The PKR method has periodic re-origination of origination prefixes
>> only (i.e., each eBGP router periodically re-originates its origination prefixes).
>> The EKR method by definition is event-driven, hence does not entail any
>periodic re-originations.
>
>You're introducing a new "event" here that has an periodic expiry attribute, this
>IS _the new added churn I was referring to.  This doesn't occur in BGP today.
>
>> The events (topology changes, etc.) are presumably rare/infrequent.
>
>
>"presumably rare/infrequent" != "does not occur".
>
>To that, how was it determined that "Transit cert can have a very large
>NotValidAter time", what requirement led to this?

The taxonomy and details & design rationale of the different key rollover methods are 
fairly well explained in [draft-sriram-replay-protection-design-discussion] in Section 5. 

>
>Again, we can repurpose and reapply terms for
>beacon/periodic/triggered/event-driven words all we want, but if an
>intermediate AS needs to retransmit an advertisement because it's forwarding
>signing "Transit cert" rollover; solely because of some refresh or expiry action
>related to key rollover then that's something that doesn't occur in BGP today,
>and yet another place where combinatorial effects of all these "capabilities"
>give me concern, and represent _the new added churn I was referring to.  This
>doesn't occur in BGP today.
>
>Given, leaving the attack window larger for "transit certs" reduces churn, but it
>should lead one to question the broader objectives and implications.

Here you have the benefit of decent descriptions of the different methods,
their pros/cons etc. in [draft-sriram-replay-protection-design-discussion].
The churn is reasonably well modeled/quantified in my Atlanta presentation 
(slides 8 thru 11):
http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf
Please let me know if you have specific questions about the analysis/data
on churn after taking another look at slides 8-11.
Please keep in mind that the churn triggered by an event such as
a topology change or a policy change happens even today in BGP-4.
So that type of churn is not new.
As for the *new* background churn in BGPSEC with *PKR*, 
we have shown that it is nearly two orders of magnitude less compared 
to today's BGP (when peak seconds are compared) as shown in slide 8
for a 24 hour replay-attack vulnerability window (in PKR).
So the additional churn in BGP due to the background churn of BGPSEC with *PKR*
is practically negligible (see slide 8 - note that the y-axis is logarithmic scale.)

Again, in [draft-sriram-replay-protection-design-discussion] we are not
advocating any specific choice of key rollover. It is a discussion document
and a companion to [draft-ietf-sidr-bgpsec-rollover]. 
The latter is planned to be a BCP and authored by Roque/Keyur/BrianW.  

>
>Finally, all these options mean relying parties (i.e., BGPSEC routers) must have
>all the old and new (and future?) certificates onboard and know which to use at
>what time for validating which origin_as or transit signature blocks at what
>times.

There should be no such confusion. Receiving router does not need to do any timing in this context.
At the signing router, the "next" cert becomes "current" cert when a key rollover happens.
The "current" cert becomes a previous cert.
The updates are always signed by the "current" cert.
The "staging", "twilight" etc. w.r.t to "current" and "next" certs propagation are streamlined 
(see Section 3.1 of [draft-ietf-sidr-bgpsec-rollover]).  

Also, please take a look at [draft-ymbk-rpki-rtr-keys]
https://datatracker.ietf.org/doc/draft-ymbk-rpki-rtr-keys/?include_text=1
RPKI cache sends {ASN, SKI, PubKey} data for all valid certs to RP routers,
and withdraws the same for any revoked/expired certs.
The updates carry ASN and SKI corresponding each signature.
The {ASN, SKI} combination maps uniquely to a router's PubKey.
So a BGPSEC router would be able to unambiguously pick the exact right PubKey 
needed to verify each signature in an update.
Assume the router has two updates - the signature in one update is signed 
using "current" cert of a router R1 and the signature in the second update is signed  
using "previous" cert of the same router (R1).
If both "current" and "previous" certs of the signing router (R1) happen to be valid 
at that time, the router can unambiguously find the correct PubKey to verify either signature. 
Eventually, the "previous" cert would be revoked or would expire, and then the second
update would be invalid. 

Sriram