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

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

>> From comments made at the mike in the last IETG sidr session after the discussion of key rollover techniques, I think there might be a bit of confusion about beaconing.
>>
>> An Expire Time was a feature of the bgpsec protocol in versions 00-01.  The purpose of the Expire Time  was to prevent replay and ensure freshness.  The effect of this feature was to require periodic readvertisements of all prefixes, hence the name "beaconing".
>
> I'm pretty sure the captured proceedings for "Discussion of Key Rollover Mechanisms for Replay-Attack Protection" [!=beacon?] mentions "beacon" at least eleven times.  Additionally, "BGPSEC router key rollover" was about periodic updates (aka "beacons") as well.

Semantically, Beaconing = Periodic re-origination of prefixes

Beaconing (i.e., periodic re-origination) was an attribute of the explicit Expire Time method, 
and it IS an attribute of the periodic key rollover (PKR) method as well.
However, beaconing (periodic re-origination) IS NOT an attribute of the Event-driven Key Rollover (EKR) method. 
This is all fairly well documented in [draft-sriram-replay-protection-design-discussion]:
 
http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-00 

and also in my presentation slides from the Atlanta IETF SIDR session:
  
http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf

Periodic key rollover (PKR) is currently recommended in [draft-ietf-sidr-bgpsec-rollover] 
as evident from the following quote (from Section 4.2):

  “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.”

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.
No CRLs need to propagate; the cert expiry is automated by setting NotValidAfter time,
and the "next" cert is always pre-provisioned well in advance. 
None of it is tied to human scale intervention -- it can all be automated.

In the same section (section 4.2) , the authors also observed:

“Advantage of Re-keying as replay attack protection mechanism:
  	 1.  Does not require beaconing”

However, that advantage #1 is not correct for the periodic key rollover method, which is currently recommended. 

>
> considerable added churn through origination and transit node-triggered "beacons", and added processing overhead for cryptographic functions for signing and validation, 
>

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. 
The events (topology changes, etc.) are presumably rare/infrequent. 

Sriram