 Yes, welcome. We will also be talking about the problems, the software thing, to make a VPN, encounters and trying to send your packets over the internet. And the problems they encounter is not only applicable to think but also to other VPN software or other peer-to-peer applications. So a bit about think. It started in September 1997 when there was a new kernel and it came with a new device, the EtherTap device. And you now know it as the TumTap device maybe. But then I thought, oh, that's nice. What can I do with it? I wrote a little program that captured the packets from this virtual network device that the EtherTap device created. And you could send it via Netcats or SSH to another computer. And there you could do the reverse. So you could send up a VPN. But it grew and grew. And currently it's a mature demon that has a number of features. For example, it connects multiple sites together and not just two endpoints but any. It routes packets or it can switch them so it can work like an ethernet device or a router. It fully supports IPv6 both on the VPN but also when tunneling packets over the internet. It has no central server. It does not make a distinction between clients and servers. And the idea is that you configure some endpoints in the VPN and then think will fill in the rest and will create a full mesh network. I will explain that later. Behind the screens it works this way, very simply put. The demons connect via TSP, they exchange data in the kernel. Then there was Fetan which started at the same time as Tink. But these projects are to my knowledge dead now. But you all know IPsec and open VPN I think. And another one is Howmachi. It's a closed source commercial like. It's kind of a Skype for VPN. Which is peer to peer. And shares many of the features of Tink. But that's unknown but all the projects, all open source projects, here are the GNU and virtual private ethernet which was started as a fork of Tink. It's cloud VPN, social VPN, end to end. And last year there was a presentation here about virtual distributed ethernet. Which deals with connecting virtual machines together. But actually it shares most of the features of VPN. So what do we want to do with Tink? Now we have the internet here. It's the blue cloud. And we have some notes. These are the black circles. A note can be a single laptop. For example, a hotel or an airport or can be complete network from a company. And we all want to connect these notes together into a single VPN. Now what you have to do, each note has to supply some configuration to Tink. So that each note can make connection to another note. So that they are all part of the VPN. But it doesn't matter in which way you connect notes. The topology is up to you. But then Tink will exchange information between notes about where everybody is. And Tink will create direct connections for each note to every other note. But it uses connection as UDP for this. This is efficient. And it skills well, even if you have 100 or more notes. But the reality on the internet is not so nice. I've drawn a few red lines here. These red orcs. Here, for example, are network address translators, which are very common these days. And the problem with those is you can make outgoing connections with incoming connections fail. And another problem is that some ISPs tend to block certain kinds of traffic. For example, they can block UDP or only allow port 80 communications. And that's the red line here. Now you see that most of the lines, the solid lines from the previous slide have disappeared. And some notes, for example, behind the net device cannot connect directly with each other anymore. You can still go via another path. But more problematic is that if a note connects to another note behind a net, and that's the initial connection it makes, then it does not receive information about where the rest is. So it is completely disconnected from the VPN. Now I will describe most of these problems in some more detail. The problem with net is that the source address and port change and incoming connections are blocked, even if you make an outgoing connection to the same to the other side, because they don't know what new port is. There are a few solutions. You can route via third note, but that's inefficient, of course. You can do port forwarding, but the user has to set up on this net device. And it's manual work, and maybe your net device was not supported, or you're not the administrator of that device. There is a protocol called UPnP, which allows you to discover net devices on your network. You can find out which ports they map your connections to, and even open up connections. And there is this protocol called Session Traversal Utilities for Net, or Internet Connectivity Establishments, which are ITF protocols, which allow you to puncture holes through a net. And in some cases, it can allow you to establish direct connections. But this is a complex protocol, and it's also not always possible. Some net devices just do not allow any form of direct communication. To put it in pictures, we have two nodes behind the net device, and they want to make a direct connection. But the outgoing connection works, but here ends up being blocked by the net. The other one tries to connect back, and it also fails. But they can change information via third note. Now, the idea is that the third note knows, because it can see the port and address that the net device maps the internal connections to, which port and address the other nodes should use when connecting to the first node. So if both nodes know this information, they can adjust their connection to use the right port to go through the net device. Another problem that we encountered is that packets are fragmented on VPNs, because if a packet on your VPN is already the maximum size that your network allows, then you encapsulate it in a new packet, then this will be larger than the original packet, and it will be fragmented by operating system. Now, this is a bit bad for performance, but more importantly, some ISPs or firewalls block fragments. And so this would block most of your VPN network. Now, the solution that we implemented is to determine the path maximum transfer units between nodes. And then, when one node wants to send a packet to another node, and it has to fragment it, instead, the think team will generate an ISMP fragmentation-needed packet, which tells the original sender, hey, your packet is too large, you have to make it smaller. And this is an IP-level mechanism, so this shoot-in-principle work for all IPC4 and IPv6 traffic. And for all kinds of traffic, which I think can also support, it will fall back to GSP encapsulation. But the problem is that there's also some firewalls and ISPs that block ICMP packets, because 10 years ago, you could still press computers by sending large pink packets. So they decided, oh, block all ICMP. But yeah, the problem is then that when things generate ICMP packets, and they somehow leave the VPN and go to the internet, this can happen if you have your default gateway on the VPN and have road warriors connect to that via the VPN. Then a host on the internet tries to send packets to the VPN, but these packets are too large to be transferred via the VPN to other nodes. And then things generate ICMP packets back. But if some host behind the internet does not see these ICMP packets, this will never adjust the packets that are too large. Now, there's another solution, and this is to clamp the MSS field and TCP packets, which is another mechanism, which does not use ICMP packets, but just the TCP packets itself. And that will also instruct the other side to reduce the size of the packets. But the limitation here is that it's only working for TCP. Now, a few other things we encountered is hosted frequently changing IP addresses, if you have a cheap ICP example, then you can use dynamic DNS services, for example. Or you could have other nodes on the VPN, remember and forward known addresses of other nodes. And that's all already implemented and think for some years. There are ICPs that only allow certain types of traffic, for example, the only allow web traffic. So you have to encapsulate everything into HTTP or HTTPS. And in some cases, you can use ICMP if it's not blocked or DNS. I think does not implement that. But there are some VPN solutions we do allow it. And there are also lots of utilities around, which can encapsulate any TCP stream into ICMP or DNS. And then there's a more, yeah, another difficult problem. ISPs that are dropping or delaying small UDP packets. This is a commercial motivation because voice over RP also looks like small UDP packets. And if they offer telephony services for which you have to pay much more than for your internet connection, then they want to disallow voice over RP and make it difficult. The problem is, if you drop packets, then these P streams inside those tunnels think it's because of congestion and they will reduce their bandwidth. For this, it's a really hard problem. I don't have a solution for this yet. Now, okay, the internet is hostile. But that's probably the reason that you want to set up the VPN in the first place. But how do you trust your notes? You have to have some form of authentication and authorization. The authentication is proving who you are. And you can do that by using a passport, for example, in real life. It's a document that shows you I am now I am asleep. And the notes on your VPN also should do that. You don't want to allow any note. But proving who you are is not the same as saying, okay, you are allowed to use this range of IP addresses on my VPN or you are allowed to use this much bandwidth on my VPN. And the problem is that these days, a lot of authorization is actually authentication. For example, you are allowed to access a web server if your client certificate, which is just a way to authenticate you is in the list. But that does not there's not a method of doing proper cryptographic authorization. But to well known, and that's mostly authentication methods are the X 509 certificates. It's, you know, it from HTTPS connections. It's a centralized approach. So there's very sign at top and some other companies and VFU middleman, which all want to extort money from you, you can get this certificate. But it focuses on identities and websites because it's made for for that. So you can only put some information like an LDAP identity, like my organization is called this, and I'm from this country into a certificate and may be limited to a certain URL. Open pitch PKs. They are I think they're very nice because you have a decentralized approach. But it also has this limitation. It was meant for email. So it is limited to email addresses. So we want something different. We want something that has some of the features like decentralized workings, a bit of trust that you can build up, which we want more. We want to authorize anything, not just email addresses. You want to add and remove authorizations very quickly. We don't want to go through a revocation method. We want to forbid things as well. And we want to make group decisions so that every note, for example, in the VPN, has the same way of allowing or disallowing other notes. So I created a library for this. It's a lightweight framework to do authorization. So it's you can create many small certificates. For example, let's say somebody said one of the notes for the VPN, for example, at a certain time that another note is allowed to access the VPN and newer certifications. So just over all the ones. So you don't have a revocation certificate. No, you have just an updated authorization. And the library makes it very easy to query these storage authorizations. And we do not want just a list of the certificates. Now we just want to know is this person allowed to go on the VPN and the library. Okay. Anyway, you can find more about the website. And there's a burst of a feather session at five o'clock.