Subject: "optmistic" defined

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Aug 2001 14:03:20 -0700 (PDT)

Right now the draft currently defines the
optimistic proposal as the first one. As stated,
that's obviously a little ambiguous since the
first proposal may allow for different transforms
and attributes. At the very least, we need to
define the optimistic proposal as the first
proposal conjugate, and for each proposal within
the conjugate the first transform and its first
attribute if present (for the ESP auth algorithm).

I'm not sure of a couple of things though:

1) There seem to be some other things which can
   also be negotiated like lifetimes, key rounds
   and key length. I'm not quite sure what key
   rounds and key length are intended for, but 
   I'd assume that if there is any possibility
   for negotiation, the first needs to be the
   "optimistic" attribute. I'm not as sure about
   the lifetimes since they really don't effect
   key generation which is really the point of
   the optimistic approach

2) Right now, there seems to be no direct way
   to determine that the receipient chose the
   optimistic payload. This requires a bunch of
   checking on the initiator to see if it chose
   all of the right things for each part of the
   conjugate. This seems like it could be the
   source of interoperability problems. Maybe 
   it would be better to have an explicit means of
   stating categorically that the recipient chose
   the optimistic proposal? Or is it sufficient
   to define, as above, what transforms, etc, 
   are pertinent to being optimistic?

		 Mike

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 27 Aug 2001 02:05:42 +0300 (EEST)

> attribute if present (for the ESP auth algorithm).

I think it is easier to remove the whole text about the optimistic
stuff, and make the negotiation always 2 packets (or 3 or 4 depending
what people decide). The Secure Shell protocol has similar optimistic
assumption and it has caused some problems in exactly same place, i.e
how to define if we actually selected the the optimistic approach or
not, does the parameters which do not affect the actual key
negotiation nullify the otherwise optimistic selection (i.e if there
are two proposals otherwise identical, but the other end selects
proposal that has life time of 3600 seconds instead of 86400 seconds).

I myself think that the gain from the optimistic approac is close to
zero, and the implementations are much easier if we do not add that
there.

Also the most common set (== best optimistic protocol suite) and the
preferred protocol suite are not necessarely same. For example the
most common protocol suite might be DES+MD5, but we might want to
propose 3DES+MD5 as our first choice (i.e the most preferred protocol
suite) instead of DES, because we think DES should be deprecated... Or
replace DES with 3DES and 3DES with AES to get up to date example.

Anyways the 3DES is going to be more common than AES for some time,
thus if we want to make use of the optimistic approach then we should
propose it first. On the other hand if we have hardware accelerator
for AES but not for 3DES, or if we otherwise just want to use faster
algorithm the preferred algorithm would be AES. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Michael Thomas <[email-masked]>
Date: Sun, 26 Aug 2001 17:29:34 -0700 (PDT)

Tero Kivinen writes:
 > stuff, and make the negotiation always 2 packets 

   There is nothing difficult about it. It just needs well
   defined rules. Also: there is no reason to not install
   the SA initially so that it is guaranteed that if the
   optimistic proposal is chosen, there won't be a race.

 > The Secure Shell protocol has similar optimistic

   If it is clear in the draft, then this shouldn't be 
   a problem. I implemented this on Friday and it seems
   to amount to checking that the transform, auth algorithm
   (for ESP) and encapsulation are the same, and perhaps
   the key length and key rounds. For IPCOMP it probably
   needs to also account for dictionary size and compression
   private algorithm. 

 > zero, and the implementations are much easier if we do not add that

   It saves a message, and provides reliability for the
   respondent instead of a race condition. That's hardly
   "zero".

 > replace DES with 3DES and 3DES with AES to get up to date example.

   This is a tradeoff that the implementation can make
   by policy. If you really, really want to use an
   uncommon transform because, say, you have hardware
   assist, then it's probably worthwhile to not choose
   the optmistic payload. Beyond that, as Dan pointed out
   on the IPsec list, in real life, it's pretty common
   that you're going to get agreement because of configuration,
   or specs which require a profile (ie, you MUST
   use 3-DES, etc). We really should take advantage of
   the common case.

 > algorithm the preferred algorithm would be AES. 

   I don't think there's a reason why KINK
   should say anything about this. It doesn't
   harm interoperability to say nothing, and 
   saves us from trying to figure out which 
   one to bet on... I'd just assume not go there.

       Mike

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 28 Aug 2001 00:28:03 +0300

>    respondent instead of a race condition. That's hardly

It does not save a message unless you want to send extra message.
There is nothing that prevents you doing the negotiation in 2 packets
in all times. I don't understand why people insist that if we do not
use optimistic approach then we must make the exchange to 3 or 4
packets. The handling can be exactly same regardless whether we used
optimistic or non optimistic except that the initiator installs the SA
only after he receives the reply from the responder. The responder
does exactly same (i.e installs the SA when sending the reply).

If you inisist that you want to have extra packet in case we are not
using optimistic approach, then you save one extra packet (which can
be interleaved with the normal data flow anyways, so it just saves
extra packet, not extra round trip or even half a round trip), but if
you do not want to have that extra packet then it saves you nothing.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Aug 2001 14:35:17 -0700 (PDT)

> does exactly same (i.e installs the SA when sending the reply).

All I can say is read the draft. There's a race
condition if the non-optimistic proposal is picked
and the first packet sent by the respondent. How
often the race condition fails is irrelevant as
to whether it's present.

 > you do not want to have that extra packet then it saves you nothing.

One of the use scenarios is small devices on
bandwidth constrained links -- like, oh say, cell
phones. A third message requires a message of
about 200-500 bytes because of the kerberos
overhead. If we don't need to send it (along with
the unpleasant need to start a timer on the reply
message), the protocol is a lot more compact on
all fronts.

	Mike

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 28 Aug 2001 00:53:33 +0300

> often the race condition fails is irrelevant as

The same race condition is also in the IKE but there it is much worse,
and most of the people do not care it less (== i.e they do not use
commit bit). Some of the IPsec implementations already have fix for
this (mostly for IKE), i.e they have small queue for incoming unknown
ESP packets (or actually known SPI, but which do not yet have keying
material).

BTW I don not think it is irrelevant how often it occurs, as if the
change is small enough then we can safely say that ok, we loose few
first packets in that case. The race condition can only cause
initiator to loose first few packets if it does not have the queue, it
cannot do anything serious.

If I remember correctly somebody also complained that they cannot do
the optimistic apporoac, because they cannot change they keying
material after the SA is installed, thus there must be some way to
disable the optimistic approach. I.e we need yet another knob there to
turn off optimistic approach, and that causes even more complex
protocol.

> message), the protocol is a lot more compact on

Thats why I was saying that do not send that third packet ever, and
always to two packets without any optimistic stuff, just install the
SAs in the responder when the first packet comes in, and install the
SAs in initiator when the responders reply comes in and everything is
done. Compact, simple, easy protocol without too mant moving parts
that can/will have bugs.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Aug 2001 17:31:33 -0700 (PDT)

> ESP packets (or actually known SPI, but which do not yet have keying

   By all means, let's faithfully reproduce IKE, bug for bug.

 > turn off optimistic approach, and that causes even more complex

   I would like more substantiation of this than an
   off the cuff comment. I would find it remarkable
   that a piece of hardware cannot be told to delete
   a currently existing SA and add another SA which
   just happens to have the same SPI as the previous.
   Indeed, I would imagine that such a piece of hardware
   is not complient with with RFC 2401 since there is
   no hysteresis with SPI's in the SADB that I'm aware of.

 > done. 

   This has a built in race condition. 

 > Compact, simple, easy protocol without too mant moving parts
 > that can/will have bugs.

   I just implemented this. It was trivial, and I'm not that
   familiar with the freeswan code, or IKE for that matter.
   Besides gaining "simplicity" at the cost of incorrect
   behavior is not a very good design practice. 

	    Mike