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.
- Re: IPCOMP and IPSEC Daniel Harkins
- IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Naganand Doraswamy
- Re: IPCOMP and IPSEC Saroop Mathur
- Re: IPCOMP and IPSEC Eric Dean
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Marc Hasson
- RE: IPCOMP and IPSEC Avram Shacham
- FW: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Avram Shacham
- Re: IPCOMP and IPSEC Daniel Harkins
- RE: IPCOMP and IPSEC Roy Pereira
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- RE: IPCOMP and IPSEC Roy Pereira
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Eric Dean
- Re: IPCOMP and IPSEC Stephen Kent
- RE: IPCOMP and IPSEC Robert Moskowitz
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Paul Koning