Re: IPCOMP and IPSEC

Daniel Harkins <dharkins@cisco.com> Sat, 30 May 1998 01:55 UTC

Return-Path: dharkins@cisco.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 SAA08745 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 29 May 1998 18:55:27 -0700 (PDT)
Received: from jindo.cisco.com (jindo.cisco.com [171.69.43.22]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id JAA19818 for <ippcp@external.cisco.com>; Thu, 28 May 1998 09:52:53 -0700 (PDT)
Received: from dharkins-ss20.cisco.com (dharkins-ss20.cisco.com [171.69.56.149]) by jindo.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA08942; Thu, 28 May 1998 09:52:51 -0700 (PDT)
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by dharkins-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA27460; Thu, 28 May 1998 09:52:51 -0700
Message-Id: <199805281652.JAA27460@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Roy Pereira <rpereira@TimeStep.com>
Cc: Stephen Waters <Stephen.Waters@digital.com>, ippcp@external.cisco.com, ipsec@tis.com
Subject: Re: IPCOMP and IPSEC
In-Reply-To: Your message of "Thu, 28 May 1998 12:25:17 EDT." <319A1C5F94C8D11192DE00805FBBADDF1244E2@exchange.timestep.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 28 May 1998 09:52:50 -0700
From: Daniel Harkins <dharkins@cisco.com>

  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.