Re: IPCOMP and IPSEC
Stephen Kent <kent@bbn.com> Tue, 02 June 1998 02:49 UTC
Return-Path: kent@bbn.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 TAA10322 for <ippcp-archive-file@ftp-eng.cisco.com>; Mon, 1 Jun 1998 19:49:17 -0700 (PDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id TAA27495 for <ippcp@external.cisco.com>; Mon, 1 Jun 1998 19:48:47 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id TAA03673 for <ippcp@external.cisco.com>; Mon, 1 Jun 1998 19:48:46 -0700 (PDT)
Received: from po1.bbn.com(192.1.50.38) by proxy1.cisco.com via smap (V2.0) id xma003667; Tue, 2 Jun 98 02:48:43 GMT
X-SMAP-Received-From: outside
Received: from [128.33.238.93] (TC093.BBN.COM [128.33.238.93]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id WAA17751; Mon, 1 Jun 1998 22:28:52 -0400 (EDT)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v0311070eb195fd4409e3@[128.33.238.33]>
In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01959165@wade.reo.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 30 May 1998 14:31:05 -0400
To: Stephen Waters <Stephen.Waters@digital.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: IPCOMP and IPSEC
Cc: ippcp@external.cisco.com, ipsec@tis.com
Stephen, >e.g. > >Original host packet [IP1][TCP][data] > >After passing through a security gateway/IP tunnel: > >[IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP auth] > > >If this is supported, is it detailed anywhere? For example, if an >Explicit IV is used, would it come after the ESP header or after the >IPCOMP header? The IV appears at the beginning of the ciphertext, which would place it in front of the IPCOMP header, by definition. However, we have not been explicit abouit mentioning the option of IPCOMP coming directly after ESP (in tunnel mode) in the arch doc. It complicates matters a bit in that this requires IPCOMP to be performed before the inner IP header check is performed. That check is part of IPSEC tunnel mode processing, so inserting IPCOMP here requires some care. I see from later messages that there is good reason to layer it here, rather than after the inner IP header; this definately makes IPCOMP an integral part of the IPsec processing, not just a modular compression protocol. To the extent that IPcomp use is specified as part of the SA negotiation, that seems fine. Steve
- 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