32C3 preroll music Herald: For several years now, here at the Congress and at the Camp, we see that we have a GSM network, that we operate our own network, that we have some services like recently GPRS or roaming between the different parts of the areas in the Camp. All of this started around 7 years from now, with a talk at the 25C3; and a bunch of projects emerged from that over the years. But wait, there is more. Right now, the people running these services and running these projects are starting to play around with 3G. And for everybody who doesn’t know what 3G is, like I did, for like 5 minutes ago, 3G means that we will have HDSPA and data services on our GSM networks. And I’m very honoured to introduce to you this evening Harald Welte, a member of our Chaos family for several years now, known maybe from the Kernel development. I first read his name while debugging a chip card driver that stated ‘All bugs introduced by…’ – this guy over there. So, other people may know him from gpl-violations.org, where they try to enforce the GPL. So. Please welcome Harald Welte, and… the stage is yours! applause LaForge: Hi. Welcome everyone to this talk about, well, running your own GSM network, or running your own 3G network, rather, sorry for that. And in more technical terms, the slide titles with lots of acronyms as it is customary in the telecom world. So forgive me if there’s too many acronyms, but I didn’t invent them, I just try to use them whenever appropriate. Okay. So, let’s start with a little bit of a history of open source in mobile communication protocols. You have to remember that we started about 16 years after the proprietary implementations, so the GSM network that we are running here at the event, or that we started to run 7 years ago, started 16 years after GSM networks were run first in the public in Europe, so, at public operators. So we’re really, really late, and if you want to compare the status of open source mobile communications with open source operating system, then I would say we are about where Linux was in ’94 or ’95. So, very far from today, for those of you who are old enough to remember these days. So, I would say “capable but not taken seriously” is sort of the general status. The developer community working on these projects is still very small. There’s a limited adoption in the market and the users, often in niche applications, but nevertheless it is functional. So, if we look a little bit at the timeline, 2008 we had the talk about “Running your own GSM network” with a huge Siemens base station weighing I think 28 kg… Did my microphone…? No, it works, sorry. …weighing 28 kg and bulky old equipment not using TCP/IP but using E1 lines etc. Over the years we added more and more BTS model vendors. Basically it means we can use Ericsson and Nokia and other equipment to actually run these GSM networks today. People have been working on GPRS support in a couple of sub projects called OsmoSGSN, OpenGGSN, also the OsmoPCU project, so we’ve been growing the stack downwards, also basically implementing the software inside such a BTS, which we call OsmoBTS. There are some production deployments – all spellings my mistake, by the way, as obviously – so, production deployments in niche applications such as maritime markets. So, if today you are on a ferry or on a cruise ship and you use GSM services, the probability that you’re using OpenBSC and associated projects in the background is very strong. There are hundreds of vessels using our software today. Now, then we… applause …then we moved on the telephone side, so we thought, well, you know, network side GSM in one thing, but let’s do the phone as well, that was OsmocomBB, started in 2010. We did improvements over the years, more and more completed the stack, but it’s really all only old GSM/GPRS technology until very recently. So in 2015, 15 years again after the first commercial deployment of GPRS in a public network, we start to have an open source implementation of EDGE, and that has just started like 2 or 3 months ago. So again, 15..16 years late compared to what happens in the proprietary world. Ok. But… this talk is not about EDGE, which is 2.75G, if you want to speak in generation numbers. Today we’re talking about 3G and 3.5G. And there’s a bit of ambivalence with that subject because, well, today, if you talk to people in the industry, they will say: “Ah, who cares about 3G, you know, it’s dead anyway!”. We have already today at the point where we have ‘Peak 3G’, so in the next few years, the number of subscribers and the number of networks offering 3G services is no longer growing, it’s basically stagnating and will turn downwards in the near future. So LTE/4G networks is basically what everyone is hot about. The other reason not to look at 3G is that it’s mind-bogglingly complex. It’s not a single telephony system, it’s actually a toolbox to build arbitrary telephony systems. And if you really wanted to start implementing it from scratch including all the lower layers, including the PHY, including the Layer 2 etc. I think it would be a waste of a lot of time, actually. So we do what we did with the GSM networks back then, we used proprietary base station hardware, and we implement the higher level protocols, and then, if needed and if there’s interest and contributions etc. we drive open source further down the stack and also into the actual cells. So, one term that’s going to be used here in this context is ‘femtocells’. Quite some number of people may have heard about femtocells before. In technical terms it’s a base station – which is called NodeB in the UMTS language world – and a radio network controller, which is the BSC, the base station controller – in UMTS in one box. And using such femtocells or similar hardware is much easier to interface than if you would use a regular base station. So that basically is sort of a path that we think is doable without spending man-years of implementing obscure and complex transport channels and bundles and mappings and whatnot. There’s been a couple of talks about doing creative stuff with femtocells. There’ve been talks by Kevin [Redon], Nico [Golde] and Ravishankar in 2010/2011 about security. There’s been a recent presentation this year at Black Hat in the United States called ‘Adventures in Femtoland’. Those talks focus on basically, well, the security of the femtocell itself, breaking into such a cell, rooting it, owning it, doing creative things and then from there e.g. attacking the mobile operator or attacking the privacy of subscribers by using such a femtocell as a man-in-the-middle platform e.g. But to my knowledge nobody has been talking about free software or open source software, to run a network with such femtocells or similar equipment. So, if we look at the UMTS architecture, like you find it in a textbook or like in this particular slide or drawing from Kevin, you will find several network elements all over the network, so lots of different elements with lots of different acronyms. We have a Mobile Equipment (ME) which is the telephone. We have a radio interface called the Uu interface. We have actual base stations called NodeB and we have a base station controller that’s called the Radio Network Controller, the RNC; and then here we have, on this boundary we have IuCS and IuPS interfaces that interface the Base Station Controllers with the core of the network which is the Mobile Switching Center, the Media Gateway, the Serving GPRS Support Node, and then other elements here. And this is actually the interface line which we have been implementing in recent months at the boundary between the Access Network, the Radio Access Network and the Core Network on the other side of the slide. So, well, you could just get a NodeB and implement the protocol Iub. This is what we did with GSM before, we basically started here. We only got the actual BTS or NodeB and we implemented that protocol. However, well, this protocol in UMTS is extremely complex and fairly low down the stack. Just to give you an idea: every single voice codec frame from a voice call that you receive has 3 different classes of bits, and each class of bits gets put into different UDP messages, and then you get basically 3 flows of UDP messages, and you need to synchronize and inter-mangle (?) and re-interleave those bits in order to get to a speech codec frame. So it’s… and I’m not even talking about the signalling plane (?). So the lower you get in UMTS the more complex it gets, let’s try to avoid that. And that’s the kind of complexity that I like to avoid. This is from the official spec about the UMTS spectrum. It’s an extremely obvious and self-explanatory slide, so I’ll… laughter I leave it at this and say, yeah, that’s not what we want to do. So, we… how can I say, we… Even though we don’t like it we just use proprietary blobs to implement that. Now, the protocol stacking on those interfaces that we actually want to implement is what I’m going to look at the next couple of slides. The Iu interface, and by the name, Iu has no specific meaning, it’s just the Iu interface, you could say the A, the B, the C, the Z interface – it’s the ‘Iu interface’. It’s split in CS and PS, that’s circuit- switched and packet-switched. Circuit-switched means telephony services and packet-switched means data services. And we’re going to look at the protocol stacking of those interfaces in the next couple of slides. Originally, remember, well, maybe a good time to go back in history, in sort of history of mobile communications, which should be taught at every school, I think, including archeology of protocols, which… no, honestly… laughter and applause You need to do protocol archeology if you want to implement certain interfaces today. So, on my blog you can find some posts about a couple of years ago where I had to basically write a parser for Microsoft Word for DOS text files to automatically extract snippets of ASN.1 syntax for MAP version 1 which is still used today. So, it’s… yes, it… sometimes you really need to do archeology. So anyway, not for this, but any… when UMTS was specified, this is the late 90s, this is when the first dotcom bubble basically got big, this is when billions and billions of Euros or Dollars or whatever unit of currency was poured into the development of the ‘universal telephony mobile system’, the… sorry, the ‘universal mobile telephony system’, the UMTS, which should basically be the grand unifying theory of mobile communications. And it was built on top of ATM, of course, because ATM was the most shiny and brightest technology in the late 90s that all the universities were researching. So, if you look at the classical protocol stacking and you look at the individual interfaces; the Uu is the radio interface, Iub is between the NodeB and RNC, but this is… the IuPS is actually what we want to implement. So basically the left side of this slide is what is implemented in the proprietary base stations or femtocells that we are using, and the right-hand side of that slide is what we are implementing. So we need to implement the protocol stackings here. As you can see the protocol stack is deep and has many acronyms. So, to make things more complicated the femtocells that you can find on the market are slightly different from the real, normal 3G architecture, so if you try to compare this slide with that slide, you will find some differences here. The difference is that they introduce a security gateway which is basically just ITU and 3GPP language for ‘IPsec gateway’, and you have a HomeNodeB gateway that doesn’t really do anything useful, rather than putting messages from one protocol stack on the left to another protocol stack on the right with the underlying protocols doing exactly the same thing but being differently encoded. And this is what you can see here, basically, the HomeNodeB gateway which is part of the software that we implemented. You can see basically, well, you have RANAP, this is the protocol that really is sort of what we’re interested in, the Radio Access Network Application Part; and RANAP, in order to implement that, there’s several other protocols underneath. And on the femtocell which is called HNodeB, the HomeNodeB, because, well, ‘femtocells’ is a marketing term and specs can never use marketing terms, so they have technical terms. So, the femtocell basically encapsulates RANAP into RUA, the ‘RANAP User…’, what was it? Sorry, …Adaptation, yes. The ‘RANAP User Adaptation’. So the ‘Radio Access Network Application Part User Adaptation’, on top of the SCTP, the Streaming Control Transfer Protocol, which some may know is a protocol that’s on the same layer as TCP or UDP but has different properties. And this RUA is implemented than (?) the HomeNodeB Gateway where it is replaced by M3UA and SCCP. And basically the same RANAP message gets passed from left to right. So it’s really… you could think like… think of it like an IPv6 to IPv4 proxy. If that’s more an area that you’re more familiar with. Okay. So, I said there are some differences between an actual, regular, old-fashioned UMTS base station, like your public operator would use it and the HomeNodeB, or femtocell, that we like to use in this project, at least initially. And I said the main difference is that the RNC, the Radio Network Controller, is built-in, so a lot of the lower layer protocols are terminated, and we don’t need to worry about that. If we look at the protocol stacking again there is a lot of protocol layers here, you can see the MAC layer, the RLC layer, the RRC layer… and all the PHYsical stuff underneath is all basically already implemented because it’s part of the femtocell, in this case. So the protocol stacking now looks a little bit like this. We have the HomeNodeB, and the HomeNodeB gateway, and then our core network elements already. So the SGSN and the GGSN, if you’ve looked at GSM in the past, or GPRS, even the software that exists today and for many years in the Osmocom project, we have implementations of those. What we are missing is the HomeNodeB gateway, and is all the fancy new protocols here. And some modifications. So, well, what do we need to do to actually implement? This Iuh protocol. As I said there’s the different protocol layers – there is RUA, there is the RANAP protocol, and the HNBAP protocol. Let’s look at those protocols, what they do, and how can we implement them. I’m skipping a few slides in the middle because it’s illustrative if somebody wants to check the slides later but it would go into too much detail at this point. So the RANAP User Adaptation layer – given the spec number above there, so if you look for that online you can find the actual spec – is a very simple connection-oriented layer that provides you the notion of a connection over a datagram transport layer underneath. It has very, very few operations and message types, including CONNECT which – well, surprisingly – sets up a new connection. DIRECT TRANSFER which transfers data inside a connection. DISCONNECT – to terminate a connection. And CONNECTIONLESS TRANSFER to transfer data outside of a connection. And, of course, an ERROR INDICATION, in case something goes wrong. So we can have multiple connections in parallel over a signalling link. And they are distinguished by a 24 bit context ID, to differentiate those multiple parallel connections. Think of it like a port number. In the case of UDP, or whatever else you might want to compare it to. So, this… if you look at this and you read the specs like “Oh, pfff, you know, it’s nothing, it’s like you implement like 5..6 message types and that’s it”… well, there’s a bit more details to that, but we’ll get back later to this. The HomeNodeB Application… no, HomeNodeB Application Part, the HNBAP protocol has a couple of more transactions which basically serve for the registration of the cell to the network, the registration of user equipment, UE, that’s your mobile phone, and some additional messages. So HNB is the HomeNodeB registration; we have Registration REQUEST, ACCEPT, REJECT, De-registration, we have the same for mobile phones. We have some more detailed transactions that I’m going to skip. But also it’s really very simple, conceptially, it’s not very complex, you don’t have like massive state machines or anything like that. Very few, very limited messages. Then we look at RANAP. That’s the Radio Access Network Application Part. This is where your actual signalling messages from the phone are tunneled through. So if your phone registers to the network you may have heard the term LOCATION UPDATE where the phone basically registers to the network or updates its location with the network. That’s the first message you would see, encapsulated inside RANAP, and transported to the core network element. Also things like PDP context activation, if you activate a data connection to a certain APN over cellular protocols, all this is encapsulated in the RANAP layer. Also the number of messages that we actually need is extremely limited. Again, it’s a very short list, it’s not like hundreds of messages. But the messages themselves can be quite complex. With nesting levels up to 12..14 layers deep. But we’ll see that later on. So we have a couple of transactions. RESET – well, I don’t need to explain – it’s a Reset. INITIAL UE MESSAGE means a new phone has connected, and it has sent us the first message that this phone has transmitted, that’s why it’s ‘initial’ message. DIRECT TRANSFER is all the follow-up transfer. IU RELEASE means we’re releasing a connection. Some commands to configure the security, the ciphering, the encryption. A PAGING command by which the network can initiate a transaction to the phone. And RAB ASSIGNMENT. RAB is the Radio Access Bearer which is basically an abstract notion of a bearer able to transport communication. If you come from classic telephony the bearer was an analog voice channel. If you go to ISDN the bearer is a 64kbps synchronous channel where you have Alaw Ulaw (?) inside, and voice data. Or you have some HTLC (?) or X75 or whatever data inside. In GSM the bearer is typically voice bearers, with different voice codecs. The same it is in UMTS. And basically you can configure those bearers in UMTS because that’s a very universal and flexible part of the system. Now, one of the protocols we have seen in the stack – I’m just going back a couple of slides to reiterate – that is the SCCP which is introduced here. The ‘Signalling Connection Control Part’, if I remember correctly. It’s a protocol that’s used a lot in core networks of mobile operators. So if you look at Roaming interfaces, at classic SS7 interfaces – think of the SS7 security talks etc. we’ve had here at CCC events a lot of times – this is a protocol that’s very often used in a lot of different parts of telecom. But the problem is – everywhere except [at] this particular point in UMTS and GSM it is used only in connection-less mode; and this is the only point where it uses connection-oriented SCCP. And therefor none of the existing free software implementations is implemented. You can look to Yate, you can look to the libosmo-sccp, the library that we have in the Osmocom project. You can look at the Mobicents Java stack for these protocols. You can look at the osmo_sccp Erlang code. Basically no implementation exists, so we also had to implement that part, at least to the point, to those features that are required. But once we have implemented all these protocols – RUA, SCCP, the RANAP, the HNBAP, then we need to somehow interface those protocols with the existing network elements that we have for GSM. And there are sort of several challenges in this area, in what people know as the OpenBSC project. Actually the program that most people use is called OsmoNITB – the network in the box – which is called ‘network in the box’ because it implements all the network elements that you need in one box, or in one program. Unfortunately we need to separate those individual pieces which are all in one blob, in order to interface at the point where we want to interface. So this separation of the MSC part and the BSC part needs to be done inside the ‘network in the box’. We need the UMTS authentication and key agreement support, and we need the different protocols that I just mentioned and link them in on the SGSN side. For the data services we need to introduce some extraction to basically differentiate the packet data connections coming from GPRS networks and those coming from the new 3G networks or base stations that we are supporting. But that’s all manageable. Now, the question is, do we really want to go for the full stack as it has been described, or can we take some shortcuts, do we really need to implement the full SCCP, for example? Do we need to implement M3UA, which is another protocol layer in there? Can we basically simplify that? The initial idea was – if we go back to that slide – to reduce the complexity, I already mentioned this HomeNodeB gateway which basically passes RANAP from left to right, and just changes the underlying encapsulation. Why don’t we just continue using RUA up into the SGSN and thereby avoid having to do SCCP and M3UA, avoid having to implement more protocols without having any functional gain. I mean it would just work the same way if we take RUA and we take it all the way into the SGSN. So there’s been some thinking along those lines but the idea was to… …go sort of in a compromise so what we’re using here is yet another protocol called SUA, the SCCP User Adaption. And that replaces those 2 layers and keeps things a little bit simpler from the implementation side. OK, now we have all these different protocol layers, and the integration into the core network elements. Now the fun starts. We have a plan, we know what needs to be done, we know what needs to be done, and now we actually need to do it. So the theory was easy – read a couple of specs, find out 6..7 messages, not too many transactions, no complex state machines. Okay, now, a lot of the more modern telecom protocols use ASN.1 syntax. It’s an abstract syntax notation for defining data structures or procedures to be communicated, and then you can use code generation tools to generate code in your favorite language from this syntax doing all the marshalling and demarshalling of the messages. That’s at least what’s the idea. This is very different from what we used to do in the GSM world because GSM was specified in the late 1980s. ASN.1 didn’t exist to my knowledge back then, or at least they didn’t know about it, and/or they thought it was not something that you could do in a mobile phone at that time. Think about 8 bit microcontrollers and whatnot, what they were using these days. So the GSM messages, basically you have…, you look at the spec and you see “Oh, there’s one byte this, then there’s a 2 byte length field, and then there’s that”. And you need to implement that basically in your code, based on the textual representation. Now, for UMTS almost all the protocols and particularly these that we’re looking [at] here are specified in abstract syntax notation which, well, on the one hand side you would say: “Oh yes, great, now we don’t need to write all this message encoding and decoding code, and then we end up interpreting the spec different[ly] and we have sort of incompatible messages and whatnot”. That’s true to some extent, okay. Now what you need to know about ASN.1 is, there are different encoding rules that define how the abstract syntax notation gets converted into a concrete binary representation. There is a Basic Encoding Rules (BER), there is all kinds of encoding rules, there is even JSON encoding rules these days. There’s also XML encoding rules. But what’s used here in these specs is called ‘aligned Packed Encoding Rules’ (APER). This is a particular encoding rule that was not… or is not supported by any of the ASN.1 compilers that exist in open source that generate C code. So we first had to teach the ASN.1 compiler this encoding rule. And the second big problem is the ASN.1 syntax used in those protocol specs uses a construct called ‘Information Object Classes’, which is sort of… well, you know, an interesting way how to express or how to have… a different notation on how to construct those messages and how to construct operations that have like an initiating request, a ‘successful’ response, a ‘successful error’ outcome or something like that. And you can express that in a really nice way but then you need a compiler and a code generator that can parse that, and that’s really difficult in the free software world within some constraints. I’ll get into the details. Now the next thing is that the way how they use ASN.1 in these protocol specs – ASN.1 being the abstract syntax notation – is not abstract enough. They need to have another abstraction layer. So they use ASN.1 to describe containers, containers for information elements, containers for messages, containers for lists of information elements and containers for pairs of information elements. It’s very important. You cannot just have a list of 2. No, you need to have a pair that says, well, this is a pair of 2 information elements. Not sure why, but somebody probably had his reasons for doing so. Now the point is, basically, you use the ASN.1 syntax and you generate some code for encoding or decoding and then you’re not really done at that point. Because then you basically: “Oh, this is a list of containers”, and then you look into each of the containers and then call the decoder again for each of the elements in the list. And then in there there might be another level of containers and you unpack it again, so it’s a little bit like matryoshka or, you know, these dolls nested in each other; or somebody sends you a large packet etc. Well, to illustrate that, if you’ve ever seen ASN.1, this is a relatively simple example describing authentication couples or triplets or quintuplets. Basically, the authentication data that’s used for authenticating subscribers in networks. This is what is used also in GSM. It’s relatively simple, so it basically tells you, well, there’s an authentication set list which contains [consists] of a choice of either a triplet or a quintuplet list. Each of those lists either have a length from 1..5, and then you have basically a sequence which is sort of struct or a record of the below items in those lists. That is how [it] is and should look like and how it normally looks like. Now in RANAP and these protocols they first – as said – they define these containers, they say: “We have…”. So it reminds me a bit of some mathematicians. It’s like “We define we have this, and then we have that, and therefore we can construct such a new structure” and whatnot. So basically, they define first a container for protocol information elements, protocol IEs. And in the protocol IE is the actual information element. Each element has an ID, it has a criticality. The criticality tells you whether, if you do not understand such an information element, should you ignore it, should you reject it, should you ignore it but report to the sender that you did not understand it despite proceeding with your operation, and then the actual value. And the value is an ANY type which means there is another ASN.1 syntax in that value that you then need to parse. So you need to do these 2 steps in the code. You first unwrap the containers and then you decode what is inside the containers. So working with ASN.1 really is not as simple and as straightforward and as automatic as it should be. And you end up with messages looking like this in Wireshark. So believe it or not, the content, the useful content of this entire message is 4 bytes here, the c0… laughter and applause …is the 4 bytes starting from c0, and those people who have seen an IP address, an IPv4 address in a 192.168. address range will recognize those bytes here at the end. So the c0 is 192. etc. And in order to communicate this message actually, this is a message that tells us to which IP address something has been bound to. In this case it’s the GTP connection for communicating packet data. And you see all these abstractions and encapsulations and the nested tree, so it’s… it starts with… well, ok, this is an outcome. It is an outcome to the Radio Access Bearer Assignment. “If you do not understand it please reject it”. We have an Assignment Response. It contains [consists] of a list of one item of protocol information elements. This one item is a SetupOrModifiedList, which again has a criticality of ‘Ignore’. If you don’t understand it… oh no sorry, here it says “If you don’t understand it just ignore it. Don’t report an error”. It’s quite interesting because you have a message that only contains one element and it says, well, you should reject the message if you don’t understand it; but then the information element says: “Oh, if you don’t understand it please ignore it”. So, okay. Then inside the SetupOrModifiedList we have one item which is a protocol IE container with one item which has an item which is the SetupOrModifiedItem, which is a Radio Access Bearer Modified Item, which contains a Radio Access Bearer SetupOrModifiedItem with a Radio Access Bearer ID of 1 and a transport layer address of this. And in case you’re wondering why the IP address has such binary crap in front – it is because it’s too difficult to express in ASN.1 that this is an IP address. You could not just define a type for an IP address. That would be too simple. No, you need to refer from this specification to another specification, another 3G specification, which then refers to ITU-T X213 which tells you how you can encode any possible transport layer address in any possible network protocol on the planet by using a hierarchical structure like OUI IDs or something like that. And ‘35’ means it’s an IETF allocated address. ‘0001’ means it’s an IPv4 address and then you actually have the payload. And you can see Wireshark is too stupid to decode such brilliance! laughter and applause Yeah, so. Then it’s hard to find example traces. You want to implement the protocol and you want to find some example traces. This is a mail I … actually I was looking for this this year, in 2015. I was googling for Iuh protocol traces. And what did I find? My own e-mail from 2009 where I was asking for protocol traces. But nobody ever responded. So the situation is better today. You can actually find, I think, 2 or 3 public pcap files containing each maybe a handful of messages on those interfaces. It’s really… it’s odd, you know? These are protocols that are specified publicly. They’re used in production. Billions of users are using these networks but nobody even has an example protocol trace of those protocols. Okay, now we have a couple of protocol traces. We understand the nesting level is deep. We are happy that Wireshark decodes at least most of it, which by the way we have to thank one particular Ericsson employee who is contributing those dissectors to Wireshark. So then we need to basically set up a tool chain to generate code from these ASN.1 syntaxes. So there is an ASN.1 C compiler from Lev Walkins. It’s good for a lot of things and I’m very happy it exists. But it lacks many if not most of the features that you need in the Telecom world. That’s sort of unfortunate. There’s no information object classes, there is no aligned PER support, there’s no support for prefixing the type names. Because we have 3 different protocols, we want to use them from one program. We need to prefix the type names because of course each of those 3 protocols has a type called ‘protocol information element container’. But of course it’s not the same protocol information element container, there it said(?). You know, each of the protocols has its own containers. So we had to add these pieces to the asn1c, at least in a minimal way in order to use it. And unfortunately I don’t know anyone, and I’m certainly no one who understands something about compiler theory, so it’s a little bit challenging. Now, alternatives to asn1c, well, the most complete tool kit you can find for working with ASN.1 exists in the Erlang OTP system. I used this in the past for a lot of Osmocom projects, but the fact is the C projects… there are other developers and people that contribute. In the Erlang projects there is nobody that contributes except from me. So I thought, well okay, it’s very nice to work with ASN.1 in Erlang, but then if nobody contributes I’d rather go the difficult C way and then have contributors in the project. Also of course in the Osmocom project we’re mostly low-level C guys; and people are very wary of virtual machines and the – at least perceived – bloat they introduce. The third alternative is to use a proprietary ASN.1 compiler, and in my day job I actually use such tools. But in the first sight you think, well, okay, so it’s a code compiler, it compiles code, and copyright law says, well, code that was generated by a machine is not copyrightable because the act of automatically compiling code from one form into another form does not make this… that does not create a copyrightable work as itself. So basically, you can take a proprietary ASN.1 compiler, compile C code and then use the resulting C code in an open source project without having any problems with the license of the ASN.1 compiler. And that’s true, however all those compilers I know, and I think I know all of them, they have a runtime library and that you only either get as a binary library or you get it in source code that’s not available under a free software compatible license. No option to do that. So we have to stick with asn1c, which as I said I don’t want to complain about, it’s a great project. It just doesn’t do all the things that we need. But then, it was not written for us, so of course it doesn’t do everything we need. Luckily, a research group at Eurecom, the European Communications Research organization, has developed a patch for adding aligned PER support to asn1c. Unfortunately it was against an old version because, well, they probably don’t want to submit this main line (?) and they don’t care about porting it and rebasing (?) it. I did that. It probably still needs some clean-up before it can be submitted, but my goal is to have this included in asn1c. And also we found quite a number of bugs still in the code, so it’s in the process of being improved. Now information object classes are hard, at least for me. Basically we skip that. I manually edit the ASN.1 syntax for not using information object classes anymore, so I’m rewriting the ASN.1, that’s supposed to be there to guarantee that the encoding is a… so it circumvents sort of the purpose. The idea is you take the ASN.1 from the spec, you use it, you don’t modify it. But I’m modifying it because, well, the tools we have are not good for what we want to do. Type prefixing is done. Now we have the information element containers. Eurecom has another idea about this. They have a long Perl script. I recommend you not to look at it, it consists of a neverending sequence of regular expressions, basically grep-ing out certain parts of the ASN.1 syntax without really formally parsing it, or lexing it, or tokenizing it; and then based on those regular expressions generating C code that then you can use with asn1c and link against it. And surprisingly it works, surprisingly good actually. We had to teach it all the things that we needed in addition to that. But really it works surprisingly. Now. Putting things together: Copy and paste the ASN.1 syntax from the 3GPP DOC files. Because 3GPP specs are published as PDF files and as Word documents, and you don’t get the actual syntax as a text file. You have to copy and paste from each page, make sure you don’t get intermixed like headlines or something like that. Then you use the hacked-up, patched asn1c to generate C code. You have to modify it to make a shared library of the runtime for the ASN.1 compiler because we have, again, 3 syntaxes that we want to mix, and that doesn’t really work with how asn1c works. We use asn1tostruct to remove this what I call the obfuscation layer, these containers. We write some code to dispatch the messages, and then finally, we see some messages. So we have those HNB register, INITIAL_UE_MESSAGE and all these things. This is what you can now get from osmo-iuh.git, the Git repository on the Osmocom server which contains all this code. It takes a long time to compile, because asn1c generates one C file and one header file for each type. And they have lots of types in those specs. So you end up with like 300..400 C files and header files compiled into a 5 megabyte binary, and then finally you want to get 4 bytes in a message. So well, where do we go from here? We have a couple of other things to do. One interesting question is – and I’m going to do a demo in a few minutes – is what kind of hardware can be used? Well, the hardware that I currently use for this development is undisclosed manufacturer, very expensive. It’s not actually a femtocell, it’s a real cell, it costs several thousand Euros, not really suitable for hackers. However many consumer grade femtocells have also this Iuh protocol with the same stacking. The problem is they’re locked down, in a way that they have certificates and connect over IPsec to the operator network etc. So if somebody can break this IPsec layer and insert its own a certificate, or disable the IPsec altogether then you can talk Iuh to the osmo-iuh and then you can use that hardware. This is something that a couple of people have looked at, and hopefully in the near future we will have 1 or 2 femtocells that people can use inexpensively in order to use the software. At the moment, I said, unfortunately it’s not possible. As a summary, before I go into the demo of demonstrating it and you having basically a look in the marvelous depth of the Wireshark decodes, Iuh is conceptually very easy to understand. The lack of good ASN.1 tools is the biggest problem in the free software world. You need to overcome these containers, and in the end you spend 90% of your time in improving the tooling, fixing the tooling and working around these layers of abstraction rather than doing the actual functionality. We have started the work on the core network components, the integration. I was hoping that I could do a full demo with a call, or a full demo with actually having a data connection over this setup that I have here, over the test setup. I’m almost there. The signalling, everything gets established, the authentication works but then somehow the data, the actual IP data doesn’t want to come through. And that is under investigation, but I’m sure it will be available rather soon. Now before we go for Q&A let me just do a quick demo and let me show you how this looks at the moment. This is still a protocol trace basically that was running in the past. I’m just going to leave this here at the left-hand side, I’m going to leave the… on the right-hand side. So what we can see is basically on the left-hand side we have the RUA encapsulated messages. This is basically the Iuh interface between the HomeNodeB and the HomeNodeB gateway. Then we have the osmo-iuh HomeNodeB gateway invisible in between here, and that’s the program running in the background. And then the other side is this protocol stacking here, where we see we have the SUA, this SCCP User Adaption rather than the RUA on the left-hand side. The RANAP messages are the same on left and right, it’s basically just converting. What I’m going to start in the background is basically – this is the wrong window, I thought I had prepared everything just… Yeah. Exactly. Good, that’s the one part, that’s the other part… So I’m going to start the… I know the font is too small, you don’t need to read that. I’m just going to tell you the… I can make it larger, then we won’t see really a lot. What’s this? Why is it not…? “Cannot listen on… socket…”. Now that’s the demo effect! Why on earth is it not binding? What a pity! Okay, that’s embarrassing. Then you get a larger font size! And then let’s have a quick look. I’ll try it very quickly. So I’m trying this, it cannot bind to the sockets. Probably my IP address has disappeared on the laptop while I’ve been talking here and now it wants to bind to an address that doesn’t exist anymore. And that seems [to be] exactly what has happened. Now don’t shout your SUDO! (?) laughter It will not like you. I can tell you. Yeah. Now this should do the trick. I’m starting this in Valgrind because I’m still debugging, yeah… Now it’s actually running, okay. Now we do the same on the other side, we go for a huge font size, and I’m starting the HNB gateway. We see a yellow line, that a connection has been established. So now we are waiting for the initial message from the HomeNodeB to arrive. We should see it here at the bottom of this trace. We should see a couple of Reset requests. Basically the HomeNodeB this… the NodeB here is trying to reconnect all the time to its HomeNodeB gateway. Of course there’s some backup… some back off included and given that it was not connected for the first 40 minutes or so it will take some time to reconnect to the SGSN and then I can have the phone that I have here regist… audio recording blanks out one minute of audio missing Herald: …is there somebody somewhere at a mike? Mike 2, please! Question: So if 3G is so annoying why not skip it and go directly to LTE? LaForge: Well, there’s a couple of reasons for that. First of all some people really need it in terms of there’s an actual demand for 3G small networks or 3G cells in applications where it’s used. The second reason is it’s a relatively limited incremental step because the Layer 3 protocols of GSM and UMTS are the same. And that’s why basically we can use… reuse the call control and the mobility management, all those parts from GSM, reuse them with 3G. I’m not saying we shouldn’t do the same with LTE as well but there are actually quite a number of projects already involved in that area. And LTE, well, to be frank, it’s so much IP it’s not really telecom anymore. You know I’m always interested in the more obscure things that people are not really looking so much at. IP, I found IP boring when I stopped working on Netfilter in 2004 or so. IP, well everyone knows about IP, that’s… you know, we need something more interesting. Herald: Microphone 1 please! Question: So you say that you have a lot of trouble parsing ASN.1. But if it’s always the same containers can’t you simply have a static dump of the binary crap before and after that stuff, and ignore the whole parsing part? LaForge: You probably could. But then, how can I say, my code athletics demand better behavior from code I write than just doing something like that. So yes, you could, probably, but I’d rather have a more clean way of doing that. Herald: And continue on microphone 1! Question: You said that UMTS or 3G is a toolbox for creating arbitrary telephony systems while my knowledge tells me that GSM is a much more rigid standard, but, if you could please elaborate on that concept of “arbitrary networks”! LaForge: Well, I could illustrate that very much with a certain protocol trace. UMTS basically… when UMTS was specified they didn’t know where the journey was going to. Basically, it was not clear that the internet would be the thing that we know as of today. They didn’t know that smartphones would exist. They didn’t know that IP data services are the type of data services that people are interested in. Rather they were thinking of… in generic terms. So it could have been that we needed all X.25 over UMTS. It could be that, you know, people wanted to do ATM over UMTS. It was not clear that circuit-switched services would basically go downhill like they did meanwhile with voice-over-IP telephony etc. It was not clear that modem calls or actual video calls that exist in UMTS would not be the future. So it was very unclear. And they tried to define something that’s as flexible as possible to do anything that you could imagine. And if you look at the way how the layers are structured and the fact that you have transport channels, and transport channel bundles, and radio access bearers etc., basically the structure. Even only to transmit voice again you have to set up with AMR for all the codecs you need to configure in the physical layer, I think, for the 3 different bit classes 10 different combinations. So you end up with something like 30 parameters or 30 sets of parameters that you need to communicate to the lower layers only to configure it for establishing a voice channel. And then the transport channels, that where the bits are included, the payload like how many bits fit in into one frame doesn’t match with your codec bitrate because they didn’t know what codecs they would use. So it’s really… it’s all arbitrary and with padding and universal. So it’s not like GSM. GSM is very simple and straightforward. Herald: Okay, we have 5 minutes left so we will have 2 quick questions from the internet because everybody on the stream: you can actually ask questions on the chat. Please! Signal Angel: Okay, thanks. We have 2 questions as you said. The first one is: if there would be interest in implementing, you know, the whole stack in a safe and non-VM based language if the tooling was good enough? LaForge breathes out heavily laughter LaForge: Well, I mean I’ve… It depends on… I don’t want to find Language Wars here. I would have been tempted to do things in Erlang but then, I said, the question is who else would have been tempted? I don’t think… I mean the point is what we’re trying to do now is to basically use most of what we already have with the least additional effort and I don’t think anyone will want to start from scratch all over again. But if they do so I would be happy to see a clean implementation, but I’m not so sure that will happen. Signal Angel: Okay, thanks. The second question is: why don’t we just start over for a clean slate with hardware and software and do a basically 100% nerd and hacker driven mobile networks? LaForge: Sorry, 100%…? Signal Angel: …nerd/hacker driven networks. LaForge: Ah, well, I mean the point of implementing all those specs is you want to use the existing devices out there. You want to use the existing billions of mobile phones that exist on the planet. And if you want to talk to them then you need to implement those protocols and those systems that they implement. If you want to start from something else and do things from scratch, well, yes, you can do that. But then keep in mind that you will have very bulky end user equipment with large like clusters of FPGAs and DSPs, draining batteries, having fans inside. Because you will not be able to implement your system in the same level of energy efficiency, in the same level of, you know, ASICs and optimized silicon processes etc. like is the case for the billions of existing devices. Herald: Okay, thank you, Harald Welte! LaForge: Yeah, thank you! applause postroll music Subtitles created by c3subtitles.de in the year 2017. Join, and help us!