Re: Handling of IPcomp in IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 10:10 AM -0500 12/3/02, Paul Koning wrote:
>  >>>>> "Bill" == Bill Sommerfeld <sommerfeld@east.sun.com> writes:
>
>  Bill> one potential downside to this proposal is that, on a system
>  Bill> where IPcomp algorithms are dynamically unloadable, you'll
>  Bill> likely advertise all of them and keep them all loaded all the
>  Bill> time.  given that we generally don't want a proliferation of
>  Bill> vanity algorithms, this doesn't seem like such a bad downside.
>
>  Bill> that said, how about:
>
>  Bill> A1) we assume the algorithm set is symmetric (if you can
>  Bill> decompress you can also compress), or
>
>  Bill> A2) each node separately announces which algorithms it can
>  Bill> compress.
>
>  Bill> and
>
>  Bill> B) The commitment to keeping the algorithms around only extends
>  Bill> to those algorithms which the sending end of the SA indicated
>  Bill> it could compress.
>
>  Bill> For what little it's worth, I prefer A1 over A2.
>
>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.

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

One-way compression seems like a far edge case.

--Paul Hoffman, Director
--VPN Consortium