[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC Security Gateways & NAT
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)
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
think it's beyond even that! Roll on IPv6 and the abandonment of NAT...
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.
Follow-Ups: