RE: IPCOMP and IPSEC
Robert Moskowitz <rgm-sec@htt-consult.com> Thu, 04 June 1998 15:50 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25411 for ipsec-outgoing; Thu, 4 Jun 1998 11:50:32 -0400 (EDT)
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"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
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
- IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Vach Kompella
- Re: IPCOMP and IPSEC Naganand Doraswamy
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- FW: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Saroop Mathur
- RE: IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Eric Dean
- Re: IPCOMP and IPSEC Stephen Kent
- RE: IPCOMP and IPSEC Robert Moskowitz
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Paul Koning