 So I feel free to ask any questions, like just raise your hand, interrupt me, and if it's a question's too big, I'll like, we'll take it offline somewhere else. So I work for the LibreSound project, that's where my main focus is on, and Red Hat lets me do a lot of work on that, so it's really nice. Most people know us from being the enterprise IPsec solution. It works really well, but we also have this other leg of our project, which really has its aim to encrypt the entire internet. And we're not there yet, but we're hoping to add more and more, but as I'll show you in some of the history, that's been a really long, slow project. So yeah, we've done recently a lot of certification stuff to get our code into good shape, and we actively are at the ITF proposing new standards and extensions to Ike. Not so much for IPsec, because it's defined and it works, but for Ike, we do have a bunch of things that keep getting proposed and added to the standard. So we're pretty active there as well. So for those of you not very familiar with IPsec, this is the one-slide explanation of IPsec. It consists of two part, Ike. That is interesting. That scrolls fine here. So what do I do then? Unplug? Okay. Is that full screen? No. Too high. Okay. Okay. Thank you. So now I won't be able to read the slides, so I'll be working around a bit more. Sorry? Oh, sure. If that doesn't crash my laptop for... Yeah. I had a lot of windows bars. Okay, awesome. Thank you. So try not to block the screen. Okay. So we'll try that. So IPsec basically consists of two part and it's a little bit confusing because people tend to call it IPsec, but IPsec is really the data channel. That's where all the packets are encrypted and decrypted. It's the kernel that's usually doing that. And then we've got Ike, which is the command channel. So that's your userland application that sends the negotiation packets to authenticate the other peer and then set up in what they call Ike association. And after authentication, they agree on some key material and then they send that key material to the kernel that will then do the encryption. And there's some parameter negotiation as well, which IP addresses are allowed. IPsec is not a virtual ethernet where you can just throw anything at it. You're supposed to really climb down on the policies of source destination address sports protocol, even though a lot of VPN people don't do it and they just build a tunnel from zero, zero to zero, zero. That's not really how we like to see things done. What else? So Ike itself is encrypted. Don't mistake that for the encryption of the packets. Those are two separate things. And some weird things is that we have two modes, tunnel mode and transport mode. Transport mode was supposed to be the simple one where you have a source IP and a destination IP and you yourself are the source IP. So you can use that for the encryption and protect the packet itself so you don't have to encapsulate the packet. But because we invented NAT, we sort of destroyed that usability in a reasonable way. So tunnel mode is the much more preferred option these days to use. And because there are also many firewall administrators that tend to block anything not TCP and UDP because they don't really know what the other things are, they sometimes tend to block the ESP protocol, which is protocol 50. And so there's also a mode also for when you're behind NAT is to encapsulate it into UDP packets. So it's literally just putting it in a UDP packet pre-panded with four zeros to market and send it out. So that's ESP and UDP. So let's see. Do I have range? I have range. VPN, two insecure networks, very red. They're not encrypted at all. They're all talk plain text in the cloud or in the data center. And except when you go across the internet, do people go, okay, we should encrypt this. Let's put some gateways in there and they do the encryption there. And those are usually your choke points, single point of failure, maybe dual point of failure if you've got like a hardware failover set. And usually these machines also are fairly expensive if you're doing like high bandwidth stuff. The licensing costs go up. So it's the traditional way of doing it and we can do much better. This is the other traditional setup. It's where you've sort of got the remote working setup. You're roaming. You connect to the corporate VPN server and then you again get access to the network. But that network itself again is completely in the clear, unprotected. And so half of your connection is still sort of in the clear. Luckily we all use SSH and HTTPS, so it's somewhat mitigated, but we still leak a lot of clear text packets. So to give you a bit of history, this goes all the way back to 1996 when John Gilmour started the project and was like, you know what, we should encrypt the internet. Let's start with in 1996 to get 5% of the internet traffic protected against passive wiretapping. So we kind of failed on that. But it was a really good start. The idea was opportunistic encryption. John Gilmour didn't really give care much about the enterprise VPN. He was like, well, those people have money. They can come up with their own thing. What I really want is to encrypt the entire internet. And that means encrypting between two parties who've never heard of each other before and who not necessarily trust each other, but they just want the communication to be encrypted. So some people sometimes ask me what the swan stands for. There's a few forks you'll see in a bit. Swan stands for secure wide area network. It was trademarked by RSA, so people stopped using it even though the FreeStrom project had some permission to use it. And so instead the term VPN became really the common term that everybody started using. It predates open SSL, which means there was no crypto library that the project could use. It all had to be written from scratch. There were no protocols yet. So the RFCs hadn't been written yet for IKR or IPsec. So they were part of the efforts of making the IPsec and IK protocols happen. So they joined the ITF from the start and tried to make this happen. It took a really long time. One famous quote from Gilmour is that the NSA tried to slow down the project and add to many features. And I think the quote is a little bit out of context because we were really our own worst enemy, you know, designed by committee kind of things, delivered these kind of solutions. And I don't think that NSA actually deserves credit for that. I think we really all did it ourselves. It predates the crypto API for people who are old enough to remember kernel i.org and export laws and all these things. So all these problems were added to the project. We want to encrypt, but where do we publish the source code? We can't publish it in the US because then it's export restriction, so it has to be done elsewhere. And Americans cannot touch the code because at the time President Clinton could order via a national security letter that if Americans touch it, it's Americans and nobody else can use it. So what happened was that most of the development actually happened in Canada because no Americans were, you know, John Gilmore did not let Americans touch code, which also caused a problem because at the time the network maintainer was Dave Miller. And so there was quite a bit of friction, like he didn't want to pull it into the kernel if he couldn't maintain it and change it and patch it. So there's this weird standoff that caused basically the kernel part of IPsec to live outside of the main kernel like up until like the early 269 days. And so all this time there was this separate kernel module called CLIPS, which Richard there maintained a bunch of it. And when he left, I was forced to take over some of this gluing. And the history with the absolute Halloween before Halloween, that's when Dave Miller checked the pile of IPsec stuff. And one of my first times that I actually met some of these kernel developers, and Alan Cox and Dave Miller, was when the Freishand people and the networking people got into a room together and said, OK, how are we going to hook this together? And in the end, I was decided to use the routing because there was nothing better than routing into some device that gets tied to a kernel module that can then do the processing. The most interesting part for me at that meeting was I was a pretty new person to it. I didn't have much experience at all. Was that in a room full of kernel experts, only Alan Cox was able to go to the whiteboard and say, this is how the packet flow works in the kernel. You go through this part and this part and this part. And I was like, it was already really complicated. And we're talking about 2.0 kernels. So these days it's orders of magnitude more complicated. There was also no DNSsec and not much of a CA industry at the time yet. So one of the big problems was key distribution. Like, how do you distribute your keys to basically strangers to validate those keys? If you're talking to someone with no pre-configuration, how can you trust them that they are who they are? And so the solution was sort of embedded in, well, we'll do it in DNS and make sure that DNS gets secured and then later on we can build on that. Unfortunately, that took a really long time. So what happened? Well, it really worked really well. Like, enterprise setups with IPsec worked really well. During interop tests, like FreeSwan was the gold standard. If you interoperated with FreeSwan, you had a properly working icon IPsec stack. Like, it was really the cornerstone of IPsec. So that was good. Things that didn't work out as well, it took a really long time. So the development within the IETF went really slow. United States citizens couldn't touch the code, so there were less people that could actually do things. The other big thing was, because everything was packet triggered, it meant that when the kernel would send a message to the use lens saying, I've got an IP packet from this source to that destination, and you want a tunnel but I don't know anything else, then the ICD man had to go figure out, OK, this is a source destination, who is this? Who's talking to who? Where do I find the authentication of this person? Where's the identity? And so the only method that was available at the time was the reverse DNS. So we said, OK, well, we'll put the key, the IPsec key, in the reverse DNS. And then by the time later on when that gets secured with the DNSsec, then we will have a really good distributed authentication mechanism. The problem was that basically the reverse got abandoned. Like, for IPv4, you could really only get to it when you were in the data center. If you're an end user at home on your DSL or your dial-up line at the time, you just had no chance of getting access to your reverse. So from a practical purpose, that just never worked. The other thing that was problematic was NAT support. Like when NAT really started to become so common, you didn't even have an IP address that you could attach to yourself. So you would have this asymmetric thing where you could connect to a server and you would know its IP address, and maybe you could from its reverse get the identity and then look it up. And then you yourself could then tell the server, well, I'm really this entity. You can look it up in a forward DNS. So that could work. But then if you had two entities on dynamic IP address, it wouldn't work. Or if you wanted to connect to your neighbor, it wouldn't work. So it was fairly limited. And that's the other problem. Like, to make this work, you had to have an identity. So your laptop or your phone would have to have an identity that is published somewhere somehow. And that really didn't work very well. And the reason that SSL actually took off, as it did, was that it didn't require the client to authenticate itself. It could just authenticate to the server. The server didn't really care who talked to it, as long as it was encrypted. And it was fine with whomever. The unauthenticated encryption. So let's just do Diffie-Hellman, do a session key, and not bother authenticating. It was rejected by the project at the time. It said, this is just too insecure. Let's not do that. It's really easy for a passive attacker to become an active attacker. And it offers no real protection. Now, had they known that everything would take 15 years, they probably would have said, OK, let's start with this, and then we'll bump it up as we go. But they didn't. So it was another 15 years of massive monitoring and storing of data that people could do. DNS stack, it was really slow. Like, 2010, the root finally got signed. Now we're finally seeing enough support on end nodes that they can actually use it and validate and not have DNS packets drop, or Cisco firewalls drop, DNS fragments, and other things. So it's finally now becoming useful. But then the other main point was this. These are all technical points. The other main point was that even when in 2001, the echelon network was outed and published to the world at large by Duncan Campbell, people didn't really care. Like, they're not spying on me. Why do I care? Like, this is also sort of before everybody's life was attached to their mobile phone, where all their data and email and everything came in. So they didn't really care. Like, I don't have that much to hide. So meanwhile, so John Gilmore gave up. He's like, I've funded this for, I don't know how many years, seven years. He was like, I'm done with this. The only people really using it are the enterprise VPNs, and they can fund it themselves. Like, I'm not doing this. So I met up with John Gilmore at the CCC in 2003 in Germany, and we sat down and was like, OK, how can we do this? So we let's fork this nicely, because we're still good friends, but he just wanted to pull out. So what happened was that we agreed to fork. We used OpenSwan as a working name. It couldn't come up with anything better, so it stuck. And John did some, he talked to Snire and Niels Ferguson. They decided, let's do a paper that says, all the bad things by IPsec. We'll strip it out of FreeSwan as a demo to see that you can do this. And then we'll just never do a FreeSwan release again. So that's what happened. FreeSwan 205, 206 are releases that removed transport mode, AH, NAT support, and I think there was some X5 and NINE support that got yanked out. So they were like, these are all evil things. We yanked them out. And so, of course, nobody used it. But John made this point. Meanwhile, a company was founded, plus the OpenSwan project was founded, two separate entities that one was supporting the other, moving forward. Red Hat actually got a bit involved and hired the company to do some things. They supplied the native IPsec packages. So meanwhile, the XF-RAM net key stack got added to the kernel in about 269. It took a few iterations before it was usable. And it actually took a long time, I would say probably until late in the 26 early three series that it's really got all the features that we wanted. And I'll list them later on. But for OpenSwan, it was folded into REL6. It became even more of a standard enterprise solution. There was some hardware acceleration support added to OpenSwan, not used in REL. It's OCF-based. That was the Open Cryptographic framework from OpenBSD. That was the Dev Crypto device. At the time, it was really important to have the hardware drivers accessible in USALENT because it was still cheaper to copy the whole thing from USALENT to the kernel, have the kernel do it with the driver and then push it back. It was still faster than for USALENT to do it without acceleration. Meanwhile, we've reached a point where that's no longer true, USALENT has access to direct AES instructions. So all of these things are no longer true. So it's since also been removed. Ikev2, the successor to the first Ike protocol, there are some things that people really didn't like. For instance, the worst thing was that if you did pre-shared key authentication, the only way you knew that the other side and you didn't agree on a pre-shared key is if you got garbled stuff and you couldn't decrypt it. So the error messaging was horrible. Like, I cannot decrypt your packet. Maybe your pre-shared key is wrong? I don't know. So there are a few extra things. Also, Ikev1, both sides were responsible for retransmitting, which gets you into this really denial of service thing where amplification attack, where you send one spoof packet to an Ikev1 gateway, and it will start sending like 10, 20 packets, depending on the exponential backup that they've implemented. Akamai actually did a paper on that a couple of months ago. So that was not good, but people realized it. So in Ikev2, it's the sender's responsibilities. Only the sender retransmits if it doesn't receive an answer, and the responder never retransmits. Unfortunately, we had no funding at the time for opportunity encryption. Like I said, no one really cared. There was nobody behind it. So it sort of fell off and didn't get used very much. And 2011, 2012, the company that was related to this but didn't own the project sort of fell apart, and there was a discussion on who owned the name or not. There was a lawsuit, and at some point we decided this is better to rename our project and to spend more money on lawyers. So that's how we got to LibreSwan. It's really a continuation of OpenSwan. It's got the exact same people behind it. And so LibreSwan got into REL7. It meanwhile got into REL6 because at some point backporting things was just too hard, especially with the new FIPS code. And there were just too many changes. We couldn't backport it anymore. It's like five years of code was being backported. It was just unsustainable. So I finally managed to convince people inside Red Hat to get rid of OpenSwan and put LibreSwan in. So lots of updates. Where in OpenSwan you could optionally use NSS or the old, old, old pre-open SSL crypto code, all of that legacy was removed. NSS was made mandatory. We removed all the X5, Y9 code, ASN1 parcels. Everything was outsourced to NSS. Cryptosweets update. So we removed things like Blowfish and other things. And well, Single Desk was never supported. Some older ModP groups we also, we were always pretty progressive compared to other people. So we never supported ModP 768. We did support ModP 1024 and 1536. And now we're actively pushing those out as well. So for IGV2, we started with ModP 2048 and accept higher. And I'm actually part of, within the ITF of both the documents for ICANN IPsec, the mandatory to implement crypto algorithms. And we're pushing it even further out to make sure that all these old algorithms are going away and we're focusing on the new ones. Just a question? Or are you looking at it? Sorry? You're looking at it. Yes. The ITF, yeah, the ITF working group has looked at it. And there's a proposal to basically what the ITF wants to do now is they want to put a stop gap in for post-quantum computers. So if they now start collecting all the data and 10 years from now, they have a quantum computer, we want them not to be able to decrypt the last 10 years of traffic. So this allows us to sort of defend without knowing what a quantum computer exactly will look like. So the idea that's been floating around now is that we'll use a post-quantum pre-shared key, which kind of sucks because the whole idea of IK was to not have pre-shared keys done. But so for now, people who want it can do an additional pre-shared key. You can send an identifier in the first packet so you can list where you want it, or it could be like an entanglement device with a light beam, or it could be a one-time pad, or whatever construct. You send the identifier and the other party knows what the identifier is, and the manual middle doesn't. Then we do a regular, what's likely? This is all draft material, so it's not guaranteed yet. The idea is that if you care about the IK essay, which is just a command channel, which normally you don't, because 10 years from now, who cares what the command channel is encrypted to, you cannot do anything with it unless you can decrypt the keys. So you really only want to protect the IPsec keys, and you don't care so much about the IK keys. So with that protection in, there is still a mode where people say, well, we also want to know because you can have address assignments happen inside IK, and maybe that will reveal who it was because he always gets the same address. So for that, the idea right now being floated is we do an immediate re-key with the post-quantum key mangled into the key material stream, so to throw into the KDF. So then, at least, the first IK exchange, they would be able to decode 10 years later, but then the next one that immediately comes out should be fine. And then, of course, there's also the post-quantum protection for the IPsec keys. So that's the sort of stopgap people are now thinking, and it's also independent of any of the designs of hardware and things that they're now doing. OK, so we got to the point again where we sort of could look at 10 years of past or 7 years of past. Let's look again if we can do opportunistic encryption. IKV2, one of the features, as well, is that it allowed asymmetric authentication. So like TLS, we could say the client can identify differently from the server. It didn't support null authentication yet, but we added support for that. I'll show it in a sec. IKV1 also didn't really natively allow a nice address assignment, and in V2, that was more internalized, was more fundamental to the protocol. So we know that everybody has the support. Same for like, on IKV1, they bolted that peer detection on later, and so you didn't know if the other end would support that peer detection, but with IKV2, it's part of the core spec, so you know everybody supports it. And the same for natural reversal support. Like, you couldn't guarantee that it worked for any client, but now in IKV2, you can. So we've got all these features that are now ready for us to actually much better see what the other end point is capable of and actually use this, because we will need some of those features. Linux XS4M was vastly improved between the early 2.6 and now. I'll go on a little on the sidetrack, actually. When people talked about earlier about bugs that live for seven years, I will give you a bug that is still living. The early draft for SHA-2 in encryption was to use, for SHA-256, the truncation was set to 96 bits in the draft. When the RFC was finalized, it became 128, like half the key size. In XS4M, there's the struct XS4M auth, which you can only specify a key size, not a truncation size. So whoever, I don't know who decided this, they decided to leave the old draft truncation in and come up with a new struct called XS4M auth trunk where you could specify the key size. So basically what they did is they left the default the wrong non-RFC value. And so some software that was actively maintained, like LibreSwan and StrongSwan, they started using this new method and they had no problems. But it turns out that, for instance, if you look at IPsec tools, Raccoon didn't get updated to that. So now we have, what was it that they said earlier, 1.4 billion devices that cannot properly do SHA-2 authentication with IPsec. I tried to convince people earlier to just get rid of the 96 one, or at least allow the 96 one only through the new mechanism with the truncation set. But they decided, I guess, that to be compatible with was already out there to keep it. And I think this really shows that was the wrong decision. Now we have 1.4 billion devices that do the wrong thing. And we didn't have that seven years ago when this was first came up. So if you ever run into a similar situation where there's an old thing and a new thing, try to do the new thing per default and let people deal with how to do the compatibility mode. Try always to move to the new thing and drop the old thing. The other thing that came, because DNSSEC has now started to move to the end node, because you can only use secure DNS if the last one is also protected. So you have to basically run it on your phone or on your laptop to get the full protection. So that actually allowed us to sort of see the DNS lookup and see the name and what it resolved to. And so earlier when I said we only had packet triggers, we only had source destination address. But now if we hook into the locally running DNS server, we actually have a name and a destination address. So then we can go lookup for the key in the DNS or at whatever LDAP or active domain or the blockchain. Wherever you think you can find a way of securely pulling keys, you can pull your keys. And that is an advantage that we're gonna use as well. And Linux contract actually got a lot of new features. So you can actually now match with IP tables. You can match based on if there's an IPSEC policy. You can say this packet can go through only if it would get encrypted or this packet can only come in on port 25 if it had been encrypted. So you get a lot of extra flexibility in there as well. So the only thing that we looked at it's like, okay, we're ready, we can do this now, we can do opportunity encryption. But there was still the one big problem that people didn't really care. So that's until this slide came along. For those who recognize it, the Edward Snowden slide on the NSA, where they said, well, this is all where the plain text lives that we can sniff and this is all where we can add and remove the SSL so we can see what's happening. So suddenly, literally everybody cared and I guess I don't have to explain it further in this audience. But everybody now wanted that data centers protected the cloud instances, there, the MPLS was suddenly, everybody always assumed MPLS. Well, it's just from my vendor, it's secure, it's private, it's not shared with anyone else. And suddenly I would just like, shit, we need to encrypt this as well. We can't trust anyone. So it's really good for us. And for us, we came to the realization that actually, opportunity encryption is the same as cloud encryption. You just want an easy way for all members in your cloud to continuously mesh to everybody. And in a way, it's the same thing as internet-wide encryption, except where you pull the authentication keys from, where it's from secure DNS of your internal zone in your cloud or a public DNS on the internet. It's sort of the same thing. So that's good because now we can sort of look and I presented this to Red Hat and said, this is what we need for the enterprise encryption. And meanwhile, for free, I will get internet-wide encryption. So some of the ITF responses, they first defined that pervasive monitoring is an attack. So any plain text is basically considered a weakness and we must fix it. So that's a good point from the ITF. And second, they tried to define opportunity security. It started with defining opportunity encryption, which is really hard because the original popularity of the term came from the FreeStrom project. And what they meant with opportunity encryption was two parties with no pre-arrangement. When we find out they have a, the other side has a key, we are going to encrypt to that key. And if it fails, we're going to heart fail. What people now mean with opportunity encryption and that's why they sort of renamed it opportunity security is that, okay, let's try authenticated encryption. And if that fails, let's try unauthenticated encryption. And if that fails, we'll do plain text. And of course, if you have a good indicator that there should be mandatory authenticated encryption, you will not do the downwards attack. So the terms are a little bit different. But we're still going with the original. If you can find someone's public key advertised in a secure way, we take that to mean you must use encryption because they publish their key, they don't want plain text, they want encryption. So we first defined a null authentication for Ike so that we could do the SSL model of being anonymous, connecting to a server because that means all our laptops and phones can use this without having to have a key or publishing mechanism or anything. And the second part is how we deal with the NAT. And I'll get back to that. So first, the Linux IP second implementation, basically how it works is you've got a security policy database and a security association database. So one is basically the states between the endpoints, like the gateways, the IP sec machines. And the other table is basically the policy table of source destination addresses that are allowed to go over it. And they're linked with what's called a rack ID. They're linked to two together. So when a packet comes in, it's matched to a policy. The policy links to a state. The state has an encryption of a decryption key and you process the packet and then you send it on. And for each policy for which you don't find a state, you basically generate an acquire to use a land to anyone who's listening to the request for acquires and say, hey, I've got the packet that triggered this policy but I have no state. Maybe you wanna go do something about that. And then the Ike daemon can go, do Ike to the remote peer, set up a state, inject the key and be ready. And meanwhile, you have to do something with the packet you are about to send out or receive. Like the packet you receive does nothing you can do if you got it in the clear. But if you have a packet that you're sending out, then you can prevent it from being sent out. So that was actually a big problem because up until the three something series of kernels, the packet would always be eaten. If we generate an acquire, it would mean the packet is gone. Like it doesn't live anymore. So for things like ICMP or UDP doesn't really matter because the application will resend it. But for TCP, that was really a problem, especially if the TCP time was long, people are really seeing delays. So I was hoping that this would get fixed and actually only find out about a month ago that it has actually been fixed in a three series kernel now. So they actually cache the first TCP packet and once the tunnel comes up, they remember that they cached a packet and they send it out encrypted. So that was a big problem of the opportunistic or the on-demand tunnels in general that we couldn't do that. And now we can. So that was a really good point. So this is how it looks like. So the top half is the policy in a kernel. So you can see in this case, this is me on the Red Hat VPN. They assigned me the address 10, 3, 2, 30, 191 and it's destination 10 slash eight. So that's the IP ranges that are covered. And for all of those packets that comply with those ranges, they will get encrypted by the key from the state that you see listed on. And so the IP addresses at the bottom entries, this is the remote and this is the local IP address. So these are the IPsec gateways and above it is the policies. If you use the IPXFRAM command, you see a whole bunch of policies as well. For instance, we do a thing like we poke a hole for the Ike port. So you can never have a conflicting policy that says, oh, you should have encrypted your Ike packet with IPsec. So we poke holes in. So it looks quite ugly when you do IPXFRAM pull but I simplified it for this slide. So what do we want to do for opportunistic? We want to make sure that every device that supports it can talk encrypted individually to the server. So there's no man in the middle, there are no gateways that collect traffic on behalf of others because even though the original freesaw implementation allowed you to specify a gateway, you could say like the entire slash 24 has to go to data IP address. But since that was defined in a reverse DNS tree, they sort of were authoritative for that IP range. Since that didn't work and we have nothing else, I cannot ask anybody who is authoritative for 1.2.3.0 slash 24. So we abandoned the whole concept of gateways. So it can only be host to host for us. But if you're a laptop or a phone, you can go through that or not and you can connect to those servers if they support it. If they don't support it, you'll just get like an unencrypted link which I marked here as red. But you could of course also run it. Like let's say you have a little router at home and all your devices, whatever your smart TV doesn't support this for a while, you can have your little device do all the opportunistic encryption, it will just take all your connections. And since it's triggering with the same mechanism, the netting it does for the internal net is separate from the IPsec encryption it does for upstream. So it will just work as well. So the problem is when you're behind NAT, you have an IP address. Let's say in this case, what did I pick, 192.168.2.45? There could be many people with that same IP address. So if you inject that policy into your kernel, you're gonna get conflicts. If you talk to different people with OE and you have the same pre-net IP address, then how is that server going to distinguish between the two sides? So one solution would be, well let the server assign an address to the client. So now you've moved the problem, right? Because now the server has no conflicts. It can take a thousand clients and hand out a thousand IP addresses and it's happy. But now the client connecting to two different opportunistic encryption servers can get assigned the same client and then it gets confused about what one wants to do. Plus if you do this, you really don't want your laptop to have 10,000 IP addresses for every stream it talks to any remote machine on the net. So we wanna have a method where we don't have to configure the IP address locally and we don't have conflicts. So what we've done is we added another IPsec policy rule you can see in blue at the bottom. So you see the first three is the regular set of the client address obtained. So the 16040.2 was given by the remote server to the client. It installed that policy in the remote service to 131. So it installed the standard three rule policy but then it also installed an IPsec policy from its pre-net IP address. And the only thing we do there is we're going to catch it. We're gonna catch the packet. We cannot actually encrypt using that source address because the remote end would actually drop the packet because it wouldn't match the policy. But we'll use it to just grab the packet. And then in IP tables, we're adding a rule that says, oh, by the way, not this thing to whatever the IP address is that they gave us. So now we basically, we don't have to configure the IP address it only sort of lives in the IPsec subsystem. So the server assigned us an address and it only lives inside the IPsec system. It doesn't get exposed to the machine itself. You don't have to configure it. You don't collect IP addresses. Now the only problem with it is that it sort of interferes with other rules that people might put in the IP table. So because it really only applies to IPsec, I'm hoping that we can push this actually into the IPsec subsystem so that we can do an XFRM call to the kernel saying I want it to be IPsec and added to this third address and then that the kernel will do it all by itself without having an IP table's entry. Any kernel hackers that have nothing to do, please approach me. So how do you configure this? So again, we're trying to make it as simple as possible and so really my slides should just be way too simple for everybody. We're looking still at making it simpler. This is still not as simple as we would like and we've had some feedback from people that said that they find it confusing. But currently we have five different what we call food groups. Block, clear, clear, private, private and private are clear. Block basically means drop all, if you got a packet with this destination, ignore it, drop it. It's sort of overlaps with a firewall so people don't have to use this. It's just that originally when these things came along, firewall rules were still IPFW admin, it was still like prehistoric. Clear means just ignore this packet, just send it out, we will never do IK on it so just send it out. Private means we mandate that it's encrypted. So if it's not encrypted, drop the packet. If we don't have a state for tell the IK daemon to do IPsec, try to set up a tunnel and if the tunnel fails, just keep dropping the packets. Private or clear means try and initiate and if it for some reason fails, you'll just allow the packet to go out plain text. And clear or private is more meant for servers instead of having to try all the clients that connect to it and all the clients don't support it. It will just go into a respond-only mode. So it will accept clear, but if someone comes in with an IK packet, it will go and do, I agree to do encryption. So here's an example, you've just put ciders in the file. So in this case, I have two slash 24s, so I put them in private or clear because I know I have machines in that network that can do it. Of course, ideally, once this gets deployed widely, you can put zero slash zero in there. And you can also combine this with like an enterprise encryption. So you can say, in private, I will put 10 slash eight because that's my local enterprise and they all do encryption and I want it to be mandatory. So the question is, how does authentication come in? And I'll show you a few more bits and tweaks that is the problem and that's why also we're looking at redoing this. So this is the original design which we sort of revived and put in, but we now know that because we do wanna say, like, try to do authenticated and if not do anonymous and we need to have a better way of specifying that. Again, we have an OE mailing list. You can join us OE at list.libersound.org and we welcome your input because this is a hard problem. Like to keep things simple is really difficult. So how does this work internally? Internally for Libersound, this is just an IPsec connection. It's not really different from anything else. So, left equals default route basically means grab whatever the IP address is that is your default route and use that as your source address. Left that is from cert as if you have a certificate just use the ID from the certificate. Just read it in. Oh, so this is the example for an enterprise encryption code. So imagine you have a 10 slash eight cloud deployment. You have, you have Puppet, you've given all your hosts a certificate, right? So then left cert is your certificate. Right is opportunistic meaning anyone can connect and it will trigger this, this special private connection. Again, the remote has its ID from the cert. You just say write CA same. So the CA that's authorized your certificate is also valid for the peer certificate. IqV2 is insist because we ripped everything out of the IqV1 code that had to do with opportunistic encryption. We didn't want to deal with any kind of, so we've, it only works when you force the connection to IqV2. And then here's two of your tweaks. Fill your shunt and negotiation shunt. Fill your shunt is what to do after you fill to bring up an I connection when you filled. You can say drop, clear, and then there's one negotiation shunt. So some people actually find it more important that the communication keeps running unencrypted, but they would like it to be encrypted if possible, but they don't want you to drop the connection. So they don't even want to pause while the Iq negotiation is happening that they don't have a packet flow. So this allows you to say negotiation shunt, either hold us and drop the, hold onto the packets or really drop them, it's not holding them. Drop the packets until the Iq is done and then do whatever the outcome is. Or you can say negotiation shunt is clear, in which case you will leak packets during the Iq negotiation. And we sort of, we like having these options, but we're still a little confused about, we don't really want to bother the users with this because they're going to make the wrong choices, they're going to copy old configs from Google searches. And so we're looking at how to make this more obvious to people still. But it works really well. So this is a fully anonymous IPsec. So this is like no authentication on either side. So you see the only change is really our left ID is null, right ID is null, and auth by is null. And clearly you make sure that you do a pass through because if you don't get anonymous, you will just leak clear text. And then we did one as an example to use Let's Encrypt. So like everybody has a CA that they sort of trust, Let's Encrypt is pretty famous, they see pretty wide deployment. So we're like, you know what, we can use this CA to do our anonymous client to authenticated server. So we just like feed onto their system. So this is how you grab the certificates from Let's Encrypt site. Unfortunately there's one, so the IdentityTrust X3 one, for some reason they published them without the begin certificate and end certificate lines on our website. So I just copied it and put those lines in front of it and put it on my website. So it doesn't make it easier to install it. And there's some commands to read these certificates, import them into the NSS database. Liberswine uses its own NSS database that is like only for IPsec. It doesn't, so it doesn't have all the root CAs from all the TLS servers all over the world. It's just for IPsec. So when you put this in, you're ready to be an anonymous client to a remote server. So this is the demo that I will actually try and show you. But in case it fails, I'll explain it. So the config I just showed you, you can download from that site. You can put the single IP address in the private or clear so that the magnetism will trigger. And then you just ping and you'll see here that the first packet was eaten. The first packet didn't make it and the second and third packet did. And then when you do IPsec back traffic status, it will show you. And so we got the address zero.2 assigned. But again, that address only lives inside the IPsec subsystem. So you don't have to worry about it. And it just works. So this is that client config for asymmetrical. So you can see left ID is null, left office null, left mode CFG, it just means that you will allow an IP address to be assigned. Left cat is yes. That is our crypto NAT solution. So we say yes, you can do this hack with the IP table rules and the extra policy. And then the other side is just a regular ID from cert. I expect them to authenticate by cert and expect that I know the CA in my NSF database. Narrowing is yes, it's just a feature of how IQV2 works with an address assignment. The client basically says, hey, I'm okay with zero slash zero and I'll allow you to narrow down and then the remote server can narrow down to one address. It's okay, but we're gonna make a tunnel for only this one address. This is the server side. So at the server side, what you do, you first install let's encrypt normally. So what this is, I forgot what the tool was called cert com or com cert, like the let's encrypt tool to set up for let's encrypt. So if you install that and run it, then you have the let's encrypt command, you give it your host name and it will put all of your certificates in ETC, let's encrypt live and then your DNS name. And so we just take those certificates, we put it into a pkss12 file and then we import it into the NSS system for LibreSwan. So now the IP sex system knows about it. You do the server configuration and you put the entire world into clear private so you will respond to everybody who wants to do IQ to you and then you run it. And this is how it looks like. So you can see here, I define the address pool to be 164.01. For those who might recognize the address, I stole it from the carrier grade network people. Since they decided to cause all the problems with that, I decided to take their addresses. They're never supposed to be visible outside of carrier grade networks. I'm never supposed to see them anyway. And it avoids conflicts because if I would, if I would put RFC 1918 addresses here and you're pre-enacted IP addresses also in that range, you get weird conflicts. So this is my way of staying out of RFC 1918 with addresses of people who cause the problems. And then our features that we're planning. So we're planning to add like Kerberos, GSS API. We're going to do the DNS triggers. One of the features I actually didn't talk about, the old clip stack had this vini-nites feature you had an IPsec zero interface and people could TCP dump on it and see all the clear text, all the post decrypted and pre-encrypted traffic. And then when they sniffed the ether device, they could just see the encrypted traffic. And you couldn't do that with XS-RAM until recently when the VTI support actually came in. And now you can use the IP tunnel command to actually add a VTI type device and you can sort of recreate the IPsec zero device. And these two features, this and the opportunistic encryption packet caching for the TCP packet were the two things that were missing for us to finally kill the clip stack. And it's been since, what was it, 1996? So we can finally kill that kernel module. If you want to see the pain of my life, let's see if I can, I was afraid of that. Okay, where did my browser go? That's a new browser. Huh, I cannot even unfold screen my browser to move it to the other window. Okay, so there's a file called in the LibreSan tree, linux net include ipsec kversion.h. That is basically a giant if def from kernel versions. We stripped everything from two, four before, but it used to contain everything from two, four up until the three kernel. Every time you guys changed the API, we had to put a macro in place to support the older and the newer kernel. And so it's a giant if def file with where I learned a lot more about the kernel that I really wanted to know. So let's see if I can move these for a little demo. The other really bad thing before VTI was that if you run TCP dump on an IPsec tunnel that you had set up, you would outgoing packets, you wouldn't see the encrypted version. You would see the plain text version because TCP dump grabbed the packet before it got encrypted. And so after TCP dump saw it and displayed it to you, it would get encrypted, but you would never see it. But for the incoming packet, you would see the encrypted packet and you would see the decrypted packet. That confused so many people that, oh, my tunnel is working half, but half of this plain text like, no, I'm sorry, you just run TCP dump on another machine in between them and you'll see it work. So you'll see here that I've logged into a different machine to avoid that problem. So that's let's encrypt.liberson.org. So we run, I guess maybe people already started doing things. Oh, that's SSH. Okay, hold on. I guess it's showing too much. So I'm not running IPsec on my laptop yet. So let's ping. So we see ping pack is going there. Okay, baseline test. We also predate all the init system. So we have an IPsec command that does all of that and maps to sysv, systemd, upstart. So I never have to worry about like what init system wins today. So that's the file I showed you that is loaded. So now let's ping again. All right, I'll clear the screen here. It's getting encrypted. And so this should scale easily, right? You can put this on all of your servers. Your client will just do it. If you prefer not to have packet loss and leak a bit in the clear at the beginning of your connection, you can do so. If you want to hold your packets and you're willing to wait one second or so before failure or click attacks hits, then you can do that too. So that's it. Questions? Comments? Do I have time? Sorry? We're running out of time. Okay, we're running out of time. Okay, so catch me now always on round if you want. So thanks.