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
- proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Ran Atkinson
- Re: proposed IPSEC changes/extensions Hilarie Orman
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Bill Sommerfeld
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Rodney Thayer
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Steven Bellovin
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions John Gilmore