 Hi, I'm Sabrina. I'm going to talk about Macsack today. So what it is, why do we even care? And yeah, why do we want yet another security encryption thing? And not really how the protocol works, but more specifically how you can use it instead. So I'm going to start with an introduction to Macsack. Oh, yeah, in general terms. Describe some environments that would be a good use case for Macsack. Then I'm going to show you a few other protocols that you could use instead of using Macsack. Maybe protocols you know a little bit better than Macsack. Yeah, then tell you some use cases for Macsack and for these other protocols. And then I'll finish with a few configuration examples for practical purposes. So first, what is Macsack? And yeah, if you're not familiar with it maybe. So yeah, what's that? It's an IEEE standard, I-2.1AE standardize in 2006. And it's for encryption of our Ethernet LANs. It provides authenticated encryption that is both integrity and confidentiality for all your traffic using GCM AES with 128 bit keys. So it's a pretty solid encryption. Since you need to forward the frames you cannot protect the source and destination, Mac addresses, but they are still authenticated so they cannot be modified by some man in the middle attack or something. And Macsack also has a mechanism for replay protection. It only works, the most specific thing about Macsack is it only works within a single LAN. So it cannot go through any router that you might have in the middle. Because anyway, the IP addresses in your packet are not even visible. They are also encrypted. There's one extension to IEEE 2.1X that allows you to do mutual authentication of nodes and key distribution, which makes it more convenient to use otherwise you have to do manual key exchange and that really sucks. So let's see some environments and use cases that are good fit for Macsack. I'm going to start with maybe the most obvious thing which is a native LAN. And then I have two variations of that. One is if you have one untrusted link in the middle of your network and one is when other use cases when you have a part of your network where you don't really know what's going to connect to it. So let's say you have one LAN and you have say two buildings on either side of the street and you have a link to connect them and you don't know, you don't trust the provider of that link and you don't know where it goes. So you want to encrypt the communication that goes over that link. So that red link in the middle, you don't trust that. And you're going to set up Macsack between switch one and switch two and all the communication there will be encrypted. And now you don't care if the provider of that link is completely untrustworthy. Another use case is you have a link that you, you have a LAN that you, you're okay with that. This, you know what's going to plug into that. Maybe it's inside your data center or something and you know this is safe. But on switch two, you have some publicly exposed port and you don't know host three, four and five. You don't know what's going to plug into your network. So by default, all these, all these communications here are not, you don't trust what's coming in here. And now let's say that host three and four have successfully started doing Macsack and they're talking to switch two. All the data that goes to between host three and four and switch two is encrypted. And so that's, that is going to be forwarded by switch two to decrypted by switch two and forward it to the rest of your network. On the other hand, you have host five that isn't participating in Macsack. It's not encrypted. It's traffic. So you still don't trust what's coming here. Maybe you don't grant it any access to the rest of your network. You don't want that kind of extension to that. This case is if you have a cloud, let's say you have a group of virtual machines that are stayed on OpenStack, for example. And what OpenStack provides you is a virtual LAN. So it's on the provider network, it's going to be some vague slant tunnels and some stuff like that. But to you, it's just a LAN. Your virtual machines, that's all they see. It's transparent. You have your LAN. And you don't really trust your, the network from your cloud provider. You don't know why your packets are going to go in between your virtual machines. So you want to encrypt the communications, for example, between virtual machine one and VM two. Maybe VM two is hosting a database that VM one is using. And you want to encrypt that communication. Of course, you cannot encrypt the communication between VM one and the users in the real world because then they cannot access your services, but you are not with Macsack at least. But between your virtual machines, you want to encrypt that communication. And you're going to set up a Macsack association between VM one and VM two, maybe another one between three and four. And now everything that goes between these virtual machines is encrypted on DHCP and everything is completely protected. I'm saying virtual machines here, but it could work the same with containers because they will also have some virtual LAN and it's basically equivalent. Now I'm going to talk about a few other protocols that maybe you've heard a bit more of. I'll start with IPsec, which is kind of similar, but the more differences it works at, layer three. So it's only going to encrypt the payload of your IP packets. The big difference here is it can go through any router you want, but it's not going to protect your DHCP. If that's something you're interested in, then you cannot use IPsec for that. IPsec provides various integrity and confidentiality modes, including the one that Macsack does, which is GCM AES. IPsec also provides replay protection and as a key exchange mechanism via Ike, internet key exchange. IPsec also has two major modes, which is the transport mode. If you only want to secure a direct connection between two machines or tunnel mode, if you want to establish a VPN between two networks. Since we're talking about VPNs, that's OpenVPN. It's only going to protect your layer four payload. All traffic is encapsulated over layer four, so it can also be routed. You can choose as an administrator whether it's going to encapsulate the N2 or L3 traffic. OpenVPN supports multiple crypto algorithms, but not GCM AES that, yes. Okay, I didn't know that, sorry. So there is GCM AES now in the latest OpenVPN release. I'm not up to date. There is also replay protection and key exchange is provided via TLS. So TLS and DTLS, its datagram brother, will only protect your L4 payload. It provides integrity and confidentiality for your data and replay protection, and there's also key exchange system. And now let's finish this overview with something a little bit different. A02.1x provides port control. So it's only access control. There is no confidentiality, no integrity. There's no encryption at all. It's just going to tell basically if the port on your switch that you're plugged in is switched on or switched off. If you don't do the authentication phase, your port is switched off, that's it. So when do you want to use MaxEc using all these ideas that you have now? So this is just an overview summary of the information in the previous slides. If you care about encrypting these layer two things, you will have to use MaxEc. Otherwise, you have more choices. Naturally, if you want to let your encrypted traffic go outside of your LAN, you need to use something else than MaxEc because MaxEc is never going to leave your LAN or not until you encapsulate it over something else. So yeah, if protecting protocols below IP is required, then you probably want MaxEc. And finally, the practical part of this presentation, how can you actually use MaxEc in your network? So the first most, say, Bourbon's approach is using IP route. IP route is nice if you just want to see how it actually works, because it's the closest approach to the actual protocol, but it's not very convenient. You have to generate your keys manually and you have to feed them to all the hosts that you're going to use. So the first, you have to generate one key for transmission and on each machine that you're going to use. And then you set up a MaxEc link on top of the whatever network interface you're using to connect to this network. You enable a key and a transmit association and then you need for each machine that you expect to receive packets from, you need to set up a receive association, a receive channel and a receive association with the key corresponding to that machine. What makes it really inconvenient is that when your packet number reaches its maximum value, your key becomes invalid and you need to set up a new one, which is again, set it up manually. So it's kind of nice if you want some quick fire thing, just set up a connection, transmit a few things, five minutes, you're done. It's a nice debugging tool, but it's not practical at all. What you probably want to use instead is WPA supplicant, which in the latest, in the current Git tree implements the full MKA, so MaxEc key exchange key agreement protocol. And that is going to generate some keys for you, do authentication between your hosts, generate some keys, configure the kernel, set up MaxEc and you don't have to touch anything anymore. So that's a simple configuration files. You have to generate one key, one connectivity association key and one cact number, that's the CKN. You need that pair. And then your WPA supplicant instances all connected to the same LAN are going to exchange some keys, are going to perform authentication, check that they are able to synchronize each other with that and start exchanging keys for MaxEc encryption themselves. So that is the, I would say, pre-shared key mode of MaxEc. There's also a kind of more, similar to Wi-Fi with WPA enterprise where you could use login and username, if you have a switch that provides the authenticated part of that. So here, if you have this configuration file, then you just run WPA supplicant. That's, if you use WPA supplicant manually, it's similar to what you would do on Wi-Fi with the MaxEc Linux driver. And that's it. As I said, it requires a very recent version of WPA supplicant, also of lib nl. But other than that, it's going to be in a future release of WPA supplicant. Now, maybe something even more convenient to a lot of people is network manager. You will also have to generate your CAC and CKM. Then you use, you can use NMCLI for that. And what network manager is going to do is set up WPA supplicant. It configures WPA supplicant for you and WPA supplicant takes care of the key exchange in the background. And that will be part of the next release of network manager. Thanks to Benjamin who is right here in the middle. And that's it. Yes. So is MaxEc suitable for 10 gigabit networks? The last test I did was only with a single TCP stream. And I was in the three to four gigabits per second with one single stream. I haven't checked with multiple streams concurrently. So you cannot, at this point you cannot do line writes on 10 gig with a single stream. But we are looking into some performance improvement. That's the next thing coming up. There's also offloading in a few, MaxEc offloading in a few models of network cards. We haven't implemented that in the kernel yet. But there are very few network cards you have to find the right one. Yes. What's switch vendors? So right now I've only tested that with a Juniper switch. I think there are a few other vendors that have MaxEc in us which is, but I don't have access to them right now. Yes. So do we expect maybe some IoT devices supporting MaxEc? I don't know. You know, because it's big difference whether it is implemented by system level or whether you are having a hard time with your software. So yeah, it is different whether the kernel has the infrastructure for that and whether actual stuff deployed in the world has it. It's still the early days of this MaxEc implementation. It's going to get, I hope, a lot more attention. Not that it's here because a year ago we didn't even have a MaxEc implementation in Linux. So hopefully it's going to gain some traction. Yes. So do we need some special configuration if we have a switch that supports MaxEc? Yes. In the Juniper switch that I tested with, you need to enable MaxEc on your port. You need to set up this connectivity association here on your switch and then your host has WPA that synchronizes and establishes the session. Yes, you actually need a license for that, true. So what's the purpose of having encrypt on and encrypt off? If you have encrypt on, your traffic will be encrypted and authenticated. With encrypt off, your traffic is just authenticated but the packets are transmitted in the clear. Like authentication header in IPsec, kind of. In some tests that I ended, there was a performance difference. I don't remember how much and we haven't investigated yet if... Yeah, there was a performance difference if you're not encrypting but I cannot tell you how much right now. And we will check if that can be improved too. Yes. You mentioned on VPN but didn't talk about LibreSwan. Is that just mentioned or have you looked at LibreSwan but LibreSwan is just for IPsec, right? Right. But you enlisted OpenVPN as a comparison. Yeah, because it's kind of separate and it's a separate technology compared to LibreSwan which is IPsec. But yeah, I could mention LibreSwan and OpenSwan and the others that I forgot when I mentioned IPsec. Sorry. There's the Linux bridge support Macsec. The Linux bridge itself doesn't really care about Macsec. You can either do Macsec on the ports that you plug in your bridge or you can do Macsec on top of your bridge. So create a Macsec link instead of using ETH0, you use BR0 or something. Yes. How's the plans for RHEL? For RHEL? So what plan do we have for Macsec in RHEL? Macsec, the journal and IP route part are already in 7.3 and the WPA applicant and network manager are going to be in 7.4. We have absolutely no plan on putting that in RHEL 6, sorry. So what about integration with OpenStack and OpenShift? If you want to, well, it depends. The most valid, in my opinion, the main use case for Macsec on OpenStack is from the tenant's point of view and so set it up within your virtual machine and I would see that using network manager in the virtual machine. We haven't, we don't have any plan yet to enable Macsec on the OpenStack itself from the operator's point of view, but we can, if someone shows me a use case for that or request to enable it, then sure, we can talk about it. I don't really see one, but I see mostly Macsec as from the tenant and that doesn't trust the operator more than from, what would the operator do? If this requirement comes, then we can talk about it. Okay, oh, quickly. 100, how does an integrated package affect you? It's something like 20 extra bytes, 20 to 32, I think. Oh, sorry, what is the extra, what is the overhead of Macsec on the packet size? You have a 16 byte authentication tag and 12 bytes header or something, yeah, pretty small. Okay, thank you, thank you very much.