Project

General

Profile

Bug #1968

upon auth resync with osmo_auth_gen_vec_auts(), use MS.SQN + (2 ^ IND)

Added by neels about 2 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Start date:
03/07/2017
Due date:
% Done:

100%

Spec Reference:

Description

USIMs have an IND value denoting the lower number of bits that are "below" the synchronized SQN significance,
i.e. we need to flip at least the (IND+1)th bit when doing AUTS resync.

For example, receiving an AUTS from a USIM showing MS.SQN = 0, an IND = 5 means
that the next auth vector should be produced for MS.SQN = 2^5 = 32.
So far we are using MS.SQN + 1, which causes the USIM to ask for resync again and again.

Add ind argument to osmo_auth_gen_vec_auts() so that the caller can communicate the USIM's IND setting,
and increment SQN by (1 << IND).


Related issues

Related to OsmoHLR - Feature #1969: add IND for proper UMTS auth resync Resolved 03/07/2017
Related to Cellular Infrastructure - Support #1965: use sysmoUSIM-SJS1 with 3G OsmoMSC Resolved 03/04/2017

History

#1 Updated by neels about 2 months ago

  • Status changed from New to In Progress

#2 Updated by neels about 2 months ago

  • Related to Feature #1969: add IND for proper UMTS auth resync added

#3 Updated by laforge about 2 months ago

  • Related to Support #1965: use sysmoUSIM-SJS1 with 3G OsmoMSC added

#4 Updated by neels about 1 month ago

We need both an ind and an i argument:
ind defines the amount of bits that are not significant for SEQ and make up SQN.
i defines which IND slot/bucket the current SQN consumer wants SQNs for.

|----------SEQ------------|
|------------------------SQN-----------|
                          |<---------->|<-- IND

We also need ind and i in the non-AUTS vector generation code.

Every consumer shall get N vectors as (SEQ + (n << IND) + i),
e.g. for IND 5 bits, the IND value range has 2^5 32 slots,
and a consumer with i 0 gets 32, 64, 96,... where i 1 gets 33, 65, 97...

This is only needed for UMTS auth, but will affect large parts of the public osmo_auth API.
Probably best to add new API to be used for UMTS auth, while the old API remains available.

#5 Updated by neels about 1 month ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF