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:
>"Steven M. Bellovin" <[e-mail]> writes:
>>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.
>
>[I assume you mean "link-layer compression" above, not "link-layer encryption"
>]. 

I did indeed.

>Thanks! What I needed was a pointer to RFC 2393, which I got from your
>paper pointed to above.
>
>It does seem as though doing it end-to-end independently of IPsec (as
>is done in the internet draft you pointed me to) would
>be a better thing. Though I suppose doing it in IKE means that it works
>for UDP also. So I guess I can't assume a TCP mechanism for negotiating
>compression will replace the IKE mechanism.

Right, though of course most traffic by volume is TCP.  TCP compression 
is better because it retains state, rather than having to compress each 
packet individually; we have some numbers that demonstrate this very clearly.


		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com