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

[Eric Rescorla <[e-mail]>]

On Tue, Nov 28, 2017 at 5:04 PM, Brian Weis (bew) <[e-mail]> wrote:

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

Yes, that seems like it would be a good idea.

-Ekr


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