[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
In message <200110290135.UAA18324@bcn.East.Sun.COM>, Radia Perlman - Boston Cen
ter for Networking writes:
>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? :-)
The problem is that link-layer encryption -- the most common form below
the application -- doesn't work on IPsec packets, and the upper layers
may not be aware of, say, gateway-to-gateway IPsec. The IPsec layer,
in other words, is the first to know for sure that a lower layer can't
do the encryption that might be desired.
There's no other negotiation mechanism for IPcomp because compression
is circuit-like, and there are no other circuits at the IP layer. (For
discussion on how to negotiate compression at the TCP layer, see
http://www.research.att.com/~smb/papers/draft-bellovin-tcpfilt-00.txt
and http://www.research.att.com/~smb/papers/draft-bellovin-tcpcomp-00.txt.
We've implemented the scheme, and are planning on updating and
resubmitting the drafts.)
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com