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

["touch@xxxxxxxxxxxxxx" <touch@xxxxxxxxxxxxxx>]

See below...

—

Dr. Joe Touch, temporal epistemologist

www.strayalpha.com

On Jun 2, 2022, at 8:03 AM, Valery Smyslov <svan@xxxxxxxx> wrote:

HI Joe,

 

On Jun 2, 2022, at 12:55 AM, Valery Smyslov <svan@xxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call