[Sidrops] Re: draft-ietf-sidrops-8210bis-23 is ambiguous session mismatch handling

[Tom Harrison <[e-mail]>]

Hi Ralph,

On Fri, Dec 26, 2025 at 12:13:38AM -0500, Ralph Covelli wrote:
> In my humble opinion, I think we need to tread very lightly here. 
> In this case I think "less is more".  One sentence added at most. 
> No change to existing logic.
> 
> The language in question is also in RFC8210 and probably should NOT
> be changed because it *IS* technically correct, it is just
> incomplete.

The problem with this approach is that it's not just one part of the
document that is not sufficiently clear in this respect (see below for
elaboration).

> RFC8210
> 5.1.  Fields of a PDU
> 
>       ... If, at any time ***after the protocol version has been
>       negotiated*** (Section 7), either the router or the cache
>       finds that the value of the Session ID is not the same as the
>       other's, the party which detects the mismatch MUST immediately
>       terminate the session with an Error Report PDU with code 0
>       ("Corrupt Data")...
> 
> In my reading of this the authors (correctly) carve out an exception
> for the Initial Serial Query (first PDU after connect).  In this
> case the protocol negotiation is happening via Serial Query PDU.
> 
> If the intention was to treat ALL Serial Queries with mismatched
> Session IDs as fatal errors then ***why mention the protocol
> negotiation at all***? 

This is a good point.  However, although this is supportive of your
reading, it doesn't mean that the reading I presented in my
second-last mail is unreasonable.  Even if you disagree with that,
though, all that my suggested changes in section 5.1 do (AFAICT) is
clarify what was presumably the original intention here, without
changing behaviour, so I'm not sure how that could be problematic.

(On this topic, though, the "after ... negotiated" text was added in
version 5 of the draft that became RFC 8210: see
https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidr-rpki-rtr-rfc6810-bis-04&url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-05&difftype=--html.
I couldn't find anything on the mailing list about why the text was
added, but maybe Rob/Randy have more details on that.)

> So if we shouldn't send a fatal error what should we do?  We should
> send a Cache Reset because we literally just reset the cache.  :-) 
> Cache Reset seems right at home here!  This is the exact same
> condition as if a Router's sequence number had fallen behind out of
> the cache window.  The RTR Cache should signal the router to clear
> its cache and issue a Reset Query.  Cache Reset's job.
>
> ...
> 
> All roads lead to convergence... but a Cache Reset gets you there
> fastest without any session disconnects!  Why encourage people to
> take the (destructive) scenic route?  :-)  A protocol should be able
> to gracefully handle its own servers restarting.  

I'm not sure it's material, but for the sake of completeness, loss of
the session may not be the "exact same" condition as deliberate
removal of old/stale serials within a given session.  Per my suggested
diff, the cache may use a stable session ID, and may therefore want to
distinguish the "stale serial" scenario from the "changed session"
scenario.  It is not necessarily the case that the session ID has to
change on server restart, either.  Having said all that, I think your
points about the end result being the same regardless, and Cache Reset
being a simpler approach, are good ones.

> Current RFC8210 documentation leaves it up to the implementer so you
> can't depend on any behavior there.  RFC6810 doesn't seem to be any
> help either.
> 
> I think the document should describe the *proper* behavior here and
> not all the *possible* behavior.  We want to be only clarifying
> existing undefined behavior, not redefining any existing behavior.

Instead of my previous suggested changes to section 5.3, what about
the following?

   If the cache does not have the data needed to update the router,
   then it responds with a Cache Reset PDU (Section 5.9).  There are
   two main scenarios where this will happen: when the Serial Number
   requested in the Serial Query is no longer available to the cache,
   and when the session ID in the Serial Query designates a session
   that is no longer available to the cache.

   Per section 5.1, if the Serial Query contains a session ID that is
   not equal to that previously established in the session between the
   router and the cache, the cache terminates the session with an
   Error Report PDU with code 0 ("Corrupt Data").  The behaviour in
   the previous paragraph is limited to the case where the router is
   using the previously-established session ID, but that session is no
   longer available to the cache.

> I think my original changes plug up all the logic holes and only
> adds 4 words. :-)

The original suggested changes here were:

    The Session ID tells the cache what instance the router expects to
    ensure that the Serial Numbers are commensurate, i.e., the cache
    session has not been changed.  *If the Session ID does not match,
    the cache MUST respond with a Cache Reset.*

The problem with this text is it conflicts with section 5.1, because
it appears to require Cache Reset in the case where the router starts
using a session ID different from that previously established.  The
text I suggested above avoids this problem by limiting the behaviour
to the case where the session is no longer available to the cache.

> RFC8210bis-23
> 5.3. Serial Query:
>    The Session ID tells the cache what instance the router expects to
>    ensure that the Serial Numbers are commensurate, i.e., the cache
>    session has not been changed.  If the Session ID does not match
>    *during protocol version negotiation*, the cache MUST respond with a
>    Cache Reset.
> 
> It should be completely safe to add wording to properly cover the Initial
> Serial Query / Cache Reset case where the *actual* cache resets without
> mentioning the misuse of 5.1 wording.  Everyone still has to treat fatal
> errors and cache resets like normal.

I don't think this suggested text helps either, due to previous
discussion of how "protocol version negotiation" can be interpreted in
different ways.

-Tom