[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPCOMP and IPSEC
Roy,
Actually, I don't think the way you proposed is correct. While IPCOMP
can be applied in either transport or tunnel mode it *has* to be applied
in the same mode as the parallel IPSec SA. The way you proposed has IPCOMP
in transport and IPSec in tunnel. That won't work.
Dan.
> IPCOMP may be applied in either tunnel mode or transport mode just like
> IPSec. You are right, either way is equally correct.
>
> > -----Original Message-----
> > From: Daniel Harkins [mailto:dharkins@cisco.com]
> > Sent: Thursday, May 28, 1998 12:53 PM
> > To: Roy Pereira
> > Cc: Stephen Waters; ippcp@external.cisco.com; ipsec@tis.com
> > Subject: Re: IPCOMP and IPSEC
> >
> >
> > Roy,
> >
> > > IPComp may be added by a security gateway just like IPSec ESP/AH is
> > > added. It would probably look like this though:
> > >
> > > [IP2]
> > > [ESP spi+replay+iv]
> > > [IP1]
> > > [IPCOMP]
> > > [TCP]
> > > [data]
> > > [ESP padding+next protocol+auth]
> >
> > Why would it look like that and not:
> >
> > [IP2]
> > [ESP spi+replay+iv]
> > [IPCOMP]
> > [IP1]
> > [TCP]
> > [data]
> > [ESP padding+next protocol+auth]
> >
> > I have a rule that says "for traffic from foo to bar apply
> > IPCOMP then
> > IPSec" so why would my IPCOMP be effectively a transport mode
> > application
> > while my IPSec would be tunnel. They're both part of the same rule so
> > they're both done in the same mode.
> >
> > An intermediate gateway shouldn't muck with the inner packet. If you
> > did what you propose the packet would be forwarded on to the
> > destination
> > address of IP1 who most likely doesn't have the IPCOMP SA to
> > decompress
> > it. The IPCOMP "SA" is negotiated along with the IPSec SA so
> > they both
> > have to be targeted to the same destination and be applied in
> > the same mode.
> >
> > Dan.
>
References: