[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPCOMP and IPSEC

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: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.
 > > 
 >
Follow-Ups: