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).

[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.