RE: IPCOMP and IPSEC

Roy Pereira <rpereira@TimeStep.com> Sat, 30 May 1998 01:55 UTC

Return-Path: rpereira@TimeStep.com
Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA08742 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 29 May 1998 18:55:26 -0700 (PDT)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id LAA01650 for <ippcp@external.cisco.com>; Thu, 28 May 1998 11:21:20 -0700 (PDT)
Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id LAA26087 for <ippcp@external.cisco.com>; Thu, 28 May 1998 11:21:18 -0700 (PDT)
Received: from ns.newbridge.com(192.75.23.67) by proxy3.cisco.com via smap (V2.0) id xma026083; Thu, 28 May 98 18:21:06 GMT
X-SMAP-Received-From: outside
Received: (from smap@localhost) by ns.newbridge.com (8.8.8/8.6.12) id OAA15033; Thu, 28 May 1998 14:17:20 -0400 (EDT)
Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma012094; Thu May 28 13:57:12 1998
Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 28 May 1998 17:57:12 UT
Received: from exchange.timestep.com (exchange.timestep.com [192.168.219.193]) by ca.newbridge.com. (8.8.6/8.8.6) with ESMTP id NAA21084; Thu, 28 May 1998 13:57:11 -0400 (EDT)
Received: by exchange.timestep.com with Internet Mail Service (5.5.1960.3) id <LKBYXLJ6>; Thu, 28 May 1998 13:56:11 -0400
Message-ID: <319A1C5F94C8D11192DE00805FBBADDF12454A@exchange.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: Daniel Harkins <dharkins@cisco.com>
Cc: Stephen Waters <Stephen.Waters@digital.com>, ippcp@external.cisco.com, ipsec@tis.com
Subject: RE: IPCOMP and IPSEC
Date: Thu, 28 May 1998 13:56:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

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