Re: TO COMPRESS OR NOT TO CMPRS (please reply)

Stephen Kent <kent@bbn.com> Fri, 21 February 1997 23:36 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15340 for ipsec-outgoing; Fri, 21 Feb 1997 18:36:37 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007806af33b2be0bf8@[128.33.229.242]>
In-Reply-To: <199702192303.BAA00169@morden.sandelman.ottawa.on.ca>
References: Your message of "Wed, 19 Feb 1997 13:12:59 PST." <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Feb 1997 15:19:18 -0500
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
From: Stephen Kent <kent@bbn.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Mike,

	One could use two SPIs to distinguish compressed vs. uncompressed
data, but since one needs to decrypt prior to decompressing, I don't know
that this different approach to demuxing is beneficial.  Aloso, if we also
are using anti-replay facilities, I now worry about the fact that these two
portions of the same data stream have been split apart and are not
synchronized.  I cannot (off the top of my head) gove a good argument why
this may be a problem, but it's bothersome.

Steve