[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Looking for info on ipsec passthrough (or passthru?)
"Strahm, Bill" <bill.strahm@intel.com> writes:
> Ok, I looked it up and think I know what "passthru" is.
>
> Getting IPsec through NAT is a VERY hard problem. There isn't an easy way
> of associating (on the wire) that a packet with an SPI of this value needs
> to be demultiplexed to this destination because a packet with another SPI
> went through the NAT gateway...
In the most recent IETF Pittsburgh meeting, there was actually a lot of
interest on this topic. To summarize:
- In general case, IPsec that will pass through NATs will require _at
least_ support from endpoints, and in many of the suggested solutions from
other network components as well (both approaches were given good overview
by Aboba/Dixon).
- There are apparently ways to just make NAT compensate for some of the
changes (as presented by Brustoloni). In this case, the
example NAT was Linux's ipmasq suite.
- Only presented approach for doing endpoint support was our draft
draft-stenberg-ipsec-nat-traversal-00.txt(*).
> Passthru is one way of solving this, basically saying all IPsec traffic
> flows through the NAT to this 1 destination.
Passthru is very ugly hack that doesn't work in European NAT cases at all
(when ISPs do NAT due to lack of sufficient address space, you can't just
have 1 NAT user _total_ at same time..).
> Passthru is a hack until something like RSIP becomes a reality.
I _wish_ RSIP could become reality in short term. But realistically speaking:
RSIP is based on the assumption that all network hardware will change just
to accommodate it - which is the opposite of the assumption made with NAT
deployment in the first place (=quick hack without changing
infrastructure).
I (more realistically?) _hope_ that the deployment efforts will be spent on
IPv6 instead.
> Bill
-Markus
(*)
I'd like to have some discussion on the topic in general on the
list. The draft's version -01 will have a lot of changes based on input
from various sources, but additional input is always welcome.
> ______________________________________________
> Bill Strahm Programming today is a race between
> bill.strahm@ software engineers striving to build
> intel.com bigger and better idiot-proof programs,
> (503) 264-4632 and the Universe trying to produce
> bigger and better idiots. So far, the
> Universe is winning.--Rich Cook
> I am not speaking for Intel. And Intel rarely speaks for me
--
Markus Stenberg <markus.stenberg@ssh.com>
SSH Communications Security Corp (http://www.ssh.com)
References: