NAT

Ryan Russell ryanr@sybase.com
Wed, 17 Jun 1998 12:01:18 -0700


Key management is one problem with NAT, but I'll leave that alone
for the moment.

I'm under the impression that if the IP header of an IPSec packet
gets modified, the packet will get rejected because IP addresses
are part of what's checked for in authentication mode.  I'm also
assuming that authentication mode is wanted/needed when doing
VPN applications.

The problem I'm concerned with is remote-access type VPN
applications.  This is where I send users running around the world
with a piece of software on their laptops, and they get whatever
kind of Internet access they can.  This would include sitting
on someone else's net, and going out through their firewall.
I think the IPSec method of transport is going to have limited
value in those situations, and we'll need something simpler
for a transport, like a TCP connection.

                    Ryan






Rick Smith <rick_smith@securecomputing.com> on 06/17/98 11:49:16 AM

To:   Ryan Russell/SYBASE
cc:   Tina Bird <tbird@iegroup.com>, "'firewall-wizards@nfr.net'"
      <firewall-wizards@nfr.net>
Subject:  Re: NAT




At 09:53 AM 6/17/98 -0700, Ryan Russell wrote:
>
>Your first paragraph clears it up, thanks.  If the IPSec happens
>after NAT, it makes perfect sense.  When one wants to use
>NAT with IPSec, then the device doing NAT would have to participate
>in the IPSec connection.

Why couldn't you put an outboard IPSEC box between the external network and
the box performing NAT? Again, the IPSEC implentation would only see the
translated addresses.

>That would imply that one couldn't get an IPSec connection
>through a box that did NAT/proxy when that box didn't
>participate in the connection.  I think that's going to be
>a major problem for IPSec based VPN soultions.

I generally think of VPN solutions as providing protection to traffic
*outside* a site, so I don't see a problem here. The NAT box sits at the
site boundary.

But if there's a requirement for end to end IPSEC crypto, then NAT would
throw a large and nasty monkey wrench in the middle. Perhaps you were
alluding to in your last message: NAT leaves you nothing to hand a security
association on when you're configuring the system. If you're using ISAKMP,
there's no mechanism to pass your key negotiation through to the endpoint
host. Even then, some ISAKMP modes only work if you have predictable IP
addresses.

Rick.
smith@securecomputing.com


Received: from tunnel.sybase.com ([130.214.231.88]) by ibwest.sybase.com
(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998)) with SMTP id 88256626.0067DEA6;
Wed, 17 Jun 1998 11:54:32 -0700
Received: from smtp1.sybase.com (smtp1 [130.214.220.35])
          by tunnel.sybase.com (8.8.4/8.8.4) with SMTP
       id LAA25949 for <Ryan_Russell@tunnel-w>; Wed, 17 Jun 1998 11:52:14
-0700 (PDT)
Received: from halon.sybase.com by smtp1.sybase.com
(4.1/SMI-4.1/SybH3.5-030896)
     id AA12782; Wed, 17 Jun 98 11:52:13 PDT
Received: from beach.sctc.com (beach.sctc.com [192.55.214.50])
          by halon.sybase.com (8.8.4/8.8.4) with ESMTP
       id LAA12366 for <ryanr@sybase.com>; Wed, 17 Jun 1998 11:52:04 -0700
(PDT)
Received: from beach.sctc.com (root@localhost)
     by beach.sctc.com with ESMTP id NAA11320;
     Wed, 17 Jun 1998 13:53:28 -0500 (CDT)
Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3])
     by beach.sctc.com with ESMTP id NAA11316;
     Wed, 17 Jun 1998 13:53:27 -0500 (CDT)
Received: from shade.sctc.com (shade.sctc.com [172.17.192.48])
     by sphinx.sctc.com (8.8.5/8.8.5) with SMTP id NAA22754;
     Wed, 17 Jun 1998 13:53:07 -0500 (CDT)
Received: from bowtie (bowtie.sctc.com [172.17.65.169]) by shade.sctc.com
(8.6.12/8.6.9) with SMTP id NAA14232; Wed, 17 Jun 1998 13:53:06 -0500
Message-Id: <3.0.3.32.19980617134916.00924b10@mailhost.sctc.com>
X-Sender: smith@mailhost.sctc.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Jun 1998 13:49:16 -0500
To: "Ryan Russell" <ryanr@sybase.com>
From: Rick Smith <rick_smith@securecomputing.com>
Subject: Re: NAT
Cc: Tina Bird <tbird@iegroup.com>,
        "'firewall-wizards@nfr.net'" <firewall-wizards@nfr.net>
In-Reply-To: <88256626.005C3DA0.00@gwwest.sybase.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"