On Thu, 28 Nov 2019, Valery Smyslov wrote:

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 sadly agree. I was quite shocked to recently learn that Cisco prefers
GRE over Transport Mode for _all_ of their subnet to subnet configurations and
they consider their policy based VPN configs using cryptomap "obsolete".

3. I think that using new Transform Type for IP-TFS negotiation is a bad idea.

I also prefer to see a USE_IPTFS notify similar to USE_TRANSPORT and 
USE_COMPRESS.

7. I don't think that late-enabling of IP-TFS described in section 2.4
   is really needed. It adds unnecessary complexity and somewhat contradicts
   to what is stated in section 2.3.

I agree. It would also have to specify a PF_KEY/NETLINK type message
because the userland IKE daemon must know this has happened, to be
able to reject/accept or at least log this event. If the only goal is
debugging, then we should just not allow this. The same could be
achieved by rekeying the child sa with the USE_IPTFS notify (which
would be another reason not to use a transform, because those must
not change during rekey)

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to