## Feature #2461

Updated by pespin over 2 years ago

Currently the "encryption" parameter lets define which cipher is allowed by BSC, 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.

Tests in osmo-gsm-tester showed that currently if "encryption a5 X" is set in osmo-msc, then same config (with X) must also be applied to osmo-bsc, otherwise the set of ciphers coming from MSC will be rejected.

Proposed way:

The BSC in this case, needs to intersect the set received by MSC with the set of supported ciphers by te MS and the set of supported ciphers by the BTS, and return the intersection or send back a "Reject" if intersection is void.

The list of ciphers supported by MS is received as explained in 3GPP TS 24.008: classmark 1 says whether a5/1 is supported, classmark 2 has a5/3 and a5/2 and classmark 3 has the rest of them.

The list of ciphers cipgers supported by the BTS is unknown. We have 2 options here:

# In BSC VTY, move the "encryption" parameter from net->encryption to net->bts[N]->encryption, that is, make it per-BTS. It should also be converted to a bitmask or a list as explained in #2460.

# Remove "encryption" parameter from BSC VTY, and expect every BTS to send list of allowed ciphers to BSC. (Not sure if this is currently possible).

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.

Tests in osmo-gsm-tester showed that currently if "encryption a5 X" is set in osmo-msc, then same config (with X) must also be applied to osmo-bsc, otherwise the set of ciphers coming from MSC will be rejected.

Proposed way:

The BSC in this case, needs to intersect the set received by MSC with the set of supported ciphers by te MS and the set of supported ciphers by the BTS, and return the intersection or send back a "Reject" if intersection is void.

The list of ciphers supported by MS is received as explained in 3GPP TS 24.008: classmark 1 says whether a5/1 is supported, classmark 2 has a5/3 and a5/2 and classmark 3 has the rest of them.

The list of ciphers cipgers supported by the BTS is unknown. We have 2 options here:

# In BSC VTY, move the "encryption" parameter from net->encryption to net->bts[N]->encryption, that is, make it per-BTS. It should also be converted to a bitmask or a list as explained in #2460.

# Remove "encryption" parameter from BSC VTY, and expect every BTS to send list of allowed ciphers to BSC. (Not sure if this is currently possible).