Re: NAT Not Needed To Make Renumbering Easy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]