*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!*