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

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



  Charlie,

  When we started the IKEv2 effort we wanted to use the lessons learned
from deployment of IKEv1 to decide what to change and how to change it.

  One of the things that almost never happened in a non-lab, non-bakeoff
environment was negotiation of SAs. No one ever really took advantage of
the complex ANDing and ORing of arbitrary proposals. So we did away with
it. I'll return to this in a second but...

  To answer your question, yes I prefer the a la carte method specified
in ikev2-02 more than I prefer the suites _and_ a la carte method
specified in ikev2-05. We should either have suites period or a la carte
period. Having both strikes me as redoing the mistakes from IKEv1 (in
an attempt to get "consensus" I tried to satisfy everyone's demands and
ended up with an overly complex beast that we all have grown to hate).

  You mention that a Diffie-Hellman group is part of the attributes
of SAs negotiated as a suite. Well, not really, as I said in my
original post on this subject. They're not part of the IPsec suites
which makes the supporting a Diffie-Hellman exchange in the 
CREATE_CHILD exchange difficult. Do you guess the group by the length
of the KE payload? That doesn't seem right and if that's the way to do
it then why have the Diffie-Hellman group as part of the IKE suite?
So properly supporting Diffie-Hellman groups in IPsec suites requires
a doubling of the IPsec suites. That is an argument against suites.

  Now back to negotiation. You say we lose the ability to offer different
compression algorithms with different suites. But our deployment experience
would show that such a capability is not necessary because it wouldn't
be used. We just have to allow the each side to say what algorithm they
are willing to do and what CPI they want to do it under (for the reasons
Avram mentioned). Such a la carte "negotiation" is currently supported in
IKEv2-05 but that's because IKEv2-05 mandates BOTH suites and a la carte.

  IKEv2-02 has a whole bunch of vanity algorithms (triple IDEA, IDEA, RC5,
TIGER, etc) that we can do away with. But the method of specifying what
you wanted to do was much simpler and it avoids the suite explosion we're
already seeing. IKEv2-02 also had the complex ANDing and ORing that I
think we should get rid of. Why not just have a single SA payload that
contains TLVs for each of the necessary attributes? Multiple occurances
of an attribute mean "I'll do either" (as it was in IKEv2-02 even though
I doubt that would be used much if ever).

   initiator: "ESP: 3DES, HMAC-SHA, Group 5, LZS, CPI=x" 
   responder: "ESP: 3DES, HMAC-SHA, Group 5". 

There, IPcomp was just un-negotiated. And they agreed on everything else.

  Whether we have suites or a la carte our deployment experience shows
that 99% of the time the initiator will just offer a single suite or
an a la carte offer of one algorithm each. There won't be any "negotiation".
It's just agreement or it's a mis-configuration. 

  Dan.

On Mon, 03 Mar 2003 21:19:36 EST you wrote
> 
> For people advocating that the working group reconsider the suites vs. a la
> carte decision, it might help clarify things if you specified whether you
> advocated a la carte as specified in ikev2-02 or whether you preferred some
> alternate encoding of offers and the accepted combination (and if so, what
> encoding). It would also be helpful if you specified how each of the
> attributes listed below should be negotiated (if different from ikev2-05).
> 
> There seems to be some confusion over exactly what's negotiated as part of
> a suite and what's not in ikev2-05. Even advocates of suites might want
> some different organization. Currently, the following attributes of SAs are
> negotiated as a suite:
> 
> ESP vs AH vs IKE SA
> Diffie-Hellman Group
> Encryption Algorithm (including mode and key size)
> Integrity Protection Algorithm (including whether Extended Sequence Numbers
> are used)
> PRF Algorithm (for IKE SAs only)
> 
> There are some other SA attributes that are negotiated independently.
> 
> Compression algorithms (IPcomp) are proposed by the initiator and selected
> (or not) by the responder. By not including compression algorithms in the
> cryptographic suites, we avoid the multiplicative explosion we should get
> in the likely case that implementations supported multiple suites and
> multiple compression algorithms. What we lose is the ability to offer Suite
> 1 with LZS or Suite 2 with DEFLATE but not Suite 1 with DEFLATE or Suite 2
> with LZS. So far, no one has made a case for needing that flexibility and
> several people have pointed out the perils of including compression in the
> cryptographic suite.
> 
> Transport Mode (vs. tunnel) is proposed by the initiator and accepted (or
> not) by the responder. Support for transport mode is optional. There is a
> presumption that if the initiator proposes transport mode that she would
> prefer to use it. There is a presumption that if the responder does not
> support transport mode, that the initiator will accept an SA in tunnel mode
> with the same cryptographic suite. If that's not true in some
> implementation, the initiator would have to close the SA without using it.
> And as with compression, there is no ability to offer Suite 1 with
> transport Mode or Suite 2 with tunnel mode but not the other combination.
> 
> Explicit Congestion Notification was negotiated in IKEv1 but a single
> algorithm (not negotiable) is specified for all SAs negotiated with IKEv2.
> No one (yet) has argued for the ability to negotiate alternate ECN
> protocols, much less to make such negotiation tied in with cryptographic
> suites. I would imagine that should we need such negotiation in the future,
> it would be negotiated independently of the other SA attributes.
> 
> UDP Encapsulation for NAT Traversal was negotiated in IKEv1 but is not in
> IKEv2. UDP Encapsulation is unilaterally selected by the initiator in IKEv2
> upon detecting a NAT, and any SA negotiated via an encapsulated IKE SA will
> also be encapsulated using the same UDP ports.
> 
> Authentication Algorithm is unilaterally selected by the initiator in
> IKEv1. In IKEv2, each end chooses its own authentication algorithm
> (sometimes with hints from the other end as to what is supported).
> 
> SA Lifetime was negotiated in IKEv1. In IKEv2, each end independently
> chooses an SA Lifetime and whoever has the shorter one will initiate a key
> rollover.
> 
> A case could be made for negotiating use of Extended Sequence Numbers
> independently from crypto suite in a manner similar to transport vs tunnel
> mode. I proposed including it in crypto suite because I assumed that the
> only reason to not use ESNs was for backwards compatibility and that all
> new cryptographic suites would require them.
> 
>           --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).
>