Re: IPCOMP and IPSEC

Stephen Kent <kent@bbn.com> Tue, 02 June 1998 02:33 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA12997 for ipsec-outgoing; Mon, 1 Jun 1998 22:33:17 -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
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

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