 Peter's going to talk a little bit about RTP today and we'll turn the floor over to him. Go for it, Peter. Hello, all. First of all, let me introduce myself. My name is Peter Liminkov. I work currently for Red Hat. But I have some telecom background that I feel eligible to tell you about RTP Blit. So what is RTP Blit? If you are lucky and didn't hear it yet, you are lucky. This is a so-called security vulnerability which allows everyone to still hijack established media, established Wi-Fi media. First of all, it was introduced, well, I think it was well known before, but it was widely introduced by two security researchers, like Sandov Gauchi and Klaus Peter Liminkov. Sorry if I pronounced it incorrectly. I just don't know how to say it. As I said, it allows almost everyone to redirect media stream. Next slide I will explain how it works. If you didn't hear about it, you will be really surprised at how easy it can be done. And unfortunately, at the end slide, it cannot be mitigated at all. That's 100% cases it cannot be. Sorry. No, it's not. It's just, I guess. Is it better? Well, where is it? No, no, it could be better. So this is exactly how RTP Blit looks before. So in Russia we call it crocodile. So anyone can plug into the cable and listen what people actually say. That's why we have in Russia saying it's not for telephone call. No, we're not going to tell about it. It's not for phone call. So now I want to tell you how actually, well, how it works. In almost all YP system, we have a very special dedicated component which does a very simple thing, just bypass traffic through it. That's it. There are some more complicated cases. There are some easy cases, but that's exactly how it works. And guess what? An attacker can just send a single few bytes of data and redirect the entire traffic from this port to his controlled port and IP. That's it. That's very simple. Everyone can do this. Well, at least he can hijack up to 30 seconds of traffic. Good thing he doesn't know whom to speak with. So these are better news. First of all, I'd like to share a funny story from my past. I have a acquaintance in Russia who was worked as a network engineer and not so huge and not so small Russian telco provider. And once I will not tell you when exactly, but in the past, he was asked by his female friend from one of the Eastern European country to do a very, very shadow thing. To hijack the range of IP addresses, you know, like even right now, Russian national signal of Internet is very free. Free in terms you won't be punished for doing what is considered a crime. So it was even free before. So he easily replied with yes, opened his console, typed a few comments and well hijacked this IP segment. It was done. I don't know exactly why it was done. Maybe they wanted to steal a DNS name or a direct email to his server just cut off from Internet. Unfortunately for him, and this cost him place in this company, in that company, he made a mistake. And unfortunately for people in that country, this country was suffered from ongoing political crisis. And he cut off the significant number of government computers from the Internet. I don't know exactly what type of crisis it was, either rigged elections or just heated parliamentary debates. But the address of the attack was very well visible and everybody started talking about Russian hackers. I told you, I know this person. So these stories about Russian hackers are not entirely groundless. Some of them actually. Why I told you that? On a personal level, on a low level, we are you and you are doing good things. Actually, we are doing right. As soon as we hear that hash functions, there is a way to duplicate a string which has the same hash result. We are abandoning the usage of hash functions. Right now, we are considering switching in Git from one hash function to another one. We are actually disabling known as insecure crypto protocols and doing all the things. We actually doing it properly. On a high level, the approach to security is very, very much different. Well, first of all, it's because it comes from, it's our heritage. It's our legacy from the past. We're actually duplicating the same approaches people doing in the 1950s, for example. So we're just doing it on a different scale. So, for example, in many countries, many countries, I guess, it's illegal to dig and cut off wire between cities. It's illegal. You can't do this. A police will come after you and that's the end of the story. Also, for example, I was told it costs about several thousand bucks to duplicate a JSM-based station and you may use for various things, but it's also illegal. I wouldn't do this because, first, I'm not interested. Second, I do not know why, how it should be done. Third, it costs significant money. And fourth, it's illegal, just in that order. But others do and that's relatively simple. And these approaches actually came to the internet. Well, for example, this is my example with the cable. You have to go somewhere, dig or climb just for cutting wire or hijacking the traffic. But in the internet, you actually don't need to go anywhere. So it's easy for everyone to attack, to do some nasty thing. Could it be? I don't know. Yeah, type, it's safe. Yeah. Also, all the problems we are dealing with, it's just the very beginning. We have to deal with the segmentation of the internet. Sometimes people will tell you, unlike countries, internet has no borders. Oh no, no, no, internet actually has borders. And these borders are very, very solid. And these are private networks. Usually people cannot see everything around, behind the wall of the private network, but not the other way around. But we still want to connect with people, right? We still want to exchange data, we call each other, etc. So we created a very specific component just for that. There are some sophisticated approaches how to deal with network address translations. I'll explain later about them. But one is a very simple approach, and actually it does work in almost every case, I know, I'm aware of. There are multiple, first of all, this is an example of how it works. In the center, in the green square, it's exactly what this component is. It's an RTP proxy entity. There are multiple implementations. You may use Asterisk, you may use FreeSwitch, RTP proxy, CIP Express Media Server, RTP engine, various actual, a lot of implementations. There are some turn implementations. We are working very, very simply. We are working very simply. Imagine, well, first of all, usually, YP calls divided into two planes. First is control plane, second is data plane. They are significant, but they are disconnected. I'll tell you something about that later, but not now. And during the communication, this control plane, we command RTP proxy entity to open a necessary number of ports for these two users from within the private networks. And they open these channels and just when data comes, we just reply it on the different port. That's it, very simple, plain and simple. And that's the problem. If the attacker sends the data to that port, open for the communication. The data from the other side will be redirected to his own port. Why is that? Is that simple? I'll explain later. So this RTP proxy is visible for both collars. It allocates, but there is another one problem. Due to difference between control and data plane, we actually do not know who started to communicate, who sends the data. It's surprising what Weber-TC actually replies the same mistake, where data plane and control plane are disconnected. There is no way to say it. Okay, okay, I will do. As I told you before, there are some sophisticated ways to deal with the same task. Unfortunately, we do not work. Just for the case of simplicity, I will not stop on that particular case. Maybe we can find some information from within RTP traffic itself. Unfortunately, no. The most obvious approach, most obvious question, would be this synchronous source identifier, these several bits in the middle. What if we use it? It should be the identifier of media stream. So maybe we should stick to that specific ID and disallow any other media traffic for these allocated ports. Unfortunately, just in standard, it can be changed during the call because media traffic can be stopped and changed for different codec, made music on hold, muted audio and muted video. It just can be changed just because the other side has broken media library, using media library or something like that. So we really can't do much on this case. We have to re-send RTP traffic with a different SSRC but with a proper structure. We have to act that way. We have to redirect traffic. Good things, good things. There is a RTP.2.0, maybe. Next RTP, security RTP, which has actually a standardised field for carrying a signature of the media traffic. So in theory, we may consider that as a distinguished idea of the source of the traffic. However, for example, my experience with OIP is mostly related to so-called hardware fonts like Cisco 7940, 7960, various links. And even a few years ago, I wasn't aware of any devices that can encrypt their RTP traffic. Not many of them actually send RTP, for example, so it's very, very complicated for them to add. In short, what can we do to mitigate the use of current architecture? We will approach. We should really stick with the IP where the IP of the first byte comes from. So if we somehow stick with that and will not allow the attacker which has come from different IP addresses, this might be the solution. Unfortunately, I tested it by myself. It won't work at least in Moscow for generation and cellular network. If you walk down through Moscow, you will find that your IP address as soon as you reconnect to a different base station, I guess. So it never doesn't work. SSRC, as I said, also could change, although this looks relatively rare, but the standard, the standard says if something changes on the client's side, for example, if client realizes that his IP address or codec or maybe anything else will change, he have to change SSRC as well. So it's natural for the client to change SSRC during the conversation. So it's not possible. We don't have, as I said, we don't have a signature of any kind. And even if it's possible, if it's possible to sign RTP with signature, it can be done with allegases devices. It's not possible. I will tell, if time permits, I will tell you what could be done and why it wasn't. So will future of IP systems be affected by this RTP bleed? IPv6, introduction of IPv6 will allow people to connect directly. However, it contradicts to current business strategies because people like to control their users. So I guess some social networks will not allow you to people to connect and directly conversate directly because it's contradicts to the commercial interests. For example, if you create a platform for learning purposes, you will likely lock down users and develop direct connections. Encryption might work, but if we say something about user from the control plane to data plane, for example, I'd love to see more SRTP plus SDS standards implemented. But some others, maybe the TLS-SRTP, it's better not to use it, but it's up to you, actually. Since time permits, I would tell a very interesting story why it wasn't mitigated previously because, as I believe, people wanted you to use VPN over, use communications over VPN so your RTP will go within the demilitarized zone. However, it's not practical nowadays. Previously, in 1980s, maybe, it might be considered seriously, but now it won't work because you will have to have a significant number of VPNs and it won't work for many users. Unfortunately, that's mostly it, so I guarantee you will bleed and it's not going to change anytime soon. But do not worry, since it affects everyone, it's not a huge problem. In short, it's the same if you ask, I'd like to have a security in HTTP, but without S. How can I do this? Unfortunately, you can't. You have to switch to HTTPS. That's it, that's the answer. If you were in the previous presentation by Siphan Sayer, you might notice that he actually using a very sophisticated trick to convert DTLS plus RTP to the plain RTP, which comes through the demilitarized zone, but that's a very, very corner case. Still time, we still have very short time. Okay, go on. Sorry, sorry. Yes, that's correct. Yes, yes. The new standards will solve most of the things, will mitigate most of the issue. However, as I said, if you are dealing with very expensive hardware devices which are not doing this, you still have room for this issue. So it's not possible to mitigate it fully within 10 years until the IPv6 will start to be implemented widely. I hope it will be in 10 years. Can you say there is no solution which works every case? In the case, yes. I think in normal cases, if you have not a fortune that works, which changes the IP address every time you move, I would meet them, but you have aesthetic IP address like a voice-over IP service for enterprise customers, for hotspots replacement and so on. I think you can really have mitigation with like... VPN, for example, yes. No, not VPN, but really those ledging. You say, okay, the first pack can tell me who is the loud ascender. Yes. If there is a lot of attack coming, you block it because you say the first one wins. So of course there is some race conditions where you still can be hit. But I think it really lowers the attack surface to a really rare place, allowing the changing only when there was a green light like telling the box to, okay, now the exhaust appears, it's allowed to change for three seconds, and then you're still walking in on this, will solve most of the problems. Yes, yes. Sandra and Klaus Peter actually does the right thing. They started to talk widely about this issue. So before, before, it was as easy as just send a zero-length UDP packet, and the traffic was hijacked. So now they implemented so-called IP address locking and SSRC locking and various algorithms as well. That's exactly how people are trying to mitigate it. And in some cases, it certainly will work. So yes, yes, you are right. Okay, go on. Okay, sure. Thanks.