[tcpm] Re: I-D Action: draft-ietf-tcpm-tcp-ghost-acks-06.txt

["yepeng.pan" <[e-mail]>]

Hi All,


I just read the current 07 draft once more.

It feels the current section 3 could be merged into section 2 and would 
also provide better transition;

For example:

 > 2. Ghost ACKs:

     ...

As a concrete example, consider a newly established TCP connection 
without data transferred during the handshake. There is|SND.UNA == 
SND.NXT == ISS + 1|.In this case, any segments with|SEG.ACK < 
SND.UNA|acknowledges bytes that the endpoint has never sent, but they 
are still considered acceptable since they satisfy the 
above|SEG.ACK|validation condition.

Ghost ACKs thus ease blind payload injection attacks, particularly for 
newly established TCP connections and potentially spoofed TCP connections.


and then section 3 can be removed.




Best regards

Yepeng Pan


On 7/2/2026 12:04 PM, Michael Tuexen wrote:
>> On 2. Jul 2026, at 03:46, Yoshifumi Nishida<[e-mail]> wrote:
>>
>> Hi Michael,
>>
>> Thanks for the reply. I put my comments in lines.
>>
>> On Mon, Jun 29, 2026 at 11:29 AM Michael Tuexen<[e-mail]> wrote:
>>
>>> 2: Section 4.1
>>>     TCP stacks that implement this mitigation SHOULD add the additional boolean
>>>     state variable NO_ISS_CHECK for each established connection. This variable
>>>     SHOULD be initialized to false. At the beginning of the SEG.ACK validation,
>>>     it SHOULD be checked if the ISS is still needed:
>>>
>>> Should we use MUST instead of SHOULD if we don't have other choice?
>> The code was using a mixture of SHOULD and MUST. I think needs to be
>> consistent. I suggested SHOULD, since, for example, the FreeBSD implementation
>> does not use a boolean variable, but a flag on the TCPCB. I guess this is
>> covered by a SHOULD, but not by a MUST.
>>
>> OK. If there are other ways, I'm fine with SHOULD.
>>    > Also, I'm wondering if we need the last sentence with RFC2119 word.
>>> Something like the following might be enough?
>>>
>>>     This variable SHOULD be initialized to false in order to check if ISS check is needed
>> There are two things here:
>> 1. How NO_ISS_CHECK is initialized. This happens when the endpoint is created.
>> 2. At the beginning of the SEG.ACK validation it should be check if the ISS based check
>>     is needed. This happens every time an incoming TCP segment is processed.
>> So I think keeping the two things in separate sentences is a good thing. They happen
>> at different times. Therefore, both should use RFC 2119 terminology.
>> I agree, the wording of the last sentence can be improved. What about:
>>
>> At the beginning of the <tt>SEG.ACK</tt> validation, it <bcp14>SHOULD</bcp14>
>> be determined if the <tt>ISS</tt>-based check is still needed:</t>
>>
>> Yes, works for me.
>>
>>> 4: Section 4.2
>>>     A local variable ACK.MIN SHOULD be computed, which is used to validate the SEG.ACK.
>>>
>>> SHOULD -> MUST? if there is no other choice
>> See above. Here, you could avoid using the local variable, but compute its value
>> whenever needed. Covered by a SHOULD, but not by a MUST.
>>
>> OK.
>>
>>> 5: Section 4.2
>>>     An implementation has to deal with tcpEStatsAppHCThruOctetsAcked overflows.
>>>
>>> This may look a bit ambiguous guidance. How about something like this?
>>>
>>>     An implementation MAY handle tcpEStatsAppHCThruOctetsAcked overflow.
>> What about SHOULD? As far as I know, Linux does not handle it...
>>
>> SHOULD is also fine for me.
> Great. All your comments have been addressed in revision 07.
>
> Best regards
> Michael
>> --
>> Yoshi
>> _______________________________________________
>> tcpm mailing list [e-mail]
>> To unsubscribe send an email [e-mail]