Project

General

Profile

Bug #2669

osm-msc doesn't clean up BSC state

Added by laforge 11 months ago. Updated 22 days ago.

Status:
New
Priority:
Low
Assignee:
Category:
A interface (general)
Target version:
-
Start date:
11/20/2017
Due date:
% Done:

0%

Resolution:

Description

If a BSC has ever sent a BSSMAP RESET to OsmoMSC we acknowledge this with a RESET-ACK. But then it appears we keep its state indefinitely and want to perform a MSC-originated RESET procedure in return. If the BSC never gets back, this process appears to continue indefinitely.

This is bad, as it means that anyone ever sending/spoofing a single "BSSMAP RESET" to OsmoMSC will be able to turn it into an "amplification attack" with OsmoMSC sending BSSMAP RESET in return.

In order to avoid this, we should probably do both of:

  • stop re-transmitting the BSSMAP RESET after some point and simply forget about the BSCs
  • introduce a "locked down" mode in which we don't accept BSSMAP from any random source out there, but only explicitly configured BSCs (in the VTY)

History

#1 Updated by laforge 10 months ago

  • Category set to A interface (AoIP)

#2 Updated by laforge 10 months ago

  • Category changed from A interface (AoIP) to A interface (general)

#3 Updated by dexter 7 months ago

See also #2397 As soon as we start collecting LACs we can also collect information about when the BSC appeared first and when the last activity was. This allows us to perform a regular garbage collection.

#4 Updated by dexter 7 months ago

Another idea: Once we can maintain the lists using the VTY, we could also have an VTY option that disables the BSC-Auto-Learning completely if necessary.

#5 Updated by laforge 22 days ago

  • Assignee changed from dexter to osmith

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)