Subject: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt

From: Randy Bush <[email-masked]>
Date: Tue, 21 Apr 2020 12:58:00 -0700

From: [email-masked]
Subject: New Version Notification for draft-ymbk-rpki-rov-timing-00.txt
To: "Randy Bush" <[email-masked]>, "Job Snijders" <[email-masked]>
Date: Tue, 21 Apr 2020 12:44:35 -0700

A new version of I-D, draft-ymbk-rpki-rov-timing-00.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-rpki-rov-timing
Revision:	00
Title:		Timing Parameters in the RPKI based Route Origin Validation Supply Chain
Document date:	2020-04-21
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-ymbk-rpki-rov-timing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-rpki-rov-timing/
Htmlized:       https://tools.ietf.org/html/draft-ymbk-rpki-rov-timing-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ymbk-rpki-rov-timing

Abstract:
   This document explores, and makes recommendations for, timing of
   Resource Public Key Infrastructure publication, propagation, and use
   of RPKI ROV data in relying parties and routers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Melchior Aelmans <[email-masked]>
Date: Wed, 22 Apr 2020 11:36:11 +0200

I like the Replying Party :)

On Tue, Apr 21, 2020 at 9:58 PM Randy Bush <[email-masked]> wrote:

> URL:
> https://www.ietf.org/internet-drafts/draft-ymbk-rpki-rov-timing-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ymbk-rpki-rov-timing/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ymbk-rpki-rov-timing
>
>
> Abstract:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 22 Apr 2020 13:57:08 +0200

Hi,

s/rcynic/rsync/g

Furthermore, I think the document could use some words on the chain before the CA. i.e. timing of creation of ROAs in the CA w.r.t. changes in announcements done.

I would say that for planned changes ROAs should be created in advance, X minutes where X > the sum of the timings after a CA creates a ROA and until it's seen by routers. For unplanned changes, I guess they should just be created ASAP, but it may help to quantify?

As a side note. We are discussing moving from rsync to RRDP in another thread. I believe that RRDP will help reduce propagation times. But I have no doubt that further improvements can be conceived in future. It helps to have guidance for maximum propagation times to serve as guidance for requirements there.

Tim

> On 21 Apr 2020, at 21:58, Randy Bush <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Apr 2020 05:28:59 -0700

mornin' tim,

thanks for review!

> s/rcynic/rsync/g

massimiliano already beat me up on that this morning.  he had done a PR,
i merged it, and then let spell check revert it <blush>.

> Furthermore, I think the document could use some words on the chain
> before the CA. i.e. timing of creation of ROAs in the CA w.r.t.
> changes in announcements done.

i am not understanding.  do you mean possible CA to publication point
delay?

> I would say that for planned changes ROAs should be created in
> advance

yes.  this was discussed many time in the design team.  the ddos defense
folk essentially said that most of the 'customers' come running in the
door in panic and had never thought to do advanced planning.  while i
have some sympathy for that, i am not sure what we can say here other
than
  o try to constrain the propagation time
  o point out that roa creation in advance of operational changes, be it
    circuit moves, ddos sinking, ... should be done sufficiently in
    advance.

i'll try to do more.

> As a side note. We are discussing moving from rsync to RRDP in another
> thread. I believe that RRDP will help reduce propagation times.

i tried to say that.  will look again.

> I have no doubt that further improvements can be conceived in future.
> It helps to have guidance for maximum propagation times to serve as
> guidance for requirements there.

i am not understanding.  maybe some coffee will help.

thanks again.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 22 Apr 2020 14:59:20 +0200

hi,

> On 22 Apr 2020, at 14:28, Randy Bush <[email-masked]> wrote:
> 
> mornin' tim,
> 
> thanks for review!
> 
>> s/rcynic/rsync/g
> 

No I mean the delay between deciding to make a change in routing announcements that one does, and using one's CA to create the ROAs. I.e. before section 4 in your draft applies.

> i tried to say that.  will look again.

You did, this was just a lead to the following.

> i am not understanding.  maybe some coffee will help.

What I am trying to say is thank you :)

In more words, hopefully less confusing, I find it useful to have this document say what the operational expectations are w.r.t. total propagation times:

Planned:
 1 - Create ROAs in CA (implied in section 4, but logically a step before the next)
 2 - Let CAs publish (your section 4)
 3 - Let RPs fetch and valid (section 5)
 4 - Let routers fetch and apply (section 6)
 5 - Do the actual announcement 

Unplanned:

 5 - Do the actual announcement
Becomes:
 0 - Do the actual announcement

But then you will still need to keep in mind how much time 1-4 takes, because until 4 is reached your announcement may be dropped.

RRDP has a limit of 60 seconds for fetching, w.r.t. point #3 (section 5). I think it will actually scale up to something faster if needed. Alternatively one could thing of push mechanisms or some flooding protocol in future. That said, it's only one kink in the chain. E.g. if there is a delay of an hour between #1 (create ROAs) and #2 (actual publication) then this won't matter much - yes, I am using a hyperbole to make a point :)

In any case, knowing how long the propagation from 1 through 4 can reasonably take will help guide what to improve.