1 00:00:00,000 --> 00:00:10,270 *32C3 preroll music* 2 00:00:10,270 --> 00:00:13,269 Herald: For several years now, here at the Congress and at the Camp, 3 00:00:13,269 --> 00:00:18,890 we see that we have a GSM network, that we operate our own network, 4 00:00:18,890 --> 00:00:23,080 that we have some services like recently GPRS or 5 00:00:23,080 --> 00:00:28,510 roaming between the different parts of the areas in the Camp. 6 00:00:28,510 --> 00:00:34,490 All of this started around 7 years from now, with a talk at the 25C3; 7 00:00:34,490 --> 00:00:39,810 and a bunch of projects emerged from that over the years. 8 00:00:39,810 --> 00:00:45,219 But wait, there is more. Right now, the people running these services 9 00:00:45,219 --> 00:00:50,050 and running these projects are starting to play around with 3G. 10 00:00:50,050 --> 00:00:55,399 And for everybody who doesn’t know what 3G is, like I did, for like 5 minutes ago, 11 00:00:55,399 --> 00:01:03,740 3G means that we will have HDSPA and data services on our GSM networks. 12 00:01:03,740 --> 00:01:08,770 And I’m very honoured to introduce to you this evening Harald Welte, 13 00:01:08,770 --> 00:01:14,070 a member of our Chaos family for several years now, known maybe from 14 00:01:14,070 --> 00:01:20,770 the Kernel development. I first read his name while debugging a chip card driver 15 00:01:20,770 --> 00:01:25,270 that stated ‘All bugs introduced by…’ – this guy over there. 16 00:01:25,270 --> 00:01:29,170 So, other people may know him from gpl-violations.org, 17 00:01:29,170 --> 00:01:33,960 where they try to enforce the GPL. So. Please welcome 18 00:01:33,960 --> 00:01:36,460 Harald Welte, and… the stage is yours! 19 00:01:36,460 --> 00:01:44,830 *applause* 20 00:01:44,830 --> 00:01:48,680 LaForge: Hi. Welcome everyone to this talk about, well, 21 00:01:48,680 --> 00:01:52,410 running your own GSM network, or running your own 3G network, rather, 22 00:01:52,410 --> 00:01:56,810 sorry for that. And in more technical terms, the slide titles 23 00:01:56,810 --> 00:02:00,969 with lots of acronyms as it is customary in the telecom world. 24 00:02:00,969 --> 00:02:05,640 So forgive me if there’s too many acronyms, but I didn’t invent them, 25 00:02:05,640 --> 00:02:11,910 I just try to use them whenever appropriate. Okay. So, let’s start 26 00:02:11,910 --> 00:02:17,720 with a little bit of a history of open source in mobile communication protocols. 27 00:02:17,720 --> 00:02:20,290 You have to remember that we started about 28 00:02:20,290 --> 00:02:25,470 16 years after the proprietary implementations, so the GSM network 29 00:02:25,470 --> 00:02:29,140 that we are running here at the event, or that 30 00:02:29,140 --> 00:02:34,610 we started to run 7 years ago, started 16 years after GSM networks were run first 31 00:02:34,610 --> 00:02:39,710 in the public in Europe, so, at public operators. So we’re really, really late, 32 00:02:39,710 --> 00:02:44,780 and if you want to compare the status of open source mobile communications 33 00:02:44,780 --> 00:02:49,239 with open source operating system, then I would say we are about where Linux was 34 00:02:49,239 --> 00:02:54,069 in ’94 or ’95. So, very far from today, for those of you who are old enough 35 00:02:54,069 --> 00:02:58,730 to remember these days. So, I would say “capable but not taken seriously” 36 00:02:58,730 --> 00:03:02,720 is sort of the general status. The developer community 37 00:03:02,720 --> 00:03:07,629 working on these projects is still very small. There’s a limited adoption 38 00:03:07,629 --> 00:03:13,470 in the market and the users, often in niche applications, 39 00:03:13,470 --> 00:03:18,450 but nevertheless it is functional. So, if we look a little bit at the timeline, 40 00:03:18,450 --> 00:03:22,629 2008 we had the talk about “Running your own GSM network” 41 00:03:22,629 --> 00:03:28,200 with a huge Siemens base station weighing I think 28 kg… 42 00:03:28,200 --> 00:03:30,540 Did my microphone…? No, it works, sorry. 43 00:03:30,540 --> 00:03:35,239 …weighing 28 kg and bulky old equipment 44 00:03:35,239 --> 00:03:38,629 not using TCP/IP but using E1 lines etc. 45 00:03:38,629 --> 00:03:42,760 Over the years we added more and more BTS model vendors. Basically it means 46 00:03:42,760 --> 00:03:46,961 we can use Ericsson and Nokia and other equipment to actually 47 00:03:46,961 --> 00:03:52,689 run these GSM networks today. People have been working on GPRS support 48 00:03:52,689 --> 00:03:58,260 in a couple of sub projects called OsmoSGSN, OpenGGSN, 49 00:03:58,260 --> 00:04:03,550 also the OsmoPCU project, so we’ve been growing the stack downwards, 50 00:04:03,550 --> 00:04:08,040 also basically implementing the software inside such a BTS, 51 00:04:08,040 --> 00:04:12,019 which we call OsmoBTS. There are some production deployments 52 00:04:12,019 --> 00:04:16,470 – all spellings my mistake, by the way, as obviously – so, 53 00:04:16,470 --> 00:04:19,858 production deployments in niche applications such as maritime markets. 54 00:04:19,858 --> 00:04:24,900 So, if today you are on a ferry or on a cruise ship and you use GSM services, the 55 00:04:24,900 --> 00:04:30,350 probability that you’re using OpenBSC and associated projects in the background is 56 00:04:30,350 --> 00:04:36,800 very strong. There are hundreds of vessels using our software today. Now, then we… 57 00:04:36,800 --> 00:04:43,270 *applause* 58 00:04:43,270 --> 00:04:46,600 …then we moved on the telephone side, so we thought, well, you know, 59 00:04:46,600 --> 00:04:50,750 network side GSM in one thing, but let’s do the phone as well, that was OsmocomBB, 60 00:04:50,750 --> 00:04:54,740 started in 2010. We did improvements over the years, more and more 61 00:04:54,740 --> 00:05:00,199 completed the stack, but it’s really all only old GSM/GPRS technology 62 00:05:00,199 --> 00:05:04,669 until very recently. So in 2015, 15 years again 63 00:05:04,669 --> 00:05:09,590 after the first commercial deployment of GPRS in a public network, 64 00:05:09,590 --> 00:05:13,730 we start to have an open source implementation of EDGE, and that has just 65 00:05:13,730 --> 00:05:18,310 started like 2 or 3 months ago. So again, 15..16 years late compared to 66 00:05:18,310 --> 00:05:23,020 what happens in the proprietary world. Ok. But… 67 00:05:23,020 --> 00:05:28,270 this talk is not about EDGE, which is 2.75G, if you want to speak 68 00:05:28,270 --> 00:05:35,330 in generation numbers. Today we’re talking about 3G and 3.5G. 69 00:05:35,330 --> 00:05:39,690 And there’s a bit of ambivalence with that subject because, well, 70 00:05:39,690 --> 00:05:43,169 today, if you talk to people in the industry, they will say: “Ah, who cares 71 00:05:43,169 --> 00:05:47,449 about 3G, you know, it’s dead anyway!”. We have already today at the point 72 00:05:47,449 --> 00:05:51,139 where we have ‘Peak 3G’, so in the next few years, 73 00:05:51,139 --> 00:05:54,600 the number of subscribers and the number of networks offering 3G services 74 00:05:54,600 --> 00:05:58,770 is no longer growing, it’s basically stagnating and 75 00:05:58,770 --> 00:06:03,160 will turn downwards in the near future. So LTE/4G networks 76 00:06:03,160 --> 00:06:08,979 is basically what everyone is hot about. The other reason not to look at 3G 77 00:06:08,979 --> 00:06:12,979 is that it’s mind-bogglingly complex. It’s not a single telephony system, 78 00:06:12,979 --> 00:06:17,490 it’s actually a toolbox to build arbitrary telephony systems. 79 00:06:17,490 --> 00:06:21,349 And if you really wanted to start implementing it from scratch 80 00:06:21,349 --> 00:06:27,449 including all the lower layers, including the PHY, including the Layer 2 etc. 81 00:06:27,449 --> 00:06:32,669 I think it would be a waste of a lot of time, actually. So we do what we did 82 00:06:32,669 --> 00:06:37,319 with the GSM networks back then, we used proprietary base station hardware, 83 00:06:37,319 --> 00:06:40,539 and we implement the higher level protocols, and then, if needed and 84 00:06:40,539 --> 00:06:44,470 if there’s interest and contributions etc. we drive open source further 85 00:06:44,470 --> 00:06:50,199 down the stack and also into the actual cells. 86 00:06:50,199 --> 00:06:55,319 So, one term that’s going to be used here 87 00:06:55,319 --> 00:06:58,910 in this context is ‘femtocells’. Quite some number of people may have heard 88 00:06:58,910 --> 00:07:02,800 about femtocells before. In technical terms it’s a base station – which is 89 00:07:02,800 --> 00:07:08,830 called NodeB in the UMTS language world – and a radio network controller, 90 00:07:08,830 --> 00:07:13,280 which is the BSC, the base station controller – in UMTS in one box. 91 00:07:13,280 --> 00:07:17,840 And using such femtocells or similar hardware is much easier to interface 92 00:07:17,840 --> 00:07:21,699 than if you would use a regular base station. So that basically is 93 00:07:21,699 --> 00:07:26,780 sort of a path that we think is doable without spending man-years of implementing 94 00:07:26,780 --> 00:07:32,859 obscure and complex transport channels and bundles and mappings and whatnot. 95 00:07:32,859 --> 00:07:37,069 There’s been a couple of talks about doing creative stuff with femtocells. 96 00:07:37,069 --> 00:07:43,890 There’ve been talks by Kevin [Redon], Nico [Golde] and Ravishankar in 2010/2011 97 00:07:43,890 --> 00:07:49,530 about security. There’s been a recent presentation this year at Black Hat 98 00:07:49,530 --> 00:07:53,659 in the United States called ‘Adventures in Femtoland’. 99 00:07:53,659 --> 00:07:58,810 Those talks focus on basically, well, the security of the femtocell itself, 100 00:07:58,810 --> 00:08:03,330 breaking into such a cell, rooting it, owning it, doing creative things 101 00:08:03,330 --> 00:08:07,389 and then from there e.g. attacking the mobile operator or 102 00:08:07,389 --> 00:08:12,190 attacking the privacy of subscribers by using such a femtocell 103 00:08:12,190 --> 00:08:17,180 as a man-in-the-middle platform e.g. But to my knowledge nobody has been talking 104 00:08:17,180 --> 00:08:21,610 about free software or open source software, to run a network with 105 00:08:21,610 --> 00:08:27,870 such femtocells or similar equipment. So, if we look at the UMTS architecture, 106 00:08:27,870 --> 00:08:32,580 like you find it in a textbook or like in this particular slide or drawing 107 00:08:32,580 --> 00:08:38,070 from Kevin, you will find several network elements 108 00:08:38,070 --> 00:08:42,659 all over the network, so lots of different elements 109 00:08:42,659 --> 00:08:48,460 with lots of different acronyms. We have a Mobile Equipment (ME) 110 00:08:48,460 --> 00:08:52,470 which is the telephone. We have a radio interface called the Uu interface. 111 00:08:52,470 --> 00:08:56,650 We have actual base stations called NodeB and we have 112 00:08:56,650 --> 00:09:01,110 a base station controller that’s called the Radio Network Controller, the RNC; 113 00:09:01,110 --> 00:09:06,690 and then here we have, on this boundary we have IuCS and IuPS interfaces 114 00:09:06,690 --> 00:09:10,650 that interface the Base Station Controllers 115 00:09:10,650 --> 00:09:14,470 with the core of the network which is the Mobile Switching Center, 116 00:09:14,470 --> 00:09:18,420 the Media Gateway, the Serving GPRS Support Node, and then other elements 117 00:09:18,420 --> 00:09:23,880 here. And this is actually the interface line which we have been implementing 118 00:09:23,880 --> 00:09:29,360 in recent months at the boundary between the Access Network, 119 00:09:29,360 --> 00:09:34,290 the Radio Access Network and the Core Network on the other side of the slide. 120 00:09:34,290 --> 00:09:39,970 So, well, you could just get a NodeB and implement the protocol Iub. 121 00:09:39,970 --> 00:09:43,790 This is what we did with GSM before, we basically started here. We only got 122 00:09:43,790 --> 00:09:48,880 the actual BTS or NodeB and we implemented that protocol. 123 00:09:48,880 --> 00:09:52,910 However, well, this protocol in UMTS is extremely complex 124 00:09:52,910 --> 00:09:56,960 and fairly low down the stack. Just to give you an idea: 125 00:09:56,960 --> 00:10:01,710 every single voice codec frame from a voice call that you receive 126 00:10:01,710 --> 00:10:05,460 has 3 different classes of bits, and each class of bits gets put into 127 00:10:05,460 --> 00:10:09,800 different UDP messages, and then you get basically 3 flows of UDP messages, 128 00:10:09,800 --> 00:10:13,750 and you need to synchronize and inter-mangle (?) and re-interleave 129 00:10:13,750 --> 00:10:18,300 those bits in order to get to a speech codec frame. So it’s… and I’m not even 130 00:10:18,300 --> 00:10:21,170 talking about the signalling plane (?). So the lower you get in UMTS the more 131 00:10:21,170 --> 00:10:24,740 complex it gets, let’s try to avoid that. And that’s the kind of complexity 132 00:10:24,740 --> 00:10:30,940 that I like to avoid. This is from the official spec about the UMTS spectrum. 133 00:10:30,940 --> 00:10:36,020 It’s an extremely obvious and self-explanatory slide, so I’ll… 134 00:10:36,020 --> 00:10:38,590 *laughter* I leave it at this and say, yeah, 135 00:10:38,590 --> 00:10:44,070 that’s not what we want to do. So, we… how can I say, we… 136 00:10:44,070 --> 00:10:50,310 Even though we don’t like it we just use proprietary blobs to implement that. Now, 137 00:10:50,310 --> 00:10:53,780 the protocol stacking on those interfaces that we actually want to implement 138 00:10:53,780 --> 00:10:58,260 is what I’m going to look at the next couple of slides. The Iu interface, 139 00:10:58,260 --> 00:11:01,910 and by the name, Iu has no specific meaning, it’s just the Iu interface, 140 00:11:01,910 --> 00:11:06,180 you could say the A, the B, the C, the Z interface – it’s the ‘Iu interface’. 141 00:11:06,180 --> 00:11:10,960 It’s split in CS and PS, that’s circuit- switched and packet-switched. 142 00:11:10,960 --> 00:11:16,040 Circuit-switched means telephony services and packet-switched means data services. 143 00:11:16,040 --> 00:11:20,370 And we’re going to look at the protocol stacking of those interfaces 144 00:11:20,370 --> 00:11:25,430 in the next couple of slides. Originally, remember, well, maybe a good time 145 00:11:25,430 --> 00:11:29,640 to go back in history, in sort of history of mobile communications, which 146 00:11:29,640 --> 00:11:35,570 should be taught at every school, I think, including archeology of protocols, 147 00:11:35,570 --> 00:11:41,890 which… no, honestly… *laughter and applause* 148 00:11:41,890 --> 00:11:46,150 You need to do protocol archeology if you want to implement certain interfaces 149 00:11:46,150 --> 00:11:50,390 today. So, on my blog you can find some posts about a couple of years ago 150 00:11:50,390 --> 00:11:55,980 where I had to basically write a parser for Microsoft Word for DOS text files 151 00:11:55,980 --> 00:12:00,060 to automatically extract snippets of ASN.1 syntax for MAP version 1 152 00:12:00,060 --> 00:12:05,630 which is still used today. So, it’s… yes, it… sometimes you really need to do 153 00:12:05,630 --> 00:12:09,790 archeology. So anyway, not for this, but any… when UMTS was specified, 154 00:12:09,790 --> 00:12:14,560 this is the late 90s, this is when the first dotcom bubble basically got big, 155 00:12:14,560 --> 00:12:18,710 this is when billions and billions of Euros or Dollars 156 00:12:18,710 --> 00:12:22,040 or whatever unit of currency was poured into the development of the 157 00:12:22,040 --> 00:12:26,490 ‘universal telephony mobile system’, the… sorry, the 158 00:12:26,490 --> 00:12:30,930 ‘universal mobile telephony system’, the UMTS, which should basically 159 00:12:30,930 --> 00:12:35,500 be the grand unifying theory of mobile communications. 160 00:12:35,500 --> 00:12:42,260 And it was built on top of ATM, of course, because ATM was the most shiny and 161 00:12:42,260 --> 00:12:47,080 brightest technology in the late 90s that all the universities were researching. 162 00:12:47,080 --> 00:12:50,740 So, if you look at the classical protocol stacking and you look at the individual 163 00:12:50,740 --> 00:12:56,740 interfaces; the Uu is the radio interface, Iub is between the NodeB and RNC, 164 00:12:56,740 --> 00:12:59,910 but this is… the IuPS is actually what we want to implement. So basically 165 00:12:59,910 --> 00:13:03,570 the left side of this slide is what is implemented 166 00:13:03,570 --> 00:13:08,060 in the proprietary base stations or femtocells that we are using, 167 00:13:08,060 --> 00:13:12,040 and the right-hand side of that slide is what we are implementing. 168 00:13:12,040 --> 00:13:15,740 So we need to implement the protocol stackings here. As you can see 169 00:13:15,740 --> 00:13:20,940 the protocol stack is deep and has many acronyms. 170 00:13:20,940 --> 00:13:24,930 So, to make things more complicated 171 00:13:24,930 --> 00:13:28,450 the femtocells that you can find on the market are slightly different 172 00:13:28,450 --> 00:13:32,580 from the real, normal 3G architecture, 173 00:13:32,580 --> 00:13:36,240 so if you try to compare this slide with that slide, 174 00:13:36,240 --> 00:13:40,490 you will find some differences here. The difference is that they introduce 175 00:13:40,490 --> 00:13:45,650 a security gateway which is basically just ITU and 3GPP language 176 00:13:45,650 --> 00:13:50,190 for ‘IPsec gateway’, 177 00:13:50,190 --> 00:13:54,770 and you have a HomeNodeB gateway that doesn’t really do anything useful, 178 00:13:54,770 --> 00:13:57,961 rather than putting messages from one protocol stack on the left 179 00:13:57,961 --> 00:14:00,910 to another protocol stack on the right with the underlying protocols 180 00:14:00,910 --> 00:14:05,530 doing exactly the same thing but being differently encoded. 181 00:14:05,530 --> 00:14:09,141 And this is what you can see here, basically, the HomeNodeB gateway 182 00:14:09,141 --> 00:14:13,300 which is part of the software that we implemented. You can see basically, 183 00:14:13,300 --> 00:14:17,600 well, you have RANAP, this is the protocol 184 00:14:17,600 --> 00:14:20,660 that really is sort of what we’re interested in, 185 00:14:20,660 --> 00:14:24,920 the Radio Access Network Application Part; and RANAP, 186 00:14:24,920 --> 00:14:29,250 in order to implement that, there’s several other protocols underneath. 187 00:14:29,250 --> 00:14:33,440 And on the femtocell which is called HNodeB, the HomeNodeB, because, 188 00:14:33,440 --> 00:14:37,690 well, ‘femtocells’ is a marketing term and specs can never use marketing terms, 189 00:14:37,690 --> 00:14:42,850 so they have technical terms. So, the femtocell 190 00:14:42,850 --> 00:14:51,270 basically encapsulates RANAP into RUA, the ‘RANAP User…’, 191 00:14:51,270 --> 00:14:56,120 what was it? Sorry, …Adaptation, yes. The ‘RANAP User Adaptation’. 192 00:14:56,120 --> 00:15:00,510 So the ‘Radio Access Network Application Part User Adaptation’, 193 00:15:00,510 --> 00:15:04,630 on top of the SCTP, the Streaming Control Transfer Protocol, 194 00:15:04,630 --> 00:15:09,180 which some may know is a protocol that’s on the same layer as TCP or UDP 195 00:15:09,180 --> 00:15:13,110 but has different properties. And 196 00:15:13,110 --> 00:15:17,180 this RUA is implemented than (?) the HomeNodeB Gateway where it is replaced 197 00:15:17,180 --> 00:15:21,950 by M3UA and SCCP. And basically the same RANAP message 198 00:15:21,950 --> 00:15:26,430 gets passed from left to right. So it’s really… you could think like… 199 00:15:26,430 --> 00:15:30,730 think of it like an IPv6 to IPv4 proxy. 200 00:15:30,730 --> 00:15:35,670 If that’s more an area that you’re more familiar with. Okay. 201 00:15:35,670 --> 00:15:41,260 So, I said there are some differences between an actual, regular, 202 00:15:41,260 --> 00:15:44,970 old-fashioned UMTS base station, like your public operator would use it 203 00:15:44,970 --> 00:15:49,090 and the HomeNodeB, or femtocell, that we like to use in this project, 204 00:15:49,090 --> 00:15:53,850 at least initially. And I said the main difference is that the RNC, 205 00:15:53,850 --> 00:15:57,510 the Radio Network Controller, is built-in, so a lot of the lower layer protocols 206 00:15:57,510 --> 00:16:00,290 are terminated, and we don’t need to worry about that. If we look 207 00:16:00,290 --> 00:16:04,880 at the protocol stacking again there is a lot of protocol layers here, 208 00:16:04,880 --> 00:16:09,910 you can see the MAC layer, the RLC layer, the RRC layer… and all the PHYsical stuff 209 00:16:09,910 --> 00:16:14,190 underneath is all basically already implemented because it’s part of the 210 00:16:14,190 --> 00:16:19,100 femtocell, in this case. So the protocol stacking now looks a little bit like this. 211 00:16:19,100 --> 00:16:24,030 We have the HomeNodeB, and the HomeNodeB gateway, 212 00:16:24,030 --> 00:16:28,000 and then our core network elements already. So the SGSN and the GGSN, 213 00:16:28,000 --> 00:16:33,190 if you’ve looked at GSM in the past, or GPRS, even the software that exists today 214 00:16:33,190 --> 00:16:37,910 and for many years in the Osmocom project, we have implementations of those. 215 00:16:37,910 --> 00:16:39,950 What we are missing is the HomeNodeB gateway, 216 00:16:39,950 --> 00:16:43,540 and is all the fancy new protocols here. And some modifications. 217 00:16:43,540 --> 00:16:50,750 So, well, what do we need to do to actually implement? 218 00:16:50,750 --> 00:16:54,920 This Iuh protocol. As I said there’s the different protocol layers – there is RUA, 219 00:16:54,920 --> 00:17:00,000 there is the RANAP protocol, and the HNBAP protocol. 220 00:17:00,000 --> 00:17:04,199 Let’s look at those protocols, what they do, and how can we implement them. 221 00:17:04,199 --> 00:17:08,030 I’m skipping a few slides in the middle because it’s illustrative 222 00:17:08,030 --> 00:17:11,650 if somebody wants to check the slides later but it would go into too much detail 223 00:17:11,650 --> 00:17:17,510 at this point. So the RANAP User Adaptation layer 224 00:17:17,510 --> 00:17:20,980 – given the spec number above there, so if you look for that online 225 00:17:20,980 --> 00:17:25,740 you can find the actual spec – is a very simple connection-oriented layer 226 00:17:25,740 --> 00:17:30,230 that provides you the notion of a connection 227 00:17:30,230 --> 00:17:34,070 over a datagram transport layer underneath. 228 00:17:34,070 --> 00:17:38,650 It has very, very few operations and message types, 229 00:17:38,650 --> 00:17:43,710 including CONNECT which – well, surprisingly – sets up a new connection. 230 00:17:43,710 --> 00:17:47,810 DIRECT TRANSFER which transfers data inside a connection. 231 00:17:47,810 --> 00:17:51,140 DISCONNECT – to terminate a connection. And CONNECTIONLESS TRANSFER 232 00:17:51,140 --> 00:17:54,860 to transfer data outside of a connection. And, of course, an ERROR INDICATION, 233 00:17:54,860 --> 00:17:59,940 in case something goes wrong. So we can have multiple connections in parallel 234 00:17:59,940 --> 00:18:06,310 over a signalling link. And they are distinguished by a 24 bit context ID, 235 00:18:06,310 --> 00:18:09,990 to differentiate those multiple parallel connections. Think of it like 236 00:18:09,990 --> 00:18:13,890 a port number. In the case of UDP, or whatever else you might want 237 00:18:13,890 --> 00:18:18,300 to compare it to. So, this… if you look at this and you read the specs like 238 00:18:18,300 --> 00:18:22,810 “Oh, pfff, you know, it’s nothing, it’s like you implement like 5..6 message types 239 00:18:22,810 --> 00:18:27,010 and that’s it”… well, there’s a bit more details to that, 240 00:18:27,010 --> 00:18:34,290 but we’ll get back later to this. The HomeNodeB Application… 241 00:18:34,290 --> 00:18:38,920 no, HomeNodeB Application Part, the HNBAP protocol 242 00:18:38,920 --> 00:18:42,830 has a couple of more transactions which basically serve 243 00:18:42,830 --> 00:18:45,790 for the registration of the cell to the network, 244 00:18:45,790 --> 00:18:50,430 the registration of user equipment, UE, that’s your mobile phone, 245 00:18:50,430 --> 00:18:54,940 and some additional messages. 246 00:18:54,940 --> 00:18:58,860 So HNB is the HomeNodeB registration; we have Registration REQUEST, ACCEPT, 247 00:18:58,860 --> 00:19:02,810 REJECT, De-registration, we have the same for mobile phones. 248 00:19:02,810 --> 00:19:07,560 We have some more detailed transactions that I’m going to skip. 249 00:19:07,560 --> 00:19:12,560 But also it’s really very simple, conceptially, it’s not very complex, 250 00:19:12,560 --> 00:19:15,450 you don’t have like massive state machines or anything like that. 251 00:19:15,450 --> 00:19:19,510 Very few, very limited messages. 252 00:19:19,510 --> 00:19:23,630 Then we look at RANAP. That’s the Radio Access Network Application Part. 253 00:19:23,630 --> 00:19:26,880 This is where your actual signalling messages from the phone 254 00:19:26,880 --> 00:19:30,750 are tunneled through. So if your phone registers to the network 255 00:19:30,750 --> 00:19:35,050 you may have heard the term LOCATION UPDATE where the phone basically 256 00:19:35,050 --> 00:19:38,670 registers to the network or updates its location with the network. 257 00:19:38,670 --> 00:19:43,980 That’s the first message you would see, encapsulated inside RANAP, and 258 00:19:43,980 --> 00:19:49,250 transported to the core network element. Also things like PDP context activation, 259 00:19:49,250 --> 00:19:53,430 if you activate a data connection to a certain APN over cellular protocols, 260 00:19:53,430 --> 00:19:59,850 all this is encapsulated in the RANAP layer. 261 00:19:59,850 --> 00:20:03,760 Also the number of messages that we actually need is extremely limited. 262 00:20:03,760 --> 00:20:08,240 Again, it’s a very short list, it’s not like hundreds of messages. 263 00:20:08,240 --> 00:20:12,230 But the messages themselves can be quite complex. With nesting levels 264 00:20:12,230 --> 00:20:17,410 up to 12..14 layers deep. But we’ll see that later on. 265 00:20:17,410 --> 00:20:21,200 So we have a couple of transactions. RESET – well, I don’t need to explain – 266 00:20:21,200 --> 00:20:26,350 it’s a Reset. INITIAL UE MESSAGE means a new phone has connected, 267 00:20:26,350 --> 00:20:29,520 and it has sent us the first message that this phone has transmitted, 268 00:20:29,520 --> 00:20:33,850 that’s why it’s ‘initial’ message. DIRECT TRANSFER is all the follow-up transfer. 269 00:20:33,850 --> 00:20:38,220 IU RELEASE means we’re releasing a connection. Some commands 270 00:20:38,220 --> 00:20:43,750 to configure the security, the ciphering, the encryption. A PAGING command 271 00:20:43,750 --> 00:20:47,680 by which the network can initiate a transaction to the phone. 272 00:20:47,680 --> 00:20:52,010 And RAB ASSIGNMENT. RAB is the Radio Access Bearer 273 00:20:52,010 --> 00:20:56,640 which is basically an abstract notion 274 00:20:56,640 --> 00:21:03,310 of a bearer able to transport communication. 275 00:21:03,310 --> 00:21:07,020 If you come from classic telephony the bearer was 276 00:21:07,020 --> 00:21:11,030 an analog voice channel. If you go to ISDN the bearer is 277 00:21:11,030 --> 00:21:14,930 a 64kbps synchronous channel 278 00:21:14,930 --> 00:21:19,470 where you have Alaw Ulaw (?) inside, and voice data. 279 00:21:19,470 --> 00:21:24,790 Or you have some HTLC (?) or X75 or whatever data inside. 280 00:21:24,790 --> 00:21:29,830 In GSM the bearer is typically voice bearers, 281 00:21:29,830 --> 00:21:36,020 with different voice codecs. The same it is in UMTS. 282 00:21:36,020 --> 00:21:39,940 And basically you can configure those bearers in UMTS because 283 00:21:39,940 --> 00:21:45,660 that’s a very universal and flexible part of the system. 284 00:21:45,660 --> 00:21:48,880 Now, one of the protocols we have seen in the stack – I’m just going back 285 00:21:48,880 --> 00:21:55,480 a couple of slides to reiterate – that is the SCCP which is introduced here. 286 00:21:55,480 --> 00:21:58,980 The ‘Signalling Connection Control Part’, 287 00:21:58,980 --> 00:22:03,450 if I remember correctly. It’s a protocol that’s used a lot in core networks 288 00:22:03,450 --> 00:22:09,360 of mobile operators. So if you look at Roaming interfaces, 289 00:22:09,360 --> 00:22:14,030 at classic SS7 interfaces – think of the SS7 security talks etc. we’ve had here 290 00:22:14,030 --> 00:22:19,120 at CCC events a lot of times – this is a protocol that’s very often used 291 00:22:19,120 --> 00:22:24,990 in a lot of different parts of telecom. But the problem is – 292 00:22:24,990 --> 00:22:29,820 everywhere except [at] this particular point in UMTS and GSM 293 00:22:29,820 --> 00:22:33,580 it is used only in connection-less mode; and this is the only point 294 00:22:33,580 --> 00:22:38,450 where it uses connection-oriented SCCP. And therefor none of the existing 295 00:22:38,450 --> 00:22:41,660 free software implementations is implemented. You can look to Yate, 296 00:22:41,660 --> 00:22:45,000 you can look to the libosmo-sccp, the library that we have in 297 00:22:45,000 --> 00:22:49,980 the Osmocom project. You can look at the Mobicents Java stack 298 00:22:49,980 --> 00:22:54,650 for these protocols. You can look at the osmo_sccp Erlang code. 299 00:22:54,650 --> 00:22:57,810 Basically no implementation exists, so we also had to 300 00:22:57,810 --> 00:23:03,720 implement that part, at least to the point, 301 00:23:03,720 --> 00:23:07,440 to those features that are required. But once we have implemented 302 00:23:07,440 --> 00:23:11,580 all these protocols – RUA, SCCP, 303 00:23:11,580 --> 00:23:15,120 the RANAP, the HNBAP, then 304 00:23:15,120 --> 00:23:20,730 we need to somehow interface those protocols with the existing 305 00:23:20,730 --> 00:23:25,070 network elements that we have for GSM. And 306 00:23:25,070 --> 00:23:29,480 there are sort of several challenges in this area, 307 00:23:29,480 --> 00:23:34,480 in what people know as the OpenBSC project. 308 00:23:34,480 --> 00:23:38,019 Actually the program that most people use is called OsmoNITB 309 00:23:38,019 --> 00:23:41,900 – the network in the box – which is called ‘network in the box’ because it implements 310 00:23:41,900 --> 00:23:47,290 all the network elements that you need in one box, or in one program. 311 00:23:47,290 --> 00:23:50,520 Unfortunately we need to separate those individual pieces which are 312 00:23:50,520 --> 00:23:57,190 all in one blob, in order to interface at the point where we want to interface. 313 00:23:57,190 --> 00:24:00,780 So this separation of the MSC part and the BSC part needs to be done 314 00:24:00,780 --> 00:24:05,220 inside the ‘network in the box’. We need the UMTS authentication 315 00:24:05,220 --> 00:24:08,270 and key agreement support, 316 00:24:08,270 --> 00:24:13,190 and we need the different protocols that I just mentioned 317 00:24:13,190 --> 00:24:17,830 and link them in on the SGSN side. 318 00:24:17,830 --> 00:24:22,710 For the data services we need to introduce some extraction 319 00:24:22,710 --> 00:24:28,390 to basically differentiate the packet data connections coming from GPRS networks 320 00:24:28,390 --> 00:24:33,200 and those coming from the new 3G networks or base stations 321 00:24:33,200 --> 00:24:37,560 that we are supporting. But that’s all manageable. 322 00:24:37,560 --> 00:24:43,400 Now, the question is, 323 00:24:43,400 --> 00:24:47,330 do we really want to go for the full stack as it has been described, 324 00:24:47,330 --> 00:24:53,980 or can we take some shortcuts, do we really need to implement the full SCCP, 325 00:24:53,980 --> 00:24:58,750 for example? Do we need to implement M3UA, 326 00:24:58,750 --> 00:25:03,520 which is another protocol layer in there? Can we basically simplify that? 327 00:25:03,520 --> 00:25:07,960 The initial idea was – if we go back to that slide – 328 00:25:07,960 --> 00:25:11,190 to reduce the complexity, I already mentioned this HomeNodeB gateway 329 00:25:11,190 --> 00:25:15,460 which basically passes RANAP from left to right, and just changes 330 00:25:15,460 --> 00:25:22,460 the underlying encapsulation. Why don’t we just continue using RUA up into the SGSN 331 00:25:22,460 --> 00:25:26,440 and thereby avoid having to do SCCP and M3UA, 332 00:25:26,440 --> 00:25:30,220 avoid having to implement more protocols without having any functional gain. 333 00:25:30,220 --> 00:25:33,720 I mean it would just work the same way if we take RUA and we take it all the way 334 00:25:33,720 --> 00:25:37,640 into the SGSN. So there’s been some thinking along those lines 335 00:25:37,640 --> 00:25:43,760 but the idea was to… 336 00:25:43,760 --> 00:25:47,880 …go sort of in a compromise so what we’re using here is yet another protocol 337 00:25:47,880 --> 00:25:52,350 called SUA, the SCCP User Adaption. 338 00:25:52,350 --> 00:25:55,750 And that replaces those 2 layers and keeps things a little bit simpler 339 00:25:55,750 --> 00:26:03,310 from the implementation side. OK, now we have all these different protocol layers, 340 00:26:03,310 --> 00:26:07,510 and the integration into the core network elements. Now the fun starts. 341 00:26:07,510 --> 00:26:11,420 We have a plan, we know what needs to be done, 342 00:26:11,420 --> 00:26:15,090 we know what needs to be done, and now we actually need to do it. 343 00:26:15,090 --> 00:26:20,470 So the theory was easy – read a couple of specs, find out 6..7 messages, 344 00:26:20,470 --> 00:26:24,510 not too many transactions, no complex state machines. Okay, now, 345 00:26:24,510 --> 00:26:27,820 a lot of the more modern telecom protocols use ASN.1 syntax. 346 00:26:27,820 --> 00:26:34,640 It’s an abstract syntax notation for defining data structures 347 00:26:34,640 --> 00:26:39,910 or procedures to be communicated, and then you can use code generation tools 348 00:26:39,910 --> 00:26:44,270 to generate code in your favorite language from this syntax 349 00:26:44,270 --> 00:26:46,809 doing all the marshalling and demarshalling of the messages. 350 00:26:46,809 --> 00:26:51,260 That’s at least what’s the idea. This is very different from what we used to do 351 00:26:51,260 --> 00:26:55,640 in the GSM world because GSM was specified in the late 1980s. 352 00:26:55,640 --> 00:26:59,770 ASN.1 didn’t exist to my knowledge back then, or at least they didn’t know about it, 353 00:26:59,770 --> 00:27:04,670 and/or they thought it was not something that you could do in a mobile phone 354 00:27:04,670 --> 00:27:07,431 at that time. Think about 8 bit microcontrollers and whatnot, 355 00:27:07,431 --> 00:27:12,430 what they were using these days. So the GSM messages, 356 00:27:12,430 --> 00:27:16,000 basically you have…, you look at the spec and you see “Oh, there’s one byte this, 357 00:27:16,000 --> 00:27:18,790 then there’s a 2 byte length field, and then there’s that”. And you need 358 00:27:18,790 --> 00:27:24,150 to implement that basically in your code, based on the textual representation. 359 00:27:24,150 --> 00:27:28,150 Now, for UMTS almost all the protocols and particularly these 360 00:27:28,150 --> 00:27:33,290 that we’re looking [at] here are specified in abstract syntax notation which, well, 361 00:27:33,290 --> 00:27:36,300 on the one hand side you would say: “Oh yes, great, now we don’t need to write 362 00:27:36,300 --> 00:27:40,650 all this message encoding and decoding code, and then we end up interpreting 363 00:27:40,650 --> 00:27:45,470 the spec different[ly] and we have sort of incompatible messages and whatnot”. 364 00:27:45,470 --> 00:27:50,830 That’s true to some extent, okay. Now what you need to know about ASN.1 is, 365 00:27:50,830 --> 00:27:55,040 there are different encoding rules that define how the abstract syntax notation 366 00:27:55,040 --> 00:27:59,830 gets converted into a concrete binary representation. There is a 367 00:27:59,830 --> 00:28:04,710 Basic Encoding Rules (BER), there is all kinds of encoding rules, 368 00:28:04,710 --> 00:28:09,809 there is even JSON encoding rules these days. There’s also XML encoding rules. 369 00:28:09,809 --> 00:28:14,470 But what’s used here in these specs is called ‘aligned Packed Encoding Rules’ 370 00:28:14,470 --> 00:28:19,740 (APER). This is a particular encoding rule that was not… or is not supported 371 00:28:19,740 --> 00:28:26,450 by any of the ASN.1 compilers that exist in open source that generate C code. 372 00:28:26,450 --> 00:28:30,960 So we first had to teach the ASN.1 compiler this encoding rule. 373 00:28:30,960 --> 00:28:34,720 And the second big problem is the ASN.1 syntax used in those protocol specs 374 00:28:34,720 --> 00:28:39,700 uses a construct called ‘Information Object Classes’, which is sort of… 375 00:28:39,700 --> 00:28:48,000 well, you know, an interesting way how to express or how to have… 376 00:28:48,000 --> 00:28:53,090 a different notation on how to construct those messages and how to construct 377 00:28:53,090 --> 00:28:58,309 operations that have like an initiating request, a ‘successful’ response, 378 00:28:58,309 --> 00:29:02,770 a ‘successful error’ outcome or something like that. And you can express that 379 00:29:02,770 --> 00:29:06,020 in a really nice way but then you need a compiler and a code generator 380 00:29:06,020 --> 00:29:12,240 that can parse that, and that’s really difficult in the free software world 381 00:29:12,240 --> 00:29:17,470 within some constraints. I’ll get into the details. Now the next thing is 382 00:29:17,470 --> 00:29:21,080 that the way how they use ASN.1 in these protocol specs 383 00:29:21,080 --> 00:29:24,860 – ASN.1 being the abstract syntax notation – is not abstract enough. 384 00:29:24,860 --> 00:29:30,299 They need to have another abstraction layer. So they use ASN.1 385 00:29:30,299 --> 00:29:34,510 to describe containers, containers for information elements, 386 00:29:34,510 --> 00:29:38,360 containers for messages, containers for lists of information elements 387 00:29:38,360 --> 00:29:42,190 and containers for pairs of information elements. It’s very important. 388 00:29:42,190 --> 00:29:46,490 You cannot just have a list of 2. No, you need to have a pair 389 00:29:46,490 --> 00:29:50,960 that says, well, this is a pair of 2 information elements. Not sure why, 390 00:29:50,960 --> 00:29:55,300 but somebody probably had his reasons for doing so. 391 00:29:55,300 --> 00:30:00,300 Now the point is, basically, you use the ASN.1 syntax 392 00:30:00,300 --> 00:30:03,500 and you generate some code for encoding or decoding and then 393 00:30:03,500 --> 00:30:07,010 you’re not really done at that point. Because then you basically: 394 00:30:07,010 --> 00:30:10,000 “Oh, this is a list of containers”, and then you look into each of the containers 395 00:30:10,000 --> 00:30:13,750 and then call the decoder again for each of the elements in the list. And then 396 00:30:13,750 --> 00:30:17,180 in there there might be another level of containers and you unpack it again, 397 00:30:17,180 --> 00:30:22,280 so it’s a little bit like matryoshka or, you know, these dolls 398 00:30:22,280 --> 00:30:27,920 nested in each other; or somebody sends you a large packet etc. Well, 399 00:30:27,920 --> 00:30:31,720 to illustrate that, if you’ve ever seen ASN.1, this is a relatively simple example 400 00:30:31,720 --> 00:30:37,720 describing authentication couples or triplets or quintuplets. 401 00:30:37,720 --> 00:30:41,770 Basically, the authentication data that’s used for authenticating subscribers 402 00:30:41,770 --> 00:30:45,909 in networks. This is what is used also in GSM. It’s relatively simple, 403 00:30:45,909 --> 00:30:50,640 so it basically tells you, well, there’s an authentication set list which contains 404 00:30:50,640 --> 00:30:54,740 [consists] of a choice of either a triplet or a quintuplet list. Each of those lists 405 00:30:54,740 --> 00:30:58,640 either have a length from 1..5, and then you have basically a sequence which is 406 00:30:58,640 --> 00:31:03,370 sort of struct or a record of the below items in those lists. That is how [it] is 407 00:31:03,370 --> 00:31:08,600 and should look like and how it normally looks like. Now in RANAP 408 00:31:08,600 --> 00:31:13,060 and these protocols they first – as said – they define these containers, they say: 409 00:31:13,060 --> 00:31:17,690 “We have…”. So it reminds me a bit of some mathematicians. It’s like 410 00:31:17,690 --> 00:31:21,260 “We define we have this, and then we have that, and therefore we can construct 411 00:31:21,260 --> 00:31:27,140 such a new structure” and whatnot. So basically, they define first a container 412 00:31:27,140 --> 00:31:32,170 for protocol information elements, protocol IEs. And in the protocol IE 413 00:31:32,170 --> 00:31:36,680 is the actual information element. Each element has an ID, it has a criticality. 414 00:31:36,680 --> 00:31:39,500 The criticality tells you whether, if you do not understand 415 00:31:39,500 --> 00:31:44,080 such an information element, should you ignore it, should you reject it, 416 00:31:44,080 --> 00:31:49,190 should you ignore it but report to the sender that you did not understand it 417 00:31:49,190 --> 00:31:54,370 despite proceeding with your operation, and then the actual value. 418 00:31:54,370 --> 00:31:58,401 And the value is an ANY type which means there is another ASN.1 syntax 419 00:31:58,401 --> 00:32:02,450 in that value that you then need to parse. 420 00:32:02,450 --> 00:32:07,450 So you need to do these 2 steps in the code. You first 421 00:32:07,450 --> 00:32:11,570 unwrap the containers and then you decode what is inside the containers. 422 00:32:11,570 --> 00:32:15,210 So working with ASN.1 really is not as simple and as straightforward 423 00:32:15,210 --> 00:32:19,170 and as automatic as it should be. And you end up with messages looking like this 424 00:32:19,170 --> 00:32:24,309 in Wireshark. So believe it or not, the content, the useful content 425 00:32:24,309 --> 00:32:28,699 of this entire message is 4 bytes here, the c0… 426 00:32:28,699 --> 00:32:37,670 *laughter and applause* 427 00:32:37,670 --> 00:32:42,179 …is the 4 bytes starting from c0, and those people who have seen an IP address, 428 00:32:42,179 --> 00:32:48,170 an IPv4 address in a 192.168. address range will recognize those bytes here 429 00:32:48,170 --> 00:32:52,429 at the end. So the c0 is 192. etc. And in order to communicate 430 00:32:52,429 --> 00:32:56,450 this message actually, this is a message that tells us to which IP address 431 00:32:56,450 --> 00:33:01,060 something has been bound to. In this case it’s the GTP connection for communicating 432 00:33:01,060 --> 00:33:05,809 packet data. And you see all these abstractions and encapsulations 433 00:33:05,809 --> 00:33:09,410 and the nested tree, so it’s… it starts with… well, ok, 434 00:33:09,410 --> 00:33:12,880 this is an outcome. It is an outcome to the Radio Access Bearer Assignment. 435 00:33:12,880 --> 00:33:16,860 “If you do not understand it please reject it”. 436 00:33:16,860 --> 00:33:20,840 We have an Assignment Response. It contains [consists] of a list of one item 437 00:33:20,840 --> 00:33:27,190 of protocol information elements. This one item is a SetupOrModifiedList, 438 00:33:27,190 --> 00:33:30,929 which again has a criticality of ‘Ignore’. If you don’t understand it… 439 00:33:30,929 --> 00:33:34,620 oh no sorry, here it says “If you don’t understand it just ignore it. 440 00:33:34,620 --> 00:33:38,270 Don’t report an error”. It’s quite interesting because you have a message 441 00:33:38,270 --> 00:33:42,110 that only contains one element and it says, well, you should reject the message 442 00:33:42,110 --> 00:33:45,190 if you don’t understand it; but then the information element says: “Oh, if you 443 00:33:45,190 --> 00:33:49,750 don’t understand it please ignore it”. So, okay. 444 00:33:49,750 --> 00:33:53,590 Then inside the SetupOrModifiedList we have one item 445 00:33:53,590 --> 00:33:57,880 which is a protocol IE container with one item 446 00:33:57,880 --> 00:34:00,950 which has an item which is the SetupOrModifiedItem, which is 447 00:34:00,950 --> 00:34:05,460 a Radio Access Bearer Modified Item, which contains 448 00:34:05,460 --> 00:34:11,369 a Radio Access Bearer SetupOrModifiedItem with a Radio Access Bearer ID of 1 449 00:34:11,369 --> 00:34:14,909 and a transport layer address of this. And in case you’re wondering 450 00:34:14,909 --> 00:34:20,310 why the IP address has such binary crap in front – it is 451 00:34:20,310 --> 00:34:25,510 because it’s too difficult to express in ASN.1 that this is an IP address. 452 00:34:25,510 --> 00:34:29,020 You could not just define a type for an IP address. That would be too simple. 453 00:34:29,020 --> 00:34:33,550 No, you need to refer from this specification to another specification, 454 00:34:33,550 --> 00:34:40,460 another 3G specification, which then refers to ITU-T X213 455 00:34:40,460 --> 00:34:45,719 which tells you how you can encode any possible transport layer address 456 00:34:45,719 --> 00:34:50,570 in any possible network protocol on the planet by using a hierarchical structure 457 00:34:50,570 --> 00:34:57,119 like OUI IDs or something like that. And ‘35’ means it’s an IETF allocated address. 458 00:34:57,119 --> 00:35:01,620 ‘0001’ means it’s an IPv4 address and then you actually have the payload. 459 00:35:01,620 --> 00:35:05,350 And you can see Wireshark is too stupid to decode such brilliance! 460 00:35:05,350 --> 00:35:15,050 *laughter and applause* 461 00:35:15,050 --> 00:35:19,150 Yeah, so. Then it’s hard to find example traces. You want to implement 462 00:35:19,150 --> 00:35:22,430 the protocol and you want to find some example traces. This is a mail I … 463 00:35:22,430 --> 00:35:27,030 actually I was looking for this this year, in 2015. I was googling 464 00:35:27,030 --> 00:35:32,450 for Iuh protocol traces. And what did I find? My own e-mail from 2009 465 00:35:32,450 --> 00:35:37,440 where I was asking for protocol traces. But nobody ever responded. 466 00:35:37,440 --> 00:35:40,950 So the situation is better today. You can actually find, I think, 467 00:35:40,950 --> 00:35:46,770 2 or 3 public pcap files containing each maybe a handful of messages 468 00:35:46,770 --> 00:35:51,270 on those interfaces. It’s really… it’s odd, you know? These are protocols 469 00:35:51,270 --> 00:35:55,650 that are specified publicly. They’re used in production. Billions of users are using 470 00:35:55,650 --> 00:36:01,000 these networks but nobody even has an example protocol trace of those protocols. 471 00:36:01,000 --> 00:36:05,210 Okay, now we have a couple of protocol traces. We understand 472 00:36:05,210 --> 00:36:09,470 the nesting level is deep. We are happy that Wireshark decodes at least most of it, 473 00:36:09,470 --> 00:36:13,480 which by the way we have to thank one particular Ericsson employee 474 00:36:13,480 --> 00:36:18,700 who is contributing those dissectors to Wireshark. 475 00:36:18,700 --> 00:36:22,920 So then we need to basically set up a tool chain to generate code 476 00:36:22,920 --> 00:36:29,030 from these ASN.1 syntaxes. So there is an ASN.1 C compiler from Lev Walkins. 477 00:36:29,030 --> 00:36:32,930 It’s good for a lot of things and I’m very happy it exists. But it lacks many 478 00:36:32,930 --> 00:36:36,030 if not most of the features that you need in the Telecom world. That’s 479 00:36:36,030 --> 00:36:38,940 sort of unfortunate. There’s no information object classes, there is 480 00:36:38,940 --> 00:36:43,500 no aligned PER support, there’s no support for prefixing the type names. 481 00:36:43,500 --> 00:36:46,960 Because we have 3 different protocols, we want to use them from one program. 482 00:36:46,960 --> 00:36:50,660 We need to prefix the type names because of course each of those 3 protocols 483 00:36:50,660 --> 00:36:54,300 has a type called ‘protocol information element container’. But of course 484 00:36:54,300 --> 00:36:57,260 it’s not the same protocol information element container, there it said(?). 485 00:36:57,260 --> 00:37:02,150 You know, each of the protocols has its own containers. 486 00:37:02,150 --> 00:37:07,290 So we had to add these pieces to the asn1c, at least in a minimal way 487 00:37:07,290 --> 00:37:11,590 in order to use it. And unfortunately I don’t know anyone, and I’m certainly 488 00:37:11,590 --> 00:37:15,189 no one who understands something about compiler theory, so it’s 489 00:37:15,189 --> 00:37:21,100 a little bit challenging. Now, alternatives to asn1c, well, 490 00:37:21,100 --> 00:37:25,030 the most complete tool kit you can find for working with ASN.1 491 00:37:25,030 --> 00:37:30,310 exists in the Erlang OTP system. I used this in the past 492 00:37:30,310 --> 00:37:36,490 for a lot of Osmocom projects, but the fact is the C projects… 493 00:37:36,490 --> 00:37:40,050 there are other developers and people that contribute. In the Erlang projects 494 00:37:40,050 --> 00:37:44,200 there is nobody that contributes except from me. So I thought, well okay, 495 00:37:44,200 --> 00:37:48,450 it’s very nice to work with ASN.1 in Erlang, but then if nobody contributes 496 00:37:48,450 --> 00:37:53,940 I’d rather go the difficult C way and then have contributors in the project. 497 00:37:53,940 --> 00:37:58,010 Also of course in the Osmocom project we’re mostly low-level C guys; 498 00:37:58,010 --> 00:38:04,460 and people are very wary of virtual machines and the 499 00:38:04,460 --> 00:38:08,980 – at least perceived – bloat they introduce. The third alternative is 500 00:38:08,980 --> 00:38:13,900 to use a proprietary ASN.1 compiler, and in my day job I actually use such tools. 501 00:38:13,900 --> 00:38:18,230 But in the first sight you think, 502 00:38:18,230 --> 00:38:24,490 well, okay, so it’s a code compiler, it compiles code, and copyright law says, 503 00:38:24,490 --> 00:38:28,020 well, code that was generated by a machine is not copyrightable because 504 00:38:28,020 --> 00:38:33,260 the act of automatically compiling code from one form into another form 505 00:38:33,260 --> 00:38:37,900 does not make this… that does not create a copyrightable work as itself. 506 00:38:37,900 --> 00:38:42,350 So basically, you can take a proprietary ASN.1 compiler, compile C code and then 507 00:38:42,350 --> 00:38:46,310 use the resulting C code in an open source project without having any problems 508 00:38:46,310 --> 00:38:50,990 with the license of the ASN.1 compiler. And that’s true, however 509 00:38:50,990 --> 00:38:54,450 all those compilers I know, and I think I know all of them, they have 510 00:38:54,450 --> 00:38:59,991 a runtime library and that you only either get as a binary library or you get it 511 00:38:59,991 --> 00:39:06,340 in source code that’s not available under a free software compatible license. 512 00:39:06,340 --> 00:39:09,910 No option to do that. So we have to stick with asn1c, 513 00:39:09,910 --> 00:39:14,470 which as I said I don’t want to complain about, it’s a great project. It just 514 00:39:14,470 --> 00:39:17,450 doesn’t do all the things that we need. But then, it was not written for us, so 515 00:39:17,450 --> 00:39:23,760 of course it doesn’t do everything we need. Luckily, a research group 516 00:39:23,760 --> 00:39:29,300 at Eurecom, the European Communications Research organization, has developed 517 00:39:29,300 --> 00:39:33,720 a patch for adding aligned PER support to asn1c. Unfortunately it was 518 00:39:33,720 --> 00:39:37,900 against an old version because, well, they probably don’t want to submit 519 00:39:37,900 --> 00:39:42,310 this main line (?) and they don’t care about porting it and rebasing (?) it. 520 00:39:42,310 --> 00:39:47,290 I did that. It probably still needs some clean-up before it can be submitted, 521 00:39:47,290 --> 00:39:52,880 but my goal is to have this included in asn1c. 522 00:39:52,880 --> 00:39:56,960 And also we found quite a number of bugs still in the code, 523 00:39:56,960 --> 00:40:01,460 so it’s in the process of being improved. Now information object classes are hard, 524 00:40:01,460 --> 00:40:05,150 at least for me. Basically we skip that. 525 00:40:05,150 --> 00:40:10,570 I manually edit the ASN.1 syntax for not using information object classes anymore, 526 00:40:10,570 --> 00:40:14,490 so I’m rewriting the ASN.1, that’s supposed to be there to guarantee 527 00:40:14,490 --> 00:40:19,090 that the encoding is a… so it circumvents 528 00:40:19,090 --> 00:40:22,200 sort of the purpose. The idea is you take the ASN.1 from the spec, you use it, 529 00:40:22,200 --> 00:40:26,060 you don’t modify it. But I’m modifying it because, well, the tools we have 530 00:40:26,060 --> 00:40:30,630 are not good for what we want to do. Type prefixing is done. 531 00:40:30,630 --> 00:40:35,190 Now we have the information element containers. Eurecom has 532 00:40:35,190 --> 00:40:41,249 another idea about this. They have a long Perl script. 533 00:40:41,249 --> 00:40:47,090 I recommend you not to look at it, it consists of a neverending sequence 534 00:40:47,090 --> 00:40:53,060 of regular expressions, basically grep-ing out certain parts of the ASN.1 syntax 535 00:40:53,060 --> 00:40:56,990 without really formally parsing it, or lexing it, or tokenizing it; 536 00:40:56,990 --> 00:41:00,440 and then based on those regular expressions generating C code that then 537 00:41:00,440 --> 00:41:04,940 you can use with asn1c and link against it. And surprisingly it works, 538 00:41:04,940 --> 00:41:08,840 surprisingly good actually. We had to teach it all the things that we needed 539 00:41:08,840 --> 00:41:13,780 in addition to that. But really it works surprisingly. 540 00:41:13,780 --> 00:41:18,910 Now. Putting things together: Copy and paste the ASN.1 syntax 541 00:41:18,910 --> 00:41:24,050 from the 3GPP DOC files. Because 3GPP specs are published as PDF files 542 00:41:24,050 --> 00:41:28,130 and as Word documents, and you don’t get the actual syntax as a text file. 543 00:41:28,130 --> 00:41:32,490 You have to copy and paste from each page, make sure you don’t get intermixed 544 00:41:32,490 --> 00:41:37,660 like headlines or something like that. Then you use the hacked-up, patched asn1c 545 00:41:37,660 --> 00:41:45,530 to generate C code. You have to modify it to make a shared library of the runtime 546 00:41:45,530 --> 00:41:49,920 for the ASN.1 compiler because we have, again, 3 syntaxes that we want to mix, 547 00:41:49,920 --> 00:41:54,349 and that doesn’t really work with how asn1c works. We use asn1tostruct 548 00:41:54,349 --> 00:41:58,660 to remove this what I call the obfuscation layer, these containers. We write 549 00:41:58,660 --> 00:42:03,540 some code to dispatch the messages, and then finally, we see some messages. 550 00:42:03,540 --> 00:42:09,700 So we have those HNB register, INITIAL_UE_MESSAGE and all these things. 551 00:42:09,700 --> 00:42:13,540 This is what you can now get from osmo-iuh.git, the Git repository 552 00:42:13,540 --> 00:42:18,280 on the Osmocom server which contains all this code. 553 00:42:18,280 --> 00:42:22,350 It takes a long time to compile, because asn1c generates one C file 554 00:42:22,350 --> 00:42:26,690 and one header file for each type. And they have lots of types in those specs. 555 00:42:26,690 --> 00:42:30,570 So you end up with like 300..400 C files and header files compiled 556 00:42:30,570 --> 00:42:38,440 into a 5 megabyte binary, and then finally you want to get 4 bytes in a message. 557 00:42:38,440 --> 00:42:44,170 So well, where do we go from here? We have a couple of other things to do. 558 00:42:44,170 --> 00:42:47,510 One interesting question is – and I’m going to do a demo in a few minutes – 559 00:42:47,510 --> 00:42:51,630 is what kind of hardware can be used? Well, the hardware that I currently use 560 00:42:51,630 --> 00:42:55,400 for this development is undisclosed manufacturer, very expensive. 561 00:42:55,400 --> 00:43:00,990 It’s not actually a femtocell, it’s a real cell, it costs several thousand Euros, 562 00:43:00,990 --> 00:43:05,310 not really suitable for hackers. However many consumer grade femtocells 563 00:43:05,310 --> 00:43:09,210 have also this Iuh protocol with the same stacking. The problem is 564 00:43:09,210 --> 00:43:15,050 they’re locked down, in a way that they have certificates and connect over IPsec 565 00:43:15,050 --> 00:43:20,700 to the operator network etc. So if somebody can break this IPsec layer 566 00:43:20,700 --> 00:43:24,780 and insert its own a certificate, or disable the IPsec altogether then you can 567 00:43:24,780 --> 00:43:29,619 talk Iuh to the osmo-iuh and then you can use that hardware. This is something 568 00:43:29,619 --> 00:43:33,030 that a couple of people have looked at, and hopefully in the near future 569 00:43:33,030 --> 00:43:38,430 we will have 1 or 2 femtocells that people can use inexpensively 570 00:43:38,430 --> 00:43:41,000 in order to use the software. At the moment, I said, unfortunately 571 00:43:41,000 --> 00:43:48,010 it’s not possible. As a summary, before I go into the demo 572 00:43:48,010 --> 00:43:53,620 of demonstrating it and you having basically a look in the marvelous depth 573 00:43:53,620 --> 00:43:59,680 of the Wireshark decodes, Iuh is conceptually very easy to understand. 574 00:43:59,680 --> 00:44:04,660 The lack of good ASN.1 tools is the biggest problem in the free software world. 575 00:44:04,660 --> 00:44:09,450 You need to overcome these containers, and in the end you spend 90% of your time 576 00:44:09,450 --> 00:44:13,380 in improving the tooling, fixing the tooling and working around these 577 00:44:13,380 --> 00:44:18,869 layers of abstraction rather than doing the actual functionality. 578 00:44:18,869 --> 00:44:22,960 We have started the work on the core network components, the integration. 579 00:44:22,960 --> 00:44:27,210 I was hoping that I could do a full demo with a call, or a full demo with actually 580 00:44:27,210 --> 00:44:32,200 having a data connection over this setup that I have here, over the test setup. 581 00:44:32,200 --> 00:44:36,120 I’m almost there. The signalling, everything gets established, 582 00:44:36,120 --> 00:44:39,910 the authentication works but then somehow the data, the actual IP data 583 00:44:39,910 --> 00:44:45,250 doesn’t want to come through. And that is under investigation, but I’m sure 584 00:44:45,250 --> 00:44:51,260 it will be available rather soon. Now before we go for Q&A 585 00:44:51,260 --> 00:44:58,620 let me just do a quick demo and let me show you how this looks at the moment. 586 00:44:58,620 --> 00:45:02,760 This is still a protocol trace 587 00:45:02,760 --> 00:45:07,510 basically that was running in the past. I’m just going to leave this here 588 00:45:07,510 --> 00:45:11,240 at the left-hand side, I’m going to leave the… on the right-hand side. So 589 00:45:11,240 --> 00:45:15,180 what we can see is basically on the left-hand side 590 00:45:15,180 --> 00:45:19,711 we have the RUA encapsulated messages. This is basically the Iuh interface 591 00:45:19,711 --> 00:45:23,940 between the HomeNodeB and the HomeNodeB gateway. Then we have 592 00:45:23,940 --> 00:45:28,369 the osmo-iuh HomeNodeB gateway invisible in between here, and that’s the program 593 00:45:28,369 --> 00:45:32,780 running in the background. And then the other side is this protocol stacking here, 594 00:45:32,780 --> 00:45:38,680 where we see we have the SUA, this SCCP User Adaption rather than the RUA 595 00:45:38,680 --> 00:45:42,130 on the left-hand side. The RANAP messages are the same on left and right, it’s 596 00:45:42,130 --> 00:45:50,180 basically just converting. What I’m going to start in the background is 597 00:45:50,180 --> 00:45:55,930 basically – this is the wrong window, I thought I had prepared everything just… 598 00:45:55,930 --> 00:46:01,290 Yeah. Exactly. Good, that’s the one part, 599 00:46:01,290 --> 00:46:06,440 that’s the other part… So I’m going to start the… 600 00:46:06,440 --> 00:46:08,970 I know the font is too small, you don’t need to read that. I’m just going 601 00:46:08,970 --> 00:46:15,520 to tell you the… I can make it larger, then we won’t see really a lot. 602 00:46:15,520 --> 00:46:24,530 What’s this? Why is it not…? 603 00:46:24,530 --> 00:46:31,110 “Cannot listen on… socket…”. Now that’s the demo effect! 604 00:46:44,640 --> 00:46:49,970 Why on earth is it not binding? 605 00:46:49,970 --> 00:47:01,040 What a pity! Okay, that’s embarrassing. 606 00:47:01,040 --> 00:47:05,640 Then you get a larger font size! And then let’s have a quick look. 607 00:47:05,640 --> 00:47:10,720 I’ll try it very quickly. So I’m trying this, it cannot bind to the sockets. 608 00:47:10,720 --> 00:47:14,460 Probably my IP address has disappeared on the laptop 609 00:47:14,460 --> 00:47:17,910 while I’ve been talking here and now it wants to bind to an address 610 00:47:17,910 --> 00:47:28,150 that doesn’t exist anymore. And that seems [to be] exactly what has happened. 611 00:47:28,150 --> 00:47:34,330 Now don’t shout your SUDO! (?) *laughter* 612 00:47:34,330 --> 00:47:39,450 It will not like you. I can tell you. 613 00:47:39,450 --> 00:47:48,020 Yeah. Now this should do the trick. 614 00:47:48,020 --> 00:47:50,350 I’m starting this in Valgrind because I’m still debugging, yeah… 615 00:47:50,350 --> 00:47:54,440 Now it’s actually running, okay. Now we do the same on the other side, 616 00:47:54,440 --> 00:47:59,670 we go for a huge font size, and I’m starting the HNB gateway. 617 00:47:59,670 --> 00:48:05,140 We see a yellow line, that a connection has been established. So now 618 00:48:05,140 --> 00:48:10,960 we are waiting for the initial message from the HomeNodeB to arrive. 619 00:48:10,960 --> 00:48:13,960 We should see it here at the bottom of this trace. We should see 620 00:48:13,960 --> 00:48:18,900 a couple of Reset requests. Basically the HomeNodeB this… the NodeB here 621 00:48:18,900 --> 00:48:24,670 is trying to reconnect all the time to its HomeNodeB gateway. 622 00:48:24,670 --> 00:48:28,030 Of course there’s some backup… some back off included and given that it was 623 00:48:28,030 --> 00:48:32,000 not connected for the first 40 minutes or so it will take some time to reconnect 624 00:48:32,000 --> 00:48:36,060 to the SGSN and then I can have the phone that I have here regist… 625 00:48:36,060 --> 00:48:59,210 *audio recording blanks out* 626 00:48:59,210 --> 00:49:32,190 *one minute of audio missing* 627 00:49:32,190 --> 00:49:36,450 Herald: …is there somebody somewhere at a mike? Mike 2, please! 628 00:49:36,450 --> 00:49:42,250 Question: So if 3G is so annoying why not skip it and go directly to LTE? 629 00:49:42,250 --> 00:49:46,930 LaForge: Well, there’s a couple of reasons for that. 630 00:49:46,930 --> 00:49:50,550 First of all some people really need it in terms of 631 00:49:50,550 --> 00:49:55,960 there’s an actual demand for 3G small networks 632 00:49:55,960 --> 00:50:00,090 or 3G cells in applications where it’s used. The second reason is 633 00:50:00,090 --> 00:50:05,660 it’s a relatively limited incremental step because the Layer 3 protocols 634 00:50:05,660 --> 00:50:11,260 of GSM and UMTS are the same. And that’s why basically we can use… 635 00:50:11,260 --> 00:50:15,320 reuse the call control and the mobility management, all those parts from GSM, 636 00:50:15,320 --> 00:50:21,180 reuse them with 3G. I’m not saying we shouldn’t do the same with LTE as well 637 00:50:21,180 --> 00:50:25,010 but there are actually quite a number of projects already involved in that area. 638 00:50:25,010 --> 00:50:32,840 And LTE, well, to be frank, it’s so much IP it’s not really telecom anymore. 639 00:50:32,840 --> 00:50:36,010 You know I’m always interested in the more obscure things that people 640 00:50:36,010 --> 00:50:40,670 are not really looking so much at. IP, I found IP boring when I stopped working 641 00:50:40,670 --> 00:50:44,030 on Netfilter in 2004 or so. IP, well everyone knows about IP, that’s… 642 00:50:44,030 --> 00:50:47,740 you know, we need something more interesting. 643 00:50:47,740 --> 00:50:51,890 Herald: Microphone 1 please! 644 00:50:51,890 --> 00:50:56,270 Question: So you say that you have a lot of trouble parsing ASN.1. 645 00:50:56,270 --> 00:51:01,740 But if it’s always the same containers can’t you simply have a static dump 646 00:51:01,740 --> 00:51:07,820 of the binary crap before and after that stuff, and ignore the whole parsing part? 647 00:51:07,820 --> 00:51:15,180 LaForge: You probably could. But then, how can I say, my code athletics 648 00:51:15,180 --> 00:51:21,760 demand better behavior from code I write than just doing something like that. So 649 00:51:21,760 --> 00:51:29,420 yes, you could, probably, but I’d rather have a more clean way of doing that. 650 00:51:29,420 --> 00:51:34,150 Herald: And continue on microphone 1! 651 00:51:34,150 --> 00:51:39,920 Question: You said that UMTS or 3G is a toolbox for creating 652 00:51:39,920 --> 00:51:45,849 arbitrary telephony systems while my knowledge tells me that GSM 653 00:51:45,849 --> 00:51:49,550 is a much more rigid standard, but, if you could please elaborate 654 00:51:49,550 --> 00:51:57,560 on that concept of “arbitrary networks”! 655 00:51:57,560 --> 00:52:03,070 LaForge: Well, I could illustrate that very much with a certain protocol trace. 656 00:52:03,070 --> 00:52:07,550 UMTS basically… when UMTS was specified they didn’t know where the journey 657 00:52:07,550 --> 00:52:12,500 was going to. Basically, it was not clear that the internet would be the thing 658 00:52:12,500 --> 00:52:16,340 that we know as of today. They didn’t know that smartphones would exist. 659 00:52:16,340 --> 00:52:20,190 They didn’t know that IP data services are the type of data services that people 660 00:52:20,190 --> 00:52:27,109 are interested in. Rather they were thinking of… in generic terms. 661 00:52:27,109 --> 00:52:33,170 So it could have been that we needed all X.25 over UMTS. 662 00:52:33,170 --> 00:52:38,109 It could be that, you know, people wanted to do ATM over UMTS. 663 00:52:38,109 --> 00:52:42,060 It was not clear that circuit-switched services would basically go downhill 664 00:52:42,060 --> 00:52:48,830 like they did meanwhile with voice-over-IP telephony etc. 665 00:52:48,830 --> 00:52:53,670 It was not clear that modem calls or actual video calls that exist in UMTS 666 00:52:53,670 --> 00:52:58,010 would not be the future. So it was very unclear. And they tried to define something 667 00:52:58,010 --> 00:53:02,010 that’s as flexible as possible to do anything that you could imagine. 668 00:53:02,010 --> 00:53:05,920 And if you look at the way how the layers are structured and the fact that you have 669 00:53:05,920 --> 00:53:10,780 transport channels, and transport channel bundles, and radio access bearers etc., 670 00:53:10,780 --> 00:53:15,260 basically the structure. Even only to transmit voice again 671 00:53:15,260 --> 00:53:21,230 you have to set up with AMR for all the codecs you need to configure 672 00:53:21,230 --> 00:53:26,230 in the physical layer, I think, for the 3 different bit classes 673 00:53:26,230 --> 00:53:30,910 10 different combinations. So you end up with something like 30 parameters 674 00:53:30,910 --> 00:53:35,780 or 30 sets of parameters that you need to communicate to the lower layers only 675 00:53:35,780 --> 00:53:40,150 to configure it for establishing a voice channel. And then the transport channels, 676 00:53:40,150 --> 00:53:44,250 that where the bits are included, the payload like how many bits fit in 677 00:53:44,250 --> 00:53:48,109 into one frame doesn’t match with your codec bitrate because they didn’t know 678 00:53:48,109 --> 00:53:52,180 what codecs they would use. So it’s really… it’s all arbitrary and with padding 679 00:53:52,180 --> 00:53:59,220 and universal. So it’s not like GSM. GSM is very simple and straightforward. 680 00:53:59,220 --> 00:54:02,240 Herald: Okay, we have 5 minutes left so we will have 2 quick questions 681 00:54:02,240 --> 00:54:04,510 from the internet because everybody on the stream: 682 00:54:04,510 --> 00:54:07,820 you can actually ask questions on the chat. Please! 683 00:54:07,820 --> 00:54:12,010 Signal Angel: Okay, thanks. We have 2 questions as you said. The first one is: 684 00:54:12,010 --> 00:54:15,480 if there would be interest in implementing, you know, the whole stack 685 00:54:15,480 --> 00:54:21,570 in a safe and non-VM based language if the tooling was good enough? 686 00:54:21,570 --> 00:54:25,850 *LaForge breathes out heavily* *laughter* 687 00:54:25,850 --> 00:54:29,480 LaForge: Well, I mean I’ve… It depends on… I don’t want to find Language Wars 688 00:54:29,480 --> 00:54:36,290 here. I would have been tempted to do things in Erlang but then, I said, 689 00:54:36,290 --> 00:54:40,240 the question is who else would have been tempted? 690 00:54:40,240 --> 00:54:44,140 I don’t think… I mean the point is what we’re trying to do now is to basically 691 00:54:44,140 --> 00:54:50,680 use most of what we already have with the least additional effort 692 00:54:50,680 --> 00:54:55,329 and I don’t think anyone will want to start from scratch all over again. 693 00:54:55,329 --> 00:54:59,000 But if they do so I would be happy to see a clean implementation, 694 00:54:59,000 --> 00:55:02,930 but I’m not so sure that will happen. 695 00:55:02,930 --> 00:55:06,890 Signal Angel: Okay, thanks. The second question is: why don’t we just 696 00:55:06,890 --> 00:55:11,410 start over for a clean slate with hardware and software and do a basically 697 00:55:11,410 --> 00:55:15,650 100% nerd and hacker driven mobile networks? 698 00:55:15,650 --> 00:55:17,470 LaForge: Sorry, 100%…? 699 00:55:17,470 --> 00:55:21,470 Signal Angel: …nerd/hacker driven networks. 700 00:55:21,470 --> 00:55:25,720 LaForge: Ah, well, I mean the point of implementing all those specs is 701 00:55:25,720 --> 00:55:30,099 you want to use the existing devices out there. You want to use 702 00:55:30,099 --> 00:55:33,500 the existing billions of mobile phones that exist on the planet. And if you 703 00:55:33,500 --> 00:55:36,510 want to talk to them then you need to implement those protocols 704 00:55:36,510 --> 00:55:40,610 and those systems that they implement. If you want to start from something else 705 00:55:40,610 --> 00:55:45,480 and do things from scratch, well, yes, you can do that. But then keep in mind 706 00:55:45,480 --> 00:55:49,520 that you will have very bulky end user equipment with large like clusters 707 00:55:49,520 --> 00:55:54,750 of FPGAs and DSPs, draining batteries, having fans inside. Because you 708 00:55:54,750 --> 00:55:59,099 will not be able to implement your system in the same level of energy efficiency, 709 00:55:59,099 --> 00:56:04,900 in the same level of, you know, ASICs and optimized silicon processes etc. 710 00:56:04,900 --> 00:56:10,660 like is the case for the billions of existing devices. 711 00:56:10,660 --> 00:56:13,910 Herald: Okay, thank you, Harald Welte! 712 00:56:13,910 --> 00:56:17,480 LaForge: Yeah, thank you! *applause* 713 00:56:17,480 --> 00:56:23,190 *postroll music* 714 00:56:23,190 --> 00:56:28,581 *Subtitles created by c3subtitles.de in the year 2017. Join, and help us!*