Re: Handling of IPcomp in IKEv2

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Paul" == Paul Hoffman </ VPNC <paul.hoffman@vpnc.org>> writes:

 Paul> At 10:10 AM -0500 12/3/02, Paul Koning wrote:
 >> I would rather not rely on assumption A1.  The reason is that a
 >> lot of compression algorithms are asymmetric: compression is much
 >> harder than decompression.  So a resource-challenged node might
 >> want to advertise the ability to decompress such an algorithm
 >> without necessarily wanting to go to the effort of also
 >> compressing with that algorithm.

 Paul> We're talking about IKEv2 here, not IKEv1. IKEv2 is aimed at
 Paul> more typical IPsec VPN scenarios. It seems highly questionable
 Paul> that you could possibly specify in a reasonable management
 Paul> interface "use one-way compression" or, worse, "use compression
 Paul> type X for incoming but compression type Y for outgoing".

 Paul> One-way compression seems like a far edge case.

I agree, but that's not what I proposed.

I assume your IKEv1 vs. IKEv2 comment means "don't make it as
complicated as IKEv1 was".  Fair enough.

When doing compression in software, I can easily imagine a case where
an implementation is willing to decompress with algorithms A, B, C,
but only wants to compress with B because A and C are too expensive in
the compress direction when done in software.  

But come to think of it, that's easy to support.  The way to do this
is to have each side announce what it can DEcompress (not compress).
In other words, what it will accept inbound.

For outbound processing, the sender then simply takes one of the
announced decompression algorithms (whichever one it prefers right
now), or it doesn't compress if it has no compatible algorithm, or for
whatever reason isn't willing to run it right now.  

This is maximally simple (each side simply announces its
capabilities), involves no negotation, does not require any
assumptions of symmetry.

	    paul