Subject: RE: IPCOMP and IPSEC

From: Robert Moskowitz <[email-masked]>
Date: Thu, 04 Jun 1998 12:01:33 -0400

At 10:38 AM 5/30/98 +0100, Stephen Waters wrote:

Sorry I have been out of the loop for a while.  I am back for a bit.

First off, gateways will REALLY NEED to implement IPCOMP.  After all, what
will MOST remotes be maintaining a tunnel too?  Hmm?

In fact this points to an advantage of IPCOMP over V.42bis and PPP
compression.  The later only benefit the dialup link.  The former will tend
to reduce bandwidth over the net (that is if we get some of those 1.7:1
reductions).

Also, as Avram pointed out, where there is a compression gain, there will
be and encryption savings.  Given the 'right' hardware this might be a
total processing gain (time will tell), and this could benefit heavily
loaded gateways.

>
>	I guess time will tell.  For remote-access VPN stuff (over the
>Internet), there is no doubt that 
>	stateless compression is what you use.  For some of the newer
>VNP-focused providers offering
>	QOS for LAN-to-LAN, it may be possible to use a history - even
>for IPPCP.

Remember one of the design problems in IPsec:  you do not want IPsec
dealing with lost packets.  That is an upper layer problem.  If you use
history, will lost packets be an issue?  There was also some concern of
security weakening with history, but that was never really nailed down.

The general concensus was that IPCOMP was yet another hack, and really
TCPng needs to add intelligent compression (that is interact with the
application).  There is could have history.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: Avram Shacham <[email-masked]>
Date: Thu, 04 Jun 1998 22:45:47 -0700

>application).  There is could have history.

In previous discussions of compression at level 4, several people correctly
pointed that TCP-compression may reduce the number of IP packets while IP
compression can only reduce the size of each packet. Fewer IP packets may
enhance performance even more than utilizing compression history.

But - and this may be a BIG implementation obstacle - the current
compression algorithms require ~16KB of compression and decompression
context for _each_ connection.  In other words, 16KB per socket...

Also, UDP is still a useful L4 protocol and no stateful compression is
possible here either.

Regards,
avram

---

From: Paul Koning <[email-masked]>
Date: Fri, 5 Jun 1998 10:39:51 -0400

>>>>> "Avram" == Avram Shacham <[email-masked]> writes:

 Avram> At 12:01 PM 6/4/98 -0400, Robert Moskowitz wrote:
 >> TCPng needs to add intelligent compression (that is interact with
 >> the application).  There is could have history.

 Avram> In previous discussions of compression at level 4, several
 Avram> people correctly pointed that TCP-compression may reduce the
 Avram> number of IP packets while IP compression can only reduce the
 Avram> size of each packet. Fewer IP packets may enhance performance
 Avram> even more than utilizing compression history.

That's a very good point.  Certainly sending the same number of bytes
in a smaller number of packets is always a win.

 Avram> But - and this may be a BIG implementation obstacle - the
 Avram> current compression algorithms require ~16KB of compression
 Avram> and decompression context for _each_ connection.  In other
 Avram> words, 16KB per socket...

That's only a few millicents per socket.

 Avram> Also, UDP is still a useful L4 protocol and no stateful
 Avram> compression is possible here either.

True, but for UDP packets that are larger than the MTU, the same
IP packet reduction benefit applies.