Plenary session
.
RIPE 82
.
17 May 2021
.
1 p.m. (CET)
.
CHAIR: We are about to start our next Plenary. As Erik said, we all need our social time and see our people and keep our sanity.
WOLFGANG TREMMEL: According to the schedule, I think Nico is starting. Let's start with first with some housekeeping, I think.
.
Do we have the housekeeping slide or should I share that? I can share it.
.
No, it doesn't work. Let's do the housekeeping just verbally. I guess you all know why we are here. Welcome to the one o'clock Plenary session. I am Wolfgang and I am chairing this together with Dmitry. We have two talks in this session, the session is one hour long, we have two talks of half an hour, and please, if you want to ask a question, use the question part of the tool. Do not ask your questions in the chat. The chat will not be monitored.
The session is being recorded as always, and of course if you always want to ask a question, with your microphone, you can also do that, just queue up in the virtual microphone queue.
.
And what's new for this RIPE meeting is, of course, you can also ask your question with the microphone and picture.
.
With that being said, I would like to hand over to Nico Schottelius, and he is talking about the post IPv4 era. And, Nico, the floor is yours!
NICO SCHOTTELIUS: Thanks a lot. First of all, thanks for having me. It's, as always, a pleasure to be around the RIPE conference as a participant, as a speaker and also with this, for me, very, very exciting topic.
.
And I have to say, the first part of my presentation you will see on the RIPE website, actually had a typo in the title, so it's supposedly entering the post IPv4 era.
.
So, before going into like everything in detail, I wanted to show you a quote that I recently got via e‑mail actually and it is from BrainGamer on the discord support. It basically says not supporting v6 is a real bummer... being someone who has to live with a DS Lite connection from an ISP with completely overloaded AFTR end points results in discord being unusable with ping spikes from 30 MS to over 2,000 MS to v6. Why do v6 seek support so low on this?
.
As you see, I received this mail around six days ago, so it's quite recent. And in a way, I wanted to take this as a starter because it really shows how the world already changed, even maybe not everywhere, but in big parts, because we are, practically speaking nowadays, reliant on IPv6.
.
And today I really want to show you like how I see like the communities I am working with and the company in I'm working with where everybody, kind of like changed from, well, we do IPv4 first, we do what's up nets to, well, the question is, not any more do I need IPv6? The question is more like, oh, does this thing not support IPv6? And for me, this is very important, because before it was more ‑‑ it was more an argument is it supportive of IPv6, do we want to go with IPv6? But there has really been a big mindset change in a lot of that I'm working with.
.
Today, I want to give you a little bit of an overview of the practical impacts there, what really changed is just a theory or, you know, what are the practical outcomes of this? And also, what it means in terms of networking and in terms of applications for you.
.
So ‑‑ the big question is like: How realistic are we in a post‑IPv4 era, when do we turn off IPv4? I know this question is always going to come and I'm probably not going to answer it today. But you will see that a lot of things are have already changed, and for me it's really impressive because when I started first talking about this I think it was around 2017, and it has made a change and it's just four years of development time.
.
So, I will start with the company that I'm working for where basically all networks that exist are IPv6‑only or IPv6 first, which practically means that in the daily usage, there is around 90% IPv6 traffic, and from the thinking perspective, networks are only being planned IPv6. Now, some of you will be like, how is this even possible? How can you do IPv6‑only planning? There are a lot of IPv4 devices. Now, I'll show you that once you begin to shift towards IPv6‑only networking or IPv6 network in general, IPv4 just becomes like a little bit of a leftover, and you might make jokes about this in terms of IPv6 has a much bigger address space, this is one of the mainly arguments for it, but it also enables these mindset change from, well, I have almost infinite IP addresses over here and I need to somewhat connect to something obsolete, something legacy on the right side business, just a tiny sub‑space of IPv6. This is very helpful in practical applications.
So, for companies that I work with and they ‑‑ when they go now to RIPE or to ARIN, they go to ARIN and they they request an ASN and an IPv6 block, they don't request an IPv4 block ‑‑ well, first of all, they can't, because it's not there any more, or they can maybe be on the waiting list, the same with RIPE. But fundamentally, the work flow changed, so people go out acquiring an ASN because you need it for peering, but they don't necessarily start with IPv4 any more. Some projects I have been involved in will later go on the open market and apply for ‑‑ or apply for ‑‑ buy, basically, IPv4 space, but it's more an optional point, but it's almost like when the project has been almost finished you can add IPv4 on top of it. So this is a more ‑‑ very different way of thinking if you compare it to a couple of years ago.
.
One of the big advantages I also see is, in network design, you don't plan dual stack any more. This time, it's kind of over. And because you have actually unique address space, you don't have any problems any more with overlapping networks when you join companies, so while we talk about this in the IPv6 world for a long time, that these configs won't be there any more, in reality this is something I really see, and even if you have IPv4, that is the really interesting part, then you can treat it like IPv6 because it is just a subset in a way. I mean, it's an incompetent protocol, but it's still like, size‑wise, it's very, very small.
.
Since Covid‑19 started, a lot of our work shifted towards much, much more focused on remote working, also in terms of maintaining customer networks, maintaining bigger corporate networks, so we are less on site, which is also a good thing in the end, and everything happens in IPv6 only. So, some branches are not yet accessible via IPv6 but in that case, that's quite interesting now. VPN tunnel being used to establish a connectivity there to the branch, but IPv4 is not being used in these networks, any more. So, IPv4 is basically becoming not Layer3 any more but going down to Layer2 and a half, so IPv4 is just a carrier for IPv6; it could equally be IP IX, or PtP or whatever. Basically, if you work this way, there is no reason any more to handle IPv4 in your daily life. It's just a tunnel ‑‑ it's just a cable in the end.
.
Something that really, really made life easier here is when you have IPv4 devices, they usually come with some kind of default IP addresses, 1982.168.11.01.10001, and in many cases, if you have to provision them in large scale, you will actually have conflicts, so you have a device, it configures, say, this type of router, 50 of those, or 100 those, and they will always be incorrect. So either you are in the wrong network or the addresses of the devices will be colliding or you have 50 devices that all have 192.168.1.1. Obviously this doesn't work in one network. If you forget that those devices have IPv4, and many of them are actually IPv6 enabled, you can just power all of them up, they have conflicting IPv4 addresses, just ignore the IPv4 connectivity and use the IPv6 all host which cast address, find all the devices and automatically provision them. This is something that is, in a practical point, it's so much easier. You don't need to do one device after another sequentially, but you just put all devices with all conflicting IPv4 on the same Layer2 network, and you can configure them, nonetheless, uniquely because they all have an IPv6 address. So once you are there, default addresses are not necessarily like the same address, but you access devices by default via link local, and they are discoverable because of the IPv6 all host multicast address.
.
This is, let's say, a maintainability or operational‑wise it's a really game changer.
.
Then, many networks where we help to operate, or operate, are actually using IPv6‑only name servers, even if this is happening in dual stack networks and the main reason for that is if it's a dual stack network and it employs RFC 1918 addresses, the management there is actually somewhat complicated so the infrastructure itself is IPv6‑only and only some part of the clients are the dual stack. So if people are somewhat pseudo smart and they say, well, I will just disable IPv6, then they will not be able to access DNS any more because DNS is only available via IPv6. So this is a standard kind of established in the networking that we see over here.
.
Then, another big thing, and this is also, operationally, a big, big change, if you were to run a client network and you will do IP address via DHCP and you want to have redundant routers, you need to have a state synchronisation, so you need to save the state of one DHCP server to another and you want to see which one is faster or if one is an active and passive. Everything in general in networking, which includes state synchronisation, is a bit of a problem, because kind of two machines then you have the split brain problematic, then you can have three machines then you go into the quorum mode. It really gets tricky when you want to do something with state. State is confusion in general but you want to achieve some kind of consensus, there have been a lot of scientific papers about this and the problem has been solved but it is a problem, nonetheless.
.
So when you go to IPv6, you just ignore this problem because machines can auto‑assign themselves IP addresses and you don't need to have shared state. So you can actually run active, active routers with different priorities because route advertisements can be low, high or medium. And you can do the same thing on the incoming traffic with OSPF or BGP to change the preferences or the metrics. So basically, you can run active, active routers without state synchronisation still working even in stateful mode in terms of like firewalling. So this is another huge game changer when you enter the IPv6‑only era.
.
So both the previous one, like reaching devices and configuring routers, makes your maintenance much, much easier, and this is also something we see being deployed where this is not possible basically in the IPv4 world.
.
When it comes to routing, you probably know, or some of you know that BGP allows multi‑protocol, or has multi‑protocol extensions, and you can route IPv4 via IPv6, which, when you first look at it, it looks a bit weird because you are sending an IPv4 packet through an IPv6‑only host, but in practice, it works. It's also called unnumbered routing, and it basically uses the link local interfaces.
.
So, this Telia allows you to say well you run an IPv6 data plane and all the traffic that's being passed through is only passed on via IPv6, so you don't even need to handle IPv4 even if you route it through your IPv6 network.
.
Then you can argue, well, I still have hosts that are not compatible with IPv6, and we also have those. They are like devices that are very old or they are power plans which are not that often updated. So they have to be in isolated zones, and how we solve it over here is, they can access the IPv6 world via stateless NAT64 SIIT. They can be accessed from the IPv6 world if access is required via state 4 net. Basically, the problem here is the IPv6 world is much bigger so you need to squash down the IPv6 space to one IPv4 address. And if those hosts need access to the IPv4 Internet, so an IPv4‑only host goes via IPv6 network goes back to the IPv4 Internet, then you can use 464 XLat, basically it's two times NAT64 SIIT that you can approach here.
Practically, also, how you can handle it, you can say whenever you have an IPv4 island where you have dedicated ‑‑ a dedicated network segment, you just dedicate a /96 IPv6 network for this. You wrap it in a /64 IPv6 network so it's, like, nicely put away.
.
But in the end, like from an operational point of view, even if you have IPv4‑only islands, you can treat them as such as an island and you can still reach it via IPv6. So there is no reason any more nowadays to say well, like, I have a complicated network design. You can even have IPv4 segments which are completely integrated into your IPv6 coordinate work or in the all ethernet works. This all works, practically speaking, today.
.
Which brings me to NAT64 prefixes. So if you are actually translating from IPv4 to IPv6, we have something that's called a NAT64 prefix. And if you have those islands, you can even, like, let a user, or, like, a company or a customer say, like okay, you get your own /48 space, whatever you want to bridge or build behind in terms of IPv4, each of the parties can do on their own, so they can cut off one /64, which wraps again a /96, and so this way, as a network operator, you also don't need to care about IPv4 any more; you just provide one NAT64 instance on your network which can be used by your customers, and, whatever traffic it comes from is IPv6‑only but can be mapped by their edge devices to IPv6. I am using often here NAT64 as an example. You can also go with map T, map E; they are just different variants, basically.
.
This is really nice, and probably something I really have to emphasise is, this is really also a game changer here because you don't need to reconfigure your network any more to support IPv4; you can go via IPv6‑only, and even leave the freedom to your users' departments, whatever you are handling with, and still let them use IPv4 in their own islands.
.
One thing that is a bit different, when you say everything is IPv6‑only, or IPv6 first, and you have monitoring and let's say you have a monitoring server which is IPv6‑only, well then it needs to use a translator, be it NAT64 or whatever, to reach IPv4 sources, but this can give false positives of what's ‑‑ yeah, false positives ‑‑ because, basically, if you translate the services down, the whole mapped IPv4 networks will also be down, so you need to add like a bit of extra step there.
.
Practically seeing what we see in daily work is that IPv6 resource monitoring has become more reliable and people are more trusting IPv6 monitoring because this is native. And this is maybe also a bit of a change in terms of, like, before, people were saying, like, okay, maybe IPv4 is more reliable. In this regard, it isn't any more.
.
Another small conflict that I don't want to hold back from you is the NAT64‑IP Sec conflict. This requires a modified IP headers and it was primarily used, I think, from my experience, a longer time ago for VPNs but, it's still being used by bigger corporations like banks. So IP Sec really bytes or NAT64 bytes IP Sec and it doesn't want to properly run over NAT64. So if the end points were IPv6 incapable, this wouldn't be problem, but, in practice, often maybe also because of the edge of the protocol, the end points are IPv4 only.
.
So what does this mean actually in terms of VPN technologies, is everything gone bust? No, most of them still work in NAT64 environments. OpenVPN works, SSL VPN works, and for those of you who know about it, WireGuard is a new custom VPN protocol, which is quite interesting, also works flawlessly through NAT64. What they all have in common is, they don't checksum over the IP heard; they are basically more contained as a payload.
.
So VPNs themselves are not a problem in NAT64 environments; it's more about IP Sec only.
One thing that we frequently get asked is, how do I deal with my old servers? What about my old network devices which can only do IPv4 net route? And there is one product that I really want to mention here, that is iPXE, which is also an open source project, you can flash into the flash of your network card, so you can actually upgrade really old equipment, only ten‑year‑old equipment that was tested where you can basically upgrade it to IPv6 compatible. Even if this doesn't work, there is an easy way around it. You can say, okay, I still have hardware that doesn't work for IPv6‑only networking, then you just put in the USB stick and flash iPXE on it so is actually loads the network card and still does net booting and this is like a really affordable approach, you spend something like $20 or whatever and the USB stick plus the working type on upgrading your server. So you don't even need to get rid of them.
.
Sometimes there are cases which we see with ‑‑ where IPv4 is required, and then it can still be deployed by a NAT64 mappings via routing over v6 which only works in the network itself. Or via VPN even like an IPv4 address to go. However, it comes at a cost. Mainly it's management cost, there is also possibly the cost for the IP address, for more memory, for translators, so in general, you can still use IPv4 in the post IPv4 era, but it's getting more costly over time, actually.
.
Obviously, if you are on link that doesn't support IPv6, you can actually do it the other way around, and ‑‑ but, yeah, both ways work pretty fine.
.
So what are the findings here?
.
From what I can see, IPv6‑only networks have really become practical, they are not like a burden any more. They are actually more of an enabler, and IPv6‑only environments are much, much easier to maintain than dual stack environments. And one lesson learned from the last years is also you can basically start rolling out IPv6 and then take away IPv4 step by step by step, like a chocolate cake, step by step ‑‑ chocolate cake maybe goes faster, but you get the picture.
.
And, in summary, so what I want to say here is, like, in practical terms, IPv6 has replaced IPv4. There are no shortcomings any more. There is nothing that you can't do in the IPv6 world and you can coax this nicely with the IPv4 world.
On the other hand, IPv4 has become more like a (inaudible). And with this, I want to close my speech here and I want to say, like, we have really entered the post‑IPv4 world. Obviously, not IPv4 isn't gone yet, but the mindset has changed, from what I can see. This is very important.
.
Thanks everyone for listening.
.
(Virtual applause)
DIMITRY KOHMANYUK: Thank you. I hope you all enjoyed the presentation, and let me take questions. Can you hear me? I am making sure my loudness is fine.
WOLFGANG TREMMEL: You are fine. We have one person asking for the microphone. Dmitry, we can no longer hear you! Okay. Elvis Velea would like to ask a question.
ELVIS VELEA: . (Inaudible).
WOLFGANG TREMMEL: Increase the gain of the microphone, please, or speak louder.
Let me read out the written question then. Perhaps try writing your question. Okay, the written question from Tomas Schafer was: With the recent Linux concerns I have problems pinging multicast all nodes which is source IP GUA. Have you seen similar problems or do you use only link local source for that purpose?
NICO SCHOTTELIUS: Interesting. Very interesting. We actually just use link local addresses for that purpose, mainly I think it is actually only standardised because the group joining in the multicast group is based on the link local address. So I'm not sure if they are actually supposed to answer on the GUA address. But interesting finding certainly.
WOLFGANG TREMMEL: Okay. Another question from Lars Prehn: Nice presentation. Now that handling IPv6 seems to be no longer an issue, what do you think how the remaining service providers back from transitioning?
NICO SCHOTTELIUS: I actually don't think much is holding back there. It's more a question of timing now. It's, basically, if you are already doing IPv6 in your network, you will probably soon go more towards IPv6‑only. If you are not doing IPv6 at the moment, it's a typical question like how much resources do you have left in the IPv4 world? From what I see is also like we are working together with quite a variety of Internet providers and upstreams and downstreams, usually hang IPv6 up or downstream is much much easier than IPv4, so I assume that even the current providers who are IPv4 bound will very soon switch towards IPv6, also when they realise like how much easier it is.
WOLFGANG TREMMEL: Okay. Thank you very much. And I am closing the questions ‑‑ oh, there is one question from Elvis since I am allowing that because the microphone didn't work. Elvis one question. Your question was: Correction, if you were just with the RIPE NCC and you have not received address space in the past, you can receive a /24 and will not put on the waiting list.
.
2. How do you handle devices that fail if they do not get an IPv4 address? This is the last question since we are running out of time.
NICO SCHOTTELIUS: Sure. Thank you. So the devices when not working without an IPv4 address, we put in an IPv4 island. Even if it's just one address it gets like a whole /96 IPv6 network and it has been stored away, basically, in its own ‑‑ yeah, in its own segment.
WOLFGANG TREMMEL: Okay. Okay. Thank you, Nico. Thanks for your presentation. And, Dmitry, are you back online?
DIMITRY KOHMANYUK: I hope so. I think it was a mic issue and I needed to reconnect my headset.
.
So, our next couple of speakers actually, which is a bit unusual, are Stephen Farrell and Patrik Faltstrom, I am hoping that I'm reading those names correctly because I am not native Swedish speaker or Irish speaker. So, please, I guess Stephen is opening and you can use your screen cast if you prefer.
STEPHEN FARRELL: Okay. And I assume you can hear me.
.
So, good afternoon, this is a talk with me leading off and then Patrik ‑‑ the topic ‑‑ the title is, I guess, the encryption debate. I suppose I am trying to provide a bit of background and Patrik's set of slides in the second half will touch more on the debate issue.
.
You can see these slides and the URL.
.
Description is there. It's not going away. And every time over the last 20, 30 years, we have seen newspaper applications where we start to see more rolling out of use of confidentiality encryption. It annoys somebody because it changes what they were previously doing and you may or may not hear kind of the sky is falling reaction, and the sky hasn't fallen, and I don't think it will.
.
But again, we can go back even before the kind of Internet, and I think this is a point that will actually crop back up in Patrik's slides and the Q&A afterwards and maybe some discussion to follow, is if you start right back at the beginning of cryptography or any kind of communications mediums, there was always of a kind of a law enforcement requirement that essentially meant that everything needs to be tappable; in other words, that the law enforcement, if they need, to need to get access to everything. And that has a requirement. Ignore the technology, ignoring how exactly we are using encryption etc., as a requirement that's kind of problematic because it kind of hasn't changed. And yet it kind of needs to. I think Patrik will touch on reasons why it's more difficult for law enforcement to discuss openly about those requirements, or to kind of give up something in terms of admitting that there is some data that they really shouldn't be able to tap. But that requirement has been there all the way from before the Internet. And probably a discussion about the level of requirement might be interesting.
.
Coming a bit more up to date. We saw the kind of crypto wars of the nineties. I am not going to revisit that. What's interesting is, there were, at the time, surveys of what people did of what cryptographic products were on sale. And really what's interesting is not the specific products, is actually the change. In that period, what we have seen really is that, back in the nineties, there was a sort of a set of encryption products. There was a set of companies, I used to work with one, that actually were selling encryption, or selling the ability to do encryption in various ways, but now, in 2016, and now, certainly, this is just a commodity, this is our standard feature of kind of everything. It's not really an interesting set of product category any more. So I think the ‑‑ you know, the debate in the nineties was quite different to now, and what we have now is the use of cryptography to provide services is just a standard set of features.
.
Of course, then we had, you know, Mr. Snowden popped up, and what became clear there was that, you know, the extent of the kind of government level of snooping that was happening in various places was more than a technical community kind of thought of, and there is, you know, again I won't kind of go into the details of the various links and so on, but there was a lot of interesting stuff that came out of that.
.
Part of the outcome of that was in the IETF community at least, and I think the IETF was just kind of broadly reflecting the broader technical community reaction to this was that we kind of agreed that, you know, this kind of pervasive monitoring itself is kind of an attack that we have to, you know, think about and defend against. And yet we also need to do things like network monitoring and so on. There is a kind of a tension there. So we kind of acknowledged the tension and it was clearly one of the reactions to this pervasive monitoring attack, is that if you encrypt things, then, you know, they are less easily attacked, at least from the point of view of monitoring.
.
So that was part of the Internet community, if you like, kind of response to Snowden. And you can see that in various statistics. This is some Firefox telemetry which kind of reflects over the period from post‑Snowden to recently, the increase in growth in HTTPS traffic. You see the same thing if you look at SMTP over TLS or mail traffic, etc. Even the use of private APIs the same is probably the case.
Currently, we see the same with Letsencrypt, is that, now, you can have kind of a reliably reissued pre‑certificates for your websites, and so on, and you can see the numbers growing there too.
.
So what ‑‑ a couple of things just to help clean up where these kind of puzzles, or whatever you want to call them, might arise.
.
DNS privacy has been something that started to be addressed in the last five or seven years or so. Originally, people just assumed that the data in the DNS is public, therefore we don't need confidentiality or privacy mechanisms for DNS. That's clearly not the case because the act of accessing a particular name or doing a query for a name can itself be sensitive, and there is a bunch of mechanisms that have been found since 2013 to improve the privacy aspects of DNS. So XName minimisation, which is not controversial at all; DNS padding, which is only useful if you are encrypting. If you are encrypting using DNS over TLS, that's also not controversial, and then it turns out, when we get something that is used widely, DNS over HTTPS, and particularly that the concept of browsers that I turn this on by default, that becomes suddenly controversial.
.
It's worth noting that the controversy there is I don't think about the encryption. It's really about moving the point of control from where it has been for many years to somewhere new, and I think that's the controversial part really. And again, there is work on all of this, just essentially looking at stub to recursive, there is work starting and maybe to progress in the near future on recursive to authoritative.
There is also things like QUIC. This is a new protocol that mostly encrypts things. And again, if you know people will react to the beginnings of deployment of these kind of things but I have my existing network stuff and now you are going to do things over QUIC and I can no longer see TCP headers or whatever, that's something you need to adjust to. Again I think it's also worth noting that confidentiality or privacy is not the only reason why people are encrypting using QUIC. They want to cut middle boxes out of the conversation for good and bad reasons. So the good reasons might be to do with something in the network, some people might claim is a bad reason is the end points maybe not acting in the end user's in the people's interests and they also want to keep out middle boxes for what are good and bad reasons from different perspectives. But it's not necessarily doing encryption for only for privacy. It's also again to put in ‑‑ you know, to enforce controls on various bases.
.
There is a bunch of newish crypto things that may affect the future. We have seen that the dual stack EC number generator, a case where there was a deliberate attempt to introduce and deploy and promote broken crypto. And so, we need a kind of ‑‑ one thing we needed was a large and diverse set of academic cryptographers, not just people on behalf of the government agencies, etc. This is a kind of real need and it's a real reason we need to creep to cryptography debate on encryption open.
.
The rule changes come forward to do with post‑quantum algorithms. Them change things like packet sizes that will that have interesting implementation deployment effects.
.
People are developing new cryptography algorithms all the time.
.
Some might be used, some might not. If we had fully encryption... that would be great. Also, there's more prosaic kind of challenges for encryption. If we think back to the previous talk, you know, it's kind of hard to get a certificate for an IP address, and for many kinds of IP addresses you can't authenticate devices in particular if they are using, you know ‑‑ RFC 1918 addresses or something or IPv6 addresses that are kind of interesting.
.
So, there is a kind of challenge there to find ways for hosts to authenticate. But in a way that kind of allows the device owner to do what they need to do without that kind of cloudy lock‑in to some vendor's name or whatever.
.
Then we have to think also about just emitting packet, whether it's encrypted or not leaking sensitive information. You know, an NTP query may mean somebody has walked into a room.
.
That's all I had. Again, I think Patrik is going to grab the screen and take over, I believe, and, if not, I'll be showing his slides.
PATRIK FALTSTROM: Thank you. There, let's see how this works. So, let me try to hand my presentation as well and then we can answer questions.
.
Let me continue where Stephen started, and he gave a good background demonstrating, I think that, in a very good way, that encryption is something that is here to stay. We see innovation both on the cryptography side and also on the usage side. We see an interest in privacy, and interest in encryption to be used in various ways.
.
At the same time, we have a different catch, a different group of people that sort of ‑‑ that's we heard sort of between the lines about, and that is the group of people that believe that encryption is bad. We had the discussion not only what you just heard Stephen talk about, we also had the discussion about the clipper chip, that there should be encryption allowed by the back door. We have the UK, in 2017, that wanted to forbid end‑to‑end encryption, and we have the European Union that now, in 2020, is pushing very hard to get back to something chats.
.
So the interest of being able to sort of having back doors or in encryption is something that has not died.
.
But, of course, as I am trying to explain, that is not how it's expressed. It's expressed as if encryption is good, everyone should use it, but...
.
I'll come back to that.
.
So, the problem is that the politicians and people making regulations, at the moment, they think that, yes, we can have encryption in encrypted connections, they will be very safe, they will be secure, we can do all transactions in a secure way, but it will still allow law enforcement to access the unencrypted data. We are to have that at the same time, right, specifically for those people like Stephen that understand the maths behind it. Specifically if you don't want to have a back door, or claim that you don't have a back door.
.
Another thing is, it is possible to limit who has encrypted information and I don't really understand how that should work either. Like, if it is the case that the back door, anyone can use it, anyone that can manage to get hold of the keys or the back door is a back door, and, on top of that, even though people try to build good technical solutions for that, we see breaches every week when people try to do that kind of solutions.
.
The third thing that I hear claims about is that we can allow law enforcement, which is specific entities, to access the unencrypted information about having a back door, and I just don't really understand how that should work; for example, in a situation with TLS and Letsencrypt and whatnot.
.
And another thing is that by sending encrypted 'messages and hashes, we keep secrets. And the problem is as Stephen also explained with the NTP packet, just sending the encrypted packet or a hash, regardless of how good the one‑way hash is, it's still the case that you might disclose quite a lot of privacy issues that you wanted to protect. There you also have a balance that is quite interesting to try to discuss where the right balance is.
.
There is also a belief that criminals do follow legislation. To me, a criminal, by definition, is trying to just do whatever they want to stay hidden, regardless of what the legislation says, which means that anyone ‑‑ all clients will do whatever the legislation requires the client to do, and then, of course, you have people doing clients that do other things as well. So, the problem is that people believe that you can have all of these things at the same time, and this is something that started already, as Stephen explained, like many many years ago, and it's still ongoing, and my main message for this session is to get everyone in the RIPE community to understand that this discussion is not dead. We need to continue to be active and remind people.
.
Here is an example from a proposal in the EU ‑ many of you might have seen this ‑ where ‑‑ which is one proposal, a possible solution on how to block and how to control the messages even though they are encrypted. So the sending device is supposed to send both a full message and a hash and the hash is not end‑to‑end encrypted and then the hash is going to a specific up‑server for review, and this is one thing that is on the table at the moment to force and require every protocol that is end‑to‑end encryption to behave like this, every protocol.
.
Of course, it's only talked about in the context of images and protection of children and all that kind of stuff, but, between the lines, you can see this is something that people want to have all over the place.
.
Another way of implementing this, which is another proposal, is to require anyone that has end‑to‑end encryption ‑‑ of course, end‑to‑end encryption is always going through the Cloud, right, so anyone ‑‑ everyone must have a secure enclave in the centre that is trusted, and inside the secure enclave you can access the unencrypted data even though it's end‑to‑end. I just don't understand how that should be implemented either, but there are people that, as I said... something like this, I have no idea how it should work, it's just weird.
.
So, the European Commission, the guiding principles, which I don't really remember the date, but it was like a month ago or something, was the last ‑‑ the latest published principle. There might have been an updated version of this, but it really talks about that an optimal solution is the one that would allow users to enjoy the benefits of encryption with regards to privacy and data protection while allowing law enforcement agencies to preserve their capability to lawfully intercept communications or gain lawful access to encrypted devices and encrypted data when this is warranted by a judge, prosecutor or similar empowered official.
.
This is what the Commission is telling the politicians in the EU at the moment, that this is something that is possible to implement, both technically and in legislation.
.
Okay, let me get that out to you, all of you.
.
Think about what this implies.
.
So, here we have one thing that increased the volume and people believing that this message is true, is of course the incident with Encrochat. Encrochat emerged in 2016. Most of probably read in the news it's a messaging app which routes conversations through a server based in France. It's also the case that the devices themselves are updated from this server and the Dutch police, with the police in France, collaborated and managed to inject the malware that managed to get them to read the messages before they were sent, manage to get them on the phones, and that way they managed to collect data from the conversations for quite a long time. The data was then distributed to other European partners, including the UK, Sweden and Norway, using this as evidence in various court cases, how ‑‑ there are still many many open court cases and so we'll see what happens with this.
.
But any ways, this is something that the law enforcement says, oh, this is great, by doing this this way, implementing this way, it worked, we can catch many criminals, so every chat service should be designed by Encrochat and they should be that by law. So they are pushing at the moment quite hard.
.
In each one of the member states, and of course I know Sweden better than other countries, we have both norms in the society, but also legislation that is very picky regarding the difference between legal intercept and also data retention. And, for example, in Sweden, the law enforcement need to ask to be able to intercept messages or via tap for a specific individual, must be a suspect, etc. They are not allowed to do phishing with the help of wire tap. If I exaggerate a little bit. But the question then is, is Encrochat a phishing expedition or is it something where they are really targeting suspected parties? Or is it a situation where law enforcements are using weaknesses and differences in the legislation in each other's states? They are all pretty interesting questions.
.
The problem at the moment is that this discussion about these issues are discussed more or less without the technical community, more or less without us.
.
So, the problem with that, to some degree we are stuck, or I would hope that we are at least stuck. Law enforcement do have problems to have some of these discussions in public because they cannot disclose their tactics, of course, because, as we already concluded, criminals are not following legislation; they are just trying to do whatever they have to do so that law enforcement cannot catch them.
.
Civil society and technical community must have the discussion in public. It has been a little bit too silent the last year, I think, and that's why I requested, together with Stephen and a few others, to actually have this presentation to wake you up, don't fall asleep, it's not over yet.
.
Unfortunately, as I showed with some of the arguments, it's like forcing a round peg in a square hole, and just because that's what's happening at the moment, we must be participating in that operation.
.
So the ‑‑ so this is both a technical problem and a legal problem and I think both civil society ‑‑ this is exactly why we need the multistakeholder discussion. We need to have law enforcement and technical community and civil society and we need to have constructive suggestions in what to do, not only what can be done and what can not be done, etc.
So, as Stephen explained, all the Internet communication today, is actually encrypted in one way or another, or we, from the technical community, together with others, are trying to ask people to use TLS to have the communication encrypted, to have secure robust services, but, unfortunately, that's the square hole within which people are trying to force a round peg.
.
Thank you. And I'll take questions.
.
DIMITRY KOHMANYUK: Thank you, Patrik and Stephen. It's an exciting topic. The chat is steering with all the comments and some great quotes. So let me read from ‑‑ well, it's actually not that many, but let's start.
Alex de Joode from AMS‑IX ‑ well, it's a comment, but I'll read it anyway.
"Under the Portuguese EU presidency, July 1, 2021, I expect a proposal with regard to access to E to E, URL follows."
.
Olaf Kolkman, Internet Society:
.
"I'd like to offer additional comment at the end of Patrik presentation.".
.
Olaf, you will get that.
.
Then, Vladislav: "How public interests... production, blocking pirate and extremist sites, law enforcement can be secured in case of DOA, DO T implementations."
So you guys can ask for that.
STEPHEN FARRELL: There is various processes. Some of the DoH processes, some of the public recursive services will offer both an unfiltered version and a filtered version on a different port or a different TOH URL and so on. I suspect deployments will kind of address these problems to the extent that you believe that these things work, I'm a bit sceptical but some people do like them and them become available.
.
DIMITRY KOHMANYUK: Thank you. Andrew Campling, at 419 Consulting:
.
"Excellent presentation. I agree that an open multi‑stakeholder succession is needed. Given the many transgressions by the companies is the focus on the encryption really an attempt to divert attention from surveillance capitalism?"
.
That's a good one.
STEPHEN FARRELL: Yes and no. Personally, I think that within those tech companies, there are a whole bunch of people who have this set of interests that this community has, and are genuinely trying to improve privacy. And those companies like to make money and they do it. I think the answer is yes and no.
.
DIMITRY KOHMANYUK: Well, it looks like there is no way to answer this question.
PATRIK FALTSTROM: No. And let me pitch in that regarding what Alex wrote about the Portuguese EU presidency. I think the slides that ‑‑ the pictures that I showed is actually from an earlier version of the proposal regarding end‑to‑end encryption. It's also the case ‑‑ a little bit unfortunate that the commission is claiming that they have had meetings with the technical community. In reality, they have had closed meetings where they invited certain companies and certain big companies, and then went up in a question how open had that discussion been, which falls into what Stephen just said, that even within the large companies, like Microsoft and Facebook and others which have been been at some of those meetings, of course they have split interests in different parts of the companies where, for example, Microsoft, they have a very interesting, what they call some kind of I don't remember the exact name, some image DNA like thing that they would like to ‑‑ it's simply a technology that they would like to sell on top of, of course, a company's corporate social responsibility will help to protect children, like all companies and others will do, but they all try to sort of make money and then sell their specific idea to the community.
.
So even in the balanced discussions that all of us should participate in the multistakeholder discussion, there might be lobbyist and open source solutions. The good solutions are the ones that Stephen talked about I think between the lines, where we all agree on open standards, good balance, how to detect whether there is a policy in the network to use certain DO T and DoH servers etc. And allow the ability to choose as well as to implementing a well‑informed legislation. Thank you.
DIMITRY KOHMANYUK: Thank you, Patrik. And thank you, Stephen.
.
Olaf Kolkman wanted to say something. I granted him video rights. We still have a couple of minutes.
SPEAKER: Excellent presentation to the both of you, Stephen, Patrik, thank you very much. I am Olaf Kolkman, I work with the Internet Society. This is a topic that is of great interest to us. And just to stress that this has ‑‑ this is a moving target right now. There is an open call in Maritius with a weird proposal, I should say. The UK has just launched its online public safety bill which contains no explicit mention of encryption, but is a regulation that is target outcome, like we want to start gravity from happening, that sort of idea behind it. There is movement in Canada, there is movement in Brazil, there is movement in Australia. This is being phrased as a safety versus security topic. And we need people who understand the technology that can explain how things work. I think that's very important. I think that is the call that I heard from Patrik. Get engaged in this conversation. If you are interested, I would like to point you to the global encryption coalition which is, if you Google for it, which is a coalition of NGOs and individuals what are interested in preventing encryption to be attacked in that way. So that was what I wanted to share.
DIMITRY KOHMANYUK: Thank you. Do you mind sharing the link in the chat for those?
.
And I guess we are checking for the one last question, audio or tech show? I don't see one yet. So thank you all, presenters. I had my best day: IPv6 and DNS security. What else can I wish for? Just to shake hands with all of you and that will be perfect.
.
So, with that said, thank you to our wonderful RIPE staff. Is there another question? We really are short on time. Let me see ‑‑ Valerie, you will get that minute, but that's pretty much all. Thank you. Valerie, do you want to say something? Because maybe that's a mistake.
.
All right. Thanks, everybody. Please don't forget to rate the talks. You can do this from the meeting programme, and see you in our next Plenary session, which I believe is in one hour. Check the schedule. Thank you.
.
(Coffee break)
