[Sidrops] Re: Roman Danyliw's Discuss on draft-ietf-sidrops-publication-server-bcp-11: (with DISCUSS and COMMENT)

[Tim Bruijnzeels <[e-mail]>]

Hi Roman,

> On 18 Sep 2026, at 22:44, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> ** Section 3.3.  This section describes a situation where a roll-back of sorts
> might occur and the “currently published ROAs no longer reflect the CA's
> intentions.”  Would that not have novel security implications that would
> benefit from further documentation?

I think that it would be good to have a discussion in the working group about
improvements to the publication model. I authored an I-D that started to explore
this a few years ago, but... due to other priorities I did not request adoption
and it's currently expired: https://datatracker.ietf.org/doc/draft-timbru-sidrops-rpki-publication-v2/

If there is interest in the working group I am more than happy to renew this
effort and discussion.

In any case, in the context of this BCP document we are raising awareness of
current implications. Do you think we should elaborate a bit more on this?

This is essentially an issue with a very low likelihood (based on track record),
but potentially high impact as it could lead to the invalidation of intended BGP
announcements.

The way to mitigate this issue under the current standards is explained in the
next section (3.4) - essentially a publisher can resynchronise frequently. While
this cannot prevent the issues, it can fix the issues as soon as possible.

Another thing to note here is that Relying Parties that have seen a more recent
manifest would be protected against the regression as they would not accept the
older manifest.

I guess the answer is "yes", but my question is if it would be helpful to capture
some more of this in the text of 3.3 and 3.4?

Kind regards
Tim