Re: IPCOMP and IPSEC

mark@mentat.com (Marc Hasson) Sat, 30 May 1998 01:36 UTC

Return-Path: mark@mentat.com
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA08572 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 29 May 1998 18:36:33 -0700 (PDT)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id MAA26905 for <ippcp@external.cisco.com>; Thu, 28 May 1998 12:19:43 -0700 (PDT)
Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id MAA05498 for <ippcp@external.cisco.com>; Thu, 28 May 1998 12:19:41 -0700 (PDT)
Received: from mentat.com(192.88.122.129) by proxy2.cisco.com via smap (V2.0) id xma005474; Thu, 28 May 98 19:19:35 GMT
X-SMAP-Received-From: outside
Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA10053; Thu, 28 May 98 12:15:25 PDT
Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id MAA00927; Thu, 28 May 1998 12:15:26 -0700
Date: Thu, 28 May 1998 12:15:26 -0700
From: mark@mentat.com
Message-Id: <199805281915.MAA00927@orna.mentat.com>
To: rpereira@TimeStep.com, dharkins@cisco.com
Subject: Re: IPCOMP and IPSEC
Cc: Stephen.Waters@digital.com, ippcp@external.cisco.com, ipsec@tis.com
X-Sun-Charset: US-ASCII

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