[tcpm] Re: RFC 5925 Section 6.2 Issue

["[e-mail]" <[e-mail]>]

There’s already an errata from 2020 that corrects the code once. This is just another bug in the code, effectively.

The intent of the SNE is clear and isn’t changing; what is changing (like in 2020) is the code that generates the intended SNE.

That’s generally considered just a technical errata - it’s not a new MUST, any more than the 2020 fix was. The RFC 9187 code was more robustly vetted than the code from 5925; neither code is a MUST in any sense.

RFC5925 states, correctly:


   ...The implementation of SNEs is not specified in this document, but one
   possible way is described here that can be used for either RCV.SNE,
   SND.SNE, or both.





Yes, the description has an error and that should be fixed. But the code in 5925 wasn’t a MUST, nor should the code in 9187 be.

Joe

> On Apr 16, 2026, at 9:13 AM, Bonica, Ron <[e-mail]> wrote:
> 
> Joe,
> 
> Thanks for writing RFC 9187. I didn't know that it existed.
> 
> But I think that we need to give the errata some consideration. Errata scope and backwards compatibility are issues.
> 
> The errata will say either:
> 
> TCP-AO MUST use the algorithm specified in RFC 9187
> TCP-AO MUST use an algorithm that, given the validation data provided in Section 6 of RFC 9187, generates the same results as the algorithm provided in RFC 9187
> 
> Can we add a MUST in an errata? We can tiptoe around the word "MUST", but we cannot tiptoe around the errata intent.
> 
> Moreover, it the errata has any impact, it will cause people to change implementations. If they change implementations, there will be a backwards compatibility issue. Granted, the backwards compatibility issue will only be evident in a few corner cases, but there will be a backwards compatibility issue.
> 
>                                                         Ron
> 
> 
> 
> From: Joe Touch <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, April 16, 2026 12:44 AM
> To: Bonica, Ron <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]> Extensions <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [tcpm] RFC 5925 Section 6.2 Issue
>  
> Errata that points to RFC 9187.
> 
>> On Apr 15, 2026, at 3:56 PM, Bonica, Ron <ronald.bonica=[e-mail] <mailto:ronald.bonica=[e-mail]>> wrote:
>> 
>> 
>> Folks,
>> 
>> There is a problem in RFC 5925. I am looking for the WG's advice regarding whether we should:
>> 
>> Ignore it
>> Fix it with an Errata
>> Fix it with a bis document
>> 
>> According to the RFC:
>> 
>> "TCP uses a 32-bit sequence number, which may, for long-lived connections, roll over and repeat.  This could result in TCP segments being intentionally and legitimately replayed within a connection. TCP-AO prevents replay attacks, and thus requires a way to differentiate these legitimate replays from each other, and so it adds a 32-bit Sequence Number Extension (SNE) for transmitted and received segments."
>> 
>> The RFC continues:
>> 
>> "For transmitted segments, SND.SNE can be implemented by extending TCP's sequence number to 64 bits; SND.SNE would be the top (high-order) 32 bits of that number.  For received segments, TCP-AO needs to emulate the use of a 64-bit number space and correctly infer the appropriate high-order 32-bits of that number as RCV.SNE from the received 32-bit sequence number and the current connection context.
>> 
>> The implementation of SNEs is not specified in this document, but one possible way is described here that can be used for either RCV.SNE, SND.SNE, or both."
>> 
>> Regardless of how SNEs are implemented, SND.SNE and RCV.SNE must be equal. Otherwise, a legitimate segment fails to authenticate and the TCP session hangs.
>> 
>> We test a scenario where:
>> 
>> RCV.SNE is implemented by the pseudocode provided in Section 6.2
>> The following TCP Sequence numbers were processed: 
>> 0xF7358299   >>>>>RCV.SNE = 0
>> 0xF735A57B  >>>>>RCV.SNE = 0
>> 0xC                   >>>>>RCV.SNE = 1
>> 0xF7358299 >>>>>RCV.SNE = 0
>> 0xC                  >>>>>RCV.SNE = 2
>> 
>> The final RCV.SNE is 2. It should be 1.
>> 
>> If SND.SNE were implemented by extending TCP's sequence number to 64 bits,  authentication would fail and the TCP session would hang.
>> 
>> How do we address this problem without creating larger backwards compatibility problems?
>> 
>>                                                                                                Ron
>> 
>> P.S. Thanks to Ping Chen for finding this problem
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> tcpm mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>