Re: proposed IPSEC changes/extensions

Rodney Thayer <rodney@sabletech.com> Sun, 03 November 1996 18:16 UTC

Received: from cnri by ietf.org id aa03059; 3 Nov 96 13:16 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa12337; 3 Nov 96 13:16 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa18577; 3 Nov 96 12:49 EST
Received: from relay.hq.tis.com by neptune.TIS.COM id aa18282; 3 Nov 96 12:37 EST
Received: by relay.hq.tis.com; id MAA24417; Sun, 3 Nov 1996 12:42:23 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma024413; Sun, 3 Nov 96 12:41:55 -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 MAA18437 for <ipsec@tis.com>; Sun, 3 Nov 1996 12:43:35 -0500 (EST)
Received: by relay.hq.tis.com; id MAA24405; Sun, 3 Nov 1996 12:41:53 -0500
Received: from mail.zipnet.net(199.232.240.10) by relay.tis.com via smap (V3.1.1) id xma024401; Sun, 3 Nov 96 12:41:24 -0500
Received: from ferguson ([199.249.254.9]) by mail.zipnet.net (8.7.6/8.7.3) with SMTP id MAA21634; Sun, 3 Nov 1996 12:43:15 -0500 (EST)
Message-Id: <2.2.16.19961103174036.0bd73814@pop3.pn.com>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 2.2 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 03 Nov 1996 12:40:36 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: proposed IPSEC changes/extensions
Cc: msabin@netcom.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

That was my view, which is why I proposed it as a separate transform.

I believe the different points of view have to do with the use of
history-based or non-history-based compression.

It is my opinion that both schemes have a place.  I sort of see things
evolving from use of a separate transform or protocol, towards some sort
of combined mechanism.  I assume that eventually the transforms actually
used in the real world will be optimized for combined functions such as
the 3des-compression-replay-etc. transform.

>Date: Thu, 31 Oct 1996 09:50:25 -0500
>From: Hilarie Orman <ho@earth.hpc.org>
>To: msabin@netcom.com
>Cc: ipsec@TIS.COM
>Subject: Re: proposed IPSEC changes/extensions
>Sender: ipsec-approval@neptune.hq.tis.com
>
>> 2)  Compression is stateful, which means that the transmitter and
receiver
>> can get out of sync if packets are missed.
>
>Isn't stateful compression is most logically done as a separate
>protocol, performed prior to any IPSEC encryption?

-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
Comment: PGP by ViaCrypt

iQCVAgUBMnzT2cKmlvJNktGxAQGrZAP8CWC8JqC80/Sire6f9OYiibM2H2JVnFMc
1LvLR/y2RjZyCKIb2ppEVm3QJ9eBXbJjNwwWDReQmton0Ei73IB5ZAPL3sue7An8
WjZWks3k2U1CT2on9Z5WomJJKy4tLvyYgsJUYHGjcn+6fNpXtohgiSEnpIC0NCjt
JE/stO4Nbzg=
=WY44
-----END PGP SIGNATURE-----

               Rodney Thayer <rodney@sabletech.com>       +1 617 332 7292
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: +1 617 332 7970           http://www.shore.net/~sable
                           Communications Software Development