Change in osmo-msc[master]: msc_vty.c: configurable retrieval of IMEI, IMEISV

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Mon Dec 17 15:27:11 UTC 2018


Neels Hofmeyr has posted comments on this change. ( https://gerrit.osmocom.org/12302 )

Change subject: msc_vty.c: configurable retrieval of IMEI, IMEISV
......................................................................


Patch Set 1:

(3 comments)

https://gerrit.osmocom.org/#/c/12302/1/src/libmsc/msc_vty.c
File src/libmsc/msc_vty.c:

https://gerrit.osmocom.org/#/c/12302/1/src/libmsc/msc_vty.c@437
PS1, Line 437:       "Send each IMEI to the EIR to ask if it is permitted or not. The EIR is implemented as part of osmo-hlr, "
slightly out-of-scope, we don't know whether the user is using OsmoHLR or something else.


https://gerrit.osmocom.org/#/c/12302/1/src/libmsc/msc_vty.c@440
PS1, Line 440:       "1 = send each IMEI to the EIR\n")
(we normally don't name the values again, just write the string for that value. online vty doc will print the value and add your string to it)


https://gerrit.osmocom.org/#/c/12302/1/src/libmsc/msc_vty.c@448
PS1, Line 448: ""
> It might be helpful to understand what "early" means in here. […]
IIUC this patch doesn't require adding IMEISV config, so maybe we can push this off into the future instead?

Some explanation:

IMEISV can be

 * not requested;
 * requested as an explicit Identity Request roundtrip;
 * requested as piggy-back on the Ciphering Mode Complete, partly to save roundtrips, but actually more importantly to not leak the identity in an unencrypted message, because above ID Request typically happens before ciphering.

So the IMEISV-Early says "We require the IMEISV, and ask for it in the beginning via ID Request".
And the IMEISV-ciphered says "We require IMEISV, but wait until after ciphering".

I think to the user, it could make sense to offer:

  retrieve-imeisv (0|1|early)
  0  Do not request an IMEISV
  1  Request an IMEISV. With encryption enabled, this will be requested during Ciphering Mode negotiation.
     Without encryption, this will cause a separate Identity Request.
  early  Request an IMEISV, always use a separate, unencrypted Identity Request even if encryption is enabled.

Not sure about:

* do we even need the 'early' option?
* I can imagine requesting IMEISV could be an implicit internal process instead of a user config, and we only have these flags in vlr because we haven't implemented the code that would require an IMEISV yet? (the SV, software version, does indicate some traits but I forget what it was)



-- 
To view, visit https://gerrit.osmocom.org/12302
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Iee516b9cd7877b21207ce9a6d954109f19558163
Gerrit-Change-Number: 12302
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: osmith <osmith at sysmocom.de>
Gerrit-CC: Max <msuraev at sysmocom.de>
Gerrit-CC: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-CC: Stefan Sperling <stsp at stsp.name>
Gerrit-Comment-Date: Mon, 17 Dec 2018 15:27:11 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181217/cace56e6/attachment.htm>


More information about the gerrit-log mailing list