Re: IPCOMP and IPSEC
Daniel Harkins <dharkins@cisco.com> Thu, 28 May 1998 16:38 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28487 for ipsec-outgoing; Thu, 28 May 1998 12:38:24 -0400 (EDT)
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>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
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.
- IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Vach Kompella
- Re: IPCOMP and IPSEC Naganand Doraswamy
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- FW: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Saroop Mathur
- RE: IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Avram Shacham
- 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