Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)

["Steven M. Bellovin" <[e-mail]>]

In message <[e-mail]>, 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