Re: suites vs. a la carte and IPcomp in IKEv2-05

[Henry Spencer <henry@spsystems.net>]

On Tue, 4 Mar 2003 Charlie_Kaufman@notesdev.ibm.com wrote:
> > The current IKEv2 draft has opted for a more conservative approach than
> > what some of the list discussion indicated was possible...
> 
> Let me make sure I understand what you're saying. At one point, I had
> proposed allowing multiple IPcomp CPIs to be valid within a single ESP SA...
> Is that what you're talking about?

Not quite.  The list discussion suggested that there is really no need to
*negotiate* IPComp at all.  It suffices for each end to advertise, as a
side issue during negotiations, which *decompression* algorithms it is
willing to use (perhaps in an order of preference, in which case there
should be a way to signify "no compression" somewhere in the preference
order -- it isn't necessarily always last choice).  There is no need for
the two ends to *agree* on anything. 

IPComp decompression must be stateless, so the only thing the receiver
needs to know is which algorithm it must apply, and that can be explicitly
indicated using preassigned CPIs, so the receiver needs no agreed-on state
to decompress packets.  In IPComp it is always the sender's choice as to
whether a particular packet gets compressed at all, so the receiver can't
use such state to do any useful error checking either.  So the receiver
has no particular need to even remember whether a particular IPsec
connection is using IPComp.  At the output end of the AH/ESP receiver, you
check whether the emerging packet's Protocol is IPComp and the algorithm
is one you implement, and if so, you decompress it. 

The sender probably wants to maintain state to decide whether to compress
the next packet, and if so, how, but the only thing he actually needs to
know about the receiver is what algorithms the receiver knows.  If there
is more than one choice acceptable to both, the sender needs to make a
decision somehow.  The receiver has no need to know what that decision is. 
There is no need for the decision to be the same in both directions, or
for it to be the same for every packet. 

                                                          Henry Spencer
                                                       henry@spsystems.net