[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (NAT) Interactions between IPSEC and NAT (fwd)
Forwarded message:
>From owner-nat Wed Feb 4 12:09:27 1998
From: Pyda Srisuresh <suresh>
Message-Id: <199802042008.MAA28067@server.livingston.com>
Subject: Re: (NAT) Interactions between IPSEC and NAT
To: Dan_Nessett@tdc.3com.com
Date: Wed, 4 Feb 1998 12:11:58 -0800 (PST)
Cc: ipsec@tic.com, nat@livingston.com, gabriel.montenegro@eng.sun.com,
vipul.gupta@eng.sun.com
In-Reply-To: <v03020911b0fde01d764e@[139.87.182.230]> from "Dan Nessett" at
Feb 4, 98 09:04:05 am
Content-Type: text
Sender: owner-nat
Precedence: bulk
Reply-To: Pyda Srisuresh <suresh>
Hi,
Please note my comments below.
cheers,
suresh
>
> Folks,
>
> I haven't been following the NAT discussions real closely, so let me know
> if this has already come up. There seems to be a real problem for NAT when
> end to end IPSEC is used. Since the NAT system must look into application
> data and change embedded IP addresses (e.g., for FTP PORT commands), if the
> session is encrypted, this is not possible. Further exacerbating the
> problem is that FTP seems to be unusual in carrying control and data on
> separate associations, so for many applications you can't even play tricks
> like not encrypting the control traffic end-to-end, but encrypting the data
> traffic.
You could play this trick and NAT wouldnt have a problem with it. FTP control
and data pkts would traverse transparantly through the NAT router. NAT
routers do not look into the payload of FTP data sessions.
>
> This seems to lead to a model where IPSEC tunnels are used from the end
> system to the NAT box, then from the NAT box to the remote system (or to
> the remote NAT box, which tunnels to the remote system). These are IPSEC
> tunnels not PPTP or L2TP tunnels. This imposes a pretty ugly trust model.
>
I understand, having a NAT box doing any kind of mods sitting between two
end nodes is not acceptable for end-to-end security stand point.
A recent draft, titled "NAT bypass for end-2-end sensitive applications",
by George Tsirtsis and Alan Oneil (<draft-tsirtsis-nat-bypass-00.txt>)
offers an alternative solution where end-2-end security is preserved.
To put things in perspective, I think, the above draft has parallels
to an entirely different draft from Mobile IP group by G. Montenegro and
V. Gupta, titled "Firewall support for Mobile IP"
(<draft-montenegro-firewall-sup-03.txt).
The mobile IP draft attempts to setup a secure communication mechanism
for a roaming private node to access corporate servers from the Internet
at large. In particular, one of the solutions involve using a SKIP based
secure channel between the mobile node and firewall and another secure tunnel
from firewall to corporate server (section 6.4).
With NAT, the roles are somewhat reversed. A node in a private network
seeking access (sort of like roaming about ) to an external node has to
get past a NAT router (unlike the firewall in mobile node case). This becomes
possible by the private node using two IP addresses. One, a fixed address
in private network, and the second a co-located global IP address assigned
for temporary use by NAT router. The private node would generate packets
using the global address, yet tunnel these packets over the local private
network to the NAT router. A second secure channel from the NAT router to
external node would complete the end-2-end secure connection between two
end nodes. Sounds reasonable?
Authors for either of the drafts, please feel free to flame if I
misstated any of the material here. Thanks.
<
> Anyone thought about this so that they can provide us with a nice clean
> answer :-) ?
>
> Dan
>
>
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe nat' in the body of the message.
>
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe nat' in the body of the message.