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.