[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC and NAT
At 01:42 PM 8/27/97 -0400, Theodore Y. Ts'o wrote:
>
>Interactions with IPSEC is just one such example of an additional cost
>of NAT's. (And let us be clear that it is a cost imposed by NAT's, not
>by IPSEC, as it is the NAT boxes which broke a fundamental property of
>the Internet architecture.)
Even given rully routable addresses, there are sever problems with routing.
Let's say that You and I wish to communicate securely over the public
portion of our connection, ie from your desk to my gateway. Since I have
lots of IPsec gateways all over the company, all with different Internet
access, there is an interesting challenge of how the packets will make it
back to the appropriate gateway from my system.
Now I could use source routing within my network. The gateway could add
the appropriate source routing information so that my system would send the
packet back. But then do I want to allow source routing within my network?
Is this 'safe networking' or playing it a little too fast and loose (btw
my network support colleagues will know that I have flipped if I ask for
internal source routing).
Alternatively I dould do dynamic route announcement at the /32 level, or
can I? Let's say that not only are you communicating with me that would go
through our Outer Drive gateway, but also to a manufacturing engineer over
at the Jefferson Rd plant (senior Jeeps) through the gateway over at Dodge
City. How do I get the packets back to the proper gateway? I would have
to block the propagation of the route. No, this would be an administration
nightmare; where do I block what?
So dynamic route announcements are out. Source routing may be unwise.
What is left? NAT is left. I change the source address of the packet as
it leaves the tunnel, before it gets dropped on my network. Such a packet
will have not no problem getting back to appropriate gateway. Each gateway
would need a pool of addresses on the private size based on the number of
concurrent remote systems that the gateway can support. But hey, I've got
32 B networks in 1918! Lots of addresses to burn.
Of course, if I had IPsec on those internal systems and we knew how to
chain IPsec tunnels, I also fix the routing problem. Well maybe; if both
systems use the same 1918 network, there could be some interesting IP
kernel challenges (and what if they have the same address!).
This is why I am very interested in what I call 'advanced VPN'. Chained
IPsec tunnels with potentially a nested IPsec transport. Attention Karen
and Steve, I will be submitting my nesting order requirements shortly; been
busy with AutoTech. This methodology obviates the routing challenge.
So Ted, Tim, the rest of you. IPsec and even NAT is not my problem. My
(and so many corporations) problem is a routing problem. IPsec aggrevates
it by interducing foreign addresses to our routing domain. BGP4 is a bit
much to take on, and perhaps it is not so much the answer. Is IDPR or
NIMROD the answer. Oh, btw, Chrysler does have a BGP3 backbone, one of the
few companies to take this path for managing routes in our internal internet.
PS. I will have to add to my IPsec-vpn-nat ID a source route option to
Network types C and D as the destination networks....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
References: