[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed IPSEC changes/extensions
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.
Follow-Ups: