Re: [Sidrops] WG Adoption call for draft-harrison-sidrops-manifest-numbers-01 - ENDS 04/15/2024 (April 15 2024)

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 2 Apr 2024, at 18:35, Job Snijders <job=[e-mail]> wrote:
> 
> Dear Tim, WG,
> 
> On Tue, Apr 02, 2024 at 01:45:59PM +0200, Tim Bruijnzeels wrote:
>> I support adoption and discussion.
>> 
>> I understand the issue this seeks to address for TA manifests. I am
>> not 100% convinced yet that the name change is the most desirable way
>> to achieve this. Perhaps it is. An alternative thought would be to
>> allow resetting the manifest number to a low value (or well: 1, but
>> RPs may not see it if another update follows shortly after) in case
>> the number has exceeded some extremely large value (like 2 to the
>> power of 159 ~ 19 octets and 8 bits…). I am not sure yet that this is
>> better either but I am just putting it out here as a thought.
> 
> Yup, Tom's deck on slide 5 also suggested 'Use serial number arithmetic
> to facilitate rollover' as a possible strategy:
> https://datatracker.ietf.org/meeting/119/materials/slides-119-sidrops-manifest-number-handling-02

If only there would have been more time to discuss presentations ;)

> 
> Thank you for sharing your thoughts, I think it is good to discuss and
> document our choices in the SIDROPS mailing list archives. I think there
> are three compelling reasons not to use serial number arithmetic in this
> particular context:
> 
> 1) The algorithm presented by RFC 1982 ("Serial Number Arithmetic") has
>   a significant shortcoming: there are sequence numbers for which
>   comparison is undefined. A potential solution is to use signed two's
>   complement binary arithmetic operations to workaround this shortfall,
>   this implies serial numbers of a bit-length matching the machine's
>   integer sizes (usually 32 or 64 bit), but in the RPKI we're dealing
>   with 159-bit serials... I consider arithmetic operations on a number
>   space this large an unwelcome complication to be avoided if possible.
> 
> 2) As you (Tim) point out: "RPs may not see it if another update follows
>   shortly after". Indeed, depending on all RPs seeing the initiation
>   and subsequent steps of the arithmetic trick seems fragile to me. 
> 
>   RFC 1982 section 7 states:
> 
>      "If this [red: a decrease] must be done, then take special care to
>       verify that ALL servers have correctly succeeded in following the
>       primary server's serial number changes, at each step."
> 
>   The type of verification RFC 1982 refers to is not possible in the
>   RPKI, as a CA can't query RPs whether they have correctly succeeded
>   in following the manifest's serial number changes.

Yeah, sure, but we could still think about a reset to a low number if the
number exceeded large some number. This being applicable to TA manifest
they are typically not republished frequently. E.g. a TA could only be allowed
to reset after a manifest has been out there for a while, like days or weeks,
or even months.

If this is to be more generally applicable to CAs (rather than forcing them
to do the key rollover mentioned) then this is probably not possible.

> 
> 3) Speaking from my own experience with the rpki-client implementation,
>   the code paths which open a previously cached manifest and a
>   purported new manifest along side each other, adequately validate &
>   compare these two objects, and finally select one of the two;
>   - already today - are amongst the most complicated pieces of code we
>   have to maintain. I am very hesitant to add more complications (such
>   as outlined above in reason 1) to this part of the code base beyond
>   what's already there.
> 
> My gut feeling is that 'filename change effectively results in serial
> numer reset' is easier to implement and easier to explain, than a
> RFC1982-based approach; having said that, I do recognize it certainly is
> not the only possible approach.

Ok, my concern is not blocking. If this is the way that current RP implementers
want to go that is fine by me (other RP implementers, opinions?).

But just to explain where my dislike of names comes from:

I don’t implement an RP today, but I was part of the team that implemented
one many years ago (see RFC 8488). This implementation intentionally separated
RPKI object fetching and validation, and did not rely on names. (and later
versions of that software also used asynchronous fetching of objects to prevent
blocking validation on bad repos). The reason for not relying on names was
that this would help to make validation URI and transport agnostic - allowing
for different mechanisms and possibly even mirroring in future.

Using names as an identifier in the way this I-D proposes complicates that
approach a bit. Then again, it seems that all other RP implementations just
use names as stable identifiers. So, this probable is not an issue to them.

Kind regards,
Tim

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops