Subject: Re: IPCOMP and IPSEC

From: [email-masked] (Marc Hasson)
Date: Thu, 28 May 1998 12:15:26 -0700

Jumping in here....

 >   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.

I think Dan's packet format makes sense, for the described scenario of
a SG that is applying both compression and encryption/tunnelling in one
step on behalf of a naive host.  (As a side tidbit though, from the
SG receiver's perspective of your packet Dan, isn't ESP really in
Transport mode with respect to IPCOMP and its IPCOMP, in turn, thats in
tunnel mode with a next header of IP?  I don't recall any mention in the
IPCOMP document of tunnel vs. transport, it seemed to assume that only
ULPs are its next header payload but I don't see why that has to be.)

But isn't Roy's packet format OK for end-hosts that have a Compression
Association between themselves (configured independently of IKE?) and
there is an intermediate SG (based on its own policies and key
negotiation) which is doing the tunnelling/encryption regardless
whether the inner IP's payload is TCP or IPCOMP?

I think Dan's scenario one that is likely to be widely deployed but Roy's
format seems just as "correct" for host-based compression.

   -- Marc --

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

---

From: Daniel Harkins <[email-masked]>
Date: Thu, 28 May 1998 12:43:10 -0700

Marc,

> ULPs are its next header payload but I don't see why that has to be.)

I guess you could say that ESP is in transport mode, but what about the
case where both AH and ESP are applied to the same packet:

	[IP2][AH][ESP][IP1][data]

Is AH in transport mode? 

> format seems just as "correct" for host-based compression.
 
Roy's would correct if the compression was being done by the host before
passing the packet to the SG, but Stephen (in the original post that started
this all) stated that the original packet received by the SG was:

	 [IP1][TCP][data]

In this case I don't think it's legal for a SG to add anything-- IPSec or
IPCOMP-- in transport mode. 

  Dan.