[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling of IPcomp in IKEv2
>>>>> "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