Re: Handling of IPcomp in IKEv2

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@notesdev.ibm.com> writes:

 Charlie> ...
 Charlie> Given all this, I don't believe it is appropriate for nodes
 Charlie> to negotiate compression algorithms as they currently do
 Charlie> where they either end up agreeing on a single compression
 Charlie> algorithm or they don't agree on any.  Rather, each node
 Charlie> should announce what compression algorithms it is capable of
 Charlie> decompressing and the two byte CPIs associated with each
 Charlie> one. A sending node can optionally compress any outgoing
 Charlie> packet with any of the algorithms supported by the other
 Charlie> end. This has several advantages:

 Charlie> 1) IPcomp negotiation becomes completely separate from ESP
 Charlie> and AH negotiation. You don't have to double the number of
 Charlie> proposals to say that each is possible with and without
 Charlie> IPcomp. (This comes with the cost that you can't say I'll do
 Charlie> AES with compression or 3DES without, but it seems unlikely
 Charlie> real implementations would want that flexibility).

Makes sense.  I agree that the example you mentioned is silly and
unlikely ever to be seen in the wild.

 Charlie> 2) It eliminates confusion around deleting IPcomp SAs. Nodes
 Charlie> commit to handling their offered decompression algorithms
 Charlie> for as long as the ESP or AH SAs are maintained. They are
 Charlie> not explicitly deleted or renewed.

 Charlie> 3) If bandwidth is at a premium compared to processing, a
 Charlie> sending node could try several different compression
 Charlie> algorithms and send whichever form was the most
 Charlie> compressed. It would also allow senders to adjust their
 Charlie> choice of compression algorithms over time depending on the
 Charlie> nature of the data being transmitted, and it would allow
 Charlie> data sent in the two directions to be compressed with
 Charlie> different algorithms if appropriate.

 Charlie> What do people think? Am I still confused?

Sounds good.  Definitely an improvement over the current mess (which
you correctly parsed as far as I can tell).

    paul