[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: compression and encryption
Text item:
I assume all these arguments apply equally well to the use of encryption
algorithms that rely on "history".
(Sorry, I've only recently been following the IPSEC mailing list) Are there
any proposals to use stream ciphers in IPSEC?
The n=1 case would be the equivalent of treating each packet as a separate
stream. Right now, I'm interested in audio/video streams (already compressed;
real-time operation). Re-transmit is not an option; but re-sync (of the
encryption algorithm) would be vital. For n>1, would it be possible to transmit
the stream offset in each packet to allow re-sync?
____________________________ Reply Separator _________________________________
>Subject: Re: compression and encryption
>Author: owner-ipsec@portal.ex.tis.com at SMTPGATE
>Date: 11/7/96 9:13 PM
>
> When my customers have run compression I've seen them find
> acceptable benefit from using non-history-based compression,
> which is to say I feel it's fine to do a reset after every
> packet. This case side-steps your analysis. I don't have
> enough information at my fingertips to confirm your simulation
> matches the field data I have seen.
>
>It's quite compatible with n=1, which is more or less my point -- that
>we need to use very small burst sizes. 1 is a very nice low number,
>and it makes the protocol a lot simpler.
>
> If someone wants to accept the potential impact of using a
> history-based compression scheme I don't see any reason to
> architect the protocol to stop them. On the other hand, if
> there's not 'rough consensus' for putting compression into ESP
> then fine, don't put it in.
>
> There's still the 'next header' field so the stand-alone
> compression transform can be used.
>
>Yes. If we're going to do compression at this layer, that may be the
>right answer. But we should measure the effectiveness of compression
>when you have a dictionary in each packet, and the packets are ~512
>bytes uncompressed.
Text item: External Message Header
The following mail header is for administrative use
and may be ignored unless there are problems.
***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
Precedence: list
Sender: owner-ipsec@ex.tis.com
From: Steven Bellovin <smb@research.att.com>
Date: Thu, 07 Nov 1996 21:13:04 -0500
Subject: Re: compression and encryption
cc: ipsec@tis.com
To: Rodney Thayer <rodney@sabletech.com>
Message-Id: <199611080213.VAA20427@raptor.research.att.com>
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA112
27 for ipsec-outgoing; Thu, 7 Nov 1996 21:13:22 -0500 (EST)
Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag
.jf.intel.com (8.8.2/8.7.3) with ESMTP id UAA29956 for <John_H_Wilson@ccm.jf.int
el.com>; Thu, 7 Nov 1996 20:22:08 -0800 (PST)
Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4])
by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id UAA08086 for <John_H_Wilson@cc
m.jf.intel.com>; Thu, 7 Nov 1996 20:19:35 -0800 (PST)
Return-Path: owner-ipsec@portal.ex.tis.com