[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.

People typically deploy new versions of software because they need
to rather than for performance alone.

> 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. 

A fix is deployable. NAT appeared because IPv6 was not deployable
when the consequences of address depletion began to be felt.


> >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.

According to Tom Knight who attended the relevant meeting 
the size of the registers in a particular model of PDP was 
used to justify the address size, against protests that it 
was insufficient.

> 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.

I find it somewhat anoying that people who complain about the
'evils' of HTTP can ignore the obvious limitations and inefficiency
of FTP which is actually worse on every scale than HTTP requiring
two TCP connections and multiple round trips to negotiate a single
file transfer.


> 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. 

I think that we need to focus on the parts of a protocol that
can reasonably be expected to work through a NAT box and those
which simply should not be expected to work without specific
configuration of the NAT box and possibly the application.

Nobody should expect to be able to run an FTP server over IPSEC
that is behind a NAT box for example. But running an FTP client
for direct retrieval is reasonable.


	Phill

Phillip


Follow-Ups: