BLE Link Layer behavior for "barge-in attack"?

[Elias]

This is a more specific counterpart to a question I posted on StackExchange. If you want to know more about the attack itself, check that out, but here, I'm asking for a specific behavior that the attack takes advantage of. I'm going to refer to Devices A and B, which are in an active unencrypted connection.

When the Link Layer of Device A receives an invalid packet, it transmits a reply with a non-incremented Next Expected Sequence Number, which signals to Device B's Link Layer that it should re-transmit the packet. Is there a limit from the perspective of Device B on how many times this can happen? If it's receiving valid packets, the channel is apparently usable, but none of the packets it's transmitting are apparently getting through.

Will Device B just keep trying to re-transmit the same packet as long as Device A keeps asking for it?

[endnode]

There is parameter called Supervision Timeout which guards "lost" connections. It's typically in 1-32s range so if you keep jamming or blocking Link Layer PDU in one or both directions for 30~1000 connection intervals in the row it's treated by BLE controllers (stacks) on both sides as if they would lost the link and they will terminate it internally. This interval has some relation to other connection parameters but in general it is managed by upper layers of the stack if they have intention to do it.

To channel re-mapping: you mean changing channel map of the connection? That cannot happen without correctly received LL packet, can it? I believe that if you are loosing all LL packets in a row you won't change any parameter of the connection (however normal "hardcoded" properties like channel hopping for every interval will be exercised).

[Elias]

Yes, I know about the Supervision Timeout, but as far as Device B is concerned, no jamming is happening. Do you mean to say that valid PDUs with a non-incremented NESN still count against the Timeout?

As for the bit about channel re-map, you're right, it would depend on the first part of the question, so I've removed it, since it was a bit distracting.

[endnode]

Indeed, not advancing LL counters mean that packet is invalid (or at least this is how I understand BT SIG Core spec and expect all BLE stacks to be validated during qualification, haven't verified myself). If the LL PDU is invalid in this sense it should be completely ignored by LL and should not be propagated to higher layers so it is effectively equal to receiving packet with wrong integrity/security or not receiving the packet at all.

[endnode]

I've also read your attack scenario several times again and I believe it is not applicable. Once any timeout kicks-in then device terminates the link so you cannot force one peer by jamming the packets to disconnect from legitimate target and then stay connected to "attacker". Or maybe I haven't understood how exactly this attack should work. From my 4-year experience and several security analysis there is just relay/MITM attack possible (you really need to "block" packets from one peer and mimic it by sending your own packets towards second peer + vice versa for the other direction) or dumb DoS (jamming whole spectrum or just particular channel + time to disturb either Tx or Rx windows). Both are pretty easy to execute (basic BLE knowledge and any dev kit will do the job).

[Hung Bui]

As far as I understand, the connection will not be timed out as long as the peer still receive "valid packet" , so it doesn't mater if it's a NACK or and ACK, it's still a valid packet. Quoted here:

To be able to detect link loss, both the master and the slave shall use a Link Layer connection supervision timer, T_LLconnSupervision. Upon reception of a valid packet, the timer shall be reset.

Core spec 4.2 , Vol 6 Part B section 4.5.2 .

B will continue transmitting , there is no time out for this except if it's in a procedure that has a timeout, such as encrypting (30s timeout).

I don't understand purpose, what is the next step of jamming a device and then let other device transmitting ?