0:00:00.000,0:00:10.270
32C3 preroll music
0:00:10.270,0:00:13.269
Herald: For several years now, here[br]at the Congress and at the Camp,
0:00:13.269,0:00:18.890
we see that we have a GSM network,[br]that we operate our own network,
0:00:18.890,0:00:23.080
that we have some services[br]like recently GPRS or
0:00:23.080,0:00:28.510
roaming between the different[br]parts of the areas in the Camp.
0:00:28.510,0:00:34.490
All of this started around 7 years[br]from now, with a talk at the 25C3;
0:00:34.490,0:00:39.810
and a bunch of projects emerged[br]from that over the years.
0:00:39.810,0:00:45.219
But wait, there is more. Right now,[br]the people running these services
0:00:45.219,0:00:50.050
and running these projects are[br]starting to play around with 3G.
0:00:50.050,0:00:55.399
And for everybody who doesn’t know what[br]3G is, like I did, for like 5 minutes ago,
0:00:55.399,0:01:03.740
3G means that we will have HDSPA and[br]data services on our GSM networks.
0:01:03.740,0:01:08.770
And I’m very honoured to introduce[br]to you this evening Harald Welte,
0:01:08.770,0:01:14.070
a member of our Chaos family for[br]several years now, known maybe from
0:01:14.070,0:01:20.770
the Kernel development. I first read his[br]name while debugging a chip card driver
0:01:20.770,0:01:25.270
that stated ‘All bugs introduced[br]by…’ – this guy over there.
0:01:25.270,0:01:29.170
So, other people may know[br]him from gpl-violations.org,
0:01:29.170,0:01:33.960
where they try to enforce[br]the GPL. So. Please welcome
0:01:33.960,0:01:36.460
Harald Welte, and… the stage is yours!
0:01:36.460,0:01:44.830
applause
0:01:44.830,0:01:48.680
LaForge: Hi. Welcome everyone[br]to this talk about, well,
0:01:48.680,0:01:52.410
running your own GSM network, or[br]running your own 3G network, rather,
0:01:52.410,0:01:56.810
sorry for that. And in more[br]technical terms, the slide titles
0:01:56.810,0:02:00.969
with lots of acronyms as it is[br]customary in the telecom world.
0:02:00.969,0:02:05.640
So forgive me if there’s too many[br]acronyms, but I didn’t invent them,
0:02:05.640,0:02:11.910
I just try to use them whenever[br]appropriate. Okay. So, let’s start
0:02:11.910,0:02:17.720
with a little bit of a history of open[br]source in mobile communication protocols.
0:02:17.720,0:02:20.290
You have to remember[br]that we started about
0:02:20.290,0:02:25.470
16 years after the proprietary[br]implementations, so the GSM network
0:02:25.470,0:02:29.140
that we are running[br]here at the event, or that
0:02:29.140,0:02:34.610
we started to run 7 years ago, started[br]16 years after GSM networks were run first
0:02:34.610,0:02:39.710
in the public in Europe, so, at public[br]operators. So we’re really, really late,
0:02:39.710,0:02:44.780
and if you want to compare the status[br]of open source mobile communications
0:02:44.780,0:02:49.239
with open source operating system, then[br]I would say we are about where Linux was
0:02:49.239,0:02:54.069
in ’94 or ’95. So, very far from today,[br]for those of you who are old enough
0:02:54.069,0:02:58.730
to remember these days. So, I would[br]say “capable but not taken seriously”
0:02:58.730,0:03:02.720
is sort of the general status.[br]The developer community
0:03:02.720,0:03:07.629
working on these projects is still very[br]small. There’s a limited adoption
0:03:07.629,0:03:13.470
in the market and the users,[br]often in niche applications,
0:03:13.470,0:03:18.450
but nevertheless it is functional. So,[br]if we look a little bit at the timeline,
0:03:18.450,0:03:22.629
2008 we had the talk about[br]“Running your own GSM network”
0:03:22.629,0:03:28.200
with a huge Siemens base[br]station weighing I think 28 kg…
0:03:28.200,0:03:30.540
Did my microphone…? No, it works, sorry.
0:03:30.540,0:03:35.239
…weighing 28 kg and bulky old equipment
0:03:35.239,0:03:38.629
not using TCP/IP but using E1 lines etc.
0:03:38.629,0:03:42.760
Over the years we added more and more[br]BTS model vendors. Basically it means
0:03:42.760,0:03:46.961
we can use Ericsson and Nokia[br]and other equipment to actually
0:03:46.961,0:03:52.689
run these GSM networks today. People[br]have been working on GPRS support
0:03:52.689,0:03:58.260
in a couple of sub projects[br]called OsmoSGSN, OpenGGSN,
0:03:58.260,0:04:03.550
also the OsmoPCU project, so we’ve[br]been growing the stack downwards,
0:04:03.550,0:04:08.040
also basically implementing[br]the software inside such a BTS,
0:04:08.040,0:04:12.019
which we call OsmoBTS. There[br]are some production deployments
0:04:12.019,0:04:16.470
– all spellings my mistake,[br]by the way, as obviously – so,
0:04:16.470,0:04:19.858
production deployments in niche[br]applications such as maritime markets.
0:04:19.858,0:04:24.900
So, if today you are on a ferry or on a[br]cruise ship and you use GSM services, the
0:04:24.900,0:04:30.350
probability that you’re using OpenBSC and[br]associated projects in the background is
0:04:30.350,0:04:36.800
very strong. There are hundreds of vessels[br]using our software today. Now, then we…
0:04:36.800,0:04:43.270
applause
0:04:43.270,0:04:46.600
…then we moved on the telephone[br]side, so we thought, well, you know,
0:04:46.600,0:04:50.750
network side GSM in one thing, but let’s[br]do the phone as well, that was OsmocomBB,
0:04:50.750,0:04:54.740
started in 2010. We did improvements[br]over the years, more and more
0:04:54.740,0:05:00.199
completed the stack, but it’s really[br]all only old GSM/GPRS technology
0:05:00.199,0:05:04.669
until very recently.[br]So in 2015, 15 years again
0:05:04.669,0:05:09.590
after the first commercial deployment[br]of GPRS in a public network,
0:05:09.590,0:05:13.730
we start to have an open source[br]implementation of EDGE, and that has just
0:05:13.730,0:05:18.310
started like 2 or 3 months ago. So[br]again, 15..16 years late compared to
0:05:18.310,0:05:23.020
what happens in the[br]proprietary world. Ok. But…
0:05:23.020,0:05:28.270
this talk is not about EDGE, which[br]is 2.75G, if you want to speak
0:05:28.270,0:05:35.330
in generation numbers. Today[br]we’re talking about 3G and 3.5G.
0:05:35.330,0:05:39.690
And there’s a bit of ambivalence[br]with that subject because, well,
0:05:39.690,0:05:43.169
today, if you talk to people in the[br]industry, they will say: “Ah, who cares
0:05:43.169,0:05:47.449
about 3G, you know, it’s dead anyway!”.[br]We have already today at the point
0:05:47.449,0:05:51.139
where we have ‘Peak 3G’,[br]so in the next few years,
0:05:51.139,0:05:54.600
the number of subscribers and the[br]number of networks offering 3G services
0:05:54.600,0:05:58.770
is no longer growing, it’s[br]basically stagnating and
0:05:58.770,0:06:03.160
will turn downwards in the near[br]future. So LTE/4G networks
0:06:03.160,0:06:08.979
is basically what everyone is hot about.[br]The other reason not to look at 3G
0:06:08.979,0:06:12.979
is that it’s mind-bogglingly complex.[br]It’s not a single telephony system,
0:06:12.979,0:06:17.490
it’s actually a toolbox to build[br]arbitrary telephony systems.
0:06:17.490,0:06:21.349
And if you really wanted to start[br]implementing it from scratch
0:06:21.349,0:06:27.449
including all the lower layers, including[br]the PHY, including the Layer 2 etc.
0:06:27.449,0:06:32.669
I think it would be a waste of a lot of[br]time, actually. So we do what we did
0:06:32.669,0:06:37.319
with the GSM networks back then, we[br]used proprietary base station hardware,
0:06:37.319,0:06:40.539
and we implement the higher level[br]protocols, and then, if needed and
0:06:40.539,0:06:44.470
if there’s interest and contributions[br]etc. we drive open source further
0:06:44.470,0:06:50.199
down the stack and also[br]into the actual cells.
0:06:50.199,0:06:55.319
So, one term that’s going to be used here
0:06:55.319,0:06:58.910
in this context is ‘femtocells’. Quite some[br]number of people may have heard
0:06:58.910,0:07:02.800
about femtocells before. In technical[br]terms it’s a base station – which is
0:07:02.800,0:07:08.830
called NodeB in the UMTS language[br]world – and a radio network controller,
0:07:08.830,0:07:13.280
which is the BSC, the base station[br]controller – in UMTS in one box.
0:07:13.280,0:07:17.840
And using such femtocells or similar[br]hardware is much easier to interface
0:07:17.840,0:07:21.699
than if you would use a regular[br]base station. So that basically is
0:07:21.699,0:07:26.780
sort of a path that we think is doable[br]without spending man-years of implementing
0:07:26.780,0:07:32.859
obscure and complex transport channels[br]and bundles and mappings and whatnot.
0:07:32.859,0:07:37.069
There’s been a couple of talks about[br]doing creative stuff with femtocells.
0:07:37.069,0:07:43.890
There’ve been talks by Kevin [Redon], Nico[br][Golde] and Ravishankar in 2010/2011
0:07:43.890,0:07:49.530
about security. There’s been a recent[br]presentation this year at Black Hat
0:07:49.530,0:07:53.659
in the United States called[br]‘Adventures in Femtoland’.
0:07:53.659,0:07:58.810
Those talks focus on basically, well,[br]the security of the femtocell itself,
0:07:58.810,0:08:03.330
breaking into such a cell, rooting it,[br]owning it, doing creative things
0:08:03.330,0:08:07.389
and then from there e.g.[br]attacking the mobile operator or
0:08:07.389,0:08:12.190
attacking the privacy of subscribers[br]by using such a femtocell
0:08:12.190,0:08:17.180
as a man-in-the-middle platform e.g. But[br]to my knowledge nobody has been talking
0:08:17.180,0:08:21.610
about free software or open source[br]software, to run a network with
0:08:21.610,0:08:27.870
such femtocells or similar equipment.[br]So, if we look at the UMTS architecture,
0:08:27.870,0:08:32.580
like you find it in a textbook or like[br]in this particular slide or drawing
0:08:32.580,0:08:38.070
from Kevin, you will find[br]several network elements
0:08:38.070,0:08:42.659
all over the network,[br]so lots of different elements
0:08:42.659,0:08:48.460
with lots of different acronyms.[br]We have a Mobile Equipment (ME)
0:08:48.460,0:08:52.470
which is the telephone. We have a radio[br]interface called the Uu interface.
0:08:52.470,0:08:56.650
We have actual base stations[br]called NodeB and we have
0:08:56.650,0:09:01.110
a base station controller that’s called[br]the Radio Network Controller, the RNC;
0:09:01.110,0:09:06.690
and then here we have, on this boundary[br]we have IuCS and IuPS interfaces
0:09:06.690,0:09:10.650
that interface the Base[br]Station Controllers
0:09:10.650,0:09:14.470
with the core of the network which[br]is the Mobile Switching Center,
0:09:14.470,0:09:18.420
the Media Gateway, the Serving GPRS[br]Support Node, and then other elements
0:09:18.420,0:09:23.880
here. And this is actually the interface[br]line which we have been implementing
0:09:23.880,0:09:29.360
in recent months at the boundary[br]between the Access Network,
0:09:29.360,0:09:34.290
the Radio Access Network and the Core[br]Network on the other side of the slide.
0:09:34.290,0:09:39.970
So, well, you could just get a NodeB[br]and implement the protocol Iub.
0:09:39.970,0:09:43.790
This is what we did with GSM before,[br]we basically started here. We only got
0:09:43.790,0:09:48.880
the actual BTS or NodeB and[br]we implemented that protocol.
0:09:48.880,0:09:52.910
However, well, this protocol[br]in UMTS is extremely complex
0:09:52.910,0:09:56.960
and fairly low down the stack.[br]Just to give you an idea:
0:09:56.960,0:10:01.710
every single voice codec frame[br]from a voice call that you receive
0:10:01.710,0:10:05.460
has 3 different classes of bits, and[br]each class of bits gets put into
0:10:05.460,0:10:09.800
different UDP messages, and then you[br]get basically 3 flows of UDP messages,
0:10:09.800,0:10:13.750
and you need to synchronize and[br]inter-mangle (?) and re-interleave
0:10:13.750,0:10:18.300
those bits in order to get to a speech[br]codec frame. So it’s… and I’m not even
0:10:18.300,0:10:21.170
talking about the signalling plane (?).[br]So the lower you get in UMTS the more
0:10:21.170,0:10:24.740
complex it gets, let’s try to avoid that.[br]And that’s the kind of complexity
0:10:24.740,0:10:30.940
that I like to avoid. This is from the[br]official spec about the UMTS spectrum.
0:10:30.940,0:10:36.020
It’s an extremely obvious and[br]self-explanatory slide, so I’ll…
0:10:36.020,0:10:38.590
laughter[br]I leave it at this and say, yeah,
0:10:38.590,0:10:44.070
that’s not what we want to do.[br]So, we… how can I say, we…
0:10:44.070,0:10:50.310
Even though we don’t like it we just use[br]proprietary blobs to implement that. Now,
0:10:50.310,0:10:53.780
the protocol stacking on those interfaces[br]that we actually want to implement
0:10:53.780,0:10:58.260
is what I’m going to look at the next[br]couple of slides. The Iu interface,
0:10:58.260,0:11:01.910
and by the name, Iu has no specific[br]meaning, it’s just the Iu interface,
0:11:01.910,0:11:06.180
you could say the A, the B, the C,[br]the Z interface – it’s the ‘Iu interface’.
0:11:06.180,0:11:10.960
It’s split in CS and PS, that’s circuit-[br]switched and packet-switched.
0:11:10.960,0:11:16.040
Circuit-switched means telephony services[br]and packet-switched means data services.
0:11:16.040,0:11:20.370
And we’re going to look at the[br]protocol stacking of those interfaces
0:11:20.370,0:11:25.430
in the next couple of slides. Originally,[br]remember, well, maybe a good time
0:11:25.430,0:11:29.640
to go back in history, in sort of history[br]of mobile communications, which
0:11:29.640,0:11:35.570
should be taught at every school, I think,[br]including archeology of protocols,
0:11:35.570,0:11:41.890
which… no, honestly…[br]laughter and applause
0:11:41.890,0:11:46.150
You need to do protocol archeology if you[br]want to implement certain interfaces
0:11:46.150,0:11:50.390
today. So, on my blog you can find[br]some posts about a couple of years ago
0:11:50.390,0:11:55.980
where I had to basically write a parser[br]for Microsoft Word for DOS text files
0:11:55.980,0:12:00.060
to automatically extract snippets of[br]ASN.1 syntax for MAP version 1
0:12:00.060,0:12:05.630
which is still used today. So, it’s… yes,[br]it… sometimes you really need to do
0:12:05.630,0:12:09.790
archeology. So anyway, not for this,[br]but any… when UMTS was specified,
0:12:09.790,0:12:14.560
this is the late 90s, this is when the[br]first dotcom bubble basically got big,
0:12:14.560,0:12:18.710
this is when billions and[br]billions of Euros or Dollars
0:12:18.710,0:12:22.040
or whatever unit of currency was[br]poured into the development of the
0:12:22.040,0:12:26.490
‘universal telephony mobile[br]system’, the… sorry, the
0:12:26.490,0:12:30.930
‘universal mobile telephony system’,[br]the UMTS, which should basically
0:12:30.930,0:12:35.500
be the grand unifying theory[br]of mobile communications.
0:12:35.500,0:12:42.260
And it was built on top of ATM, of course,[br]because ATM was the most shiny and
0:12:42.260,0:12:47.080
brightest technology in the late 90s that[br]all the universities were researching.
0:12:47.080,0:12:50.740
So, if you look at the classical protocol[br]stacking and you look at the individual
0:12:50.740,0:12:56.740
interfaces; the Uu is the radio interface,[br]Iub is between the NodeB and RNC,
0:12:56.740,0:12:59.910
but this is… the IuPS is actually what[br]we want to implement. So basically
0:12:59.910,0:13:03.570
the left side of this slide is[br]what is implemented
0:13:03.570,0:13:08.060
in the proprietary base stations[br]or femtocells that we are using,
0:13:08.060,0:13:12.040
and the right-hand side of that[br]slide is what we are implementing.
0:13:12.040,0:13:15.740
So we need to implement the protocol[br]stackings here. As you can see
0:13:15.740,0:13:20.940
the protocol stack is deep[br]and has many acronyms.
0:13:20.940,0:13:24.930
So, to make things more complicated
0:13:24.930,0:13:28.450
the femtocells that you can find[br]on the market are slightly different
0:13:28.450,0:13:32.580
from the real, normal 3G architecture,
0:13:32.580,0:13:36.240
so if you try to compare[br]this slide with that slide,
0:13:36.240,0:13:40.490
you will find some differences here.[br]The difference is that they introduce
0:13:40.490,0:13:45.650
a security gateway which is basically[br]just ITU and 3GPP language
0:13:45.650,0:13:50.190
for ‘IPsec gateway’,
0:13:50.190,0:13:54.770
and you have a HomeNodeB gateway[br]that doesn’t really do anything useful,
0:13:54.770,0:13:57.961
rather than putting messages from[br]one protocol stack on the left
0:13:57.961,0:14:00.910
to another protocol stack on the right[br]with the underlying protocols
0:14:00.910,0:14:05.530
doing exactly the same thing[br]but being differently encoded.
0:14:05.530,0:14:09.141
And this is what you can see here,[br]basically, the HomeNodeB gateway
0:14:09.141,0:14:13.300
which is part of the software that we[br]implemented. You can see basically,
0:14:13.300,0:14:17.600
well, you have RANAP,[br]this is the protocol
0:14:17.600,0:14:20.660
that really is sort of what[br]we’re interested in,
0:14:20.660,0:14:24.920
the Radio Access Network[br]Application Part; and RANAP,
0:14:24.920,0:14:29.250
in order to implement that, there’s[br]several other protocols underneath.
0:14:29.250,0:14:33.440
And on the femtocell which is called[br]HNodeB, the HomeNodeB, because,
0:14:33.440,0:14:37.690
well, ‘femtocells’ is a marketing term[br]and specs can never use marketing terms,
0:14:37.690,0:14:42.850
so they have technical[br]terms. So, the femtocell
0:14:42.850,0:14:51.270
basically encapsulates RANAP[br]into RUA, the ‘RANAP User…’,
0:14:51.270,0:14:56.120
what was it? Sorry, …Adaptation,[br]yes. The ‘RANAP User Adaptation’.
0:14:56.120,0:15:00.510
So the ‘Radio Access Network[br]Application Part User Adaptation’,
0:15:00.510,0:15:04.630
on top of the SCTP, the Streaming[br]Control Transfer Protocol,
0:15:04.630,0:15:09.180
which some may know is a protocol[br]that’s on the same layer as TCP or UDP
0:15:09.180,0:15:13.110
but has different properties. And
0:15:13.110,0:15:17.180
this RUA is implemented than (?) the[br]HomeNodeB Gateway where it is replaced
0:15:17.180,0:15:21.950
by M3UA and SCCP. And basically[br]the same RANAP message
0:15:21.950,0:15:26.430
gets passed from left to right. So[br]it’s really… you could think like…
0:15:26.430,0:15:30.730
think of it like an IPv6 to IPv4 proxy.
0:15:30.730,0:15:35.670
If that’s more an area that you’re[br]more familiar with. Okay.
0:15:35.670,0:15:41.260
So, I said there are some differences[br]between an actual, regular,
0:15:41.260,0:15:44.970
old-fashioned UMTS base station,[br]like your public operator would use it
0:15:44.970,0:15:49.090
and the HomeNodeB, or femtocell,[br]that we like to use in this project,
0:15:49.090,0:15:53.850
at least initially. And I said the[br]main difference is that the RNC,
0:15:53.850,0:15:57.510
the Radio Network Controller, is built-in,[br]so a lot of the lower layer protocols
0:15:57.510,0:16:00.290
are terminated, and we don’t need[br]to worry about that. If we look
0:16:00.290,0:16:04.880
at the protocol stacking again there[br]is a lot of protocol layers here,
0:16:04.880,0:16:09.910
you can see the MAC layer, the RLC layer,[br]the RRC layer… and all the PHYsical stuff
0:16:09.910,0:16:14.190
underneath is all basically already[br]implemented because it’s part of the
0:16:14.190,0:16:19.100
femtocell, in this case. So the protocol[br]stacking now looks a little bit like this.
0:16:19.100,0:16:24.030
We have the HomeNodeB,[br]and the HomeNodeB gateway,
0:16:24.030,0:16:28.000
and then our core network elements[br]already. So the SGSN and the GGSN,
0:16:28.000,0:16:33.190
if you’ve looked at GSM in the past, or[br]GPRS, even the software that exists today
0:16:33.190,0:16:37.910
and for many years in the Osmocom[br]project, we have implementations of those.
0:16:37.910,0:16:39.950
What we are missing is[br]the HomeNodeB gateway,
0:16:39.950,0:16:43.540
and is all the fancy new protocols[br]here. And some modifications.
0:16:43.540,0:16:50.750
So, well, what do we need to[br]do to actually implement?
0:16:50.750,0:16:54.920
This Iuh protocol. As I said there’s the[br]different protocol layers – there is RUA,
0:16:54.920,0:17:00.000
there is the RANAP protocol,[br]and the HNBAP protocol.
0:17:00.000,0:17:04.199
Let’s look at those protocols, what they[br]do, and how can we implement them.
0:17:04.199,0:17:08.030
I’m skipping a few slides in the[br]middle because it’s illustrative
0:17:08.030,0:17:11.650
if somebody wants to check the slides[br]later but it would go into too much detail
0:17:11.650,0:17:17.510
at this point. So the RANAP[br]User Adaptation layer
0:17:17.510,0:17:20.980
– given the spec number above there,[br]so if you look for that online
0:17:20.980,0:17:25.740
you can find the actual spec – is a very[br]simple connection-oriented layer
0:17:25.740,0:17:30.230
that provides you the[br]notion of a connection
0:17:30.230,0:17:34.070
over a datagram transport[br]layer underneath.
0:17:34.070,0:17:38.650
It has very, very few operations[br]and message types,
0:17:38.650,0:17:43.710
including CONNECT which – well,[br]surprisingly – sets up a new connection.
0:17:43.710,0:17:47.810
DIRECT TRANSFER which transfers[br]data inside a connection.
0:17:47.810,0:17:51.140
DISCONNECT – to terminate a connection.[br]And CONNECTIONLESS TRANSFER
0:17:51.140,0:17:54.860
to transfer data outside of a connection.[br]And, of course, an ERROR INDICATION,
0:17:54.860,0:17:59.940
in case something goes wrong. So we can[br]have multiple connections in parallel
0:17:59.940,0:18:06.310
over a signalling link. And they are[br]distinguished by a 24 bit context ID,
0:18:06.310,0:18:09.990
to differentiate those multiple[br]parallel connections. Think of it like
0:18:09.990,0:18:13.890
a port number. In the case of UDP,[br]or whatever else you might want
0:18:13.890,0:18:18.300
to compare it to. So, this… if you look[br]at this and you read the specs like
0:18:18.300,0:18:22.810
“Oh, pfff, you know, it’s nothing, it’s[br]like you implement like 5..6 message types
0:18:22.810,0:18:27.010
and that’s it”… well, there’s[br]a bit more details to that,
0:18:27.010,0:18:34.290
but we’ll get back later to this.[br]The HomeNodeB Application…
0:18:34.290,0:18:38.920
no, HomeNodeB Application[br]Part, the HNBAP protocol
0:18:38.920,0:18:42.830
has a couple of more transactions[br]which basically serve
0:18:42.830,0:18:45.790
for the registration of[br]the cell to the network,
0:18:45.790,0:18:50.430
the registration of user equipment,[br]UE, that’s your mobile phone,
0:18:50.430,0:18:54.940
and some additional messages.
0:18:54.940,0:18:58.860
So HNB is the HomeNodeB registration;[br]we have Registration REQUEST, ACCEPT,
0:18:58.860,0:19:02.810
REJECT, De-registration, we have[br]the same for mobile phones.
0:19:02.810,0:19:07.560
We have some more detailed[br]transactions that I’m going to skip.
0:19:07.560,0:19:12.560
But also it’s really very simple,[br]conceptially, it’s not very complex,
0:19:12.560,0:19:15.450
you don’t have like massive state[br]machines or anything like that.
0:19:15.450,0:19:19.510
Very few, very limited messages.
0:19:19.510,0:19:23.630
Then we look at RANAP. That’s the Radio[br]Access Network Application Part.
0:19:23.630,0:19:26.880
This is where your actual signalling[br]messages from the phone
0:19:26.880,0:19:30.750
are tunneled through. So if your[br]phone registers to the network
0:19:30.750,0:19:35.050
you may have heard the term LOCATION[br]UPDATE where the phone basically
0:19:35.050,0:19:38.670
registers to the network or updates[br]its location with the network.
0:19:38.670,0:19:43.980
That’s the first message you would[br]see, encapsulated inside RANAP, and
0:19:43.980,0:19:49.250
transported to the core network element.[br]Also things like PDP context activation,
0:19:49.250,0:19:53.430
if you activate a data connection to[br]a certain APN over cellular protocols,
0:19:53.430,0:19:59.850
all this is encapsulated[br]in the RANAP layer.
0:19:59.850,0:20:03.760
Also the number of messages that we[br]actually need is extremely limited.
0:20:03.760,0:20:08.240
Again, it’s a very short list, it’s[br]not like hundreds of messages.
0:20:08.240,0:20:12.230
But the messages themselves can be[br]quite complex. With nesting levels
0:20:12.230,0:20:17.410
up to 12..14 layers deep.[br]But we’ll see that later on.
0:20:17.410,0:20:21.200
So we have a couple of transactions.[br]RESET – well, I don’t need to explain –
0:20:21.200,0:20:26.350
it’s a Reset. INITIAL UE MESSAGE[br]means a new phone has connected,
0:20:26.350,0:20:29.520
and it has sent us the first message[br]that this phone has transmitted,
0:20:29.520,0:20:33.850
that’s why it’s ‘initial’ message. DIRECT[br]TRANSFER is all the follow-up transfer.
0:20:33.850,0:20:38.220
IU RELEASE means we’re releasing[br]a connection. Some commands
0:20:38.220,0:20:43.750
to configure the security, the ciphering,[br]the encryption. A PAGING command
0:20:43.750,0:20:47.680
by which the network can initiate[br]a transaction to the phone.
0:20:47.680,0:20:52.010
And RAB ASSIGNMENT. RAB[br]is the Radio Access Bearer
0:20:52.010,0:20:56.640
which is basically an abstract notion
0:20:56.640,0:21:03.310
of a bearer able to[br]transport communication.
0:21:03.310,0:21:07.020
If you come from classic[br]telephony the bearer was
0:21:07.020,0:21:11.030
an analog voice channel.[br]If you go to ISDN the bearer is
0:21:11.030,0:21:14.930
a 64kbps synchronous channel
0:21:14.930,0:21:19.470
where you have Alaw Ulaw (?)[br]inside, and voice data.
0:21:19.470,0:21:24.790
Or you have some HTLC (?) or X75[br]or whatever data inside.
0:21:24.790,0:21:29.830
In GSM the bearer is[br]typically voice bearers,
0:21:29.830,0:21:36.020
with different voice codecs.[br]The same it is in UMTS.
0:21:36.020,0:21:39.940
And basically you can configure[br]those bearers in UMTS because
0:21:39.940,0:21:45.660
that’s a very universal and[br]flexible part of the system.
0:21:45.660,0:21:48.880
Now, one of the protocols we have[br]seen in the stack – I’m just going back
0:21:48.880,0:21:55.480
a couple of slides to reiterate – that[br]is the SCCP which is introduced here.
0:21:55.480,0:21:58.980
The ‘Signalling Connection Control Part’,
0:21:58.980,0:22:03.450
if I remember correctly. It’s a protocol[br]that’s used a lot in core networks
0:22:03.450,0:22:09.360
of mobile operators. So if you[br]look at Roaming interfaces,
0:22:09.360,0:22:14.030
at classic SS7 interfaces – think of the[br]SS7 security talks etc. we’ve had here
0:22:14.030,0:22:19.120
at CCC events a lot of times – this is[br]a protocol that’s very often used
0:22:19.120,0:22:24.990
in a lot of different parts of[br]telecom. But the problem is –
0:22:24.990,0:22:29.820
everywhere except [at] this[br]particular point in UMTS and GSM
0:22:29.820,0:22:33.580
it is used only in connection-less[br]mode; and this is the only point
0:22:33.580,0:22:38.450
where it uses connection-oriented[br]SCCP. And therefor none of the existing
0:22:38.450,0:22:41.660
free software implementations is[br]implemented. You can look to Yate,
0:22:41.660,0:22:45.000
you can look to the libosmo-sccp,[br]the library that we have in
0:22:45.000,0:22:49.980
the Osmocom project. You can[br]look at the Mobicents Java stack
0:22:49.980,0:22:54.650
for these protocols. You can look[br]at the osmo_sccp Erlang code.
0:22:54.650,0:22:57.810
Basically no implementation[br]exists, so we also had to
0:22:57.810,0:23:03.720
implement that part,[br]at least to the point,
0:23:03.720,0:23:07.440
to those features that are required.[br]But once we have implemented
0:23:07.440,0:23:11.580
all these protocols – RUA, SCCP,
0:23:11.580,0:23:15.120
the RANAP, the HNBAP, then
0:23:15.120,0:23:20.730
we need to somehow interface[br]those protocols with the existing
0:23:20.730,0:23:25.070
network elements that we have for GSM. And
0:23:25.070,0:23:29.480
there are sort of several[br]challenges in this area,
0:23:29.480,0:23:34.480
in what people know[br]as the OpenBSC project.
0:23:34.480,0:23:38.019
Actually the program that most[br]people use is called OsmoNITB
0:23:38.019,0:23:41.900
– the network in the box – which is called[br]‘network in the box’ because it implements
0:23:41.900,0:23:47.290
all the network elements that you[br]need in one box, or in one program.
0:23:47.290,0:23:50.520
Unfortunately we need to separate[br]those individual pieces which are
0:23:50.520,0:23:57.190
all in one blob, in order to interface[br]at the point where we want to interface.
0:23:57.190,0:24:00.780
So this separation of the MSC part[br]and the BSC part needs to be done
0:24:00.780,0:24:05.220
inside the ‘network in the box’.[br]We need the UMTS authentication
0:24:05.220,0:24:08.270
and key agreement support,
0:24:08.270,0:24:13.190
and we need the different[br]protocols that I just mentioned
0:24:13.190,0:24:17.830
and link them in on the SGSN side.
0:24:17.830,0:24:22.710
For the data services we need[br]to introduce some extraction
0:24:22.710,0:24:28.390
to basically differentiate the packet data[br]connections coming from GPRS networks
0:24:28.390,0:24:33.200
and those coming from the new[br]3G networks or base stations
0:24:33.200,0:24:37.560
that we are supporting.[br]But that’s all manageable.
0:24:37.560,0:24:43.400
Now, the question is,
0:24:43.400,0:24:47.330
do we really want to go for the[br]full stack as it has been described,
0:24:47.330,0:24:53.980
or can we take some shortcuts, do we[br]really need to implement the full SCCP,
0:24:53.980,0:24:58.750
for example? Do we need to implement M3UA,
0:24:58.750,0:25:03.520
which is another protocol layer in there?[br]Can we basically simplify that?
0:25:03.520,0:25:07.960
The initial idea was[br]– if we go back to that slide –
0:25:07.960,0:25:11.190
to reduce the complexity, I already[br]mentioned this HomeNodeB gateway
0:25:11.190,0:25:15.460
which basically passes RANAP[br]from left to right, and just changes
0:25:15.460,0:25:22.460
the underlying encapsulation. Why don’t we[br]just continue using RUA up into the SGSN
0:25:22.460,0:25:26.440
and thereby avoid having[br]to do SCCP and M3UA,
0:25:26.440,0:25:30.220
avoid having to implement more protocols[br]without having any functional gain.
0:25:30.220,0:25:33.720
I mean it would just work the same way[br]if we take RUA and we take it all the way
0:25:33.720,0:25:37.640
into the SGSN. So there’s been[br]some thinking along those lines
0:25:37.640,0:25:43.760
but the idea was to…
0:25:43.760,0:25:47.880
…go sort of in a compromise so what[br]we’re using here is yet another protocol
0:25:47.880,0:25:52.350
called SUA, the SCCP User Adaption.
0:25:52.350,0:25:55.750
And that replaces those 2 layers[br]and keeps things a little bit simpler
0:25:55.750,0:26:03.310
from the implementation side. OK, now we[br]have all these different protocol layers,
0:26:03.310,0:26:07.510
and the integration into the core[br]network elements. Now the fun starts.
0:26:07.510,0:26:11.420
We have a plan, we know[br]what needs to be done,
0:26:11.420,0:26:15.090
we know what needs to be done,[br]and now we actually need to do it.
0:26:15.090,0:26:20.470
So the theory was easy – read a couple[br]of specs, find out 6..7 messages,
0:26:20.470,0:26:24.510
not too many transactions, no[br]complex state machines. Okay, now,
0:26:24.510,0:26:27.820
a lot of the more modern telecom[br]protocols use ASN.1 syntax.
0:26:27.820,0:26:34.640
It’s an abstract syntax notation[br]for defining data structures
0:26:34.640,0:26:39.910
or procedures to be communicated, and[br]then you can use code generation tools
0:26:39.910,0:26:44.270
to generate code in your favorite[br]language from this syntax
0:26:44.270,0:26:46.809
doing all the marshalling and[br]demarshalling of the messages.
0:26:46.809,0:26:51.260
That’s at least what’s the idea. This is[br]very different from what we used to do
0:26:51.260,0:26:55.640
in the GSM world because GSM[br]was specified in the late 1980s.
0:26:55.640,0:26:59.770
ASN.1 didn’t exist to my knowledge back[br]then, or at least they didn’t know about it,
0:26:59.770,0:27:04.670
and/or they thought it was not something[br]that you could do in a mobile phone
0:27:04.670,0:27:07.431
at that time. Think about 8 bit[br]microcontrollers and whatnot,
0:27:07.431,0:27:12.430
what they were using these days.[br]So the GSM messages,
0:27:12.430,0:27:16.000
basically you have…, you look at the spec[br]and you see “Oh, there’s one byte this,
0:27:16.000,0:27:18.790
then there’s a 2 byte length field, and[br]then there’s that”. And you need
0:27:18.790,0:27:24.150
to implement that basically in your code,[br]based on the textual representation.
0:27:24.150,0:27:28.150
Now, for UMTS almost all the[br]protocols and particularly these
0:27:28.150,0:27:33.290
that we’re looking [at] here are specified[br]in abstract syntax notation which, well,
0:27:33.290,0:27:36.300
on the one hand side you would say: “Oh[br]yes, great, now we don’t need to write
0:27:36.300,0:27:40.650
all this message encoding and decoding[br]code, and then we end up interpreting
0:27:40.650,0:27:45.470
the spec different[ly] and we have sort of[br]incompatible messages and whatnot”.
0:27:45.470,0:27:50.830
That’s true to some extent, okay. Now[br]what you need to know about ASN.1 is,
0:27:50.830,0:27:55.040
there are different encoding rules that[br]define how the abstract syntax notation
0:27:55.040,0:27:59.830
gets converted into a concrete[br]binary representation. There is a
0:27:59.830,0:28:04.710
Basic Encoding Rules (BER),[br]there is all kinds of encoding rules,
0:28:04.710,0:28:09.809
there is even JSON encoding rules these[br]days. There’s also XML encoding rules.
0:28:09.809,0:28:14.470
But what’s used here in these specs is[br]called ‘aligned Packed Encoding Rules’
0:28:14.470,0:28:19.740
(APER). This is a particular encoding rule[br]that was not… or is not supported
0:28:19.740,0:28:26.450
by any of the ASN.1 compilers that exist[br]in open source that generate C code.
0:28:26.450,0:28:30.960
So we first had to teach the ASN.1[br]compiler this encoding rule.
0:28:30.960,0:28:34.720
And the second big problem is the ASN.1[br]syntax used in those protocol specs
0:28:34.720,0:28:39.700
uses a construct called ‘Information[br]Object Classes’, which is sort of…
0:28:39.700,0:28:48.000
well, you know, an interesting way[br]how to express or how to have…
0:28:48.000,0:28:53.090
a different notation on how to construct[br]those messages and how to construct
0:28:53.090,0:28:58.309
operations that have like an initiating[br]request, a ‘successful’ response,
0:28:58.309,0:29:02.770
a ‘successful error’ outcome or something[br]like that. And you can express that
0:29:02.770,0:29:06.020
in a really nice way but then you need[br]a compiler and a code generator
0:29:06.020,0:29:12.240
that can parse that, and that’s really[br]difficult in the free software world
0:29:12.240,0:29:17.470
within some constraints. I’ll get into[br]the details. Now the next thing is
0:29:17.470,0:29:21.080
that the way how they use ASN.1[br]in these protocol specs
0:29:21.080,0:29:24.860
– ASN.1 being the abstract syntax[br]notation – is not abstract enough.
0:29:24.860,0:29:30.299
They need to have another[br]abstraction layer. So they use ASN.1
0:29:30.299,0:29:34.510
to describe containers, containers[br]for information elements,
0:29:34.510,0:29:38.360
containers for messages, containers[br]for lists of information elements
0:29:38.360,0:29:42.190
and containers for pairs of information[br]elements. It’s very important.
0:29:42.190,0:29:46.490
You cannot just have a list of 2.[br]No, you need to have a pair
0:29:46.490,0:29:50.960
that says, well, this is a pair of[br]2 information elements. Not sure why,
0:29:50.960,0:29:55.300
but somebody probably had[br]his reasons for doing so.
0:29:55.300,0:30:00.300
Now the point is, basically,[br]you use the ASN.1 syntax
0:30:00.300,0:30:03.500
and you generate some code for[br]encoding or decoding and then
0:30:03.500,0:30:07.010
you’re not really done at that point.[br]Because then you basically:
0:30:07.010,0:30:10.000
“Oh, this is a list of containers”, and[br]then you look into each of the containers
0:30:10.000,0:30:13.750
and then call the decoder again for each[br]of the elements in the list. And then
0:30:13.750,0:30:17.180
in there there might be another level[br]of containers and you unpack it again,
0:30:17.180,0:30:22.280
so it’s a little bit like matryoshka[br]or, you know, these dolls
0:30:22.280,0:30:27.920
nested in each other; or somebody[br]sends you a large packet etc. Well,
0:30:27.920,0:30:31.720
to illustrate that, if you’ve ever seen[br]ASN.1, this is a relatively simple example
0:30:31.720,0:30:37.720
describing authentication couples[br]or triplets or quintuplets.
0:30:37.720,0:30:41.770
Basically, the authentication data that’s[br]used for authenticating subscribers
0:30:41.770,0:30:45.909
in networks. This is what is used[br]also in GSM. It’s relatively simple,
0:30:45.909,0:30:50.640
so it basically tells you, well, there’s[br]an authentication set list which contains
0:30:50.640,0:30:54.740
[consists] of a choice of either a triplet[br]or a quintuplet list. Each of those lists
0:30:54.740,0:30:58.640
either have a length from 1..5, and then[br]you have basically a sequence which is
0:30:58.640,0:31:03.370
sort of struct or a record of the below[br]items in those lists. That is how [it] is
0:31:03.370,0:31:08.600
and should look like and how it[br]normally looks like. Now in RANAP
0:31:08.600,0:31:13.060
and these protocols they first – as said –[br]they define these containers, they say:
0:31:13.060,0:31:17.690
“We have…”. So it reminds me a bit[br]of some mathematicians. It’s like
0:31:17.690,0:31:21.260
“We define we have this, and then we have[br]that, and therefore we can construct
0:31:21.260,0:31:27.140
such a new structure” and whatnot. So[br]basically, they define first a container
0:31:27.140,0:31:32.170
for protocol information elements,[br]protocol IEs. And in the protocol IE
0:31:32.170,0:31:36.680
is the actual information element. Each[br]element has an ID, it has a criticality.
0:31:36.680,0:31:39.500
The criticality tells you whether,[br]if you do not understand
0:31:39.500,0:31:44.080
such an information element, should[br]you ignore it, should you reject it,
0:31:44.080,0:31:49.190
should you ignore it but report to the[br]sender that you did not understand it
0:31:49.190,0:31:54.370
despite proceeding with your operation,[br]and then the actual value.
0:31:54.370,0:31:58.401
And the value is an ANY type which[br]means there is another ASN.1 syntax
0:31:58.401,0:32:02.450
in that value that you then need to parse.
0:32:02.450,0:32:07.450
So you need to do these[br]2 steps in the code. You first
0:32:07.450,0:32:11.570
unwrap the containers and then you[br]decode what is inside the containers.
0:32:11.570,0:32:15.210
So working with ASN.1 really is not[br]as simple and as straightforward
0:32:15.210,0:32:19.170
and as automatic as it should be. And you[br]end up with messages looking like this
0:32:19.170,0:32:24.309
in Wireshark. So believe it or not,[br]the content, the useful content
0:32:24.309,0:32:28.699
of this entire message[br]is 4 bytes here, the c0…
0:32:28.699,0:32:37.670
laughter and applause
0:32:37.670,0:32:42.179
…is the 4 bytes starting from c0, and[br]those people who have seen an IP address,
0:32:42.179,0:32:48.170
an IPv4 address in a 192.168. address[br]range will recognize those bytes here
0:32:48.170,0:32:52.429
at the end. So the c0 is 192. etc.[br]And in order to communicate
0:32:52.429,0:32:56.450
this message actually, this is a message[br]that tells us to which IP address
0:32:56.450,0:33:01.060
something has been bound to. In this case[br]it’s the GTP connection for communicating
0:33:01.060,0:33:05.809
packet data. And you see all these[br]abstractions and encapsulations
0:33:05.809,0:33:09.410
and the nested tree, so it’s…[br]it starts with… well, ok,
0:33:09.410,0:33:12.880
this is an outcome. It is an outcome to[br]the Radio Access Bearer Assignment.
0:33:12.880,0:33:16.860
“If you do not understand[br]it please reject it”.
0:33:16.860,0:33:20.840
We have an Assignment Response. It[br]contains [consists] of a list of one item
0:33:20.840,0:33:27.190
of protocol information elements. This[br]one item is a SetupOrModifiedList,
0:33:27.190,0:33:30.929
which again has a criticality of ‘Ignore’.[br]If you don’t understand it…
0:33:30.929,0:33:34.620
oh no sorry, here it says “If you don’t[br]understand it just ignore it.
0:33:34.620,0:33:38.270
Don’t report an error”. It’s quite[br]interesting because you have a message
0:33:38.270,0:33:42.110
that only contains one element and it[br]says, well, you should reject the message
0:33:42.110,0:33:45.190
if you don’t understand it; but then the[br]information element says: “Oh, if you
0:33:45.190,0:33:49.750
don’t understand it please[br]ignore it”. So, okay.
0:33:49.750,0:33:53.590
Then inside the SetupOrModifiedList[br]we have one item
0:33:53.590,0:33:57.880
which is a protocol IE[br]container with one item
0:33:57.880,0:34:00.950
which has an item which is the[br]SetupOrModifiedItem, which is
0:34:00.950,0:34:05.460
a Radio Access Bearer Modified[br]Item, which contains
0:34:05.460,0:34:11.369
a Radio Access Bearer SetupOrModifiedItem[br]with a Radio Access Bearer ID of 1
0:34:11.369,0:34:14.909
and a transport layer address of[br]this. And in case you’re wondering
0:34:14.909,0:34:20.310
why the IP address has such[br]binary crap in front – it is
0:34:20.310,0:34:25.510
because it’s too difficult to express[br]in ASN.1 that this is an IP address.
0:34:25.510,0:34:29.020
You could not just define a type for an[br]IP address. That would be too simple.
0:34:29.020,0:34:33.550
No, you need to refer from this[br]specification to another specification,
0:34:33.550,0:34:40.460
another 3G specification,[br]which then refers to ITU-T X213
0:34:40.460,0:34:45.719
which tells you how you can encode[br]any possible transport layer address
0:34:45.719,0:34:50.570
in any possible network protocol on the[br]planet by using a hierarchical structure
0:34:50.570,0:34:57.119
like OUI IDs or something like that. And[br]‘35’ means it’s an IETF allocated address.
0:34:57.119,0:35:01.620
‘0001’ means it’s an IPv4 address and[br]then you actually have the payload.
0:35:01.620,0:35:05.350
And you can see Wireshark is too[br]stupid to decode such brilliance!
0:35:05.350,0:35:15.050
laughter and applause
0:35:15.050,0:35:19.150
Yeah, so. Then it’s hard to find[br]example traces. You want to implement
0:35:19.150,0:35:22.430
the protocol and you want to find some[br]example traces. This is a mail I …
0:35:22.430,0:35:27.030
actually I was looking for this this[br]year, in 2015. I was googling
0:35:27.030,0:35:32.450
for Iuh protocol traces. And what[br]did I find? My own e-mail from 2009
0:35:32.450,0:35:37.440
where I was asking for protocol traces.[br]But nobody ever responded.
0:35:37.440,0:35:40.950
So the situation is better today.[br]You can actually find, I think,
0:35:40.950,0:35:46.770
2 or 3 public pcap files containing[br]each maybe a handful of messages
0:35:46.770,0:35:51.270
on those interfaces. It’s really… it’s[br]odd, you know? These are protocols
0:35:51.270,0:35:55.650
that are specified publicly. They’re used[br]in production. Billions of users are using
0:35:55.650,0:36:01.000
these networks but nobody even has an[br]example protocol trace of those protocols.
0:36:01.000,0:36:05.210
Okay, now we have a couple of[br]protocol traces. We understand
0:36:05.210,0:36:09.470
the nesting level is deep. We are happy[br]that Wireshark decodes at least most of it,
0:36:09.470,0:36:13.480
which by the way we have to thank[br]one particular Ericsson employee
0:36:13.480,0:36:18.700
who is contributing those[br]dissectors to Wireshark.
0:36:18.700,0:36:22.920
So then we need to basically set up[br]a tool chain to generate code
0:36:22.920,0:36:29.030
from these ASN.1 syntaxes. So there is[br]an ASN.1 C compiler from Lev Walkins.
0:36:29.030,0:36:32.930
It’s good for a lot of things and I’m[br]very happy it exists. But it lacks many
0:36:32.930,0:36:36.030
if not most of the features that you[br]need in the Telecom world. That’s
0:36:36.030,0:36:38.940
sort of unfortunate. There’s no[br]information object classes, there is
0:36:38.940,0:36:43.500
no aligned PER support, there’s no[br]support for prefixing the type names.
0:36:43.500,0:36:46.960
Because we have 3 different protocols, we[br]want to use them from one program.
0:36:46.960,0:36:50.660
We need to prefix the type names because[br]of course each of those 3 protocols
0:36:50.660,0:36:54.300
has a type called ‘protocol information[br]element container’. But of course
0:36:54.300,0:36:57.260
it’s not the same protocol information[br]element container, there it said(?).
0:36:57.260,0:37:02.150
You know, each of the protocols[br]has its own containers.
0:37:02.150,0:37:07.290
So we had to add these pieces to the[br]asn1c, at least in a minimal way
0:37:07.290,0:37:11.590
in order to use it. And unfortunately[br]I don’t know anyone, and I’m certainly
0:37:11.590,0:37:15.189
no one who understands something[br]about compiler theory, so it’s
0:37:15.189,0:37:21.100
a little bit challenging. Now,[br]alternatives to asn1c, well,
0:37:21.100,0:37:25.030
the most complete tool kit you[br]can find for working with ASN.1
0:37:25.030,0:37:30.310
exists in the Erlang OTP system.[br]I used this in the past
0:37:30.310,0:37:36.490
for a lot of Osmocom projects,[br]but the fact is the C projects…
0:37:36.490,0:37:40.050
there are other developers and people[br]that contribute. In the Erlang projects
0:37:40.050,0:37:44.200
there is nobody that contributes except[br]from me. So I thought, well okay,
0:37:44.200,0:37:48.450
it’s very nice to work with ASN.1 in[br]Erlang, but then if nobody contributes
0:37:48.450,0:37:53.940
I’d rather go the difficult C way and then[br]have contributors in the project.
0:37:53.940,0:37:58.010
Also of course in the Osmocom project[br]we’re mostly low-level C guys;
0:37:58.010,0:38:04.460
and people are very wary of[br]virtual machines and the
0:38:04.460,0:38:08.980
– at least perceived – bloat they[br]introduce. The third alternative is
0:38:08.980,0:38:13.900
to use a proprietary ASN.1 compiler, and[br]in my day job I actually use such tools.
0:38:13.900,0:38:18.230
But in the first sight you think,
0:38:18.230,0:38:24.490
well, okay, so it’s a code compiler, it[br]compiles code, and copyright law says,
0:38:24.490,0:38:28.020
well, code that was generated by[br]a machine is not copyrightable because
0:38:28.020,0:38:33.260
the act of automatically compiling[br]code from one form into another form
0:38:33.260,0:38:37.900
does not make this… that does not[br]create a copyrightable work as itself.
0:38:37.900,0:38:42.350
So basically, you can take a proprietary[br]ASN.1 compiler, compile C code and then
0:38:42.350,0:38:46.310
use the resulting C code in an open source[br]project without having any problems
0:38:46.310,0:38:50.990
with the license of the ASN.1 compiler.[br]And that’s true, however
0:38:50.990,0:38:54.450
all those compilers I know, and I think[br]I know all of them, they have
0:38:54.450,0:38:59.991
a runtime library and that you only either[br]get as a binary library or you get it
0:38:59.991,0:39:06.340
in source code that’s not available[br]under a free software compatible license.
0:39:06.340,0:39:09.910
No option to do that. So we[br]have to stick with asn1c,
0:39:09.910,0:39:14.470
which as I said I don’t want to complain[br]about, it’s a great project. It just
0:39:14.470,0:39:17.450
doesn’t do all the things that we need.[br]But then, it was not written for us, so
0:39:17.450,0:39:23.760
of course it doesn’t do everything[br]we need. Luckily, a research group
0:39:23.760,0:39:29.300
at Eurecom, the European Communications[br]Research organization, has developed
0:39:29.300,0:39:33.720
a patch for adding aligned PER support[br]to asn1c. Unfortunately it was
0:39:33.720,0:39:37.900
against an old version because, well,[br]they probably don’t want to submit
0:39:37.900,0:39:42.310
this main line (?) and they don’t care[br]about porting it and rebasing (?) it.
0:39:42.310,0:39:47.290
I did that. It probably still needs some[br]clean-up before it can be submitted,
0:39:47.290,0:39:52.880
but my goal is to have[br]this included in asn1c.
0:39:52.880,0:39:56.960
And also we found quite a number[br]of bugs still in the code,
0:39:56.960,0:40:01.460
so it’s in the process of being improved.[br]Now information object classes are hard,
0:40:01.460,0:40:05.150
at least for me. Basically we skip that.
0:40:05.150,0:40:10.570
I manually edit the ASN.1 syntax for not[br]using information object classes anymore,
0:40:10.570,0:40:14.490
so I’m rewriting the ASN.1, that’s[br]supposed to be there to guarantee
0:40:14.490,0:40:19.090
that the encoding is a… so it circumvents
0:40:19.090,0:40:22.200
sort of the purpose. The idea is you take[br]the ASN.1 from the spec, you use it,
0:40:22.200,0:40:26.060
you don’t modify it. But I’m modifying[br]it because, well, the tools we have
0:40:26.060,0:40:30.630
are not good for what we want[br]to do. Type prefixing is done.
0:40:30.630,0:40:35.190
Now we have the information[br]element containers. Eurecom has
0:40:35.190,0:40:41.249
another idea about this.[br]They have a long Perl script.
0:40:41.249,0:40:47.090
I recommend you not to look at it, it[br]consists of a neverending sequence
0:40:47.090,0:40:53.060
of regular expressions, basically grep-ing[br]out certain parts of the ASN.1 syntax
0:40:53.060,0:40:56.990
without really formally parsing it,[br]or lexing it, or tokenizing it;
0:40:56.990,0:41:00.440
and then based on those regular[br]expressions generating C code that then
0:41:00.440,0:41:04.940
you can use with asn1c and link[br]against it. And surprisingly it works,
0:41:04.940,0:41:08.840
surprisingly good actually. We had to[br]teach it all the things that we needed
0:41:08.840,0:41:13.780
in addition to that.[br]But really it works surprisingly.
0:41:13.780,0:41:18.910
Now. Putting things together:[br]Copy and paste the ASN.1 syntax
0:41:18.910,0:41:24.050
from the 3GPP DOC files. Because 3GPP[br]specs are published as PDF files
0:41:24.050,0:41:28.130
and as Word documents, and you don’t[br]get the actual syntax as a text file.
0:41:28.130,0:41:32.490
You have to copy and paste from each page,[br]make sure you don’t get intermixed
0:41:32.490,0:41:37.660
like headlines or something like that.[br]Then you use the hacked-up, patched asn1c
0:41:37.660,0:41:45.530
to generate C code. You have to modify it[br]to make a shared library of the runtime
0:41:45.530,0:41:49.920
for the ASN.1 compiler because we have,[br]again, 3 syntaxes that we want to mix,
0:41:49.920,0:41:54.349
and that doesn’t really work with how[br]asn1c works. We use asn1tostruct
0:41:54.349,0:41:58.660
to remove this what I call the obfuscation[br]layer, these containers. We write
0:41:58.660,0:42:03.540
some code to dispatch the messages,[br]and then finally, we see some messages.
0:42:03.540,0:42:09.700
So we have those HNB register,[br]INITIAL_UE_MESSAGE and all these things.
0:42:09.700,0:42:13.540
This is what you can now get from[br]osmo-iuh.git, the Git repository
0:42:13.540,0:42:18.280
on the Osmocom server which[br]contains all this code.
0:42:18.280,0:42:22.350
It takes a long time to compile,[br]because asn1c generates one C file
0:42:22.350,0:42:26.690
and one header file for each type. And[br]they have lots of types in those specs.
0:42:26.690,0:42:30.570
So you end up with like 300..400[br]C files and header files compiled
0:42:30.570,0:42:38.440
into a 5 megabyte binary, and then finally[br]you want to get 4 bytes in a message.
0:42:38.440,0:42:44.170
So well, where do we go from here?[br]We have a couple of other things to do.
0:42:44.170,0:42:47.510
One interesting question is – and I’m[br]going to do a demo in a few minutes –
0:42:47.510,0:42:51.630
is what kind of hardware can be used?[br]Well, the hardware that I currently use
0:42:51.630,0:42:55.400
for this development is undisclosed[br]manufacturer, very expensive.
0:42:55.400,0:43:00.990
It’s not actually a femtocell, it’s a real[br]cell, it costs several thousand Euros,
0:43:00.990,0:43:05.310
not really suitable for hackers. However[br]many consumer grade femtocells
0:43:05.310,0:43:09.210
have also this Iuh protocol with the[br]same stacking. The problem is
0:43:09.210,0:43:15.050
they’re locked down, in a way that they[br]have certificates and connect over IPsec
0:43:15.050,0:43:20.700
to the operator network etc. So if[br]somebody can break this IPsec layer
0:43:20.700,0:43:24.780
and insert its own a certificate, or[br]disable the IPsec altogether then you can
0:43:24.780,0:43:29.619
talk Iuh to the osmo-iuh and then you[br]can use that hardware. This is something
0:43:29.619,0:43:33.030
that a couple of people have looked[br]at, and hopefully in the near future
0:43:33.030,0:43:38.430
we will have 1 or 2 femtocells[br]that people can use inexpensively
0:43:38.430,0:43:41.000
in order to use the software. At the[br]moment, I said, unfortunately
0:43:41.000,0:43:48.010
it’s not possible. As a summary,[br]before I go into the demo
0:43:48.010,0:43:53.620
of demonstrating it and you having[br]basically a look in the marvelous depth
0:43:53.620,0:43:59.680
of the Wireshark decodes, Iuh is[br]conceptually very easy to understand.
0:43:59.680,0:44:04.660
The lack of good ASN.1 tools is the[br]biggest problem in the free software world.
0:44:04.660,0:44:09.450
You need to overcome these containers,[br]and in the end you spend 90% of your time
0:44:09.450,0:44:13.380
in improving the tooling, fixing the[br]tooling and working around these
0:44:13.380,0:44:18.869
layers of abstraction rather than[br]doing the actual functionality.
0:44:18.869,0:44:22.960
We have started the work on the core[br]network components, the integration.
0:44:22.960,0:44:27.210
I was hoping that I could do a full demo[br]with a call, or a full demo with actually
0:44:27.210,0:44:32.200
having a data connection over this setup[br]that I have here, over the test setup.
0:44:32.200,0:44:36.120
I’m almost there. The signalling,[br]everything gets established,
0:44:36.120,0:44:39.910
the authentication works but then[br]somehow the data, the actual IP data
0:44:39.910,0:44:45.250
doesn’t want to come through. And that[br]is under investigation, but I’m sure
0:44:45.250,0:44:51.260
it will be available rather soon.[br]Now before we go for Q&A
0:44:51.260,0:44:58.620
let me just do a quick demo and let me[br]show you how this looks at the moment.
0:44:58.620,0:45:02.760
This is still a protocol trace
0:45:02.760,0:45:07.510
basically that was running in the past.[br]I’m just going to leave this here
0:45:07.510,0:45:11.240
at the left-hand side, I’m going to leave[br]the… on the right-hand side. So
0:45:11.240,0:45:15.180
what we can see is basically[br]on the left-hand side
0:45:15.180,0:45:19.711
we have the RUA encapsulated messages.[br]This is basically the Iuh interface
0:45:19.711,0:45:23.940
between the HomeNodeB and the[br]HomeNodeB gateway. Then we have
0:45:23.940,0:45:28.369
the osmo-iuh HomeNodeB gateway invisible[br]in between here, and that’s the program
0:45:28.369,0:45:32.780
running in the background. And then the[br]other side is this protocol stacking here,
0:45:32.780,0:45:38.680
where we see we have the SUA, this SCCP[br]User Adaption rather than the RUA
0:45:38.680,0:45:42.130
on the left-hand side. The RANAP messages[br]are the same on left and right, it’s
0:45:42.130,0:45:50.180
basically just converting. What I’m[br]going to start in the background is
0:45:50.180,0:45:55.930
basically – this is the wrong window,[br]I thought I had prepared everything just…
0:45:55.930,0:46:01.290
Yeah. Exactly. Good, that’s the one part,
0:46:01.290,0:46:06.440
that’s the other part…[br]So I’m going to start the…
0:46:06.440,0:46:08.970
I know the font is too small, you don’t[br]need to read that. I’m just going
0:46:08.970,0:46:15.520
to tell you the… I can make it larger,[br]then we won’t see really a lot.
0:46:15.520,0:46:24.530
What’s this? Why is it not…?
0:46:24.530,0:46:31.110
“Cannot listen on… socket…”.[br]Now that’s the demo effect!
0:46:44.640,0:46:49.970
Why on earth is it not binding?
0:46:49.970,0:47:01.040
What a pity! Okay, that’s embarrassing.
0:47:01.040,0:47:05.640
Then you get a larger font size![br]And then let’s have a quick look.
0:47:05.640,0:47:10.720
I’ll try it very quickly. So I’m trying[br]this, it cannot bind to the sockets.
0:47:10.720,0:47:14.460
Probably my IP address has[br]disappeared on the laptop
0:47:14.460,0:47:17.910
while I’ve been talking here and now[br]it wants to bind to an address
0:47:17.910,0:47:28.150
that doesn’t exist anymore. And that[br]seems [to be] exactly what has happened.
0:47:28.150,0:47:34.330
Now don’t shout your SUDO! (?)[br]laughter
0:47:34.330,0:47:39.450
It will not like you. I can tell you.
0:47:39.450,0:47:48.020
Yeah. Now this should do the trick.
0:47:48.020,0:47:50.350
I’m starting this in Valgrind[br]because I’m still debugging, yeah…
0:47:50.350,0:47:54.440
Now it’s actually running, okay. Now[br]we do the same on the other side,
0:47:54.440,0:47:59.670
we go for a huge font size,[br]and I’m starting the HNB gateway.
0:47:59.670,0:48:05.140
We see a yellow line, that a connection[br]has been established. So now
0:48:05.140,0:48:10.960
we are waiting for the initial message[br]from the HomeNodeB to arrive.
0:48:10.960,0:48:13.960
We should see it here at the bottom[br]of this trace. We should see
0:48:13.960,0:48:18.900
a couple of Reset requests. Basically the[br]HomeNodeB this… the NodeB here
0:48:18.900,0:48:24.670
is trying to reconnect all the time[br]to its HomeNodeB gateway.
0:48:24.670,0:48:28.030
Of course there’s some backup… some[br]back off included and given that it was
0:48:28.030,0:48:32.000
not connected for the first 40 minutes or[br]so it will take some time to reconnect
0:48:32.000,0:48:36.060
to the SGSN and then I can have[br]the phone that I have here regist…
0:48:36.060,0:48:59.210
audio recording blanks out
0:48:59.210,0:49:32.190
one minute of audio missing
0:49:32.190,0:49:36.450
Herald: …is there somebody somewhere[br]at a mike? Mike 2, please!
0:49:36.450,0:49:42.250
Question: So if 3G is so annoying why[br]not skip it and go directly to LTE?
0:49:42.250,0:49:46.930
LaForge: Well, there’s a[br]couple of reasons for that.
0:49:46.930,0:49:50.550
First of all some people[br]really need it in terms of
0:49:50.550,0:49:55.960
there’s an actual demand[br]for 3G small networks
0:49:55.960,0:50:00.090
or 3G cells in applications where[br]it’s used. The second reason is
0:50:00.090,0:50:05.660
it’s a relatively limited incremental[br]step because the Layer 3 protocols
0:50:05.660,0:50:11.260
of GSM and UMTS are the same.[br]And that’s why basically we can use…
0:50:11.260,0:50:15.320
reuse the call control and the mobility[br]management, all those parts from GSM,
0:50:15.320,0:50:21.180
reuse them with 3G. I’m not saying we[br]shouldn’t do the same with LTE as well
0:50:21.180,0:50:25.010
but there are actually quite a number of[br]projects already involved in that area.
0:50:25.010,0:50:32.840
And LTE, well, to be frank, it’s so much[br]IP it’s not really telecom anymore.
0:50:32.840,0:50:36.010
You know I’m always interested in[br]the more obscure things that people
0:50:36.010,0:50:40.670
are not really looking so much at. IP,[br]I found IP boring when I stopped working
0:50:40.670,0:50:44.030
on Netfilter in 2004 or so. IP, well[br]everyone knows about IP, that’s…
0:50:44.030,0:50:47.740
you know, we need[br]something more interesting.
0:50:47.740,0:50:51.890
Herald: Microphone 1 please!
0:50:51.890,0:50:56.270
Question: So you say that you have[br]a lot of trouble parsing ASN.1.
0:50:56.270,0:51:01.740
But if it’s always the same containers[br]can’t you simply have a static dump
0:51:01.740,0:51:07.820
of the binary crap before and after that[br]stuff, and ignore the whole parsing part?
0:51:07.820,0:51:15.180
LaForge: You probably could. But then,[br]how can I say, my code athletics
0:51:15.180,0:51:21.760
demand better behavior from code I write[br]than just doing something like that. So
0:51:21.760,0:51:29.420
yes, you could, probably, but I’d rather[br]have a more clean way of doing that.
0:51:29.420,0:51:34.150
Herald: And continue on microphone 1!
0:51:34.150,0:51:39.920
Question: You said that UMTS[br]or 3G is a toolbox for creating
0:51:39.920,0:51:45.849
arbitrary telephony systems while[br]my knowledge tells me that GSM
0:51:45.849,0:51:49.550
is a much more rigid standard,[br]but, if you could please elaborate
0:51:49.550,0:51:57.560
on that concept of “arbitrary networks”!
0:51:57.560,0:52:03.070
LaForge: Well, I could illustrate that[br]very much with a certain protocol trace.
0:52:03.070,0:52:07.550
UMTS basically… when UMTS was specified[br]they didn’t know where the journey
0:52:07.550,0:52:12.500
was going to. Basically, it was not clear[br]that the internet would be the thing
0:52:12.500,0:52:16.340
that we know as of today. They didn’t[br]know that smartphones would exist.
0:52:16.340,0:52:20.190
They didn’t know that IP data services are[br]the type of data services that people
0:52:20.190,0:52:27.109
are interested in. Rather they were[br]thinking of… in generic terms.
0:52:27.109,0:52:33.170
So it could have been that[br]we needed all X.25 over UMTS.
0:52:33.170,0:52:38.109
It could be that, you know, people[br]wanted to do ATM over UMTS.
0:52:38.109,0:52:42.060
It was not clear that circuit-switched[br]services would basically go downhill
0:52:42.060,0:52:48.830
like they did meanwhile with[br]voice-over-IP telephony etc.
0:52:48.830,0:52:53.670
It was not clear that modem calls or[br]actual video calls that exist in UMTS
0:52:53.670,0:52:58.010
would not be the future. So it was very[br]unclear. And they tried to define something
0:52:58.010,0:53:02.010
that’s as flexible as possible to do[br]anything that you could imagine.
0:53:02.010,0:53:05.920
And if you look at the way how the layers[br]are structured and the fact that you have
0:53:05.920,0:53:10.780
transport channels, and transport channel[br]bundles, and radio access bearers etc.,
0:53:10.780,0:53:15.260
basically the structure. Even[br]only to transmit voice again
0:53:15.260,0:53:21.230
you have to set up with AMR for all[br]the codecs you need to configure
0:53:21.230,0:53:26.230
in the physical layer, I think,[br]for the 3 different bit classes
0:53:26.230,0:53:30.910
10 different combinations. So you end[br]up with something like 30 parameters
0:53:30.910,0:53:35.780
or 30 sets of parameters that you need[br]to communicate to the lower layers only
0:53:35.780,0:53:40.150
to configure it for establishing a voice[br]channel. And then the transport channels,
0:53:40.150,0:53:44.250
that where the bits are included, the[br]payload like how many bits fit in
0:53:44.250,0:53:48.109
into one frame doesn’t match with your[br]codec bitrate because they didn’t know
0:53:48.109,0:53:52.180
what codecs they would use. So it’s[br]really… it’s all arbitrary and with padding
0:53:52.180,0:53:59.220
and universal. So it’s not like GSM.[br]GSM is very simple and straightforward.
0:53:59.220,0:54:02.240
Herald: Okay, we have 5 minutes left[br]so we will have 2 quick questions
0:54:02.240,0:54:04.510
from the internet because[br]everybody on the stream:
0:54:04.510,0:54:07.820
you can actually ask questions[br]on the chat. Please!
0:54:07.820,0:54:12.010
Signal Angel: Okay, thanks. We have 2[br]questions as you said. The first one is:
0:54:12.010,0:54:15.480
if there would be interest in[br]implementing, you know, the whole stack
0:54:15.480,0:54:21.570
in a safe and non-VM based language[br]if the tooling was good enough?
0:54:21.570,0:54:25.850
LaForge breathes out heavily[br]laughter
0:54:25.850,0:54:29.480
LaForge: Well, I mean I’ve… It depends[br]on… I don’t want to find Language Wars
0:54:29.480,0:54:36.290
here. I would have been tempted to[br]do things in Erlang but then, I said,
0:54:36.290,0:54:40.240
the question is who else[br]would have been tempted?
0:54:40.240,0:54:44.140
I don’t think… I mean the point is what[br]we’re trying to do now is to basically
0:54:44.140,0:54:50.680
use most of what we already have[br]with the least additional effort
0:54:50.680,0:54:55.329
and I don’t think anyone will want[br]to start from scratch all over again.
0:54:55.329,0:54:59.000
But if they do so I would be happy[br]to see a clean implementation,
0:54:59.000,0:55:02.930
but I’m not so sure that will happen.
0:55:02.930,0:55:06.890
Signal Angel: Okay, thanks. The second[br]question is: why don’t we just
0:55:06.890,0:55:11.410
start over for a clean slate with hardware[br]and software and do a basically
0:55:11.410,0:55:15.650
100% nerd and hacker[br]driven mobile networks?
0:55:15.650,0:55:17.470
LaForge: Sorry, 100%…?
0:55:17.470,0:55:21.470
Signal Angel: …nerd/hacker[br]driven networks.
0:55:21.470,0:55:25.720
LaForge: Ah, well, I mean the point[br]of implementing all those specs is
0:55:25.720,0:55:30.099
you want to use the existing[br]devices out there. You want to use
0:55:30.099,0:55:33.500
the existing billions of mobile phones[br]that exist on the planet. And if you
0:55:33.500,0:55:36.510
want to talk to them then you need[br]to implement those protocols
0:55:36.510,0:55:40.610
and those systems that they implement.[br]If you want to start from something else
0:55:40.610,0:55:45.480
and do things from scratch, well, yes,[br]you can do that. But then keep in mind
0:55:45.480,0:55:49.520
that you will have very bulky end user[br]equipment with large like clusters
0:55:49.520,0:55:54.750
of FPGAs and DSPs, draining batteries,[br]having fans inside. Because you
0:55:54.750,0:55:59.099
will not be able to implement your system[br]in the same level of energy efficiency,
0:55:59.099,0:56:04.900
in the same level of, you know, ASICs[br]and optimized silicon processes etc.
0:56:04.900,0:56:10.660
like is the case for the[br]billions of existing devices.
0:56:10.660,0:56:13.910
Herald: Okay, thank you, Harald Welte!
0:56:13.910,0:56:17.480
LaForge: Yeah, thank you![br]applause
0:56:17.480,0:56:23.190
postroll music
0:56:23.190,0:56:28.581
Subtitles created by c3subtitles.de[br]in the year 2017. Join, and help us!