<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DoS immunity at general advertising mode</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/9761/dos-immunity-at-general-advertising-mode</link><description>Hello, 
 My question based on case, I&amp;#39;ve experienced recently.
nRF device that could advertise in general mode for limited time by pressing on button and continuously in whitelist mode after bonding. The windows was paired with this device before. I</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 20 Oct 2015 13:35:18 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/9761/dos-immunity-at-general-advertising-mode" /><item><title>RE: DoS immunity at general advertising mode</title><link>https://devzone.nordicsemi.com/thread/36161?ContentTypeID=1</link><pubDate>Tue, 20 Oct 2015 13:35:18 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a0bc63a3-9f16-4605-9f32-eac7827415c3</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Valer,&lt;/p&gt;
&lt;p&gt;It&amp;#39;s true that it could be a risk that we can be DoS attacked by attacker by do continuous scanning and sending connect request.&lt;/p&gt;
&lt;p&gt;Unfortunately, with the current Bluetooth stack, we don&amp;#39;t have a way to do a blacklist advertising to avoid being connected by a central device (the attacker can spoof and change the address of the central device anyway).&lt;/p&gt;
&lt;p&gt;Your solution to reduce the TxPower sounds like a good idea. You can set that mode so that the first connection and bond should be performed with short distance.&lt;/p&gt;
&lt;p&gt;Another solution is that you do non-connectable advertising at the beginning then you do active scanning from the central device you want to connect to. The previously bonded device will also do active scanning but you should be able to detect him. By having active scan, you should be able to find the address of the new device you want to allow connection.&lt;/p&gt;
&lt;p&gt;Then you can start advertising with whitelist for only the specific device. This way you can block the connect request from the other device.
However, it won&amp;#39;t help if the previously device keep sending connect request on every single advertising packet (jamming the connection).&lt;/p&gt;
&lt;p&gt;So, what you proposed is a proper workaround.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>