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!