Re: Looking for info on ipsec passthrough (or passthru?)
Markus Stenberg <mstenber@ssh.com> Thu, 31 August 2000 13:16 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19544; Thu, 31 Aug 2000 06:16:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00713 Thu, 31 Aug 2000 07:34:03 -0400 (EDT)
To: "Strahm, Bill" <bill.strahm@intel.com>
Cc: "'John C. Day'" <JCDay@JCDay.com>, ipsec@lists.tislabs.com
Subject: Re: Looking for info on ipsec passthrough (or passthru?)
References: <7DAA70BEB463D211AC3E00A0C96B7AB20344B9E8@orsmsx41.jf.intel.com>
From: Markus Stenberg <mstenber@ssh.com>
Date: Thu, 31 Aug 2000 16:40:07 +0900
In-Reply-To: "Strahm, Bill"'s message of "Wed, 30 Aug 2000 08:45:21 -0700"
Message-ID: <87d7ipanfs.fsf@porsas.tokyo.jp.ssh.com>
Lines: 63
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"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)
- Looking for info on ipsec passthrough (or passthr… John C. Day
- RE: Looking for info on ipsec passthrough (or pas… Strahm, Bill
- RE: Looking for info on ipsec passthrough (or pas… John C. Day
- RE: Looking for info on ipsec passthrough (or pas… Michel de Koning
- Re: Looking for info on ipsec passthrough (or pas… Markus Stenberg
- RE: Looking for info on ipsec passthrough (or pas… Strahm, Bill
- RE: Looking for info on ipsec passthrough (or pas… Michel de Koning