[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression and encryption
Rodney Thayer writes:
> 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.
Considering that compression is most likely to benefit "bulk data
transfer", such as ftp & web (with relatively large packet sizes); and
considering that compression doesn't help much in non-bulk activities
such as telnet (with small packet sizes), perhaps non-history-based
compression might be a reasonable approach.
However, perhaps much of the bulk data transfer that takes place is
pre-compressed for archival storage anyway, and therefore is basically
incompressible. Would this remain true for secured transmissions too?
> Steve Bellovin writes:
> >Based on all this, I make the following recommendations:
> >
> > a) we proceed with ESP as it is now. No changes should
> > be made, or hooks left, for compression.
> >
> > b) the key management exchanges should permit the negotiation
> > of an arbitrary set of compression parameters, for when something
> > is defined.
> >
> > c) we investigate IPSEC header compression.
> >
> > d) the IPSEC architecture must allow for the header formats
> > resulting from POP-based encryption.
> >
> >Comments?
--
Leonard Samuelson, Ascend Communications, Inc. 614-326-6824
References: