RE: IPCOMP and IPSEC

Robert Moskowitz <rgm-sec@htt-consult.com> Thu, 04 June 1998 16:09 UTC

Return-Path: rgm-sec@htt-consult.com
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA10165 for <ippcp-archive-file@ftp-eng.cisco.com>; Thu, 4 Jun 1998 09:09:17 -0700 (PDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id JAA05750 for <ippcp@external.cisco.com>; Thu, 4 Jun 1998 09:08:15 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id JAA10194 for <ippcp@external.cisco.com>; Thu, 4 Jun 1998 09:08:14 -0700 (PDT)
Received: from homebase.htt-consult.com(208.235.169.130) by proxy1.cisco.com via smap (V2.0) id xma010192; Thu, 4 Jun 98 16:08:12 GMT
X-SMAP-Received-From: outside
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA299; Thu, 4 Jun 1998 12:05:51 -0400
Message-Id: <3.0.5.32.19980604120133.00a58c50@homebase.htt-consult.com>
X-Sender: rgm-sec@homebase.htt-consult.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 04 Jun 1998 12:01:33 -0400
To: Stephen Waters <Stephen.Waters@digital.com>, Avram Shacham <shacham@cisco.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: RE: IPCOMP and IPSEC
Cc: ipsec@tis.com, ippcp@external.cisco.com
In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A23E5D@wade.reo.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: rgm-sec@htt-consult.com