Re: Handling of IPcomp in IKEv2

[Paul Koning <pkoning@equallogic.com>]

>>>>> "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.

	paul