Re[2]: compression and encryption
John H Wilson <John_H_Wilson@ccm.jf.intel.com> Fri, 08 November 1996 16:24 UTC
Received: from cnri by ietf.org id aa03386; 8 Nov 96 11:24 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa14365; 8 Nov 96 11:24 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12999 for ipsec-outgoing; Fri, 8 Nov 1996 11:14:38 -0500 (EST)
Date: Fri, 08 Nov 1996 08:12:00 -0800
From: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
Message-ID: <Fri
To: owner-ipsec@portal.ex.tis.com, rodney@sabletech.com
cc: ipsec@tis.com
Subject: Re[2]: compression and encryption
Sender: owner-ipsec@ex.tis.com
Precedence: list
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
- compression and encryption Steve Bellovin
- RE: compression and encryption Bill Hunt
- Re[2]: compression and encryption John H Wilson