RE: Compression, encryption and authentication at a Security Gateway

["Bob Monsour" <[e-mail]>]

At the Munich IETF meeting (first meeting of the IPPCP wg), Cisco presented
their experience of implementing IPPCP. The presentation can be found at:

	http://www.tgv.cisco.com/public/shacham/ipcomp.ppt

This was using an IP-in-IP approach to the compression header. After the
current compression header approach was adopted, Avram re-ran his results
and later posted the following on 9/15/97:

	The I-D was written after implementing the WG resolutions into my code in
	Cisco Stack 100 v2.1 for Win95, which is based on an IPv4 stack and static
	keys. The bonus from the new header is a better compression ratio - the
	Calgary files now compress at the ratio of 1.81:1, in comparison to the
	ratio of 1.782:1 when IP-over-IP was in use.

Also, there are three things to recall when implemeting compression and the
potential benefits of it prior to IPSec encryption. First is the bandwidth
improvement; second is that for highly cpu intensive encryption algorithms
like 3des, in some cases (about a 2:1 compression ratio) the cost of
compressing plus encrypting can be "cheaper" than encrypting alone. Lastly,
with the per-packet overhead of IPSec due to AH and ESP, even a modest
compression ratio gain can reduce the liklihood of packet fragmentation.
This is an issue with packets at or near the MTU which is where the
compression ratio is likely to be best. In the LZS compression draft, we
recommend a  120 byte packet size as the minimum size to begin considering
compressing the packet.

Lastly, as you are all aware, compression results are data dependent and
your mileage may vary.

Regards,
-Bob

> -----Original Message-----
> From: Stephen Waters [mailto:[e-mail]]
> Sent: Friday, May 29, 1998 4:27 AM
> To: [e-mail]; [e-mail]
> Cc: Stephen Waters
> Subject: Compression, encryption and authentication at a Security
> Gateway
>
>
>
> The hunch/findings that folk seem to have when running IPPCP is that the
> performance is poor and if IPPCP is done in series with encryption,
> compression is probably not worth bothering with (I'm assuming that you
> would be using IPPCP because you wanted to use IPSEC encryption).
>
> Host hosts have IPSEC/IPPCP,  there is the option that Security Gateways
> won't need to do encryption either, for example, a remote-worker who
> tunnels to a Security Gateway for authentication and then encrypts to a
> mail-server with transport mode :
>
> [IP2][AH][IP1][ESP][upper][pad/np][icv]
>
> The Security gateway does packet-level authentication and the target
> node (say, a mail server) does the decode.
> I see that the [IP1] header is no longer confidential, but the
> alternative is to have the SG re-encrypt the entire packet.
>
> What I'm coming to is that Security Gateways are likely to want to be
> VERY sharp at doing per-packet authentication.
>
> (hiding under table time)
> Steve.
>
>
> Stephen Waters
> DEVON, UK
>
> National: 01548 551012 / 550474
> International: 44 1548 551012 / 550474
> [e-mail]
>
>