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