Re: IPCOMP and IPSEC

[Daniel Harkins <[e-mail]>]

  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:[e-mail]]
> > Sent: Thursday, May 28, 1998 12:53 PM
> > To: Roy Pereira
> > Cc: Stephen Waters; [e-mail]; [e-mail]
> > 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.
>