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

[Job Snijders <[e-mail]>]

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

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.

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.

Kind regards,

Job