[42199] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: IPSEC and PAT

daemon@ATHENA.MIT.EDU (Tim Irwin)
Fri Sep 14 00:47:51 2001

Reply-To: <tim@eng.bellsouth.net>
From: "Tim Irwin" <tim@eng.bellsouth.net>
To: "Steven M. Bellovin" <smb@research.att.com>,
	"Vandy Hamidi" <vhamidi@insweb.com>
Cc: <nanog@merit.edu>
Date: Fri, 14 Sep 2001 00:42:40 -0400
Message-ID: <LCEKLACNFGLMOPOGNBNMMEBBCEAA.tim@eng.bellsouth.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20010914014348.6E3177BFD@berkshire.research.att.com>
Errors-To: owner-nanog-outgoing@merit.edu


> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
> Steven M. Bellovin
> Sent: Thursday, September 13, 2001 9:44 PM
> To: Vandy Hamidi
> Cc: nanog@merit.edu
> Subject: Re: IPSEC and PAT
>
>
>
> In message
> <912A91BC69F4D3119D1B009027D0D40C01BB45A7@exchange1.secure.insweb.co
> m>, Vandy Hamidi writes:
> >It is working now.  I've done it with Linksys and Netopia DSL routers.
> >Software client on the laptop that DOES tunnel mode ESP.  No AH
> and running
> >through a PAT and it works flawlessly.  I just want to know how it works,
> >I've already determined that it does.
> >The point where my logic fails is where PAT relies on modifying
> the TCP/UDP
> >port numbers, an ESP packet has a standard IP header with an additional
> >protocol 50 ESP header.  Since there is no ports to change to
> create a table
> >to keep track of which packet came from which internal client,
> what is used
> >to keep track.
> >Someone said something about the UDP encapsulation, but what about the
> >NETOPIA which doesn't do that?
>
> I repeat -- it doesn't do PAT.  Some "routers" -- they're really no
> such thing, of course; they're NAT boxes and/or bridges -- allow one
> host behind them to speak IPsec.  If a host emits a packet using ESP,
> it's tagged as *the* IPsec user; return IPsec packets are routed to
> that host.  (Some of these boxes may use manual configuration instead
> or in addition.)  You can't have two IPsec hosts, because there's no
> way to know which should receive incoming packets -- there's no
> relationship between inbound and outbound SPIs.
>
> As for the UDP encapsulation -- yes, the IETF's IPsec working group is
> moving in that direction.  But it's not standardized yet, and there may
> be patent issues to sort through.

I looked at this a while back... I am dusting off the cobwebs of my mind, so
no flames please.  I believe that the NATing device must modify the SPI
values.  The sending device sends out an ESP packet with src addy of, say
192.168.1.2, to the NAT router.  The router must look at the TCP port to
determine that it's IPSEC in order to figure out that it's a special case
and NAT it.  It then must modify the SPI value (which is partially made up
of the src IP address) as it leaves because the NAT dst device will use the
info in the SPI value in the formulation of it's reply.

If this is wrong, please correct me... I'm interested in knowing as well.

FWIW, I was recently told by one vendor that some company has developed a
technology that will support multiple NAT'ed clients and that they have
patented this concept.  Anyone know if there is any truth to this or who
might have developed said patent?

Regards,
Tim


> 		--Steve Bellovin, http://www.research.att.com/~smb
> 				  http://www.wilyhacker.com
>
>



home help back first fref pref prev next nref lref last post