[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling of IPcomp in IKEv2




Charlie,

The issue of using a negotiated CPI vs. using a well-known algorithm
number has been discussed at length on the (ipsec and ippcp) lists and in
the bakeoffs, as the attached implementation note from RFC 3173
summarizes.

Your suggestion #1 provides a way to establish a CPI from both ranges --
well known numbers and negotiated -- thus preserving the current RFC 3171
functionality.  Also, it seems that none of your suggestions should modify
the current packet structure on the wire, only the method of negotiation.

The elimination of the flexibility to establish protection suites, where
compression is attached only to a specific encryption algorithm, could be
a problem if those suites describe hardware accelerators, if such
accelerators exist.

The suggestion to support multiple compression algorithms simultaneously
in the same session has never been raised in the ippcp wg or on the lists,
so I'm not sure if there is a real need for suggestion #3.

(btw, the current protocol -- see (*) below -- already includes a way to
    "allow data sent in the two directions to be compressed with
    different algorithms if appropriate."
though I'm not aware of any implementation that is so configured.)


Regards,
avram


rfc-3173 (page 9):

4.1. Use of IKE
[...]
   Implementation note:

      IPCAs become non-unique when two or more IPComp sessions are
      established between two nodes, and the same well-known CPI is used
      in at least two of the sessions.  Non-unique IPCAs pose problems
      in maintaining attributes specific to each IPCA, either negotiated
      (e.g., lifetime) or internal (e.g., the counters of the adaptive
      algorithm for handling previously compressed payload).  To ensure
      the uniqueness of IPCAs between two nodes, when two or more of the
      IPCAs use the same compression algorithm, the CPIs SHOULD be in
      the negotiated range.  However, when the IPCAs are not required to
      be unique, for example when no attribute is being utilized for
      these IPCAs, a well-known CPI MAY be used.  To clarify: When only
      a single session using a particular well-known CPI is established
      between two nodes, this IPCA is unique.


(*) 4. IPComp Association (IPCA) Negotiation
[...]
   Two nodes may choose to negotiate IPComp in either or both
   directions, and they may choose to employ a different compression
   algorithm in each direction.


Charlie_Kaufman@notesdev.ibm.com wrote:
>
>
>
> 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).
>
>