Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
From:   =?UTF-8?B?UmFmYcWCIEdhamRh?= <rafal.gajda@silvair.com>
Date:   Mon, 30 Mar 2020 11:27:11 +0200
Message-ID: <CAFcXi1wcxdckvPhs_Rf-4dB4Ws6wvqiuMjXfc_zP2u+OK9ToPw@mail.gmail.com>
Subject: Incorrect IV update behavior
To:     linux-bluetooth@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi,

It looks like there is a bug in daemon IV update procedure handling.

When node with iv=3Dn and ivu=3DFalse receives beacon it should:
a. beacon with IV=3Dn+1, IVU=3DTrue - set own IVU=3DTrue, send with IV=3Dn,
don't reset sequence
b. beacon with IV=3Dn+1, IVU=3DFalse - set own IV=3Dn+1, send with IV=3Dn+1
and reset sequence

Currently, when daemon receives beacon with IV=3Dn+1, IVU=3DFalse it will
start sending messages with new IV and set sequence to 0.
However if daemon receives another beacon with IV=3Dn+1, IVU=3DTrue it
will go back to sending messages with old IV=3Dn (IVU will be set to
True).
Because sequence number has been reset those messages will be dropped
by replay protection and node will lose communication.

Once IV is updated daemon should not go back to using the old value.
--=20
Rafa=C5=82 Gajda

Silvair Sp. z o.o.