> On Dec 2, 2019, at 3:01 AM, Steffen Klassert <[email protected]>
> wrote:
>
> On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote:
>> Hi,
>>
>> after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts.
>>
>> 1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS for
>> transport mode ESP
>> is equally important because one of the widely used scenario is to
>> combine general purpose
>> tunneling (like GRE) with transport mode ESP. In this case traffic
>> flowing over such SA
>> will in fact be tunnel traffic from several hosts, but the SA is created
>> in transport mode.
>> For this reason I think that IP-TFS must support transport mode SA either.
>
> I'd like to agree here. It does not add much more complexity and there are
> valid usecases
> for transport mode (and even for BEET mode).
>
>> 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.
One way to implement this is using a queue of packets to order the
transmission. The flows (using any number cpus) add their packets to the queue.
The IP-TFS ESP encapsulation code (again using any number of CPUs) remove
packet fragments, in order, from the queue when constructing the IP-TFS ESP
packets. The SA ESP sequence number stored with the queue.
Another way to do this (the way we are coding it) is to queue pre-built IP-TFS
payloads directly onto a queue. In this case you have an "in-progress" payload
that you add the next packet to while the queue is locked. If you fill this
in-progress payload you simply move it to the send queue and start a new
in-progress payload, repeat if need be until the whole packet is present in the
queue, then you unlock the queue. The send routine (again running on any number
of CPUs) dequeues, encrypts and sends the payloads.
For the second method the payload construction is very quick as we are not
doing buffer copies, but simply using buffer chaining/indirection, so the queue
lock is not problematic.
Thanks,
Chris.
> Steffen
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
