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)