OpenLI: Lawful Intercept Without the Massive Price Tag

[Applause] and thank you for turning up I know on Friday afternoon that's it's easy to just sneak off and have a nap but well I'll try and keep you awake keep it light and breezy so this is a talk about the open la project which is a project that's been occupying me over the last 12 to 18 months and it's designed to allow Internet service providers and network operators to meet their lawful intercept obligations without having to spend a whole lot of money so what what is lawful intercept lawful intercept is the legal and authorized interception of telecommunications and usually that's used with the purpose of either investigating or trying to prevent criminal activities terrorism things like that so it's a power given by the government to law enforcement agencies such as the police and national security agencies intelligence services and so on to be able to investigate or intercept the communications of a person of interest and use those to try and prevent or investigate solve crimes so of course nowadays we live in what is primarily a digital age so the vast majority of events communications are going over the Internet in some way and this includes obviously email but things like voice over IP replacing people's landlines in their homes instant messaging social media video calling through services like Skype and and even all of your mobile phone calls are typically carried over the internet for at least some portion of the way so this means that these old-school wiretapping techniques that the agencies used to use don't really apply anymore so they have to make way for new techniques so how does lawful intercept in the digital age really work well here's an example I've got an ISP here they have three customers and Bella and Chad and the ISP effectively acts as a gatekeeper right all of the communications from these three people going to and from the Internet are passing through the ISP and this means that the ISP is in a perfect spot to covertly intercept the communications many of those customers now while Annabella of law-abiding citizens Chad is a slightly shady a character and has managed to attract the attention of the police the police would like to intercept Chad's communications to gain some additional evidence that could prove here his partaken in the crime that they believe that he is involved with and so the police must obtain warrant for an intercept of Chad's communications from a judge now assuming the police case is you know reasonable then the warrant gets issued and the police then forward that warrant on to the Internet service provider now by law as a result of that warrant turning up the Internet service provider must forward a copy of all of Chad's communications that pass through their network on to the police for as long as that warrant remains an effect but the OSP also has a few additional obligations that they must fulfill when performing such a lawful intercept so the most important one perhaps is that Chad must not be able to detect that he is the subject of an intercept at any time otherwise he's obviously going to stop doing the things that might incriminate him right and this can range from the very obvious things that the ISP shouldn't do like suddenly disconnect Chad and reconnect him on the magic interception link through the things like degrading there can't be any degradation and Chad's internet performance there can't be any changes in the routes that Chad would normally use to access the internet that could be detected with a tool like traceroute they can't be any increases or decreases in latency that you might recognize if he was technically savvy and so on the infrastructure that the ISP is going to use to perform the intercepts there's an obvious privacy concern and so they have to take great pains to prevent any unauthorized access to that system and that includes from other employees at the ISP right so nobody else other than the people who are authorized to be involved in conducting intercepts should be able to see that an intercept has taken place right so imagine if Chad had a friend who worked at the IAS P and this is P had a big dashboard that they had on big monitors we're listening all the current active intercepts Chad's friend might tell him that he is under surveillance the ISP must be extremely careful not to over click and by over clicked I mean they can't collect any traffic or any communications for any people other than whom the warrant applies to so Anabella traffic must remain private but on the flip side of that failing to intercept all of Chad's communications is also a very bad thing right so consider an example sentence that say that was intercepted and it's being replayed in court where Chad appears to say I will help you with robbing the bank looks like Chad might be guilty but what if the intercept had accidentally missed the part of the communication that contained the key word not right so Chad's not so guilty looking now and even if there is some possibility in the collection mechanism the under collection could have taken place and not being detected that's enough for a savvy defense lawyer to be able to raise any reasonable doubt about the value of the intercept as a whole so what is the situation like in New Zealand for Li so it's governed by at the moment a law called the telecommunications interception capability and security act more affectionately known as Texa so this was passed in 2013 and the key palace was that all internet providers in New Zealand must be Li capable if they have 4,000 or more customers and by Li capable I mean they must be able to not quite immediately but as soon as it's reasonably possible begin intercepting a customer's traffic on demand and delivering that to a law enforcement agency of course in a wonderful example of the separation between law and actual practicality the implementation of this was not included in the definition that was going to be announced later so this question was resolved through an announcement in the New Zealand Gazette August 2017 and this is where the Etsy standards for Li with this mentioned within the context of New Zealand lawful intercept there's two problems with us the first was that the Gazette is not exactly required reading for any New Zealand network operators and the second one is that most operators had probably barely even heard of the HC standards before this time so this was all very new so what am i referring to what I'm talking about PhD standards so it's here's the European telecommunications standards Institute they an organization say similar to the ITU and various other standards bodies would like to sit around and have meetings and come up with the way that things should work without ever thinking about how you would go about implementing them their standards for LA are very widely adopted throughout the world so Europe obviously many countries in Asia are using them New Zealand obviously now and also Australia are looking at this as well the one exception of course our good friends in the US who decide to come up with an entirely separate mechanism but the the underlying principles are more or less the same so what do these standards offer that make them so appealing so first off they have very comprehensive is a set of standards they cover all of the different modern digital technologies for communication so you've got standards for conventional Internet traffic for IP you've got a separate standard for voice over IP you've got a standard that covers the interception of email mobile communications and so on but this does also introduce a bit of a downside in that there are a lot of standards to read through their lengthy they're complex they refer to each other all over the place and that creates a significant barrier to entry for anyone who's thinking about implementing them so the key requirement in the it CLI standards is that intercepted traffic must be streamed live in real time to the law enforcement agencies over an internet connection or a network connection of some form so this gives the agencies a chance to react to the information that we're receiving as it happens so consider the case you know for instance if there is an ongoing kidnapping investigation and the kidnappers are talking about where they going to transfer the person they've kidnapped - the police would like to know about that say within five minutes of that discussion and not the next day when you have a for the relatively low security intercepts so a lot of police investigations would fall in this relatively low security category those would be streamed using TCP sessions over the public Internet but wrapped in some form of encrypted tunnel higher security intercepts that involve intelligence agencies spies so on and so forth they'll have additional security requirements on top of that each it's the intercept is delivered using two separate handovers so they have a handover for delivering what's called intercept related information I our eyes this is mostly metadata about the industry so it will tell them when a target Senta kated with the isp when they were assigned an IP address and what IP address they were assigned in the case of voice call it's when was the call initiated who initiated the call when it was accepted things like that and then alongside that you have the communication content itself which is the raw data packets that the communication took place in so these are two separate streams of information they often used to corroborate each other it is very rigorous about ensuring that every intercepted packet is properly labeled so all traffic for a particular intercept is labeled with what we call an ally ID or an intercept ID and that's assigned by the agency that is requesting the intercept and in each separate voice call or ap session within an intercept has its own unique communication identifier on top of that and then finally within each communication everything's tagged with a sequence number so you can make sure that everything is in the right order and you can tell if any anything's gone missing between the point of interception and the law enforcement agency that's receiving it so as you can see Li is a little bit more complicated than just TCP dumping an interface and uploading that pcap file to some ftp server somewhere but there is one big practical issue with this choice of DHC standards and that is the issue of money so in the new zealand case the network operators get absolutely no financial assistance to cover the costs of integrating Li into the networks and when we're looking at the typical vendor solutions for LA that are it C compatible the costs are running into the tens if not hundreds of thousands of dollars and that's not even taking into account the ongoing licensing costs they come along with that unfortunately the option of not complying is just as if not more expensive so operators that have found to be non-compliant when they're called on to do an intercept they face daily fine of up to $50,000 per day and so shortly after the announcement in The Gazette that the its extents were required you don't need to read all of this email but Dave mill race this subject on the New Zealand network operators group mailing list and he had noticed that there was no open source solution for Li and he was curious as to what of opera is in the same position as him small operators in particular we're doing about meeting their light requirements and the answer was nothing it soon became apparent that very few operators we've been aware of new requirements remember I said that the Gazette is not exactly a widely read publication and so they had made no effort towards meeting them and there was now an increasing realization within that community that they had a big problem on their hands with no obvious solution right how are they going to be able to come become compliant without going bust and that's where I came in or my research group came in so some of the operators in that group approached us at the one network research group we're at the University of Waikato in Hamilton and they asked us if we'd be able to help out and why they come to us well we have a bit of a history of doing stuff with capturing packets so we've published plenty of research in the past based on live packet capture analysis doing this stuff in real time and you know weird accumulate a bit of expertise in this particular field and the operators figured that might be quite helpful in this situation furthermore we've been quite closely and tied with the offer our community we we shop at their annual conference every year it has to be next week and so we like to think we're fairly well regarded within the industry and so right from the outset the suggestion was for us to develop an open-source la solution for New Zealand network operators all right so the operators themselves were really good about this they were quite keen for the software to be open-source to be available a lot of what wand has done in terms of our research outputs and our software has been released in the past as open source so it was kind of a natural fit for us to to do it this way and so from this we kind of you know this open li project was was created with the idea of it being a solution that was built by the network operated community and ourselves as you know friends or members of that community for the mutual benefit so that being said there would still be some costs that associated with this project that you know we'd have to recover somehow right so this was a a big project was a serious project required a real commitment of not just time but also expertise right this wasn't something that we could just you know fob off to an undergraduate student to do as the honors or just knock it out in a few spare hours that we had so this was going to be a job for for someone who at least had a bit of experience and doing this sort of thing and so that's that's how it fell into my lap so I personally I'm research program of being with the group for a long time over a decade and most that time has been spent writing this packet capture software research projects we do so it became my problem it was also quite important that the project was treated as a priority right so already at this point the ISPs were under quite a bit of pressure to be Ally capable as soon as possible so they couldn't really afford to wait you know years for for me to get around to to churning this out there must be a time so we decided to go back to the community and we we said right we're willing to do this right but we're gonna need a bit of bit of money to to justify me taking time away from my other projects to do this excuse me and so the yet like I say those funds would be used to basically cover the cost of me spending around half my working hours on this project for as long as the fund had money and in the internet turned out to be about a year so we we figured a good minimum contribution would be about $10,000 and that's you know based on what I said earlier that's that's a tiny fraction of what each is P would have been looking at to buy a solution or of course there's a tiny fraction of the fines that they'd be looking at paying if they were caught out but when you propose a solution like that there is always the danger that you know we'd get a bit of a prisoner's dilemma and not enough operators would contribute because as you can imagine this the obvious route of you go well hmm if I don't pay now and my competitors all do and it's going to be open source at the end then I can just get it for free right so we tried to throw in a few incentives to Inc charge people to to get on board early so any anyone who provided funds for our project was given a pre-release access to the code so they could get a head start on trying to integrate it into their into their test beds and then possibly even towards production by the time the code was actually ready and we also gave them a real direct line to myself in terms of getting assistance and getting help support with with playing with that pre-release code we also gave them a bit of an opportunity to request certain custom features that might be necessary to make the software integrate properly into their network so everyone's network is different there are lots of fiddly little things that maybe wouldn't necessary that I wouldn't have necessarily thought of when coming up with a generalized solution and so if you are on board with us and you wanted something custom I was going to do it for you as part of my development and so we had some really cool companies come on board some members of those companies happen to be in this room today so I will just remind you that those companies are great and you should thank them a lot for what they've done so they stepped up helped fund the project and it was full steam ahead so let's talk a bit about the software itself so like any good software project open li is built on top of a lot of other people's work and should probably acknowledge that work so the most obvious one given that I'm talking here today right now is Linux so Open Li is specifically written for Linux I developed it and tested it mostly on Debian because that's what we use at wand so I know it works pretty well there but there's no reason why open-air I should be able to be easily used on other Linux distros as well everything's written in C there's two main reasons for that one is that C is still really the only option for anyone trying to write any serious packet capture and analysis code that wants to perform it even a decent rate and the other reason is that I'm actually still an old-school programmer I like writing C code so that's what I used another key building block the Lib trace packet capture and processing library so this is code that's been developed and maintained by I wand and a lot of it by myself over again over the last sort of 10 to 15 years and the main aim of live trace is to simplify the task of writing pen capture code by hiding a lot of the variations and and the nuances of different packet capture formats and different protocol stacks you know different ways that you can layer protocols on top of one another but with what we've done is we've kind of abstract a lot our way and put in a standardized API and so you write one simple Lib trace program and it works regardless of how many VLAN tags you've got on your packets that works regardless of what capture format you use to capture it whether you use pcap whether you use a linux socket so on and so forth so it's live trace is really cool if you do any work with pcaps packet capture TCP dump traffic analysis in general definitely encourage you to to look it up while the capture methods that supported by Lib trace is the data plane development kit or DP decay so this is a collection of drivers libraries that can be used to perform very high-speed packet capture using relatively inexpensive commodity network interface cards it was originally a project that was came out of Intel but for use mainly with their own 10 gigabit cards but it's spun off into its own open source community now so it's really quite helpful the last thing I'd like to mention is this library Lib wonder there's a general-purpose library that I wrote for encoding and decoding messages you're using d ER which is the format that we needed to encode our it C output in so I wrote it with a it was specifically written phone Li but the API was generic enough that it can be used outside of there as well so it's it's own separate LGPL entity now so the software itself so it consists of three distinct components or the first ones the provisioner this is basically acting as a centralized manager for the rest of the open Li system so what you generally have of the provisioner is you have the police they issued the warrant to a very stressed looking network operator and all they have to do is just take the intercept details and enter them into the provisioner and its configuration so so that the parishioner is the only part of the open Li system that the operator would have to interact with on a regular basis the the other stuff can kind of just sit there and maybe that's this had been my login to it every now and again to make sure it's still there but otherwise the operator is really only dealing with the provisioner most of the time it's got very little work to do because presumably you're not being requested to do intercepts every day and so it's perfectly suited to may be running in a VM or as a process on the same box there's a whole bunch of your upper management or monitoring systems at the moment all the configuration for intercept is manual so that they sit in a config file you want to add another one you eat at the file and then you retell the provision of service to reload it's conflict but we are thinking about ways that we can improve that the second components the collector so this is the real workhorse of the system so the network operator would provide the collector with a feed of their the network traffic that a sub could be subject to an intercept usually by configuring some sort of mirror port on the appropriate device in their network the the collector also receives a set of intercept instructions from the prisoner so those instructions will tell it who is an intercept target and what metadata should be included in anything that's encapsulating those records so that lawful intercept ID for instance I mentioned earlier so each packet that comes in from the mirror what will be checked to see if it's related to an active intercept if so we'll take a copy of it wrap it in the appropriate encoding and then forwarded on to the last component which is the mediator now because the collector will have or could have a very heavy workload we do strongly recommend that this is run on bare metal some real physical hardware VM simply aren't suitable for high-speed reliable packet capture that you're going to need to be able to do 4li having said that though we've we've tried to keep the hardware requirements pretty modest so you sort of off-the-shelf pizza box 1u server from which if a vendor you prefer should be more than enough with the one edition of DP DK capable ten gig and network interface card and that's just so that if you throw a lot of traffic in it at it it'll be able to keep up and even these necks aren't that expensive these days so the media is the last component and really all it does is it collects together everything that the collector or collectors throw at it and make sure that it's forwarded on to the appropriate law enforcement agency and the parishioner issues these forwarding instructions to tell the mediator which intercepts go to which agency so everything ends up in the right place the media ADA is the only component that will need any access outside of your network so everything else would be quite internal to the core network and the mediator just talks out even then it's only making outgoing and connections over the encrypted tunnel that hopefully you've been able to configure with your agencies earlier so something like a PC or a VPN or something like that the mediator actually attempts to stay to keep those connections up at all times so it's using regular keeper lives both at the TCP layer and within the mediator protocol itself to monitor whether it can still reach the agencies and give you an opportunity to repair that connection if it goes down before you need to send them an intercept and of course since ISPs may have multiple points of presence where they would want to put these interception boxes you know for instance you might want to put one in every major city the open Li architecture was designed from the ground up to support multiple of these collection boxes right so in in the time that I've got left I just want to go over a couple of the big picture issues that we ran into so the the first challenge or which hopefully is reasonably obvious to anyone who has any experience in networking is that while the agency might turn up and requests that we intercept traffic for Chad few if any of Chad's communications are going to have his name in them right the packets don't you have an envelope surrounding them saying from Chad or to Chad or anything like that so the ISP itself might have assigned a particular user name to chat and that will be used within the into an authentication system but even then that's not something that we might necessarily see in the communication stream itself so what we really need is we need to know what public IP address is using but we also have that issue that IP address is often assigned dynamically so there's no not necessarily a as you know a fixed record that we can go okay Chad maps directly to this one address and Chad's not guaranteed to keep that same address for the duration of the intercept of Chad turns off his home router for a couple hours turns back on you might get a new address and so we've got to keep track of any changes like that when we're doing intercepts for voice calls this is even trickier because we need to know the UDP port numbers that the voice stream is going to be going over to be able to cherry-pick just that media out for the intercept so of course in practice what happens within ISP networks is that we have these special control protocols they're used to announce or negotiate these sorts of details so if you have a an IP session the most common one common protocol that's used for this purpose might be something like radius and the that's used to announce to it well a user will authenticate true radius and then get get back an IP address that they can use for the duration of that session in the VoIP environment SEP is the protocol used to establish the phone call and as part of this establishment there's an exchange of IP addresses and port numbers that the media stream is going to appear on so as long as we're given it access to the packets that make up these control protocols and we are able to pass them then we can ask the OSP to give us a feed of that pass those control messages into the collector alongside the real communications and then the collector can inspect those and use that information to work out which traffic actually maps to Chad's current IP sessions or as currently active voice calls just by looking at the packet headers pulling out the IP addresses and port numbers these control protocol messages are also used to to form the basis of that IRI metadata I mentioned earlier so they there's a lot of direct one-to-one mapping between those the messages and those protocols and the metadata that we're required to intercept anyway so we have to have them regardless but there are some complications radius is not too bad radius there's a protocol that's generally entirely internal to their ISP and so it's reasonably trustworthy we can in in you know names that are announced in that protocol we can assume are actually going to be the names of the person that's making that request that Saif is a bit tricky to work with in particular sip has a couple of fields in it there's you know that has a Fromme field and a to field that normally contain a name or a phone number of the person who is even making or receiving the call but it turns out that the from field is quite easily spoofed ball so Chad could quite easily replace the from field with someone else's name or even worse someone else could accidentally end up replacing their Fromm filled with Chad's name and then we get the over collection problem yet so but it's also possible for incoming callers to suppress their caller ID and so it's it the agency may not be able to see who's calling Chad and that is obviously information that they'd be quite keen to have fortunately you know there are a lot of places in the city where we can find this information we have to be a bit trickier about it but there are other hitters that we can use and it also does somewhat depend on if we receive our SIPP feed from if they're outside the SIP server inside the SIP server and things like that some hitters tend to be strict or some fields tend to be stripped and so if you're on the wrong side then you might miss them again anyway the other problem is that in New Zealand we actually have pretty good internet so in my home in a town of about 10,000 people I have a one gigabit plan and I'm sure plenty of the other New Zealanders in the audience have something similar right so this creates a bit of a problem if you are thinking about intercepting people's traffic because all of a sudden you might have to deal with a simultaneous intercept involving multiple these people all who happen to be saturating their one gigabit per second plan right and if they are doing that how can we be sure that we can intercept all of that traffic without dropping any packets due to poor software performance all right so we've got to make sure that our software is working at optimum speed not wasting even a nanosecond of processing time just for that worst-case scenario right we can't afford to spend any time unnecessarily looking at packets so one of the big advantages that we get out of using Lib trace is that we're able to spread out capture workload across multiple CPU cores basically transparently so what this means is that we can do more simultaneous captures on different interfaces so we the operator can spread some load themselves by again in multiple interfaces different feeds of different classes of traffic we can assign multiple processing threads to each of those capture interfaces and we can also we also automatically get support for a variety of high-speed packet capture methods so this can include things like DP decay as I mentioned before that's natively built into Lib trace if you've got a bit more money to spend and you have you know you definitely need some high speed stuff then work very well with the in days as we capture hardware and if you have never of those then you can still fall back to the T packet interface within the next itself to get some degree of parallelism but this introduces a whole new set of problems right because if we start spreading packets all across multiple threads how do we sort of synchronize that state how do we keep track of things like if I have a sip session that's announcing the details of the call appearing on the street here and the media stream appearing on this thread over here how do I make sure that this thread knows the port numbers that it should be looking forward to perform the intercept and so well and another problem another similar problem is we have to have keep these sequence numbers very consistent for everything that we're exporting right and if we're intercepting half of someone's IP session over here and the other half over here we don't want to be exchanging a lock back and forth to ensure that we are assigning our sequence numbers in the right order so how do we keep track of that and the answer is actually more threads so we've met we had to add a thread that was dedicated to pausing so packets add a thread burst dedicated to pausing the radius packets we have a thread that's dedicated specifically to keeping track of sequence numbers and so we there's a reason why I didn't include a diagram of the collector infrastructure itself because there's so many things being passed back and forth through mrs. cutesy it's impossible to draw in two dimensions at least what what that looks like we have a pool of worker threads for doing the encoding work because the encoding is actually the hardest part of the job it's it's another problem that I I'm not going to mention today because I don't have time and then finally we have a forwarding thread at the end that kind of takes all the output figures out the right order reorders it and then pushes out to the mediator and so all this is sort of you know maintained with a whole bunch of 0nq message queues that are just used as a lock less way to chuck messages around between threads so having said all of that we do it it's done it sort of it's done so all the core functionality is in place we can do IP data intercepts we can do VoIP intercepts it seems to work reasonably well so we've got a successful production deployment with one of our ISP partners and I'm hoping that a few more wall will give it a crack in the coming weeks I'm running a tutorial at the indeed nog conference next week so that should definitely get them started the deployment that we have done it's passed some basic tests for compliance that we've done in conjunction with the New Zealand Police they've said that it did work and in terms of performance in our testing environment I've advanced to optimize things enough that open though I was hoping fairly comfortably with 500,000 packets per second so hopefully I would that would cover the use cases of most of the smaller network operators without too much issue doesn't cover the worst case if their customers are trying to you know DDoS themselves or others then it might not keep up but I do also have some ideas on how we can improve the performance there in the long run it's just a bit more work so I need to find a bit more time for that but most important the codes out it's released it's up on a github GPL 3 licensed we're more than happy for people to start taking a look at it give us some feedback it's still pretty early days so mostly expecting sort of bug reports and a few feet to request from our users but it would also be nice to see people staying to you know contribute that back and sending us some PRS as well that were great we've we've patched it to make it life a bit easier at least for people who are using Debian and Ubuntu and these are available from our bin tray but we're hoping you know one day we'll get them into official Debian mainstream packages as well that would be cool so there's there is one big question remaining and we often get asked this is how much support can an open Li user expect and given how important the lawful intercept compliance is and how much is at stake if open l I happens to fail at a key moment it's a pretty fair question so we've we've talked to people they have a wide range of opinions some people say they're going to need some sort of 24/7 support contract right so open LI to even be something they can consider they won't be able to get it past you know the guys in suits but the reality is is that it's much more like the guy on the right you know it's me at my desk putting in my best effort when I can when I'm not swamped with something else so we're still working through this and I'm expecting it to be a pretty big discussion point at NZ nog next week and we might have a bit more clarity again and ultimately I'm hoping to see a bit of a community start to start to grow around the software where we've got some users who are starting to contribute back code documentation especially helping out with that and user guides because like I say what everyone's network is different there also some things that they have in common maybe you know if somebody's gone through the pain once they might share their experience and save someone else the pain ideally you know I'd like to see this turn out like some of the other bigger open-source projects and networking space so I'm thinking things like free radius and bind an asterisk where they've got real communities built around them and it's not just you know one guy dictating how things go and it would really be nice to feel confident that we've got a bus factor that small of one sooner rather than later so finally just a few quick thank-yous our sponsors again especially the the technical people at those organizations who have been able to provide me with a lot of assistance a lot of examples and remind me of all sorts of things that I wouldn't consider because I'm a more academic person I think there's a theory about how things should work and the practice is entirely different the New Zealand Police have being really helpful with this project as well they've I wouldn't necessarily I'm not allowed to say that they support it but there's been a lot of useful back and forth and help in especially in testing and the New Zealand network operators group as well for being so enthusiastic about about the whole idea so I'll just throw those links up again but if I have some time I'm happy to take a few questions [Applause] so the the question was can it handle a highly dynamic environment like a hotel where you person's identity is is essentially quite tied to a room and a short time period a few days I honestly don't know I I think that that would come down to how the operator is managing the identity so whoever's providing internet to that hotel would be responsible for the Li rather than the hotel itself so it goes a bit further up the chain and then in that case hopefully there'd be some some way of being able to map the users within the hotel to the say what addresses yeah you'd have to have some sort of static mapping let's go over here now right so that the question is that if I can sort of paraphrase it is that have we got essentially anyone from the ISPs or from the police contributing back to the project and the answer is not yet the hope is that as at least from the IEP perspective that as they're staying to use it and they maybe need to add a few extra custom features to make things work for them that they might contribute those things back as there's modules or as as you know optional components that people can make use of because as I said if it's a problem for one it's probably a problem for someone else it's not necessarily a problem for everyone so yeah yeah so I can tell you that for the last year anyone who's had intentions of using this project has basically said we're waiting for the project to be finished and released and that's kind of been enough for them to get by as long as they've been able to have some sort of alternative backup method but that's obviously not going to be an excuse for anyone anymore yeah so the question was what what consideration will be given to the risks of people who may not have such good intentions making use of this software the the answer is that to make use of this software really just takes a feed of views of packet communications and turns them into the right format for them to be compliant with the law and so if you have a feed of all of those packets you can do whatever you want with that using by software is just a really complicated way to turn it into a format that you probably don't want it in any way yes so the question is do they have any insight into what larger operators have done given that this is a project that's more targeted smaller ones the larger operators have basically they have spent the money already they went with the vendor solutions because for them that you know the economies of scale and all that meant that you know it was just easier for them to spend the money and get the the support level that they would get from those vendors because they're having to deal with the majority of the intercept requests anyway and so they had to be compliant sooner rather than later we have seen some interest in adoption outside of New Zealand so not that long ago we got an email from a company in Kazakhstan who had who who had somehow stumbled across our project and it said that you know that their government is is putting pressure on them to be able to do this sort of thing as well so yes there is interest outside in New Zealand once we get a few more sort of presumably deployments and things they and people sort of publicly saying hey this works then I suspect that could even rise there but again I think it'll it always be quite something that will only really appeal to small operators if you're big enough then you're probably better after spending the money and not relying on something I wrote anyone else any tips on defeating it not that I can not that I can say right now while I'm being recorded but maybe maybe obviously I know a little bit more about what can be used to defeat these things and no doubt I still have plenty of bugs to fix as well so there could be a number of ways to defeat it I hope that will get better over time but like I say I'm I'm probably not allowed to elaborate too much more on that one more yeah well okay so the question is why didn't I basically use rust because it's yeah yeah yeah so the the answer that is that a I didn't have time to learn and the other one is that with the the processing obviously with in terms of processing the the soup and the radius traffic I'm going to have to parse it and look through that and that better is definitely a risk the rest of the packets I basically just encapsulate so so they're not so much of a problem and I really just have to be very careful about how I pass things and and make sure that I you know don't screw it up hopefully hopefully we're a few years of experience I've I've got at least the the obvious ones out of the way but yeah I'm I'm happy that because we've released it there's that gives people an opportunity to also ordered it people who are independent and that will also help as well but the real research yeah I didn't have time to learn Russ [Applause]

Channel: linux.conf.au

Views: 3,216

Rating: 4.2173915 out of 5

Keywords: lca, lca2019, #linux.conf.au#linux#foss#opensource, ShaneAlcock

Id: 4eV5a-uoaLg

Length: 49min 34sec (2974 seconds)

Published: Thu Jan 24 2019