[PATCHv6 3/5] FT RRB: add msg replay and msg delay protection

[Jouni Malinen]

On Sun, Apr 02, 2017 at 02:52:51PM +0200, Michael Braun wrote:
> This adds a counter and adds sequence numbering to FT RRB packets. The
> sequence number is checked against r0kh/r1kh sequence number cache.
> 
> Special attention is needed in case the remote AP reboots and thus loses
> its state. I prefer it to recover automatically even without synchronized
> clocks.  Therefore an identifier called dom is generated randomly along the
> initial sequence number. If the dom transmitted does not match or the
> sequence number is not in the range currently expected, the sender is asked
> for a fresh confirmation of its currently used sequence numbers. The packet
> that triggered this is cached and processed again later.

This seems to be breaking a number of hwsim test cases. For example,
ap_ft_sae fails every time when run on its own. When run after some
other FT test cases, it can pass, but that is not really good behavior,
i.e., every single case should work.

Something seems to be going wrong with sequence number updating:

FT: Received push
FT: sequence number - hexdump(len=12): 11 22 b1 de 61 22 3f bc 03 00 00 00
FT: Possibly invalid sequence number in push from 02:00:00:00:03:00
FT: RRB-OUI type 4 send to 02:00:00:00:03:00

FT: Received sequence number request
FT: seq request - nonce - hexdump(len=16): 38 87 10 d5 a9 38 e2 1b 6a a1 ee bf fb 78 49 06
FT: RRB-OUI type 5 send to 02:00:00:00:04:00

FT: Received sequence number response
FT: sequence number - hexdump(len=12): 11 22 b1 de 62 22 3f bc 03 00 00 00
FT: seq response - reset seq number
FT: Received push
FT: sequence number - hexdump(len=12): 11 22 b1 de 61 22 3f bc 03 00 00 00
FT: Invalid sequence number in push from 02:00:00:00:03:00


It looks like the sequence number does indeed get reset, but the first
message that needed this gets dropped completely and there is no
automatic recovery from that. This makes the first FT protocol exchange
fail. Was this by design? Or was there supposed to be some kind of
mechanism to allow this first frame be accepted after sequence number
reset?


I was going through the remaining patches in this series and did some
cleanup while reviewing them. The current snapshot is here:
https://w1.fi/p/ft-rrb/

However, I could not proceed any further due to these hwsim test case
failures from this patch 3/5. And I cannot apply the first two patches
either on their own since I want to get all the
backwards-compatibility-breaking patches in at the same time.

-- 
Jouni Malinen                                            PGP id EFC895FA