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(_at_)sabahattin-gucukoglu(_dot_)com> 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(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf