All right guys iPhone 14 Pro in the purple 128 gigabytes this is the Pro Max let's go ahead and unbox this for the very first time you have a USB-C to lightning cable then you have the SIM ejection pin which in the UK it still has the SIM card tray in the iPhones in the US it has the eSIM so you wouldn't have this option then you have yourself the iPhone information and warranty with an Apple sticker right at the back let's go ahead and turn the phone on for the very first time and I will transfer my entire iCloud backup from my iPhone 12 Pro to my iPhone 14 Pro Max now I'm going to select transfer from iPhone this may take some while but the one thing I really like about iPhones is that once I've purchased a new iPhone directly from the Apple website a pop-up notification appeared on my current iPhone which said to back up everything to iCloud and have it completely ready to transfer once I unlock and login to my new iPhone and there we go the transfer has now begun this is probably going to take some time but once it's complete all of my apps my settings my cards in my wallet and anything else that I've set up on my previous iPhone will be transferred over to my new 14 Pro Max and there we go the transfer is complete and the new iPhone will restart and it will be ready to use okay so the phone has restarted and you can see this has the always unlock screen let's go ahead and unlock both of these there we go you can see it's copied everything like for like the layout the apps the widgets as well which I think is great and of course the first thing I want to do which I was always waiting for Apple to reintroduce is turn on the battery percentage at the top right-hand side of the screen there we go that's something I've been wanting for quite a long time and of course there's going to be a few other things in the settings that didn't exist with the iPhone 12 Pro but for the most part it's just going to finish downloading all of the apps that I've had and once that's done I'm pretty much ready to go I've now put the SIM card from my old phone into the new iPhone and I'm pretty much ready to start using this straight away and in my next video guys I'm going to be showcasing all of the different features that you get with the iPhone 14 Pro versions compared to the iPhone 12 Pro versions so make sure to subscribe so you don't miss that video I'm going to showcase not just the features but also the quality of the camera and all of the features that come with these three different lenses and hopefully you guys will find that useful in making a decision if the iPhone 14 Pro is actually worth upgrading from the iPhone 12 Pro thanks for watching guys and I will see you at the next one


guess five minutes up to I guess 10 or 15 if you're building and like the the cloud images usually take like between five to seven minutes and we can also like deploy it for you directly to the cloud environment we can we can also build ISOs and those usually take a little longer repeating that there's also the on-premise version that you can run if you have an RPM based operating system you can DNF installed OS build composer and have it running and build your images now I don't know who's first you so the question was how do we how does this model work for situations where you might not know the workload you just want to build an image well so it well first of all the sort of like the workload situation it's kind of optional it doesn't need to be a predefined workload the way we kind of works now if we map this sort of like new way of thinking about things of the old way we would of course have a custom workload or even an old workload where you you don't get any extra packages you don't get any extra configurations you just get the base system obviously you can't you can't skip the selection of distribution and platform that wouldn't make sense environment you could have like a base environment that sort of it doesn't belong to any cloud or anything it's kind of just something you know it's just something that that can maybe maybe maybe you can have a think of think of it as like the default is like a bare metal installation for example but that would totally be an option right it's like any there's they're saying defaults I think for for the environment and the workload that we can sort of think about and yeah custom software the follow-up question was how would custom software be layered in well that depends I mean right now we already have the capability of letting the user define their own content sources if you have an internal in your company an internal RPM repository or a public one that's third-party you can just define it and pull content from there and it'll be installed we can embed containers at build time as well I mean any other ideas were open to suggestions about how to get custom software yeah yeah you can also inject custom files at build time for the on-premise version you can just write a file and it'll get injected at build time into the directory the question or am I out of time okay do we integrate with Ansible short answer no long answer no yeah there is in Ansible also Ansible integrates with us right yeah yeah which is sort of what OS build is doing I mean not sort of that's what always build is there how much so first of all how much how much time do we have because this this seems like a discussion for over there and I think there were a couple more questions if we have time to get to there was one there before sorry can I get some sorry start again I didn't hear anything oh yeah of course the question knows if we consider other platforms and yes we can build okay we don't have virtual box yeah we have right it's the same as okay so we have yeah right and that's sort of the thing right it's not just about making the file the file format correct it's also about knowing what does this virtualization platform need and you know we're always we're always expanding we're always adding more stuff and that's sort of what part of the reason we're thinking about this we're rethinking about how we put these things together is that if for example we said let's add let's have let's do that let's do vagrant right we would figure out vagrant for well nine and then it'll be like and then we would we would be thinking okay this is this is livered for well nine x86 and then we would have to go through that again and redefine it for every configuration and now what we want to do is say okay what is what is vagrant need it needs these things we we define them in sort of like a well-defined way and how they interact with the other components and then you can drop it into any configuration and it should work okay so the question is if you if you want to do something that isn't covered by OS build you need to write your own OS build stage yeah I mean that's kind of the way to do it like if there's if there's some kind of configuration or there's something that needs to be run at build time that the OS build library doesn't cover with a stage the answer is right a stage but the the the best answer is write a stage and send it upstream please because we need them right is that no it's not well there's someone behind me and I think you are the what if you want it so the current state yeah the question was yeah the question was we have the yeah we have the manifest we have the UI and stuff but what if I want to version control my sort of set my configuration my image type of what whatever you're doing well the good news is the the way you build an image on premises is with what we call a blueprint which is a tumble file and I'm out of time but it's a text file you can version it we also can we also support versioning the way it works now which might change soon but the you write a tumble file which configures the image and you push it into Composer and Composer itself also has a versioning system that might be going away but it's text files you can yeah you can version them and even in cockpit Composer which is sort of like the web UI that you run on premises you can click through and configure the image and then you can export that configuration as a tumble file and save it where I'm out of time thank you all very very much hi my name is Clemens Lang and today we not we need to talk about your use of root privileges in containers I start out with a bit about me I did study computer science in southern Germany in 2011 got interested in open source projects while doing Google summer of code with a Mac post project I'm using a Mac here and after that landed a job at BMW doing infotainment so that's where I spent seven years building infotainment for cars first doing some software integration work doing packaging then and this is where the connection to today's talk comes in we wrote a thousand line of C single binary container on a runtime to simplify building software for a platform and I got very familiar with the various namespaces involved in doing that then switched to over the software updates for the entire car I think with were the second in the market after Tesla to do that for the entire car and for the last few years did security at BMW SSO secure boot and all that you know I say Linux whatever you have and that eventually brought me to Red Hat where I now work in the crypto team so first note I don't do anything with containers in my day-to-day work right so this is sort of a talk from an outsider and what I'm doing at the moment is I patch up in SSO I try to get rid of char one where I can you know that might have fallen in some of your feet recently one of the culprits was me probably and I'm also dealing with fifth certification because that's a fun topic for everybody so route and containers right before there were containers there was some conventional wisdom that we always applied if you run a service create a separate user for it just for separation purposes right and while you know then Docker came along and we started running everything as route again because that's just what Docker did but nobody thought this was a problem and honestly we still don't think it's a problem and probably also isn't that big of a problem right so just to put the entire talk into perspective for you and I brought an example here let's assume I create a directory and var lip and then I bind mount that into a container and that container is running as routes I'm running the entire commander's route and inside that container I just happy happened to copy bin cat into that bind mounted directory and then run a chmod command to give it that said you add a bit so that means anybody who runs that binary now will get effective route permissions and that also works outside of the peanut container so if I then outside of the containers which to use a nobody run that particular binary and give it an argument of ETC shadow then I will get the contents of that file even though the nobody user should normally not be allowed to read that this isn't really a surprise to anybody and it's not really a security vulnerability as is because you know if you bind mount stuff in then you should know what you're doing so this isn't a surprise but you know if we were running this with rootless potman then this wouldn't be an issue you would still get this at UAD binary but it would be for that particular user that might not have privileges to do anything else so we could improve by running this container as rootless potman right so running things as rootless potman that brings us to the issue of networking because if you want to offer a service then you probably want network in your container and in potman in rootless potman there are basically two options either it's slurp for net and s that works using a tap device but has a couple of limitations for example you can only communicate among various containers by via exposed ports on the exact same host or using the local host interface and all the requests that you get will seem to originate from the IP address that's associated with a tap device so you lose the information of where the request was actually coming from and you might want to use that to filter you know for which IP networks you offer a particular service then there's some improvement on top of that where you and essentially take slurp for net and s put it in the user namespace that owns a network namespace and then do a common typical networking using net a vark and after that that's great because it now allows you to do standard networking between containers but it still uses the slurp for net and s tap device so all requests still originate from the same IP address so this isn't really ideal if if we want to do is run a service so the question that I was asking really turns into can we run each container as a separate rootless potman user but with the proper networking proper in quotes as in the root for networking right and that's the question that I want to answer today and so you now see my motivation is the outline for the talk we have to talk a bit about theory but it will be quick I promise you and then I'll outline the various solutions that I found by following a mailing list post in the presentation somewhere in the potman user group in 2021 I think that was recently removed from the web server boo I have to go to archive.org to get it now right let's get into it some theory why is it that inside of the container we can even read the file that's owned by root right to know that we need to understand how username spaces work username spaces separate they basically give you a separate UAD range and that UAD range is mapped from inside the container to outside the container using a mapping file and this is what does this mapping file is you can do this with pretty much every container that uses username spaces and essentially tells you zero in the container is user a thousand outside of the container and repeat this for the following number of UADs in this case one and then after that one the UAD one is mapped to UAD five two four something for the next sixty five thousand and three hundred and something UADs and this is what it will typically look like on a modern system we have sub UADs and the rule for accessing files is that containers and I look this up in the kernel can't access I notes that are owned by UADs and GADs that are not mapped inside your container so if you don't map the UAD zero then nobody can access roots files it's as simple as that so that's theory part one theory part two is on networking for that you need to know that any non-user namespace is associated with a particular username space and if you want to do an operation inside that namespace then you need the required capabilities in that username space to do that sounds complicated but will be a lot easier once we get to the example so managing a network connection requires cap net admin that's the capability that the Linux kernel checks when you try to modify the IP address of a device for example if you now do this in a network namespace owned by a username space in which you are root then you have that capability usually and that action is allowed however changing the hosts network namespace requires cap net admin in the hosts username space which is the root namespace that you typically don't see in configure but it exists and that also tells us something it tells us if we want to use the real networking then at some point we will have to have cap net admin in the root username space so there's no way of doing any of this without using actual root so for some pieces we will need root so my first idea when I was trying to do this was okay I'll start a rootful container but potman offers me this this flag dash dash UAD map that allows me to configure which UAD mapping I actually want so let's just not map the root user from outside into the container and then the problem that I was trying to solve the soft right this is what these lines here do so essentially I'm saying zero in the container maps to the user that I'm currently am outside of the container and then the second UAD map line just does the same thing with sub UADs we will ignore for now because it's you know we don't need to understand this to understand the the concept that I'm trying to go for so when I prepared this talk I rerun this command and my heart almost stopped because I thought wait this didn't use to work and this is the error message that I used to get when I did this turns out this is fixed in potman 45 right so this is what you should be doing thanks for coming to my tattoo goodbye yeah so I mean now this works but I'm still gonna tell you what I did before it worked and there might be you know you might learn a thing or two and you might still want to not do this particular solution but we get to that so I did some googling and I found a presentation that essentially said yeah you can run these two commands then run set up the network manually and that should work and here's a link to a mailing list post of a guy who probably did that at some point in time and then I clicked that and thought okay this looks nice I can probably do this and the idea here is that we you know all of this is as user now so we are running rootless potman I create the container note create not run or start or any of that I create the container without networking I give it a name because we will need that name for the for the commands that follow right after I run container in it that's also an interesting command because what that does it sets up all the namespaces but doesn't actually start anything inside your container so you have the namespaces available then you have time to modify them for example the configure network which you know I did here in a script let's call it magic.sh and after that I run potman start and my container starts as normal so the question really is what's inside this magic.sh and it's this and it's kind of a lot right let's go through what this does I will take potman and spec to figure out the PID of the container that we initialized but didn't start then this next the sudo ln line is really just to give the network namespace a name that the IP utility from the IP route package can use and then I do what potman initially or internally also does which is set up a virtual ethernet pair move one side of that ethernet pair into the container then rename it into the inside of the container to eth0 which is what we would expect the network's name to be and then bring it up on both sides and configure an IP address so we can have communication going on that is a lot of work and note that we haven't actually we haven't well we had to do manual IP config for this so I had to choose an IP address and set it then potman inspect won't know about this because we didn't use potman to configure the network we must repeat this every time we start the container and I haven't yet dealt at all with exposing ports which requires right writing firewall rules which I really don't want to do manually this is like tedious work and I yeah I could probably write a script but at this point I was almost I was about to give up on this because I thought now I don't want to deal with firewall rules and exposing ports I don't want to let's just run everything with root and then I thought how does potman actually do this where's the code in potman that creates all these network interfaces and chooses an IP address and assigns all of this and turns out there isn't because what potman does it calls net awark for this and just pipes a bunch of JSON into it and net awark takes care of of configuring the network interfaces moving them into the right namespace and so on so I thought can I just you know create this JSON configuration pipe it to net awark and it will do what I want for me and turns out yes I can so I created a new potman network you can give it IP we think IPv6 or not if you want to I mean we want to get rid of legacy IP so you should these days then generate the required JSON that contains the IP address that you want to give the container so we still have that problem and you that contains the exposed ports and then pipe that to net awark setup with a path that identifies the network namespace in which you want to do this and then that will give you in return a namesaver server configuration that you should somehow get into the container I was lazy I just wrote it to ETT Resolve Conf what does that JSON structure look like unfortunately it's not documented at least not in the net awark readme's or documentation and also not in the potman documentation so I reverse engineered it and this is the the rundown of what this is it tells you okay I'm looking at this container ID with this container name here's a list of the port mappings from which container port to which host port how many ports which protocol and it also gives you a list of the networks that you want to attach to and which IPs and you want inside that network and this also gives you DNS so you can get name resolution and the service discovery if you also specify name aliases for that and then there's this block network info here at the bottom that I omitted because it's really just the output of potman inspect on the network right and this is the point where I show you that this works and let's pray to the demo gods because I'm running this over Wi-Fi and if it doesn't work then I have a a TTY recording of me showing this so I have two shells here on a Fedora 38 system can you still hear me while I'm sitting yes great I have two shells here on a Fedora 38 system one is root and one is the test user and I said we want to start out as the test user so let's do that I want to define a runtime directory let's call our container root less and for that reason I'm choosing that particular runtime directory and then that probably doesn't exist yet so I'm gonna make it and then I'm running potman create and this CAD file that I'm specifying here I explain in a second because I automated all of this I'm not gonna do it manually now for everyone and that expects the ID of the container in this particular path so that's why I'm creating it disabling network giving it a name and we're starting Fedora 38 and just for the demo we're starting a Python web server on port 8088 right so this was created now now I need to run this container init command that we saw earlier so potman container init and then the name of the container that passed and now we can see in potman ps-a that we have the container it's in status initialized it's not running yet right so let's get the PID for this so we can see what's going on how am I probably I should probably skip some of this let's go to yeah I scripted some of this and this is the part where we need to start running things as root so as root I have a script here that allows me to set this up now I need to use the exact same runtime directory that I used here so let me copy this and fix it because obviously ID dash you will return something else then I run setup I specify a name that's used to generate an IP address so in this case I just use the container name again then I have a secret that I use so that the IP address isn't predictable that I'm generating test is the user that I'm running the container under then I want to attach this to the rootful zero network and I let me quickly check that this network actually exists so we don't get an error it exists and I want to publish a port that's 80 to 88 so 80 is outside of the container 8080 is inside of the container and I could also specify a network alias here but I'm not going to show you the resolution anyway so let's just skip it I mistype something this exists and container ID exists in there there must be a typo where I don't see it can no no that's not that's not the issue I mean at this point this the case where I'm stopping this and just showing you the recording because I don't have time to debug this right now so you we see the same thing and now I'm sure that this will work right and the advantage says that I have time and I don't have to a type so I can tell you what's happening so we already saw this right I'm creating the runtime directory then create the container without network again again I'm giving it a name and we're starting the exact same Fedora 38 container is created containers initialized then again we see the status is initialized here I'm getting the PID of that container because I'm in this case I'm going to show you some of the network namespaces so what we see now is this is the process that's actually running right the containers and running but there's the C run process which initializes the namespace this also lists the namespaces that we that we have so if you have time to look at the details you notice that the numbers are different behind this so this means that the namespaces have in fact been created both the user namespace and the network namespace and we can also see and that's what this nsenter command is doing here now we can now enter the namespace and look at the IP configuration inside of the namespace and we should expect that there will just be a localhost interface interface because we told it not to set up any network and that's what we see here right so there's no eth0 no other network connect connectivity now is the point where I want to set up the network so again we see the rootful zero bridge exists that's the bridge that I want to attach to this container again the path to the container to the runtime directory that it created set up to tell it to set up rootless is the name and then the secret that I used to generate the IP address test as the user rootful zero is the is the network name then publish because they want to publish a port and in this case I'm also specifying a network alias that will be in the DNS server inside of the container and this is the successful output a lot of JSON you don't need to understand it it just gives you the network the DNS configuration and now we see if we rerun this ns enter command that the Ethernet connection exists at this point right and if we want to right now we need to start it obviously because then the process inside the container wasn't running yet so I ran potman start rootless now it's running and now we still need to test it because you know if it if we didn't test it then it's broken obviously so I'm figuring out my own IP address and using curl to send an HTTP request to the Python web server inside of the container and it works so our networking worked as expected I'll skip the stopping because we're running out of time I also have the same thing automated with system D so I put the exact same commands in a system D service file and the lines that require root privileges system D allows you to just specify a plus at the beginning of the command and I will run them with root so that's a nice trick to get all of this in a single system D service file I'd show you but we run out of time so you'd have to go to the website where I published this and you don't have to scan the QR code now it will be on the last slide again and so no hurries and that also will contain this root for networks Python script that I just used to do this right so what did we achieve so far we now have automatic IP configuration even though you know I had to reimplement it but the script does it for you otherwise Portman would have done it we can expose ports with the system D service file that I talked about I can have this container controlled by system D and that takes care of correct start up and tear down Portman inspect still won't know about this network because we added the networking manually and if we try to run try to use system D notifications that also won't work in this particular configuration because system D will refuse the notify it will see it but it will refuse it so what's next on this before Portman 4.5 introduced this the working dash dash here D-map flag where this just works out of the box I would have said maybe we should add a mode to Portman to drop all privileges except for network configuration now I'm not so sure honestly if you're on Portman larger than 4.5 probably just use you at E-map to do the same thing and maybe there's some improvement to be had for rootless networking there's a talk tomorrow at 9.30 on rootless less container networks get in shape with pasta so if you want to give that a shot right that's it thank you for attending and any questions right the question was then the JSON format for network isn't documented so probably not standardized am I afraid that this will break with the next network update yes very on the other hand it's also a interface across two processes between Portman and network so I know those two are developed in in unison but I'm at least hoping that they will preserve backward compatibility and what I'm currently doing will continue to work it also looked like somebody really wanted to document the JSON interface just didn't so I think that's the lack of time is the only reason why it wasn't documented yeah so the question is I demonstrated that the that said you are deep bit trick won't work because it will map to the unprivileged user what about file capabilities I actually can't tell you I'd have to look into the kernel source code what it does but I'm assuming the the rule that I learned from Michael Karoski has a great training on all those isolation APIs if you have a chance attended what I what I learned from him is the general rule that you need the permissions in the username space that owns what you're trying to access and if that principle holds then it shouldn't be possible because in the user namespace that owns the files which should be the root namespace you as unprivileged user wouldn't have the capability to do that but you know I'd have to test other questions question from the internet maybe then thank you and enjoy DevCon hi so this talk is about RP filter as you could guess I'm believe most of you know what RP filter is or at least have some idea about what it does in this talk I'm going to make the scope a little bit larger because I'm going to first start developing on what the IETF says about what I will call RPF so I will make a distinction for the purpose of this call between RPF the algorithms defined by the IETF and RP filter the Linux kernel implementations and as we will see there are several of these implementations in the kernel so what is RPF let's say we have a router here in the middle connected to different networks and with RPF the general idea is that the router instead of just routing packets depending of the destination address it would also validate some the source address of incoming packets so here for example we receive a packet from network blue and it will verify that the source IP address of the packet actually belongs to network blue and not network red the objective is to limit problems caused by IP address poofing on the internet let's say for example here we have an attacker inside network green and this attacker want to attacks the victim in blue so it sends a packet to the server in red but instead of setting the source IP address with its own address it used the IP address of the victim so when the server receives a packet it replies to the victim and there are two benefits for the attacker first its IP address never leads to the network so the victim has no idea where the attack actually comes from and also when we choose carefully the server we have a nice amplification factor so the attacker can send just small packets and the server would reply with much bigger packets so there are protocols that are famous for doing that like SNMP for example so this problem has been known for a very long time and even some old RFCs like RFC 1812 requirements for IPv4 routers it defines a basic algorithm to do some source IP address validation unfortunately even at that time it was clear that it would break some routing topologies so it was recommended to not turn it on then came RFC 2827 which is more commonly referred to with the best current practice so BCP 38 that belongs to BCP man is just a collection of RFC unfortunately this RFC didn't really provide any technical solution it just talked about using access control list it just say that source IP address validation was important but he didn't say how to do that but the IETF has continued to work on this problem and we now have two other RFCs RFC 3704 and 8704 and we will see what are the algorithms they define so this first RFC defines four different flavors of RPF we have stripped RPF lose lose RPF ignoring default routes and feasible reverse the reverse pass forwarding feasible RPF the stripped RPF is really the simplest and most intuitive version so here we have a router connected to two gateways bringing to two different networks so with stripped RPF what this router does is when it receives a packet from gateway blue it will look at the source IP address and if this IP address belongs to network blue it will route the packet normally and if it belongs to another network either network red or it's not routed at all it drops the packets so this is the original idea that we found even in the oldest RFC the problem is that it has always been clear that it would break a symmetric routing so here for example we have two nodes node A and B they can communicate between each other between two gateways blue and red but node A is configured to only use a gateway blue and node B is configured to only use gateway red so when node B receives a packet from node A from gateway blue it will do the strict RPF control and it will realize that normally the node A is routed through gateway red also it received the packet from gateway blue so it will drop the packet and same thing with node A it receives packet from node B through gateway red but it would route it through gateway blue so RPF strict RPF has actually broken communication between our two nodes so another variant of RPF that was defined was lose RPF so the lose version doesn't actually take the input interface into account so it just verifies that the packet is actually rotable that the source IP address of the packet is actually rotable so in this case we have when the router receives a packet from gateway blue it will just do a route lookup on the source IP address and if the source IP address is rotable it will just route the packet normally even if the source address belongs to network red obviously if the router even has a default route lose RPF is going to let almost any packet go because yeah as soon as it's rotable it flows that's why we have the special variant of lose RPF ignoring default route where the default route actually can't be used for the route lookup but it doesn't really make any difference in practice for example in our case gateway blue or an attacker from network blue could still proof an IP address from network red so the first variant of RPF that was defined in RFC 3704 is feasible RPF feasible RPF is interesting because it uses some extra information that were not used in the other variants so we actually use all the information that are available through the different dynamic rotting mechanisms so let's say that we're using BGP here we have different botanomus system so at the bottom we have AS0 that announces different routes while here it's the same route so it's 2001 DB8 AS-48 it's announced to AS1 and to AS2 and eventually AS4 learns about this route and AS pass is longer on the red side so it for routing purpose AS4 doesn't takes the route from AS3 into account but with feasible RPF for incoming packets AS4 would accept packets with source IP address 2001 DB8 AS-48 as a source IP even though it wouldn't use it to send packets because of feasible RPF and because it was announced on the other interface too but that wasn't enough for all practical use cases so actually the IETF has continued working on this problem and has defined a new RFC which is RFC 8704 with two new variants of RPF so they're all based on the idea of a feasible RPF but yeah the algorithm gets a little bit more complex yet even the acronym as you can see is getting complex so the idea here is again to use the information we can collect with BGP and instead of checking the origin of the source IP address we will check the reachability of the autonomous system that the source address belongs to so for example this is algorithm A so that's the first algorithm defined in this RFC we have AS0 that sends that announced a route to AS1 and a different route to AS2 and finally AS3 receives the announcement for both routes and with this ERPF the enhanced feasible paths RPF will accept packets from any of these prefix no matter if it's received from AS1 or from AS2 because these prefix both belong to AS0 and AS0 is the origin AS in both AS paths in practice there are also problems with routes that are not propagated to all the autonomous systems so the IETF has defined algorithm B so that a network administrator could work around this problem by putting interfaces into an interface group so here we have AS0 who announced a route to AS1 and AS2 it's the same route but AS2 that don't propagate this route to AS3 but this is worked around with the administrator putting both interfaces into the same interface group so now AS3 can send packets with source IP address belonging to this route even if it arrives from AS2 it will be accepted by AS3 because it's in the same interface group as AS1 and it would be accepted if it had arrived on AS1 so as you can see RPF has become something much more complex and complete than just a simple route lookup on the source IP address and we need some information that are not available by the kernel to actually implement them okay so enough with the theory now let's see how the Linux kernel implements RP filter so as I said we have several RP filter implementations we have one CCTL for RPV4 and then the IP tables IP6 tables and NF tables modules that all have their own implementation so that's three IPv4 implementation two IPv6 implementations so here how we can configure them you can see that in the slide offline all these implementations support strict and lose RPF there's a special option for lose RPF with all these modules and beyond the limitation we already saw in the theoretical RPF algorithms we have to face some kernel specific problems so first we have five implementation to keep synchronized and we have the fact that the kernel doesn't handle IPv4 and IPv6 routing tables in the same way and we also have kernel advanced routing features so we'll see in detail what are these problems so first let's see just how RP filter interacts with regular routing tables so here we have a route that is defined to use two different output interfaces so what happens is that with most of the RP filter implementation we can receive packets from any of these interfaces just the NF table IPv6 implementation only allows one of the interfaces if you we do the same kind of configuration but with more recent commands let's say so we who if we use next hop groups instead of a single route with several next hop as we did before we get the exact same results so I'm not going to go too much into the details about why it's the case but it happens that the problem stands in how RP filter handles ECMP routes because what we did in these two examples is create an equal cost multipass route so yeah RP filter and the IPv4 and IPv6 implementation handle that in different ways which leads to different results now let's see what happens when we define the same route twice but with different gateways so we can do that with IP route append and let's see what happens so this time we don't have an ECMP route so what happens is that most most implementations with will only accept the first route and only the IPv6 tables RP filter implementation will accept packets from any of these interfaces and again that's slightly handled about how the kernel handles ECMP even though we didn't explicitly want an ECMP route but IP IPv6 internally converts these routes into a single ECMP route and yeah the rest is implementation detail that yeah I'm not going through that now because we won't have time now let's see a more common use case which is to define the same route but with different preference so here we have preference 1000 and preference 2000 they use two different interfaces a preference is like metric you can use yeah whatever the keyword however you call it it was the same way so the favorite route is eth 0 and eth 1 is just the full background so what is RP filter RP filter supposed to do should it accept packets on eth 1 or only on eth 0 and the result is that almost all implementation accept packets only from eth 0 but again IPv6 tables behaves differently here it's slightly related the road course is slightly is the same as for the previous example this is because yeah this implementation constrained the route lookup for IPv6 RP filter but yeah again that's maybe something we can talk about later if we have time these are problems that probably could be worked on in the kernel at least to make the different implementation behave similarly but there are also problems that really are more fundamental problems and that are not only dependent on how the code is written so let's talk about policy routing policy routing for those who don't know is when we use different routing tables filled with different routes and we jump from one table to the other depending on some particular patterns so here for example we have the main routing table that uses eth 0 and we use eth 1 for table 100 and we decide if we do our lookup in the main table or in table 100 depending on the destination port so here if destination port is 50,000 we jump to table 100 and if not we jump or we stay in the main routing table so let's see what happens and in this case what happens that only the RP filter cctl the IPv4 so we jump to table 100 so it will roll packets it will accept packets from eth 1 if the source port is 50,000 so here RP filter just swap the source and destination port which probably is intuitive because actually that's what happens for the IP address but we'll see that it's not always the right solution and for all the other implementation it's simple the destination port is not taken into account so we just never jump to table 100 so jumping to table 100 when we have source port 50,000 might look like the good idea because when we send the packet to destination port the answer will come back with the ports a source and destination port swapped but that's not always the case especially with UDP tunnels like Vixler or Geneve we always use the same destination port and in this case this behavior is not appropriate so let's do policy routing but on something different let's use a packet field that we can't swap between the request and the response so let's use the DS field DS field is kind of like the toss for IPv4 or the traffic class for IPv6 those should be obsolete and should be replaced by DS field but you get the idea of what it is so let's see what happens and if there are some differences between our different RP filter implementations and actually all implementation work more or less the same way I'll leave some details but we can consider for this talk that they behave the same way so what happens is that if the DS field from the written pass matches the IP rule then we do the wrap lookup in the table 100 so again that probably looks intuitive but in reality the DSCP doesn't have to be mirrored on the return pass so if the if the return packets don't have the same DSCP value than the outgoing packets we're not going to jump in the same table and RP filter will break connectivity and we can also do policy routing based not on IP packets or IP packets fields but on metadata of the packets for example we could use the packet mark the socket user ID the input interface and more but we are only going to consider these examples so packet mark most of well all of the RP filter implementation won't take the packet mark into account for doing their wrap lookup because the problem is that again we need to have the same packet mark on outputs and on input to get to jump to the right table and often it's difficult enough to have the packet mark be symmetric on input and output so we have to use a special special options to make RP filter no matter the implementation respect the the packet mark and we have also problems with a socket user ID so we can jump to a different routing table based on the user ID of the socket that sends the packet so that's for locally generated packets but on the return pass of course we don't receive the packet from the socket we receive them directly from a network interface and we don't even know yet on which socket it will be delivered so all the RP filter implementation make the wrap lookup with socket or the user ID 0 so as if it was sent by root and for input interface we have the same kind of problem so if we do some policy routing based on the input interface for when we send the packet that has just been routed we know on which input interface we received it but on the return pass how should we do our wrap lookup if we want to reverse input and output interface then we should say the input interface is the actually the output interface we would use but this also is not known all the time this depends on where the the rule is on the net filter hook so that depends not only on the implementation but also on where the rule is inserted so to summarize the problem with policy routing we have different set of meta data available in the transmission and reception pass we have packet information that might be different on transmit and receive pass and even for something as obvious source and destination port where we say well we should just swap the source and destination port that doesn't work all the time so really we have a fundamental asymmetry between the receive and the transmission pass which makes policy routing mostly incompatible with RP filter so to summarize the world talk RP filter even if we consider just the theoretical part of it and only the IETF work it's not just a simple on-off functionality we have to select which flavor of the algorithm we want to use for advanced algorithms we had we need some cooperation with dynamic routing daemon we might need for if you remember algorithm B some special configuration from the administrator also we have to keep in mind that RPF was designed for routers and especially for ISPs not for end host and yeah routing daemon I talked about it and then we have the implementation so we have five different implementations for RP filter which are hard to keep synchronized we have all the complexity of how the kernel manages the kernel route lookups and that has some side effects on the implementations there are some things we could improve like the handling of equal cost multipass in order to make all implementation behave similarly but there are also some fundamental incompatibilities with advanced routing in particular every time well or many times where we use IP roles also we don't support and can't really support currently the advanced RP filter algorithms because we need some cooperation with BGP daemon okay so thank you and time for questions yeah so the question is can we detect if automatically if some IP rules are going to create problems when we use RP filter we could at least detect that we have some special IP rules and then consider this is a potential problem for RP filter but the biggest problem is yeah what are we going to do if we activate RP filter and we detect that there's going to be a problem do we just disable RP filter entirely because there's no correct way for some of these IP rules there's just no correct way to handle the problem automatically we need some help from the administrator yes yes so yeah the question is is it primarily primarily a mean to manage the problem under the problem of IP spoofing on the internet yes from the IETF point of view and the reason why RPF was designed by the IETF yeah that's the main reason that's really the reason yes so what the IETF recommends is that you activate RPF as close to the customer as possible and if possible even on the first router and then if you have a very big broadcast network behind this well probably you also have also security problems if you have a big internet segment yeah again on linux we can activate it on router or the N-host or RP filter implementation they work similarly on the router on routers on and on N-host is just make less sense on the N-host because if it's not going to change anything for the IP spoofing yeah yeah okay yes repeat the question the question is should we disable it on the rail by default I know this question has been answered already some years ago and it was said that no we shouldn't disable it by default because it's security and we don't disable security and there's no really technical argumentation it's just a fear of accepting packets that were not accepted before so yeah the reason is this yes no more question thank you


But before we do go again special thanks to QA team. Yes, yeah, Ryan Pete Matt for Putting this together. We have a fight now that we're gonna show you between Johnny Cage and Scorpion showing how they actually Work in a real fight. Take a look. Oh, that's classic that I've used that move before Well, you do act like a 12 year old Johnny Cage clearly has the home advantage Yeah, that's true Although, I mean you could make the case that he's gonna be more tentative while fighting because he doesn't want to break everything Oh, yeah, he definitely would not like Right, it's a really nice looking art and an indoor pool in the front room There's a giant picture of himself in there as well, which I absolutely love I need to get one of those There he goes for the hold. Oh, that's a perfect example He risked it to get that meter up and Totally lost because of it, but One of the little meta things there is maybe he felt it was a losing round Anyway, it's worth it to have it for the next round fun facts during during development That flamingo back there like there are multiple times where if you did like a big hit or something it would just go fly Out of the pool. I hope they fix it. Oh good punish on that Bacteri rope the breakers look so cool in this. I love it because again with cameos. They're all different. Yes Good punish. Oh and Swagging wow using the teleport in a combo very very cool on that that overhead kick gets me all the Love the cameras on the throws, too. They're very very cool. Oh Okay, man, you canceled out of it. Yep. He just wanted to check it out. All right If you need me here if you need me He's been sitting on hype. He has not activated the whole time. Oh, excellent use of canoes cameo there, too Here we go Very smart from scorpion. He was ready for it. The hype note is active. Here we go. Oh my god. Oh How many times he's gonna hit the person in the crotch? Wow a 50% combo with hype Possibly the last round. Yeah, excellent with Scorpion there. I was right how rounds work I love this throw. He's sitting back there taking frame of it. Oh That Johnny Cage. Oh He almost had him right there You would have gone to the upper cup brutality. That was the case. We'll be in the ones nothing to do with this. Oh So you like explain that fatal blow the attack into it is actually a parry that he can hold And it it catches you. Yeah, it's like We're gonna save that for next time for another time another time. Okay, okay Nice. Well, big things to QA. That was an awesome fight. Yes. That was fantastic The when they first showed sent it to me. I was like, oh, that's exactly what I wanted Just amazing. So we will have some more of those