Forgive me if I do not see botching the IPSEC spec so that it fails through NAT as an argument against NAT. Why don't we repair the damage instead? If we are serious about the IPv6 transition then we should be insisting that IPSEC work transparently over NAT46 and NAT64. Its easy enough to solve the NAT issue in IPSEC. Just extend the key agreement so that the endpoints inform each other of the IP address that they believe to be in use and store that with the key data required to check the MAC. Then consider fixing up the IP address to be part of the verification function. Problem solved - unless some patent troll has claimed this rather obvious fix. The IETF can choose not to add it to the standard, and thus choose to ensure that IPSEC connectivity remains fragile. But that is a really lousy way to respect your customers. Authenticating the IP address is totally unnecessary from a security point of view, the data can only be checked at the security association endpoint. So if the packet has got there the address can't have been too far wrong. Further the binding of the key to the security association is going to be keyed of the IP source and destination addresses so it is rather hard to see how an attacker can gain from manipulating the IP addresses. Probably simpler to just declare some dummy algorithm identifiers for HMAC-SHA256 ignoring the IP addresses. And you can probably use the exact same hack to make the connection NAT46/64 agnostic, though to be honest I have not thought the issue through. OK back to polishing the moulds for my robot. On Mon, Nov 9, 2009 at 10:11 PM, Sabahattin Gucukoglu <mail@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 8 Nov 2009, at 16:22, Phillip Hallam-Baker wrote: >> >> There are two typical modes of deployment for IPSEC, the first is as a >> lousy remote access protocol where the lack of NAT support makes it >> far more effort than other solutions. SSL and SSH remote access just >> works, IPSEC VPN may or may not work depending on the phase of the >> moon. The third party clients are terrible, the built in support in >> the O/S is unusable because it does not have the tweaks necessary to >> get through the firewall. So we do not really have a standard for >> IPSEC remote access. > > There's at least one product making actual money in this space, Hamachi ( > http://www.hamachi.cc/ ). Basically third-party-mediated IPSec-lite that > goes over NAT. If you must use NAT, at least be aware of what can come back > to your network due to NAT behaviour and internally initiated connections. > I don't think NAT is providing the right kind of security here. But I must > be careful not to start another flame war. > > But anyway, IPv6/Teredo does the same thing, and better; Microsoft is > working on going that extra mile with IP over HTTPS, too, so soon we'll have > peer-to-peer VPNs that really do "Just work". In every case it is better > than Hamachi's use of unassigned address space, and in no case better than > fixing the trouble at the root, and shredding NAT. > > But, if NAT's your thing ... > > Cheers, > Sabahattin > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf