Project

General

Profile

Feature #2460

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

Added by pespin over 1 year ago. Updated 11 months ago.

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

100%

Resolution:

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
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 Closed2017-08-22

Related to OsmoBSC - Feature #2461: Improve "encryption" VTY parameterResolved2017-08-24

History

#1 Updated by pespin over 1 year ago

  • Description updated (diff)

#2 Updated by pespin over 1 year ago

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

#3 Updated by pespin over 1 year ago

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

#4 Updated by neels over 1 year ago

  • Description updated (diff)

#5 Updated by laforge over 1 year ago

  • Assignee set to sysmocom

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.

#6 Updated by laforge 12 months ago

  • Status changed from New to In Progress
  • Assignee changed from sysmocom to laforge

#7 Updated by laforge 12 months ago

  • Category set to A interface (AoIP)

#8 Updated by laforge 12 months ago

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

#9 Updated by laforge 12 months 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.

#10 Updated by neels 11 months ago

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

#11 Updated by laforge 11 months 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)