Subject: [Hipsec] Update race condition

From: [email-masked] (Jan Mikael Melen)
Date: Thu Mar 4 02:05:03 2004

Hi!

The draft-moskowitz-hip-09 in section 8.10 step 10 the draft state that
"If the system is in state REKEYING, and the UPDATE doesn't have the R-bit set
in the NES TLV, there are apparently two UPDATE packets crossing each other
in the network. Consequently, the R-bit-less packet is handled as specified
in Section 8.10.1."

The update packets that are crossing each other in the network can not be
handled as specified today in section 8.10.1 because if they are handled as
specified in 8.10.1 then both ends will fetch wrong incoming SA keys and
wrong outgoing SA keys. Host-A expects to receive with the same key as HOST-B
expects to receive not good. Have I understood the draft correctly?

Solution to this problem would be that the keys would be fetched in predefined
order. When a update packet is received the keys are always fetched in
following way. Compare the HITs and first fetch the key of the host that has
in network byte order smaller HIT and then fetch the key of the host that has
in network byte order greater HIT (this is also used in section 9 generating
HIP Keymat). Comments?

There is one corner case which has to be also stated in the draft and that is.
If host A has sent a update containing keymat index 172 to host B. At the
same host B has sent a update packet containing keymat index 220 to host A (B
has for some reason decided not to use the keying material between 172-220
this is allowed already today). These two packets are crossing each other on
the network. So A has to accept the greater keymat index gotten in update
packet although it does not match with the index sent. Also B has to accept
that the keymat index in update packet is older than what it would like to
use (this is new and should be allowed only if B is in state rekeying). Both
A and B when creating the update reply packet must put the greater keymat
index in to the reply packet. The bigger keymat index always wins.

  Regards,
        Jan

---

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 5 00:54:01 2004

> in network byte order greater HIT (this is also used in section 9 

Sounds good to me.

> index in to the reply packet. The bigger keymat index always wins.

Sounds good.

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Tue Mar 23 08:01:01 2004

Related to the UPDATE race condition, I propose some changes to text in 
8.10 and 8.10.1. Any comments?

/petri

Jan Mikael Melen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

I propose to add some text to 8.10:

8.10 Processing UPDATE packets

    When a system receives a UPDATE packet, its processing depends on
    whether the packet is a reply to a previously sent UPDATE packet or
    the UPDATE is a new packet.

    The order of the keys retrieved from the KEYMAT during rekeying
    process depends on the HIT value comparison. We denote the host with
    lower HIT value with HITl and, respectively, the host with greater
    HIT with HITg. The HITs are compared in network byte order. The keys
    are retrieved from the KEYMAT in the following order:

       SA-gl ESP encryption key for HITg's outgoing traffic

       SA-gl ESP authentication key for HITg's outgoing traffic

       SA-lg ESP encryption key for HITl's outgoing traffic

       SA-lg ESP authentication key for HITl's outgoing traffic

    The following steps define the conceptual processing rules responding
    handling a received UPDATE packet:
...

> index in to the reply packet. The bigger keymat index always wins.

And to fix this potential problem:

In 8.10, change the bullet number 5 (to allow also lower Keymat Index if 
we are in REKEYING state):

    5.   If the received UPDATE does not contain a Diffie-Hellman
         parameter, the received Keymat Index MUST be larger or equal to
         the index of the next byte to be drawn from the current KEYMAT.
         If the host is in REKEYING state, a smaller Keymat Index value
         MAY be accepted.  If the host is in ESTABLISHED state and this
         test fails, the packet SHOULD be dropped and the system SHOULD
         log an error message.

And in 8.10.1, a new bullet that defines that in race condition, we 
select the bigger of the Keymat Indexes:

    4.  If the host is in REKEYING state, and neither the incoming UPDATE
        packet nor the sent UPDATE packet required new KEYMAT generation,
        the bigger Keymat Index number of those two UPDATE packets shall
        be used.

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 29 02:58:05 2004

>    When a system receives a UPDATE packet, its processing depends on

s/a UPDATE/an UPDATE/

>    the UPDATE is a new packet.

I find the statement above confusing, since the following text does
not specify what is the difference.  Maybe the text should be moved
into another position (later)?

>    are retrieved from the KEYMAT in the following order:

Should there be a reference to the KEYMAT generation section here,
noting that this is identical to the process of generating the
initial KEYMAT?

I also find it slightly confusing to call the *hosts* as HITg and
HITl, maybe use H_g and H_l or HOST_g and HOST_l instead?

>    handling a received UPDATE packet:

Other than the comments above, OK so far.

> In 8.10, change the bullet number 5 (to allow also lower Keymat Index 
> if we are in REKEYING state):
>

I find this lacking of information.  I think there should be some 
description
of the reasons for the MAY, i.e., under which condition accepting such a
lower index is reasonable.

>        the bigger Keymat Index number of those two UPDATE packets shall

Maybe add: ... generation, /and the Keymat Index numbers in the UPDATE
packets are different,/ the bigger...

If you add that, you can deleted /of those two UPDATE packets/

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Mon Mar 29 05:40:01 2004

>>    When a system receives a UPDATE packet, its processing depends on

Fixed, together with few other similar bugs that were left in the paper
after NES -> UPDATE change.

> into another position (later)?

I changed it a bit, see below together with the KEYMAT text.

> noting that this is identical to the process of generating the

In the original KEYMAT generation, the HITs are put into the KEYMAT
"generator" in a certain order. The key retrieval is done depending on
the Initiator / Responder status. In the UPDATE case, we retrieve keys 
using the HIT comparison. I don't see direct analogy between these 
processes. Or was this what you meant?

Maybe the text should be written like (including modified text due to 
the earlier comment):

8.10 Processing UPDATE packet

When a host receives an UPDATE packet, it indicates that either the host
itself has earlier requested rekeying or the peer is initiating rekeying.

If either of the hosts requires that a new KEYMAT must be generated, the 
generation is done as described in 9. HIP KEYMAT.

The order of the keys retrieved from the KEYMAT during rekeying process
depends on the HIT value comparison. We denote the host with lower HIT
value with HOST_l and, respectively, the host with greater HIT with
HOST_g. The HITs are compared in network byte order. The keys are
retrieved from the KEYMAT in the following order.

<list of retrieval rules>

Note that the retrieval is different than in the case of initial KEYMAT
generation (see. 9. HIP KEYMAT) where the retrieval is based on host's
Initiator / Responder status. This is not relevat during rekeying
process, especially in a possible race situation when both hosts have
initiated the rekeying simultaneously.

The following steps define the conceptual processing rules for handling
a received UPDATE packet (note that the handling is slightly different

> HITl, maybe use H_g and H_l or HOST_g and HOST_l instead?

(Ok, above)

> lower index is reasonable.

... a smaller Keymat Index MAY be accepted, if the host itself has
skipped part of the KEYMAT and selected a bigger index for the
previously sent UPDATE packet.

> If you add that, you can deleted /of those two UPDATE packets/

Ok.

/petri