Subject: suggested workaround for "reliable acks"

From: Michael Thomas <[email-masked]>
Date: Sun, 19 Aug 2001 17:57:43 -0700 (PDT)

Considering that there isn't a technical obstacle
to providing a solution for our charter and
requirements item that KINK has the ability to set
up an SA in two messages, I'm very, very reluctant
to give it up just because of new found religion
on the "it's more complex" front where the
supposed complexity is manifestly not very high.
Indeed, if we want to avoid unnecessary
complexity, we would not have used Quick Mode
which is a *lot* more complex than this issue.

There are two choices, I'll list them in order of
my preference:

1) With ACK's:

o We mandate the respondent MUST request an ACK
  if it does not choose the first proposal, or
  if PFS was required by the initiator. 

o We eliminate Nr in the response

o We put the reply on a timer, and retransmit
  until we get an ACK

2) Without ACK's:

o We eliminate ACK's altogether
o The respondent lives with the non-deterministic SA
  installation by the initiator when the
  optimistic route is not taken.

I have some real reservations about (2) as this is
a current criticism of IKE and it's somewhat
specious to talk about something that "simpler"
which is simultaneously broken. 

	 Mike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Aug 2001 01:12:40 +0300 (EEST)

> which is simultaneously broken. 

If you have been following the discussion on the IPsec list you notice
that this is the way the IKE quick mode is moving to (or the other
possibility is 4 packets).

I don't really understand what is so hard or non-deerministic about
this.

The initiator has something he wants to send to the responder, he
starts negotiation and sends his first packet, which includes SA, Ni,
[IDs], [KE] etc. The responder sees that packet and selects whatever
SA he wants and send reply back with SA, Nr, [IDs], [KE]. After
sending reply back he creates the keying material and installs the
SA.

Now the initiator gets the reply packet which includes all the
information needed to create the SA, thus he can install the SA and
start using it. If he does not receive the reply packet for some time,
he resends the first packet and in that case the responder will
immediately retransmit his packet back.

Now both ends have SAs up and the initiator starts sending the packets
he has queued up waiting for the IPsec SA to be created. If the
responder happens to have some packets to send between the time where
he has installed the SAs, but before the initiator has set up his SAs
(very unlikely event), then he will send the packets to the initiator
with the SA that is know to the initiator, but to which he does not
have keying material yet (the initiator knows the SPI, as it was
selected by him). The initiator can just simply drop the packets if he
feels like, or he might queue them up waiting for the SAs to come up.

If this is rekey case then the responder will use the old SA as long
as it is there, meaning that it moves to use the new SA when it is
deleted via explicit delete or because it expired. It can have some
kind of timer to send delete for the old SA itself if the initiator
who started the rekey does not delete the SA after few minutes or so. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 22 Aug 2001 18:53:48 -0400

> The initiator can just simply drop the packets if he feels like, or
> he might queue them up waiting for the SAs to come up.

A few months ago I implemented inbound queueing of this form; it makes
a *big* difference in reducing connection setup latencies (and
typically means that the first "ping"/SYN packets get through, albeit
with a significantly higher latency).

> who started the rekey does not delete the SA after few minutes or

Note that different folks do this differently ( "use oldest" vs "use
newest"; "use newest" recovers faster from a partial loss of state,
though that's largely irrelevant if you have initial-contact.

					- Bill

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Aug 2001 16:21:05 -0700 (PDT)

> with a significantly higher latency).

Bill,

I'm having a hard time reconciling Tero's
characterization of this being a rare situation
(since it requires the initiator to lose the
reply) and your characterization that make a *big*
difference. I agree with Tero that it ought to be
as rare as the chance of the initiator losing the
reply which under normal circumstances shouldn't
be very often.

Are we talking about the same thing?

    Mike

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 22 Aug 2001 19:26:59 -0400

> difference. 

It's not rare if the first encrypted packet of traffic hits the
initiator's inbound SA lookup before the KM reply is processed and the
SA is fully built.  

If the KM reply is processed on a "slow path" (on solaris, we do key
management in userland but ESP in the kernel), this sort of
"reordering" happens more often than not..

					- Bill

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Aug 2001 16:34:00 -0700 (PDT)

> "reordering" happens more often than not..

   Ah, thank you. The alternative of the convoluted (imo)
   inbound SA queuing you spoke of is to require Bob
   to receive the ACK from Alice before installing his
   outbound SA. Inbound queuing on a potentially volatile
   half opened connection seems rather... gross. It
   would be better to have this be completely deterministic
   for Bob and Alice. That's why I favor option (1).

	   Mike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Aug 2001 02:52:09 +0300

> "reordering" happens more often than not..

This is for the rekeying case I assume. For the rekeying it is common
case that the responder has something to send to the initiator, and if
he switches to the new SA immediately after he sets it up, then the
initiator might see traffic that he does not have keying material yet.

This same thing also happens with the 3 packet quick mode currently
defined in IKE when the initiator sends the final HASH and immediately
starts sending ESP traffic using that SA. Now the responder usually
will wait the HASH to arrive before installing the SA, which means
that when the final qm packet arrives and is being processed by the
userland ike daemon, the ESP traffic is at the same time already
coming to the machine.

This does not apply to KINK as responder can always install the SA
immediately after seeing the first packet, thus he will have the SA
state up and ready when the initiator starts using it. This same thing
will be the case for the 2 packet quick mode for IKE also when the
replay attack for quick mode has been solved by some other mean than
requiring the 3rd packet.

The case which I said to be rare is the case where initiator and
responder do not have SAs up, and the initiator starts negotiation
with responder and after the first packet of the quick has been
processed by the responder the responder gets something it wants to
send to the initiator before the initiator has processed the packet
sent by the responder. I.e:

     Initiator					Responder
     ---------					---------

     Gets a packet he wants
     to send to responder.

     Starts creating IPsec SA

     Sends SA, Ni ------------------->

						Receives SA, Ni

						Generates SA, Nr

						Calculates keying
						material

						Installs IPsec SA

						*start*

			<---------------------	Sends SA, Nr

     Receives SA, Nr

     Calculates keying
     material

     Installs IPsec SA

     *end*

I.e if the responder suddenly gets some packet it wants to send to the
initiator between time *start* and *end* it will send it using the SA
which the initiator does not yet have keying material, thus the
initiator either needs to queue it up or discard the packet.

In normal case it would be very rare that the responder spontaneously
happen to have something to send to the initiator which needs IPsec
processing during this few milliseconds time.

In normal case it is the time needed by the responder to send the
packet it already has ready after the SA has been installed (one
system call after the install SA returns, can be happening
simultaneously if there is multiple processors in the system) plus the
time needed by the initiator from receiving the 2nd quick mode packet
from the ethernet to the point it installs the IPsec SA (this needs
parsing of the packet, few hash calculations, and installing of SA). 

The time can be larger in case we are using PFS, in which case the
initiator has to do rest of the Diffie-Hellman calculation before it
can install the SA.

Also if the 2nd quick mode packet is lost then we need to add
retranmission time (or multiple of those if more packets get dropped)
to get the actual time window.

One case where this case might not be that uncommon is for some kind
of clock syncronization protocol where both ends are sending each
other a packet every hour or something. In that case both ends have
data to send at almost the same time, and they either end up having
two SAs in case the clocks are really on sync, or one SA, and then the
machine that was slower in starting to send is going to have
possibility that his packet is dropped by the initiator.

There are multiple ways for the implementation to get rid of this
problem. One could be that inbound queue for partial SAs, another
could be that responder does not install the outbound SA immediately
but only after some timeout or after seeing some traffic on inbound SA
etc.

For most of the case I think this problem is so rare, that we can just
cope with one lost packet. The upper level protocol must have
retransmission and ack system anyways if they really want the packet
to reach the other end.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/