Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

See below...
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jun 2, 2022, at 8:03 AM, Valery Smyslov <svan@elvis.ru> wrote:
> 
> HI Joe,
>  
> On Jun 2, 2022, at 12:55 AM, Valery Smyslov <svan@elvis.ru <mailto:svan@elvis.ru>> wrote:
>>  
>> HI Joe,
>>  
>> one more question:
>>  
>>           You can also note that there are ways to mitigate the cost of resync when
>>           this implementation is tightly coupled with TCP, e.g., by ensuring every Nth
>>           IPsec packet starts at the beginning of a new TCP packet.
>>  
>>          How would this help? Can you please elaborate?
>  
> If every 4th IPsec packet is always aligned to the TCP segment data start, then resync checks could be simple and rapid - check only the first bytes for a known pattern.
>  
> That makes resync happen with lower overhead, i.e., rather than searching the whole payload.
>  
>           Interesting idea, but how the receiving node would know that sending node employs this method?

They don’t need to. Basically the receiver should “check a few places until it wants to give up”. There’s no rule that resync must be exhaustive, but if it succeeds, it averts the need for a new connection.

>           And, in my understanding some middleboxes can re-arrange TCP segments, merging and splitting them,

They DO this, as do some offloading devices, sometimes in ways that break TCP. But that doesn’t matter here - again, at the receiver, it either works or it doesn’t.

>           so the beginning of IPsec packet may still appear in the middle of TCP segment (the same can happen
>           with retransmissions, but I guess you assume that sending TCP/IP stack would take care in this case, but it adds complexity).

Retransmissions don’t need to realign; the sender can just do this on first transmission. It’s just an optimization that helps the receiver potentially resync faster or not need to give up on resync as quickly.

>  
>          So, I think that the idea is interesting, but the additional complexity and unreliability makes it not so attractive.

It doesn’t need to be reliable to be useful, as per above.

>  
>           Regards,
>           Valery.
>  
> Joe
> -- 
> last-call mailing list
> last-call@ietf.org <mailto:last-call@ietf.org>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>