Project

General

Profile

Actions

Feature #2460

closed

Change "encryption" VTY parameter to allow more than one cipher

Added by pespin over 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
A interface (general)
Target version:
-
Start date:
08/24/2017
Due date:
% Done:

100%

Resolution:
Spec Reference:

Description

Currently the "encryption" parameter lets define which cipher is allowed by MSC, but only one can be allowed at a given time: "encryption a5 (0|1|2|3)"

In AoIP protocol, however, the cipher is negotiated between MSC<->BSC (BSC interesected with BTS and MS capabilities). Once "Authentication Response" reaches MSC with correct challenge response, the MSC sends a "Cipher Mode Command" to the BSC with a bitmask stating the allowed ciphers.

As we currently only set 1 cipher in config, only 1 bit can be enabled at a time in the bitmask, and if that mode doesn't match the one required by BSC/BTS/MS, then BSC will send a Reject and the modem will fail to connect.

We should be able to specify "encryption" parameter either as a bitmask or a list instead of a plain integer, eg:

encryption a5 <0..7> [<0..7>] [<0..7>] [<0..7>] [<0..7>] [<0..7>] [<0..7>]

allowing

encryption a5 0 1 3

Files

encryption.diff encryption.diff 3.1 KB laforge, 12/23/2017 05:25 PM

Related issues

Related to OsmoGSMTester - Feature #2457: osmo-gsm-tester: add test case: validate "encryption" & "authentication" vty parameter Closedpespin08/22/2017

Actions
Related to OsmoBSC - Feature #2461: Improve "encryption" VTY parameterResolvedlaforge08/24/2017

Actions
Actions #1

Updated by pespin over 6 years ago

  • Description updated (diff)
Actions #2

Updated by pespin over 6 years ago

  • Related to Feature #2457: osmo-gsm-tester: add test case: validate "encryption" & "authentication" vty parameter added
Actions #3

Updated by pespin over 6 years ago

  • Related to Feature #2461: Improve "encryption" VTY parameter added
Actions #4

Updated by neels over 6 years ago

  • Description updated (diff)
Actions #5

Updated by laforge over 6 years ago

  • Assignee set to 4368

makes a lot of sense to me.

At the same time, we also have to take into consideration the capabilities of the BTS.

So there is basically:
  • capability of the phone in classmark (interpreted by the MSC, I suppose?)
  • capability of the BTS (BSC should know based on BTS atttributes [new] or implicitly by BTS model / version)
  • policy on the BSC (which ones are administratively permitted or not)
  • policy on the MSC (which ones are administratively permitted or not)

All in all, it's a bit like codec support/negotiation, but luckily only with one leg/phone at a time.

In terms of defaults, we should probably have 1+3 as "administratively permitted" unless the config file/vty states something else.

Actions #6

Updated by laforge over 6 years ago

  • Status changed from New to In Progress
  • Assignee changed from 4368 to laforge
Actions #7

Updated by laforge over 6 years ago

  • Category set to A interface (AoIP)
Actions #8

Updated by laforge over 6 years ago

  • Category changed from A interface (AoIP) to A interface (general)
Actions #9

Updated by laforge over 6 years ago

Implemented in https://gerrit.osmocom.org/5559 and https://gerrit.osmocom.org/5560

Unit test still should be expanded to cover the new features.

Actions #10

Updated by neels about 6 years ago

added minor comments to the patches ... but I see that we might not want to merge before we have tests for it

Actions #11

Updated by laforge about 6 years ago

  • Status changed from In Progress to Resolved
  • Assignee changed from neels to laforge
  • % Done changed from 80 to 100

patches merged, as they have been tested against the new test cases of https://gerrit.osmocom.org/6145

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)