Introduction Hi, in this video we're going to explore a new Cilium feature coming in Cilium 1.15, which lets you authenticate BGP sessions using MD5. It is a feature that has been requested for quite a while in the BGP world. It has been available for about 25 years, and you can see that in RFC 2385, which talks about how you can protect BGP sessions using the TCP MD5 signature option. It is now available in Cilium 1.15. It is really simple to implement, so let's take a look in a demo. For this video, I'm using one of our new labs, the Advanced BGP Features lab, where you can test a lot of the different features we've seen in some of the videos, and I'll show you how to set up BGP authentication using Cilium. MD5 authentication overview It's pretty simple. First, you want to create a Kubernetes Secret, and that's where you're going to store the actual password for your MD5 authentication. As you can see, we are creating a Secret. It is essentially based on the password my-secret-password, and we will need to configure that password on the other side of our peering session. With MD5-based authentication, we essentially apply the MD5 algorithm and create a hash. We send it to our peer, and the peer will apply the same hash using its own password and verify that they match. That's how we can essentially prevent spoofing and provide some more security to our BGP sessions. Peering policy configuration Now that we've created our password, let's take a look at our BGP peering policy, and we're going to refer to the Secret we just created. In Cilium, the way we configure BGP is through something called a BGP peering policy, which is just a YAML manifest where you specify your BGP neighbor, your peer AS numbers, your timers, and all your different BGP options, including now the name of the Secret where you define your BGP password. Here, as you can see, we called it secret-name, and that's what we're doing here. Let's just go ahead and apply this Cilium BGP peering policy. Here we go. Now, as mentioned, we've configured Cilium, and now the session would actually go down because only one side of the session has the password. We can use the Cilium CLI to verify the peering relationship, and as you can see, Cilium has gone into active mode, which means that it's trying to connect but it can't, because the passwords don't match. One side has the password, the other side doesn't, so we're going to connect to our remote peer, which is using FRR, Free Range Routing, a very popular open source routing daemon. So we're going to go and configure that first. We're going to add the password to the neighbor. Configure BGP MD5 authentication Then we'll double-check the running config. While we're connected to our FRR device, let's take a look at the BGP summary. You can see the session has just come back up and has been re-authenticated, and it's working great. We can see we've learned a route as well. So it's all working fine, and we've now re-established connectivity. The peering session is back up, and we've authenticated on both sides of the session. Validate authenticated BGP session Now, if you're curious, you can actually follow me as I use Wireshark to look at the actual TCP packet if we want to see the hash and make sure the session is authenticated. Again, we can go into our Cilium agent and install tcpdump. It takes a little while. I connected to the Cilium agent in the kube-system namespace, and then I deployed tcpdump and termshark. Termshark is actually a Linux version of Wireshark. First we're just capturing the traffic for a few seconds. We're capturing BGP traffic because that's over TCP port 179 and is coming from our remote end. There we go. Now we're just going to take a quick look at that output. In our BGP packet here, let's have a look. BGP MD5 is essentially using the TCP MD5 option, so we have to look into the TCP header here and scroll down. In TCP options, you can see the TCP MD5 signature. Here we go, you can see the MD5 digest. Again, that's just to show you how the authentication happens. When our packet is sent, we create a digest based on things like the source IP and ports, and using the password we created locally, we send that hash digest across to the remote side, which will then compare it with its own digest, and if the digests don't match, the packet will be dropped. That's how we ensure the security of our BGP session. Deploy BGP MD5 authentication That's all for today. Thank you very much for watching, and I will see you in the next one.