Re: NAT

[Paul Sangster <sangster () reston ans net>]

On Wed, Jun 17, 1998 at 12:01:18PM -0700, Ryan Russell wrote:
> 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.

Not every mode of IPSEC authenticates the outermost IP header, thus
preventing external NAT.  If the VPN nodes are using ESP in tunnel
mode with authentication (for instance) the new outer IP header is
not protected by the authenticator so it can be changed in transit.
Here's the packet diagram from the specs:

                 BEFORE APPLYING ESP
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------
 
                 AFTER APPLYING ESP TUNNEL
            -----------------------------------------------------------
      IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
            |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
            -----------------------------------------------------------
                                |<--------- encrypted ---------->|
                          |<----------- authenticated ---------->|

However, using AH whose goal is to protect the outer IP header from
in transit modifications will not allow NAT tampering.  Notice its
authenticator covers the entire packet:

                 AFTER APPLYING AH TUNNEL
            ------------------------------------------------
      IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
            |(any options)| AH | (any options) |TCP | Data |
            ------------------------------------------------
            |<- authenticated except for mutable fields -->|
            |           in the new IP hdr                  |

I think the most flexible solutions will provide IPSEC and NAT on the
same nodes so as to allow NATing the addresses just before the packet
gets authenticated.  Even this won't deal with all the 'real world'
NAT issues, hopefully the combination of the fact that creating
tunnels itself causes a source NAT to occur (all tunnel protected packets
has a new source of the IPSEC node) and the potential to use NAT boxes
inside the VPN links can solve many problems.

> 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.

Depends on the remote sites security policies.  If the remote customers
isn't willing to let unrestricted tunnel come out of their network (such 
as an IPSEC or other tunneling protocol) then your right.  In fact I
suspect many firewalls won't be able to pass IPSEC packets anyway unless 
they support IPSEC to begin with as AH and ESP are IP level protocols (AKA
don't ride on TCP or UDP).  Of course the packet filter type firewalls
are good at blindly passing protocols so they'll be able to do it :).

Paul

> 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"

-- 
_______________________________________________________________________
                            Paul Sangster 
 ANS Communications                       Senior Software Engineer
 1875 Campus Commons Dr.                  sangster () reston ans net
 Suite 220,  Reston VA 22091              http://www.ans.net/InterLock
_______________________________________________________________________

Attachment: _bin
Description: