Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

[endnode]

Dear Nordic team and community,

Have you encountered the problem where standard BT4.0/4.1 GAP Peripheral device would be "blocked" from connection (kind of "denial of service" situation) by too many actively scanning GAP Scanners/Centrals? We are seeing this with certain mobile phones (especially Android) in "observing" role and this is pretty independent on adv. interval we use (typically 20-200ms). All adv. events are "loaded" with SCAN_REQ packets when there are 5 or more "scanning" phones and beside SCAN_REQ collisions (which are typically not critical for BLE solutions) basically all CONNECT_REQ collide with some SCAN_REQ packet and thus Peripheral never follows the connection.

Any suggestions (beside trying to lower scanning activity on phones' side which obviously isn't always possible)?

Thanks Jan

[Roger Clark]

Hi Jan

I can see DOS attacks being more and more common, especially with the BLE Web API being released by Google recently (in Chrome)

I have thought about defence strategies for this, and one option I considered was changing the "connectable" flags if your software thinks its under DOS attack

e.g. just turn it off for a few seconds, of perhaps longer.

But. I've not tried this myself yet.

I also looked at trying to prevent devices connecting in an attempt to flatten the battery.

So I tried immediately disconnecting, if the first attempt didn't immediately write to a custom (authorisation) characteristic, with a password. But it didnt help, because Android appears to immediately tries to reconnect, over and over again, until it times out (which seems to take around 5 secs)

Hence I considered changing the connectable flag, but didnt have time to investigate whether that would work

[endnode]

Hi Roger, you are right, there are two well known and pretty easy DOS attacks on BLE:

1. "flooding" all 3 adv. channels (or entire 40) with noise
2. connecting to every adv. packet issued (so peripheral device won't be available for legitimate Central).

Note that there is almost no mitigation possible and that's also reason why you will have big problems to deliver radio-based applications to critical applications such as healthcare, military and security. Anyway that's not what I'm describing here. For two DOS scenarios I've mentioned you need to be active attacker with clearly malicious intentions (or absolutely ignorant to standards and regulations) so you could track it and put the attacker down. The scenario I'm describing in this question is different: all the parties behave normally and perfectly according to the specifications, yet they create DOS when reaching critical mass.

[endnode]

Few more things on the issue:

• It really looks like having any mobile app on mobile which causes heavy active (SCAN_REQ) scanning in GAP Scanner/Central role can take 15-30% of available "slots" (aka RX windows following ADV_IND packets from GAP Peripheral) so at 3-4 devices in the range you wills tart to observe occasional collisions and with 5-6 you will already have big troubles to find any available RX window to start connection.
• Note that this can be hardly prevented as users can have BT enabled and any application running and you can do very little about it.
• This would mean that any "dense" areas such as airports, office spaces, rush streets etc. should be full of such "DOS" zones. However there seems to be no such complains so I'm wondering if this "heavy scanning" behavior is limited only to few devices (I've tested Samsung Galaxy S6/7/8) or it happens only...

[endnode]

... if applications are in the foreground (which is unusual) or it is something pretty recent so similar reports are yet to come.

[Roger Clark]

Hi Jan

My concern was not for a hardware DOS style attach, where the channels were effectively jammed by sending random noise, as I dont know if its possible to write a phone app to make the phone hardware do that.

I was more concerned with web pages maliciously using the BLE web api without the user knowing it was happening. i.e if an app deliberately does this, its likely google and apple would remove it from their App stores. But scripts on websites are a lot harder to ban.

At the moment I dont know enough about the BLE protocol to know how to defend from the script kiddie type DOS attack.

I have investigated multiple beacons in close proximity ( 100 beacons in the same room) and I did not see to many problems with this, but I have not tried lots of phones and a few beacons. I suppose I could simulate this by reflashing my Smartbeacons with some Central code.