[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC Security Gateways & NAT
In addition to the issues raised below, the current esp-in-udp proposals
do not address device management.
jshukla wrote:
>
> ----- Original Message -----
> From: "Chris Trobridge" <CTrobridge@baltimore.com>
> To: <ipsec@lists.tislabs.com>
> Sent: Thursday, June 07, 2001 4:56 AM
> Subject: IPSEC Security Gateways & NAT
>
> >
> > Even assuming that the management issues associated with agreeing SAs
> > (possibly with dynamic NAT) can be fixed, there appears to be a deeper
> > issue: Some protocols, most notably FTP, pass IP socket addresses at the
> > application level. These need to be translated by Application Level
> > Gateways (ALGs). However, once IP traffic has been enrypted, this
> > information cannot be available to the ALG.
> >
>
> There is another proposal to solve the IPSec and NAT conflict. It
> specifically
> shows how the FTP problem can be solved.
>
> http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible
> -security-00.txt
>
> Although we have not talked about the case when NAT is performed
> by the ISP, it is not a problem. Our new draft will address that.
>
> In addition to the issues raised by you, there are other problems,
> such as, peer-to-peer security, support for per-flow based QoS,
> and content based switching. Our proposal solves all these problems
> as well.
>
> On the other hand, ESPinUDP does not enable peer-to-peer
> security, per-flow based QoS, and use of ALGs.
>
> > This appears to imply that NAT, in general, must be performed before
> > encryption. This is at odds with the models that a number of service
> > providers are trying to apply. Are there any solutions to these problems?
> > Or any papers detailing the sort of problems that occur when mixing NAT
> with
> > IPSEC.
> >
> > Thanks,
> > Chris
> >
>
> regards,
> Jayant
References: