<p><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/19793">View Change</a></p><p>1 comment:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/19793/2/src/osmo-bsc/abis_rsl.c">File src/osmo-bsc/abis_rsl.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/19793/2/src/osmo-bsc/abis_rsl.c@1406">Patch Set #2, Line 1406:</a> <code style="font-family:monospace,monospace">     l</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">how do we protect against Denial of Service here?  I think we unconditioally append every channel request to the queue, growing it to extreme lengths.  Think of somebody running a RACH DoS attack.</p><p style="white-space: pre-wrap; word-wrap: break-word;">If I read the code correctly:</p><p style="white-space: pre-wrap; word-wrap: break-word;">With the previous code in master (without a queue), I think there is stil la somewhat fair chance that a valid RACH request from a user gets a channel, as valid and invalid requests compete.</p><p style="white-space: pre-wrap; word-wrap: break-word;">With an indefinitely long queue, all of the hundreds to thousands of fake RACH requests make a very long queue, and until that queue has been fully processed, no new real RACH request has any chance of succeeding.</p><p style="white-space: pre-wrap; word-wrap: break-word;">So I think this patch would create a "DoS amplification", as it makes the situation even worse than it already is under DoS.</p><p style="white-space: pre-wrap; word-wrap: break-word;">If the queue grows beyond a certain length, the phone will have given up waiting for an IMMEDIATE ASSIGN (or IMMEDIATE ASSIGN REJECT) by the time we process the entry in the queue.  So I think the entries must have a timeout that correlates with the timeout on the MS side, which in turn I believe is configured by the RACH control parameters in the system information.</p><p style="white-space: pre-wrap; word-wrap: break-word;">What about: When we dequeue the entries, we first check if the timeout already has expired.  If it has, discard that queue entry and move to the next?</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-bsc/+/19793">change 19793</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-bsc/+/19793"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-bsc </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36 </div>
<div style="display:none"> Gerrit-Change-Number: 19793 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: dexter <pmaier@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-CC: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 03 Sep 2020 10:31:20 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>