[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC Security Gateways & NAT
----- Original Message -----
From: "Chris Trobridge" <CTrobridge@baltimore.com>
> No, it doesn't address the problem. The problem is that service providers
> (rather than ISPs) have provided NAT-based VPNs without any thought of the
> long-term impact of this on security - and IPSEC in particular. The
> introduction of IPSEC, in particular, renders 'cheap' NAT solutions
> ineffective and this leaves the SPs in a spot of bother. Naturally, this
> gets taken out on the security providers ;-).
>
> This is a different problem to the more common one of running NAT on the
> public SG addresses.
>
> The introduction of IPSEC prevents service providers from providing a
> transparent VPN solution (to a group of conflicting networks) because
IPSEC
> prevents them from manipulating the private addresses with NAT. The best
> (cheapest) solution is to put NAT on the security gateway but this moves
the
> solution away from them and, presumably, some of their revenue - if only
on
> future contracts. (this is related to the control issue over crypto
> managment, which is something customers appear to want to retain)
>
What you are looking at is an end-to-end VPN that can
traverse through multiple NATs, right?
> Thanks for your attention anyway. I wasn't expecting a solution. I was
> interested to see if anyone would pop up with a proprietary solution but I
We have a solution.
> think it's beyond even that! Roll on IPv6 and the abandonment of NAT...
>
Even if you use IPv6, you run into the same problem
when you install a proxy. Can you conclusively say
that you will never need to use proxy in IPv6?
NAT provides a level of protection from outside
scrutiny of your internal network that is very valuable.
I don't know if people will be willing to give up NAT
even when IPv6 is deployed.
regards,
Jayant
> Chris
>
> > -----Original Message-----
> > From: Riley, Susie [mailto:Susie_Riley@adc.com]
> > Sent: 11 June 2001 16:08
> > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com
> > Subject: RE: IPSEC Security Gateways & NAT
> >
> >
> > if the security box is encrypting everything - traffic
> > destined for the vpn
> > box at the other side, as well as traffic destined for some other site
> > (internet), then all the traffic will end up at the vpn box
> > at the other
> > side, and i'm assuming there would be a router somewhere on
> > the other side's
> > network which will sort out the traffic and route internet
> > destined traffic
> > back out, and keep the locally destined traffic. the isp at
> > the other end
> > connected to the router could then perform nat if necessary.
> >
> > if the security box has more smarts, it can encrypt only the
> > vpn destined
> > traffic and send in the clear the internet destined traffic.
> > in this case,
> > the isp could perform nat on the internet destined traffic (it's not
> > encrypted), and nat on the outer layer of the tunneled
> > traffic (it doesn't
> > care about the inner addresses since it's ending up in the customer's
> > intranet anyway).
> >
> > would these approaches address some of the issues, and are
> > there problems
> > with these approaches that you can see?
> >
> > susie
> >
> > -----Original Message-----
> > From: Chris Trobridge [mailto:CTrobridge@baltimore.com]
> > Sent: Monday, June 11, 2001 9:27 AM
> > To: Riley, Susie; Joern Sierwald; ipsec@lists.tislabs.com
> > Subject: RE: IPSEC Security Gateways & NAT
> >
> >
> > The ISP wants to muck around with the inner addresses to cater for
> > overlapping address ranges between different sites.
> >
> > The trouble is that there have been various cases where ISPs
> > have 'solved'
> > their customer's VPN problem with NAT prior to introducing
> > security. This
> > means they've often used NAT to move datagrams over their
> > network, as well
> > as to avoid overlapping subnets. I've also seen it used for
> > more esoteric
> > purposes.
> >
> > The above illustrates a scenario where the ISP has invested
> > in NAT'ing the
> > customers addresses. When the ISP adds encryptors they
> > expect the existing
> > network to need no change but IPSEC security gateways tunnel
> > and break their
> > model. So the ISP will ask "can you use transport mode?", so they can
> > continue to NAT. However, I'm not convinced this would work
> > as NAT ALGs
> > will still not have access to the TCP/UDP payloads for the
> > application-level
> > NAT. Even without ALG, this would also require the transport
> > headers to be
> > passed in clear.
> >
> > Of course, as the IPSEC SG only needs one external address,
> > there's little
> > point for NAT on the ISP side anymore. And the ISP is still
> > required to
> > provide a transparent solution to the customer but isn't
> > trusted with the
> > security.
> >
> > Chris
> >
> > > -----Original Message-----
> > > From: Riley, Susie [mailto:Susie_Riley@adc.com]
> > > Sent: 11 June 2001 13:23
> > > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com
> > > Subject: RE: IPSEC Security Gateways & NAT
> > >
> > >
> > >
> > > if you are trying to put an encryption/vpn box between the
> > > customes sites
> > > and the isp, the address assignment by the isp should be
> > for the outer
> > > tunnel address (to be used by the vpn box to tunnel the
> > > traffic). in this
> > > case, as people suggest, esp+udp should work for nat, and
> > > it's the outside
> > > address the isp might muck with - not the inner address
> > > because as far as
> > > the isp is concerned, there's only one box behind it, and that's the
> > > ipsec/vpn box. as far as the isp is concerned all the boxes
> > > behind the
> > > ipsec/vpn box could be using private addresses and it should
> > > not care. can
> > > you describe a scenario where the isp would want to muck with
> > > both inside
> > > and outside addresses in a ipsec/vpn scenario, or are you
> > > talking about a
> > > different scenario altogether?
> > >
> > > susie
> > >
> > > -----Original Message-----
> > > From: Chris Trobridge [mailto:CTrobridge@baltimore.com]
> > > Sent: Thursday, June 07, 2001 10:25 AM
> > > To: Joern Sierwald; ipsec@lists.tislabs.com
> > > Subject: RE: IPSEC Security Gateways & NAT
> > >
> > >
> > > The scenario I'm talking about is where the service provider
> > > wants to NAT
> > > the private addresses, ie the inner addresses if tunnelling.
> > > Obviously this
> > > is completely contrary to the RFCs but ownership/management
> > > issues make it
> > > hard to place the NAT before encryption (when customer
> > > encrypts and service
> > > provider NATs).
> > >
> > > I don't think it can be done but I'm looking for some
> > > consensus or other
> > > evidence on this point.
> > >
> > > Chris
> > >
> > > > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode,
> > > > and insert a UDP header in front of the ESP header. This is
> > > > dead simple and works with normal NAT boxes.
> > > >
> > > > Problems and solutions:
> > > >
> > > > - some NAT boxes drop fragmented UDP packets. You'll have to
> > > > mess around
> > > > with TCP segment sizes and/or encrypt fragments.
> > > >
> > > > - The NAT box does not affect any protocols, like FTP,
> > > > because it's modifying
> > > > the "outer" IP header and an artifical UDP header.
> > > >
> > > > - There might be address collisions. Two clients might be
> > > > behind firewalls
> > > > and have
> > > > the same address 192.168.98.6. Now they do quick mode to
> > > > the same GW.
> > > > Trouble ahead. You need some NAT here, be it at the GW or
> > > > at the client,
> > > > or private IP address by cfg-mode. Or something.
> > > >
> > > > J-rn
>
>
> --------------------------------------------------------------------------
---------------------------------------
> The information contained in this message is confidential and is intended
> for the addressee(s) only. If you have received this message in error or
> there are any problems please notify the originator immediately. The
> unauthorized use, disclosure, copying or alteration of this message is
> strictly forbidden. Baltimore Technologies plc will not be liable for
direct,
> special, indirect or consequential damages arising from alteration of the
> contents of this message by a third party or as a result of any virus
being
> passed on.
>
> In addition, certain Marketing collateral may be added from time to time
to
> promote Baltimore Technologies products, services, Global e-Security or
> appearance at trade shows and conferences.
>
> This footnote confirms that this email message has been swept by
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.
References: