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