Re: proposed IPSEC changes/extensions

Stephen Kent <kent@bbn.com> Mon, 04 November 1996 17:42 UTC

Received: from cnri by ietf.org id aa09116; 4 Nov 96 12:42 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa16148; 4 Nov 96 12:42 EST
Received: by neptune.TIS.COM id aa19905; 4 Nov 96 12:08 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa16162; 4 Nov 96 11:15 EST
Received: from relay.hq.tis.com by neptune.TIS.COM id aa15779; 4 Nov 96 10:35 EST
Received: by relay.hq.tis.com; id KAA07454; Mon, 4 Nov 1996 10:40:06 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007435; Mon, 4 Nov 96 10:39:44 -0500
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA13747 for <ipsec@tis.com>; Mon, 4 Nov 1996 10:41:22 -0500 (EST)
Received: by relay.hq.tis.com; id KAA07396; Mon, 4 Nov 1996 10:39:37 -0500
Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma007390; Mon, 4 Nov 96 10:39:30 -0500
Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA20281 for <ipsec@TIS.COM>; Mon, 4 Nov 1996 10:41:29 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v02130510aea3bc01b554@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 04 Nov 1996 10:43:07 -0500
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: proposed IPSEC changes/extensions
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

Folks,

        I think the concensus is that we should NOT include compression in
ESP, for a bariety of reasons.  So, the revised ESP document will not
include ANY hooks for compression, reserved fields, etc.  Note, however,
that we are moving away from the notion of transforms as bundled sets of
algorithms described in a single document.  Instead, we are defining the
algorithms separately, and the notion of a transform will appear only in a
document that describes the combinations of algorithms that are negotiated
during SA establishment.  It will cite these algorithms by reference to
appropriate RFCs, but wil not provide processing descriptions, etc.  Thus I
do not see how to include compression into ESP processing at some later
time.  If we keep it as a separate protocol, that's fine, but don't count
on some more optimized version that is tightly integrated into ESP.

Steve