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.
Steffen
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
