[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
The need for IPComp (RFC 3173) came from IPsec originally. There were
folks who argued they could not deploy IPsec for remote access unless
it had some pre-IPsec compression. Existing remote access traffic was
compressible, IPsec would make such compression ineffective. Customers
would (presumably) find that unacceptable.
To just use IKE was sort of the obvious thing to do. No one really
thought IPComp would be used except with IPsec.
The old mailing list still lives, at ippcp@cisco.com.
Thomas
From: Joel Snyder <Joel.Snyder@Opus1.COM>
To: John Border <border@hns.com>
Cc: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>,
ipsec@lists.tislabs.com, narten@raleigh.ibm.com, nordmark@Eng.Sun.COM
Date: Mon, 29 Oct 2001 12:49:22 -0700
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
There are two other reasons why putting compression in IKE is probably
preferable to doing it ad-hoc in protocols at the higher layer
(end-to-end argument notwithstanding):
1) VPN boxes typically have lots of spare cycles because they're heavily
overconfigured, and therefore the burden of compression is not as much
of an issue on them as it might be on end systems. Similarly, the VPN
boxes are often closer to the WAN side of the network where compression
is more of a win. In testing real compression implementations, it is
often not worth compressing on the LAN because the overhead of
compression is not compensated for by the savings in transmission.
(i.e., it goes slower when compressed sometimes) Ergo, the choice on
whether to compress or not is more topology/routing based than
end-system based.
2) IPSEC REALLY needs compression to avoid fragmentation---large packets
which can save 60 octets via compression don't have to be fragmented in
ESP. So whereas compression in general may or may not be useful in many
cases, in ESP it's a big win (for large packets) to save a few octets.
jms
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
+1 520 324 0494 x101 (voice) +1 520 324 0495 (FAX)
jms@Opus1.COM http://www.opus1.com/jms Opus One
Electronic mail is always the best way to contact me.
John Border wrote:
>
> I have always assumed that the reason is based on advice I have often
> heard given by the Trasport ADs to Transport working groups... "Don't invent
> a new protocol if an existing protocol can be adapted to meet the
> requirements." If IKE was not used to negotiate IPcomp, then something else
> would have needed to be developed to do so.
>
> In addition (or maybe instead, see my disclaimer), there is a relationship
> between compression and encryption in that compression needs to occur first if
> both are to be used. Therefore, negotiating them at the same time seems more
> efficient in terms of the number of handshakes required.
>
> Disclaimer: I was not around when IPcomp was developed, so I do not know
> for a fact that this reasoning is correct. And, I am not sure to which
> working group mailing list to forward the question. I am pretty sure the work
> was done in the Internet Area because the Internet ADs are the ones who took
> an interest when I submitted an independent I-D for publication as an
> Informational RFC for a specific IPComp protocol (V.44)...
>
> John
>
> Radia Perlman - Boston Center for Networking wrote:
> >
> > I don't quite understand why IKE is negotiating IPcomp, and it clutters
> > up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
> > in you might want to send a compressed packet even if it isn't
> > cryptographically protected. So presumably there's already some way
> > of negotiating compression algorithms, or at least there would have
> > to be in order to deploy IPcomp without IPsec. So would anyone object
> > to removing all mention of IPcomp from the IKE spec?
> >
> > If anyone likes IPcomp and wants it
> > to stay in IKE, perhaps they'd be willing to explain it to me? :-)
> >
> > Radia