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

From: [email-masked]
Date: Tue, 4 Mar 2003 22:46:33 -0500

Henry Spencer <[email-masked]> wrote:
> On Mon, 3 Mar 2003, Abraham Shacham wrote:
> > Nowhere in the IKEv2 I-D the issue of using IPComp CPIs from
> > the pre-assigned transform ID range is mentioned, afaik.
>
> The current IKEv2 draft has opted for a more conservative approach than
> what some of the list discussion indicated was possible.  I'm personally
a
> bit disappointed, but I see no grave disadvantages and hence don't feel
> strongly about it.

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.
That way, a sender could try compressing a packet in multiple ways and send
the one that came out the shortest. But no one seemed to get excited about
this capability and several people warned about adding options without a
documented need, so I never added it to the spec.

Is that what you're talking about?

I'm even more reluctant to add functionality now, but would note that it
would not be difficult to add it (optionally) to some future revision of
the protocol.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Henry Spencer <[email-masked]>
Date: Wed, 5 Mar 2003 14:28:57 -0500 (EST)

On Tue, 4 Mar 2003 [email-masked] wrote:
> > what some of the list discussion indicated was possible...
> 
> proposed allowing multiple IPcomp CPIs to be valid within a single ESP SA...

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
                                                       [email-masked]

---

From: Abraham Shacham <[email-masked]>
Date: Wed, 05 Mar 2003 14:18:40 -0800

Henry Spencer wrote:
> Not quite.  The list discussion suggested 

A more accurate way to describe the discussion could be:

   *some* on the list suggested, and others disagreed.

After all, your words yesterday regarding the current content
of IKEv2-05:

    ...but I see no grave disadvantages and hence don't feel
    strongly about it.

> that there is really no need to

The current IKE and IKEv2-05 provide IPComp implementations with
a mechanism to negotiate, in other words to agree on, IPComp specific
parameters. That capability is in use in actual implementations.

As for using only the CPIs from the pre-defined range, both the current IKE
and IKEv2-05 provide implementations with a mechanism to use the well-known
CPIs or to negotiate a CPI.  The fact is, most implementations use a CPI
from the negotiated range.

Mandating using the the first over the other is not on the turf of the key
exchange protocol, imo, and IKEv2-05 should continue following that logic.

Regards,
acvram