On Mon, Dec 02, 2019 at 06:22:26AM -0500, Christian Hopps wrote: > > On Dec 2, 2019, at 3:01 AM, Steffen Klassert <steffen.klass...@secunet.com> > > wrote: > > On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote: > > > >> 4. I'd like to see more text in the draft regarding reassembling of > >> incoming packets. > > > > Yes, I think some words on how to reassemble the fragments are really > > needed. > > > >> It seems to me that it can be done pretty easy by linking the > >> reassembly logic > >> with replay protection window. > > > > While it looks like doing the reassembling based on ESP sequence numbers > > might be an easy approach, it could be also dangerous. > > > > Consider a system that encapsulates two flows on different cpus > > with the same SA. This system can TX packets in the following > > order: > > > > TX cpu0 inner flow0 SA0: > > > > Offset: 0 Offset: 100 > > [ ESP1 (1500) ] [ ESP3 (1500) ] > > [--800--][--800- -][-----1400---] > > > > -------------------------------------------------------------------------------------- > > TX cpu1 inner flow1 SA0: > > Offset: 0 Offset: > > 100 > > [ ESP2 (1500) ] [ ESP4 > > (1500) ] > > [--800--][--800- > > -][----1400----] > > > > > > On the receive side, it is not that clear how to reassemble the fragments > > from ESP3 and ESP4 into the fragments from ESP1 and ESP2. Maybe some > > packet ID in the IP-TFS header could help to identify related fragments. > > Indeed the code mustn't fragment this way. :) > > We could add a bit of text that one should avoid this mistake.
I'm not so sure whether the receiver should rely on that the sender did the fragmentation right. I think a packet ID, like IP fragments have, would just solve the problem. The implementation would not even need to care about this multicore race then. Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
