Re: [Sidrops] Eric Rescorla's No Objection on draft-ietf-sidrops-bgpsec-rollover-03: (with COMMENT)

["Brian Weis (bew)" <[e-mail]>]

Hi EKR,

Thanks for your review. Comments below are prefaced with BEW.

> On Nov 28, 2017, at 4:10 PM, Eric Rescorla <[e-mail]> wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-sidrops-bgpsec-rollover-03: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>   BGPsec router certificate with a new public key and the time a BGPsec
>   router begins to use its new private key).  This can be due to a need
>   for a BGPsec router to distribute BGPsec updates signed with a new
> Nit "the period between the time when an AS distributes …."

BEW: This is the new text, which I believe matches the comment. 

“It is also important for an AS to minimize the BGPsec router key rollover 
interval (i.e., the period between the time when an AS distributes a BGPsec 
router certificate with a new public key and the time a BGPsec router begins
to use its new private key)."

> 
>   Protection against withdrawal suppression and replay attacks:  An AS
>         may determine withdrawn BGPsec updates are being propagated
>         instead of the most recently propagated BGPsec updates.
> Nit: may determine that.

BEW: fixed.

> 
>   certificate used for signing updates in transit is expected to live
>   longer than the one used for signing origination updates.
> Why is it unimportant to worry about replays on transit updates? As I read the
> references it's just that changing the transit key is expensive, right? But I'm
> not sure why that means you don't have to do it.

BEW: Replay attack protection provides an origin AS a way of ensuring its latest 
updates are being propagated through the network. A transit AS is not likely to 
know or care whether whether the policy of the origin AS has changed, however. 
So when an origin AS changes it’s signing key as a replay attack protection, it 
doesn’t have any motivation to change its transit  signing key as well, and this is 
what the paragraph is intending to say.

One reason to recommend not changing the transit key on the same schedule 
as the origin key (e.g., for replay attack protection) is to limit damage if there is 
a glitch in the rollover process. If a new origin key doesn’t get installed in time, 
then only the origin AS will be affected. But since large numbers of updates have 
been signed with that transit key, a failure in distributing a new transit key could 
result in large numbers of updates originated by many origins will have been 
invalidated, which could result in substantial damage to the Internet.

Probably some text should be added to the paragraph to explain this.

Thanks,
Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]