Handling of IPcomp in IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

I never really understood how IPcomp worked in IPsec until Tero explained
it to me at the recent IETF. It seemed like it couldn't work as the IKEv1
spec said, yet I had heard that people used it, so I left it alone. Now
that I understand it better (or at least think I do), I can see how the
current spec works (sort of) but believe it could be better and simpler. My
proposal is motivated in part by the desire to separate negotiation of
IPcomp from the "cryptographic suites" - something that people at the IPsec
meeting seemed to want but it wasn't immediately clear how.

IKE optionally negotiates IPcomp when it negotiates an ESP SA, and AH SA,
or an ESP within AH SA. As currently specified, an IPcomp SA is negotiated
where an IPcomp SA has a two byte CPI (analogous to the four byte SPIs in
ESP and AH). That always made me uneasy, because SPIs are supposed to be
unique (within a single IP destination) and two bytes might not be enough.
Of course, given that the IPcomp SA is bound to a containing ESP or AH SA,
it's not clear why it needs a CPI at all (in which case, why waste the two
bytes).

As Tero explained it, the IPcomp SA is not really an SA at all. First,
unlike ESP and AH, it is optional on a packet by packet basis. This is so
that if the compression algorithm is not effective on a particular packet
(e.g. the compressed version is bigger), IPcomp processing can be skipped
on that packet. The CPI at the beginning of the IPcomp header is not to
identify the session on which the packet is arriving - that is implicit
from the ESP or AH header. Instead, it identifies the compression algorithm
used, which is only interesting if the receiving node is capable of using
multiple compression algorithms. In the common case, a node only supports a
single compression algorithm and always assigns the same CPI to all IPcomp
SAs.

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

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

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

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

What do people think? Am I still confused?

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