[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 and NAT traversal
On Mon, 17 Dec 2001, Hallam-Baker, Phillip wrote:
> The ability to support NAT reliably is likely to become the main value add
> that son-of-IKE provides to end users.
I think that's only one of several issues, and would note better
performance and explicit support for more complex tunnel endpoints (not
just a single subnet on each end) as others. But NAT traversal certainly
is significant.
> It is disappointing that there is still a faction still peddling the 'if you
> are NAT on the NET you are not on the NET' dogma. NAT is what you get when
> you architect a network with a built in upper bound of 4 billion addresses
> on a planet with a human population of ten billion, it fixes a bug in the
> design of the Internet...
Uh, no. The bug is *fixed* by larger addresses, e.g. IPv6. NAT is a
kludge, a workaround, with serious disadvantages. That said, it is
(unfortunately) a popular and widespread kludge which cannot be ignored,
much though that would simplify life.
>that was introduced so that an IP address
>would fit in a register on a long defunct machine...
The Internet infrastructure machines at the introduction of IPv4 did not
have 32-bit registers. Try 16. The size of the IPv4 address was set by
considerations of design, not implementation. Unfortunately, the design
situation looked very different then than it does now, and tradeoffs which
seemed good then are proving problematic now.
> One solution to this that occurs to me is to modify the key agreement so
> that the sender tells the reciever the IP address that they believe that
> they are using and the responder tells the sender the one that it sees...
> permitting the responder to affect repairs to the said damaged packets.
Care would be needed to avoid chicken-and-egg problems here -- the
information needed to make repairs can't be exchanged by mechanisms which
assume repair is already possible! That said, this has potential.
> I am less bothered by the secondary points in the requirements document
> about applications that rely on IP addresses embedded in protocols. I
> suspect that such protocols break anyway when they pass through the current
> generation of NAT...
No, they don't, because current-generation NAT software contains special
kludges to fix the packets of such protocols. This is not easy to do, and
it relies on imperfect heuristics, but it works well enough that (like NAT
itself) it cannot be ignored. Note that FTP is among the affected protocols.
However, in most IPsec situations there is little that can be done about
it. There simply is no way to do benign surgery on packet innards without
causing IPsec authentication failures, even if you have access to the
innards at all, which you don't if they're encrypted.
Henry Spencer
henry@spsystems.net
Follow-Ups:
References: