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

[Ralph Covelli <[e-mail]>]

Hi,

I should also mention that routers must already have to deal with this.  
Consider the following scenario:

1) Router disconnects from RTR cache.

2) RTR cache has enough updates to knock the Routers serial number out 
of the cache window.

3) Router reconnects to RTR cache and sends Serial Query.

4) Router issues a *Cache Reset* because the serial number is not in the 
window.  (Session ID is the same)

Whether its because of the serial number window or the session id the 
result is the same.  Routers MUST handle this.

These are the protocol handshake pathways:

1) Reset Query -> Cache Response

2) Reset Query -> Error No Cache

3) Serial Query -> Cache Response

4) Serial Query -> Error No Cache

5) Serial Query -> Cache Reset

Thanks!

On 12/26/2025 12:13 AM, Ralph Covelli wrote:
>
> Hi Tom!
>
> I read your changes.  Thank you for taking the time to address this 
> ambiguity!  It is much appreciated!!
>
> 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.
>
> 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***?  There is no protocol negotiation *before* the 
> Serial Query PDU because the information is *inside* that Serial Query 
> PDU.  Your interpretation would make sense if there was a separate PDU 
> for version negotiation but there isn't.  Why would the authors 
> explicitly make an exception for an impossible PDU?  :-)
>
> The problem here is the authors don't say what you should do when it 
> *IS* an Initial Serial Query.  They only tell you what *NOT* to do... 
> *Don't* send a fatal error.  RTR cache servers that do this are not 
> technically conforming to RFC8210.  It's relatively harmless besides 
> the kill but I don't think we should remove or change this.  It's 
> correct as written.  Changing this now would create contradictions 
> with RFC8210 which we don't need.
>
> 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.
>
> It seems my worries about Routers not learning new Session ID's from 
> Cache Resets/Reset Queries were incorrect.  This case is already 
> handled.  (woops my fault!)
>
> RFC8210
> 5.5.  Cache Response
>
>     In response to a Reset Query, the ***new*** value of the Session ID tells
>     the router the instance of the cache session for future confirmation.
>
> From this wording it seems that routers *should always* be willing to 
> update Session ID's after a Reset Query so this shouldn't be a problem 
> for Cache Reset.
>
> I understand you are worried about compatibility with implementations 
> in the wild.  I am not advocating for the addition of language that 
> would break any compatibility.
>
> If an RTR cache issues a Fatal Error instead of a Cache Reset the 
> Router will synchronize via reconnect and Reset Query.
>
> If an RTR cache issues a Cache Reset and for some reason the router 
> continues to use the old Session ID, the RTR cache will send a Fatal 
> Error and the Router will synchronize via reconnect and Reset Query.
>
> 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. 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.
>
> I think my original changes plug up all the logic holes and only adds 
> 4 words. :-)
>
> 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 would be interested in hearing from the authors on their section 5.1 
> intentions here.
>
> What do you think Tom?  (or anyone else who would like to chime in)
>
> Thanks!
>
> On 12/23/2025 1:05 AM, Tom Harrison wrote:
>> Hi Ralph,
>>
>> On Mon, Dec 22, 2025 at 10:35:53PM -0500, Ralph Covelli wrote:
>>> On 12/22/2025 10:28 PM, Ralph Covelli wrote:
>>>> The problem is that the "existing behavior" is *not* clearly
>>>> defined in this case.  Your testing confirms this. (thank you for
>>>> taking the time to look)
>>>>
>>>> If you treat this condition as an error you will wind up
>>>> unnecessarily killing all of your router connections every time you
>>>> reset the RTR cache.
>> I think these are good points.
>>
>>>> In the end all roads lead to convergence:
>>>>
>>>> With Cache Reset:
>>>>
>>>> 1) Router disconnects from RTR cache
>>>> 2) RTR cache server restarts
>>>> 3) Router connects to RTR cache and sends Serial Query
>>>> 4) RTR cache sends Cache Reset to Router
>>>> 5) Router syncs
>>>>
>>>> With terminal Error:
>>>>
>>>> 1) Router disconnects from RTR cache
>>>> 2) RTR cache server restarts
>>>> 3) Router connects to RTR cache and sends Serial Query
>>>> 4) RTR cache sends Error to Router and disconnects
>>>> 5) Router connects to RTR cache and sends Reset Query
>>>> 6) Router syncs
>>>>
>>>> The Session ID appears to be designed to detect cache changes. This
>>>> should work both ways.  Router to RTR cache and RTR cache to
>>>> router.
>>> *Whether* its treated with a Cache Reset or a Terminal Error, the
>>> specific wording should be added to the document.
>> Although I think clarifying the document and providing some way to
>> avoid unnecessary connection terminations are useful things, I'm
>> mindful that there is at least one implementation that operates in
>> reliance on the reading I described in my previous mail.  I've had a
>> go at updating the text to address these problems at
>> https://github.com/APNIC-net/rpki-rtr-demo/commit/dd901d4f98cc3be23b798bc1e04fbd5042001965#diff-ba5205cdbf492fee8c9ee5a7c3afa6ea4f0eb87eb392a0286f9bce7eb783a631.
>> Do those changes look OK to you?
>>
>> -Tom
>>
>> _______________________________________________
>> Sidrops mailing list [e-mail]
>> To unsubscribe send an email [e-mail]
>
> _______________________________________________
> Sidrops mailing list [e-mail]
> To unsubscribe send an email [e-mail]