Can you please explain your point about transport mode being bad ? We do not see any problem with it in real world deployments. It is quite the opposite actually.
I agree that AH is a hindrance, especially that it protects the non-mutable fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. the main difference between AH and ESP_NULL is really this outer IP header protection which is detrimental in most practical networks. On 15 Nov 2011, at 08:09, Paul Wouters wrote: > On Tue, 15 Nov 2011, Yoav Nir wrote: > >> FreeS/WAN did eliminate transport mode, but that project is dead. The >> project that is active now (strongSwan) does have it. > > <openswan hat> > > So does openswan, which is the continuation project from FreeS/WAN, and had > its most recent software > release just a few weeks ago. But we wish people would not use either > transport mode or AH. > >> RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for >> L2TP over IPsec. That, and the fact that this is the way Microsoft >> implemented their L2TP client is the reason why most gateway vendors have >> implemented transport mode. That and the fact that Cisco like to encrypt >> their GRE tunnels in transport mode. > > openswan also supports multiple L2TP clients behind the same NAT router > and multiple L2TP clients on the same overlapping pre-NAT IP address > using the KLIPS stack with SAref tracking using two new socket options and > ip_conntrack. The NETKEY builtin stack for Linux has no such capability. > > See: > > http://www.openswan.org/docs/ipsecsaref.png > https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd > https://gsoc.xelerance.com/projects/openswan/wiki/Building_and_Installing_an_SAref_capable_KLIPS_version_for_DebianUbuntu > > The same funcionality is used with Openswan to support multiple connections > with customers with > unknown RFC1918 address space that overlaps, which is common in large cloud > deployments. > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
