- nextepc - lists.osmocom.org

SNOW-3G / ZUC implementation under FOSS license?
by Paul Sutton 16 Jul '19

16 Jul '19

Hi Harald, The srsLTE implementation is taken from the ETSI specs simulation program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf https://www.etsi.org/intellectual-property-rights#mytoc3 and https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the copyright licensing details for software incorporated in ETSI standards however I have not taken legal advice on compatibility of this license with AGPLv3. >From a quick review, it looks like the CryptoMobile and NextEPC versions have taken the same approach. It would be good as you say to have a "clean copyright" implementation - perhaps this is something we could help with. Best regards, Paul > Hi! > > I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for > NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. > > However, it seems there is no real FOSS implementation of the SNOW-3G algoritm > around? All I could find was: > > * https://github.com/mitshell/CryptoMobile with unclear source of the code, > without a copyright statement or license annotation > > * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main… > without a copyright statement or license annotation > > * https://github.com/Jadson27101/SNOW_3G in go, > without a copyright statement or license annotation > > * https://github.com/KsirbJ/SNOW-3G > without a copyright statement or license annotation > > * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c > without a copyright statement or license annotation. Looks rather similar > to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? > > * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc > also contains no coypright statement or license, but might be construed > to be AGPLv3 like all of srsLTE. However, it states it is "adapted" > from ETSI/SAGE specifications. Does that mean it is an independent > implementation of the algorithm by just reading the specs, or does it > contain actual ETSI-copyrighted code? > > It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) > don't contain any actual information but all just point to the ETSI SAGE specification > which can be found (at the very least) here: > https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf > and interestingly doesn't contain any copyright statement whatsoever. > > This discussion is not about any potentially 'essential patents' that may or may > not apply in some jurisdictions on the algorithm itself. I'm currently only interested > in a "clean copyright" implementation of any of the EIA/EEA implementations used > on the LTE NAS layer. > > I'd appreciate any useful comments. Thanks! > > -- > - Harald Welte <laforge at gnumonks.org <https://lists.osmocom.org/mailman/listinfo/openbsc>> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -- ________________________________________________________________ Paul Sutton Ph.D. Software Radio Systems (SRS) http://www.softwareradiosystems.com paul(a)softwareradiosystems.com PGP Key ID: 3B4A5292 Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292 ________________________________________________________________

2 1

osmocom CN domain and keyword
by Peter Liu 16 Jul '19

16 Jul '19

(It's very urgent, please transfer this email to your CEO. Thanks) We are a Network Service Company which is the domain name registration center in Shanghai, China. On July 16, 2019, we received an application from Kaiqian Ltd requested "osmocom" as their internet keyword and China (CN) domain names (osmocom.cn, osmocom.com.cn, osmocom.net.cn, osmocom.org.cn). But after checking it, we find this name conflict with your company name or trademark. In order to deal with this matter better, it's necessary to send email to you and confirm whether your company have connection with this Chinese company or not? Best Regards *************************************** Peter Liu | Service & Operations Manager China Registry (Head Office) | 6012, Xingdi Building, No. 1698 Yishan Road, Shanghai 201103, China Tel: +86-02164193517 | Fax: +86-02164198327 | Mob: +86-13816428671 Email: peter(a)chinaregistry.org Web: www.chinaregistry.org *************************************** This email contains privileged and confidential information intended for the addressee only. If you are not the intended recipient, please destroy this email and inform the sender immediately. We appreciate you respecting the confidentiality of this information by not disclosing or using the information in this email.

1 0

OCS interface/NB-IoT support
by Daniel Feferman 15 Jul '19

15 Jul '19

Hi, First of all congrats for the work, I've been testing over this week and it has been really nice to stress it. I have two questions: 1- It would be really nice to see an OCS integration, is it possible to connect the PCRF and PGW with it? I believe this would be done by a 127.0.0.X IP, right? Is this something simple to implement? It would be nice to check the support to OCS 2- I believe you are developing NB-IoT support as part of your roadmap, what are the main challenges you see in this task? Is it just programming the messages of NB-IoT? Or is it something else? I can try to help you with this task. Best regards, Daniel <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 2

Re: CS Fallback in NextEPC
by Romeu Medeiros 14 Jul '19

14 Jul '19

Hello Sukchan, I already go out from the lab today, but Monday I will made this test that you ask for. Have a great day there. Romeu Medeiros Em sáb, 13 de jul de 2019 às 21:01, Sukchan Lee <acetcom(a)gmail.com> escreveu: > Hi Romeu, > > I'm really appreciate testing CSFB even though I have never been testing > this feature in the lab. > > BTW, I have one question. If we want to remove Security-Related IE in UE > Context Modification Request, > I think NextEPC should not derive kENB in Extended Service Request handler. > > Nevertheless, I've merged your pull request since it is properly worked at > first. ^^; > > If your lab is available, could you test one more by removing the > following code? > > In src/mme/emm-handler.c > 586 if (SECURITY_CONTEXT_IS_VALID(mme_ue)) { > 587 mme_kdf_enb(mme_ue->kasme, mme_ue->ul_count.i32, mme_ue->kenb); > 588 mme_kdf_nh(mme_ue->kasme, mme_ue->kenb, mme_ue->nh); > 589 mme_ue->nhcc = 1; > 590 } > > Just test it. If my expectation is true, I will fix all other things. > > Thank you for your GREAT job! > > Best regards, > Sukchan > > > > > > On Sun, Jul 14, 2019 at 8:04 AM Romeu Medeiros <medeiros(a)medeiros.eng.br> > wrote: > >> Hello Sukchan, >> >> Now after remove this everything run correctly. >> >> [image: image.png] >> >> I will made the change more beatiful and pull the modification to the git >> to you aprove. >> >> Thanks >> >> Romeu Medeiros >> >> On Sat, Jul 13, 2019 at 6:50 PM Romeu Medeiros <medeiros(a)medeiros.eng.br> >> wrote: >> >>> I found this in the 3GPP documentations [1]: >>> >>> [image: image.png] >>> >>> I will change the code to send only the CSFallback indicator in this >>> case to see if can solve the problem. >>> >>> Thanks >>> >>> Romeu Medeiros >>> >>> 1. >>> https://www.etsi.org/deliver/etsi_ts/136400_136499/136413/09.10.00_60/ts_13… >>> >>> On Sat, Jul 13, 2019 at 6:35 PM Romeu Medeiros <medeiros(a)medeiros.eng.br> >>> wrote: >>> >>>> Hello Sukchan and friends. >>>> >>>> I'm trying to use the CSFB in test lab, and every time that nextepc >>>> send the UEContextModificationRequest, the UE respond with an >>>> UEContextModificationFaliure [ Protocol-cause=semantic-error ]. >>>> >>>> [image: image.png] >>>> >>>> I'm looking why I'm getting this. Someone have any idea? >>>> >>>> Thanks >>>> >>>> Romeu Medeiros >>>> >>>> On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee <acetcom(a)gmail.com> wrote: >>>> >>>>> Dear Osmocom & NextEPC Community, >>>>> >>>>> Today I've added CS Fallback and released NextEPC v0.5.0 >>>>> >>>>> So, I'd just like to test this part with Osmocom project, but it seems >>>>> to be a difficult task. The reason is why I have little knowledge about >>>>> 2G/3G. Nevertheless, I will try to do it >>>>> >>>>> BTW, I don't know if there is anyone who wants to integrate this big >>>>> thing. >>>>> Even though I'm not sure if this will help, but let me introduce the >>>>> configuration of the NextEPC. >>>>> >>>>> To use SGsAP, change the mme.conf as follows: >>>>> >>>>> # >>>>> # <sgsap> >>>>> # >>>>> # o Single MSC/VLR >>>>> # sgsap: >>>>> # addr: 127.0.0.2 >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4130 >>>>> # lac: 43690 >>>>> # >>>>> # o Multiple MSC/VLR >>>>> # sgsap: >>>>> # - addr: 127.0.0.2 >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4131 >>>>> # lac: 43692 >>>>> # - addr >>>>> # - 127.0.0.3 >>>>> # - fe80::2%lo0 >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4132 >>>>> # lac: 43692 >>>>> # - name: msc.open5gs.org >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4133 >>>>> # lac: 43693 >>>>> # >>>>> >>>>> FYI, I also attach the pcap that I run with nextepc simulator as below. >>>>> >>>>> $ ./tests/testcsfb >>>>> mo-idle-test : SUCCESS >>>>> mt-idle-test : SUCCESS >>>>> mo-active-test : SUCCESS >>>>> mt-active-test : SUCCESS >>>>> All tests passed. >>>>> >>>>> Feel free to raise any questions about this things. >>>>> >>>>> Best Regards, >>>>> Sukchan >>>>> >>>>>

2 10

Question on Uplink 'sequence count' handling in MME
by Harald Welte 13 Jul '19

13 Jul '19

Hi Sukchan and list, I'm currently reading the MME code and I'm having some trouble understanding the handling of the uplink counter for NAS security. I only see mme_ue->ul_count.i32 ever being set to '0' when a new security context is used. But I don't see it ever being incremented? I only see ul_count.sqn incremented, but then the nas_mac_calculate() always gets ul_count.i32 passed as input. So I'm somehow not understanding how the MAC can ever verify on any uplink message beyond/after the first one which establishes a new security context. What am I missing? Thanks for your insight! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

SNOW-3G / ZUC implementation under FOSS license?
by Harald Welte 12 Jul '19

12 Jul '19

Hi! I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. However, it seems there is no real FOSS implementation of the SNOW-3G algoritm around? All I could find was: * https://github.com/mitshell/CryptoMobile with unclear source of the code, without a copyright statement or license annotation * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main… without a copyright statement or license annotation * https://github.com/Jadson27101/SNOW_3G in go, without a copyright statement or license annotation * https://github.com/KsirbJ/SNOW-3G without a copyright statement or license annotation * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c without a copyright statement or license annotation. Looks rather similar to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc also contains no coypright statement or license, but might be construed to be AGPLv3 like all of srsLTE. However, it states it is "adapted" from ETSI/SAGE specifications. Does that mean it is an independent implementation of the algorithm by just reading the specs, or does it contain actual ETSI-copyrighted code? It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) don't contain any actual information but all just point to the ETSI SAGE specification which can be found (at the very least) here: https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf and interestingly doesn't contain any copyright statement whatsoever. This discussion is not about any potentially 'essential patents' that may or may not apply in some jurisdictions on the algorithm itself. I'm currently only interested in a "clean copyright" implementation of any of the EIA/EEA implementations used on the LTE NAS layer. I'd appreciate any useful comments. Thanks! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Easy way to add subscribers to hss without node.js / web UI
by Harald Welte 12 Jul '19

12 Jul '19

Hi Sukchan and list, I was wondering if there was a way to create subscribers in the HSS from a script or from the command line and avoid/bypass all the node.js and npm "nightmare" (I know, it's a matter of taste, but to me it is). Particularly for automated tests, I wouldnt't want to write scripts against a web gui to create subscribers. Also, for most operators (small or big), I guess they want to import a bulk CSV (or other format) file with key data. If there was a way to add subscribers from a script / command line, I could e.g. writea script to import the CSV for the sysmoUSIM/SJS1 easily. Thanks for any assistance. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 2

Wy does the MME need a mongodb database?
by Harald Welte 11 Jul '19

11 Jul '19

Hi Sukchan and othres, I'm wondering why the MME itself is currently requiring a mongodb database? What is it used for? I'm a bit confused, I thought mongodb was only used by the HSS for subscriber storage. However, it seems that (at least with current nextepc), the MME also needs mongodb. I cannot immediately find any code that uses it? Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Security research
by Holtmanns, Silke (Nokia - FI/Espoo) 11 Jul '19

11 Jul '19

Hi, I'm part of security research and we are mainly interested in the core network part and not on the UE part. What we want to do is have a PGW which has some the EPC "machinery" behind to get a TEID and have MME, HSS, SGW initialized and some not real UEs i.e. the fake UEs would sit in or next to the eNB. In the end we are interested in plugging this EPC next to a real one with a real S8 connection. We do not need real internet connection for the "fake UE" and user plane is also not that important for us. So how can we get a "fake UE" into the eNB, so that is makes all the protocol runs for data communication set-up. Any hints? Greetings silke

3 2

License for our test suites
by Harald Welte 09 Jul '19

09 Jul '19

Dear Osmocom community, during recent years we have developed a quite extensive set of test suites for virtually all interfaces on all protocol levels of our 2G stack, and recently even extended at least with some 3G IuCS coverage. Those test suites are considerably valuable for testing any kind of implementation of 2G / 3G network elements, even beyond Osmocom. I'm a bit worried that they might be used to test proprietary implementations, which would bring no value to growing FOSS in mobile communications. Whether we license the test suites under GPL or AGPL doesn't actually change much here: Imagine "EvilCorp" developing a BSC, using our test suites against it. They neither distribute the test suite, nor do they provide "access over a network" to it, an hence they could keep any modifications/extensions/derivatives private without having to contribute those back. I think this is problematic. We develop those test suites because we care about having well-tested FOSS in cellular communications, whether Osmocom or other FOSS projects. I certainly don't want to spend my spare time, or invest sysmocom resources towards improving the test coverage of any non-FOSS implementations. If such users are out there, they should at the very least contribute to the development effort in one way (code) or another (funding). For 2G/3G, I think this discussion is quite theoretical, as there is unlikely anyone else implementing those old technologies in proprietary systems - Osmocom is probably typically the latest player in the market to do so. However, as I'm currently working on a first set of TTCN3 tests for testing a LTE MME (initially attacing to S1 and SGs), I'm wondering if we should continue to release related code under traditional copyleft licenses. One idea would be to have a license that permits the use of the test suites to test only FOSS software. In theory, that would mean that all projects we care about (such as currently srsLTE, nextepc, OAI EPC, ...) could use the test suites to test their software. On the other hand, if some vendor of proprietary MME/EPC software would want to [legally] use the tests, they would need to obtain a different (paid) license to the test suite. Of course they could simply ignore the license and we'd have little chance to learn about it - but I would argue most proper companies typically would obtain a license if they used some software they knew they had to license. This is a very double-edged sword. Drafting such a new license would cause license proliferation, which is always bad. It also raises quesetions of license compatibility with e.g. some of our common existing 'library' code that would need to be investigated. Finally, it also means that we'd no longer be writing "free software" nor "open source", as the respective relevant definitions always require "non discriminatory use for any purpose", which would no longer be the case here. This is currently an early stage brainstorming. Now is the right point in time to talk about this, before we release any LTE/EPC related tests. Let me know if you have any thoughts to share. While I'm cross-posting this to openbsc@ and nextepc@ lists, pleaes follow-up-to openbsc(a)lists.osmocom.org, as that's the main Osmocom mailing list and we don't have any specifically only for the test suites. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

2025

2024

2023

2022

2021

2020

2019

nextepc