Re: proposed IPSEC changes/extensions
Santeri Paavolainen <santtu@cs.hut.fi> Fri, 01 November 1996 14:21 UTC
Received: from cnri by ietf.org id aa03303; 1 Nov 96 9:21 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa10255; 1 Nov 96 9:21 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa02620; 1 Nov 96 8:39 EST
Received: from relay.hq.tis.com by neptune.TIS.COM id aa02373; 1 Nov 96 8:19 EST
Received: by relay.hq.tis.com; id IAA20460; Fri, 1 Nov 1996 08:23:20 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma020446; Fri, 1 Nov 96 08:23:01 -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 IAA16824 for <ipsec@tis.com>; Fri, 1 Nov 1996 08:24:39 -0500 (EST)
Received: by relay.hq.tis.com; id IAA20427; Fri, 1 Nov 1996 08:22:51 -0500
Received: from hutcs.cs.hut.fi(130.233.192.6) by relay.tis.com via smap (V3.1.1) id xma020413; Fri, 1 Nov 96 08:22:44 -0500
Received: from localhost (santtu@localhost) by hutcs.cs.hut.fi (8.7.6/8.7.3) with SMTP id PAA21743 for <ipsec@TIS.COM>; Fri, 1 Nov 1996 15:24:35 +0200 (EET)
Date: Fri, 01 Nov 1996 15:24:35 +0200
From: Santeri Paavolainen <santtu@cs.hut.fi>
X-Sender: santtu@hutcs
To: ipsec@tis.com
Subject: Re: proposed IPSEC changes/extensions
In-Reply-To: <199610311806.NAA00482@thunk.orchard.medford.ma.us>
Message-ID: <Pine.GSO.3.94.961101151133.21413A-100000@hutcs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
On Thu, 31 Oct 1996, Bill Sommerfeld wrote: > > Isn't stateful compression most logically done as a separate > > protocol, performed prior to any IPSEC encryption? > > Maybe from a "purity of layers" perspective, but stateful compression > requires similar message-sequencing goop as replay detection; there > are likely some real efficiencies from handling both at the same > time.. True, but unless there is a good reason to put both of them into a single transformation they should be kept separate. It is up to the IPSEC layer to optimize (if possible) the packet processing. Even if compression and replay prevention both require state, their state is separate from each other's state. Compression does not need to know anything about replay prevention's state to work. Why should they be defined in the protocol to be contained both in a single transformation? There could be benefits in code if you combined both of these transformations into a single one, but I see optimizing for such case the responsibility of the IPSEC implementation, not the standard. Logically they should be separate -- the IPSEC code itself is free to implement them in any way as long as the final product appears to have gone through the both transformations as separate, even if the IPSEC itself has optimized by doing the both transformations in a more "singly" transformation way. I would not sacrifice the "purity of layers" for the ease of efficient implementation. I think to do so would be short-sighted. -- sjpaavol@cc.Helsinki.FI I have become death, destroyer of the worlds.
- 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