Cisco Secure Zero-Touch with IOS XR: Seamless Trust Enabled on Day Zero

hi i'm akshat sharma i'm a tme tech leader at cisco and i primarily handle xr and a lot of the operational and the automation requirements around it so what we'll cover today is an rfc compliant implementation of uh secure zero touch that's coming out with ios xr and uh i think it's quite exciting to actually have this uh gear up with a lot of the stuff that's going out for both the 5g and the data center deployments from the xr portfolio so we'll kind of see how that matches up and we can go into more details there in all right so before i start off let me give you a quick background on what we've done with classic gdp there's a reason why it's called classic cdp now because secure zdp is on its way and this classic cdp workflow is something that you'll see in a similar fashion across vendors essentially your box boots up there's no config on it it's going to send out dhcp messages v4 or v6 you typically have a dhcp server and you'll have certain set of options that you'll use to identify your device classify it give it an ip give it the specific options that it needs for example for v4 you'll give it option 67 a boot file name and that ends up giving you either the location the url to download a cli config directly or a ztp script in the xr lan we support uh frankly any type of uh binary packaging that you need but uh we of course support natively python and bash libraries which allow you to do just about anything on the box in terms of automation so typically you would expect that customers have their ztp scripts lying on a web server based on the option url given to the device the script gets downloaded or the config and it gets executed subsequently so the device basically gets provisioned to a certain state as needed which is these three components in play the router basically with no config or anything on it the dhcp server to get it the ip and the options that it needs and then the web server to download stuff now keeping that in mind what do we actually do with it uh we can apply configs we can deploy applications uh whether they're on box uh you know containers binaries cron jobs whatever you want to set up you have several software upgrade and downgrade workflows that you can work with so you can actually utilize your scripts to do a bunch of upgrades and downgrades and you can even do that uh subsequently in the day one day two life cycle of the device as well and of course you get access to just about all the automation libraries that you need so you can use cli you can use the yag modules etc right on d0 and that's you know the basic set of functionalities that you typically want to cover and yeah it depends on you on in terms of the amount of complexity you want to have on day 0 versus day 1 or and above so if you want to pack let's say nso into your workflow you typically have a cdb script followed by nso bringing in you know the entire shebang or what you want to run on the device and as i mentioned we have a well established python and batch library available on the box so you can basically get access to either the cli or the xml format for the yang models to work with typically we've seen that most customers are still really conversing with cli automation on day zero and they tend to prefer that so you definitely have an exhaustive library covering that and that gives you a quick background on classic gdp what we want to consider however is where is it lacking well first of all where do we want to play now ios xr for the longest time has covered several parts of the service provider network and for the first time with some of our boxes that came out particularly the ncs 540s we also started focusing a lot more on the access side of the service provider market and when you consider that part of the deployment including uh several requirements around you know the 5g access we start considering the basic requirements for ctp primarily because of the shear scale of devices that you're trying to deploy and remember this is topology agnostic so you don't really care about whether it's a ring topology or a hobbin spoke or a hierarchical setup irrespective of how they're connected you need to figure out a mechanism for either all or some of your devices to be bootstrapped in a zero-touch fashion and make sure that they're able to connect back either to a centralized location or to multiple centralized locations as the case may be so keeping that in mind there are three basic items that you can think of one of course you would have a tree based build out strategy so if you have sort of a tree that you're building out you know that irrespective of the topology if one device has access to a set of services like the dhcp and web server it can act as a relay for the next set of devices that connect to it and you can build out uh quite organically and this is we've done several deployments in this fashion and really just becomes topology agnostic once you're able to figure out the correct relay configurations that get applied um in sequence across these devices as they come up and of course security is critical right so once you start considering where these devices are going they could be in um shared knocks they could be on top of a telephone pole um you're basically trying to make sure that you have a way to trust the device that joins the network and if possible allow the device to touch the network that is joining right and that's the level of security that you're looking for when you bring these devices in and bear in mind this works for several data center deployments as well and we're talking to a lot of tier one web customers that are actually super interested in getting a secure workflow on uh day zero ztp and of course there are several other competents coming in with vlan discovery i'm not going into those details today but uh even if you have a layered cloud in the middle uh figuring out how to discover the vlan on which the dhcp request must be sent out is something that a bare-bone naked device needs to do when it comes into the network so there's several mechanisms at play there but as i mentioned the talk today is primarily on the security aspect so we'll focus there another important point to consider is the fact that the ztp implementations are very similar but really different across vendors i'm just giving you a quick snapshot without naming names of uh the type of options that you haven't have in play right the options that you send out from the device to the dhcp server and what you get back from the dhcp server varies across vendors uh those who know know which vendors i'm talking about and as a result of this what happens is that there is an abstraction that the operator then has to take care of to deal with this sort of disjoint complexity on the operational side and then figure out how to make things work in a consistent fashion it goes without saying that you need to get to a system where you can standardize these workflows and not really depend on you know vendor specific options that have been designed over a period of time so keep these in mind we basically have a system today that allows you to automate on day zero but it has no security in play right so you can basically go ahead and download complete malware and the uh except for a few checks most of the devices would run it across vendors um and uh there is no way for the device to trust the network today nor does the network trust the device and lastly there is no standardization at all in terms of the dhcp options that are utilized and that is precisely where we start thinking about enabling trust in the gdp workflow um i think this is fairly obvious to most people security and convenience don't go together right so we need to find a sweet spot where we can get our end-to-end security as we need it and but still get a zero touch workflow going we absolutely do not want to make it a one-touch workflow where people have to get a bunch of devices in a pre-staging facility and then figure out how to securely transport them to the actual install site so what is that sweet spot in order to achieve security for ztp there are three basic things that you're trying to do one when the router joins the network you need to validate that it is the router that it's claiming to be well secondly the router itself without any config on it needs to validate that it accepts the network that it's trying to join uh and lastly the artifact which could be config scripts and with the new gtp workflow images these artifacts that are downloaded are signed and therefore uh accepted by the by the router on day zero keep these three aspects in mind and we'll combine these together to understand how the rfc basically plays out hardware root of trust so in order to accomplish any of those three aspects that i mentioned you need hardware root of trust you absolutely cannot begin with a trust that begins in the software because there there would be no way to uniquely claim that a device is let's say a cisco device and a device belonging to a particular customer bought by a given customer unless you have trust that is anchored in the hardware and that is precisely where we come to the cisco tam if you know about let's say tpm 2.0 you know more or less most of the things around cisco tam but one of the main aspects that you should remember is that all of the keys here and are signed by cisco there are certain keys in particular like the cisco cd here um that are very relevant to the secure ctp workflow and we basically make sure that based on the keys that are being utilized these are can be inserted only by cisco manufacturing or can be changed only by cisco manufacturing which basically ensures that you have supply chain protection from the get go so there is more storage available on the tab which allows customers to bring their own keys as well but you have a certain set of cisco keys already there that allow you to basically have a trust on the supply chain for the device that's being shipped out to you and therefore the sudhi becomes extremely important um ieee 802.1ar compliant we basically have sudhi a secure unique device identifier that is essentially a certificate right so it contains your paid the type of platform that you're trying to you know identify and of course the public key associated with that particular device for which the corresponding private key is also burned into the tam this is extremely important because we're going to utilize the suri to identify the device and also uniquely challenge it to prove that it is the device that we're talking about so in order to establish this sort of unique identity this is the structure that is utilized based on the ufi secure boot spec i believe 2.3.1 is the first one that started off with it you have a bunch of uh keys pk the dbdbx setup that allows you to have a bunch of keys signed by cisco in the in the chip which is the with tam and then you have a few more locations particularly the on-chip secure storage that you see here which can also allow you to bring in certificates from the customer into play right so uh in addition to that there's also one more aspect which i think would be important to understand as we go through it which is the feature control flags so we are also introducing a new secure flag called the secure gtp flag which will also be used to make sure that a device only does secure zdp if it's enabled right so keep these in mind uh we're going to use the tam particularly the suede certificate within it and the enable disable secure ztp flag to make sure that the device does secure ctp only when it is shipped out and shipped out by cisco manufacturing right so what are we trying to accomplish before we do secure ctp you have to establish ownership on a device so a cisco device is shipped out to a customer site it is a cisco device but it is not owned by the customer so as part of the day zero workflow you want to ensure that when the device does get provisioned on the install site you can go ahead and push some sort of ownership credentials onto the device as part of the day zero workflow ensuring that the ownership is established as part of secure ctp what we therefore want is that if you take your own certificate so the customer creates their own let's say open ssl certificate or they have some certificates already lying around they can go ahead and use that owner's certificate burn it into the tam using the on-chip secure storage and if that happens you basically have a device that can then utilize it for subsequent features and applications etc allowing you to have ownership establishment on the device but that's a little hard to do how do you get a certificate on a naked device that doesn't trust anything at this point and make sure that it is accepted into the device in a trustworthy fashion that's where the first rfc that we care about comes in rfc836 rfc a366 basically gets you ownership vouchers this is where it starts getting interesting because we're actually stitching together a couple of pieces that leads us to the secure ztp workflow um this is the yang model from rfc a366 that describes what an ownership voucher is what you care about are a couple of things a serial number and a pin domain certificate or a pdc what this means is that for a given device you can create an ownership voucher that contains the serial number of that device alone and it contains sort of the root certificate for the ownership that we want to burn into the tap right so to establish ownership you want to burn and own a certificate into the temp the root certificate or at least a certificate down in the chain of the owner certificate is placed in an ownership voucher along with the serial number of the device if you keep just these two items in mind what you get to is this basic workflow i have a bare-boned device with a tam and i use an ownership voucher which contains the trust chain for the owner's certificate and as long as the ownership voucher is trusted by the device it will accept your own assert burn it into the tab and why does the device actually care about the ownership voucher well because this ownership voucher will be signed by the vendor in this case cisco and that is how you create a trust chain where the device accepts the signature of the ownership voucher based on the keys that are already burned by cisco manufacturing into the dam uses that to validate the owner cert and pushes it into the tab and you have ownership establishment effectively this is essentially rfc a366 right but it is the auxiliary rfc so you've considered the classic cdp workflow earlier you know dhcp server web server and the device interacting with each other and you can see the ownership establishment through rfc a366 here so we'll combine the two together and you basically get rfc8572 which is secure ztp how do you get the oe for the router what we've done is we've gone ahead uh and created a cloud-based master service basically a manufacturer authorized signing authority that's what it stands for and this particular entity is allowed to give you a signed ownership voucher based on cloud apis that you can access and you can basically use that to fetch the ownership voucher place it on a secure gtp server which is rfc compliant in this case cisco crosswork sctp server is one such example and that way you have a way to create a trust chain for certificates that will be accepted by the device in the secure gtp workflow and of course you can use the apis directly to also be able to push the ztp servers for on-prem rollout so you don't necessarily need internet access just to get to the master service in uh in all cases so there are several automation options available here and therefore i come to essentially my last couple of slides which is tying all of this together rfc8572 the standardized implementation of ztp that will ensure that you finally have potentially a multi-vendor sort of deployment possible a cross-vendor implementation of ztp and something that is secure end-to-end how do you do it you get a device bare-bone shipped by cisco manufacturing there's a dhcp server completely untrustworthy so we're not going to use it to actually give us all of the information on what to install and what to run we'll only use the dhcp server now to give us option 143 or 136 based on v4 or v6 whatever you're using and use that to allow the device to reach out to a ztp server as defined in rfc8572 there will be a bunch of yang model interactions between them and all of this happens over an http session and this allows your device to then download signed artifacts that can be run right so you basically extended the original classic cdp workflow but you have a few more complex elements added how does this in the end work out you have router validation as one of the first steps you need to accomplish how does the network trust the device i spoke about the cd certificate the secure unique device identifier that is burnt into the tab both the public and the private key the device offers the sudi cert to the ztp server upon joining the network the ztp server will go ahead and do a challenge response make sure only the device that contains this sudhi certificate is the one that is essentially corresponding and then you end up having a router validation on day zero and the second aspect which is how does the device trust the network this happens this happens basically through the workflow you see here there is bootstrapping data coming from the vdp server to the device and we follow the trust chain that we spoke about earlier there is an owner certificate backed up by the ownership voucher provided by cisco signed by cisco and all of your artifacts scripts configs redirect urls are also signed by that owner certificate that you now trust you use all of this information in a single bootstrapping data context and give it to the device the device will validate it and accept it because it trusts the ownership voucher therefore the owners cert and hence the signature on the artifact which contains the scripts configs etc and what you end up accomplishing is basically a workflow where router client validation step number one and the network domain validation step number two are both accomplished in a cup in a couple of workflows the cd certificate is used by the network or the zdp server to validate the device and finally the device validates the network based on the bootstrapping data that at a minimum contains the ownership voucher signed by cisco that is the vendor uh how crucial is that to have the ztp the service provider field because the the in the sp you don't typically see that they are rolling out the hundreds of devices every day right so in the in the enterprises it's really important to have that but how can you kind of clarify that oh what what so what meaning it has in the sp actually it has quite a lot of relevancy on the sp side uh when you look at specifically as i mentioned the access deployments um and particularly the 5g access deployments you have several hundreds of sites that are coming up at a given point in time right and those sites typically are handled by third-party vendors in a lot of different countries some of them are handled directly by the network operators themselves but essentially what you expect there is that in a given site you may have a a bunch of devices let's say 10 to 20 devices coming up in a ring and then in another site you do the same thing and again and again so what you end up doing is that today you're used to maybe deploying a certain set of devices at a time and you may structure that over a few days or few weeks or few months but with secure ctp in particular what you're trying to do is accomplish a lot of these deployments um over a period of a few days or a couple of weeks so that you're able to get a lot of these sites up and running almost immediately so we do actually see a lot of the high numbers going out with access deployments and a couple of uh our customers both uh in europe and and in the us are actually looking at exactly this workflow deploy out let's say a bunch of ncs 540s uh going into the access site in several different sites and these would go from 100 to thousands in numbers based on the number of sites you deployed

Channel: Tech Field Day

Views: 99

Keywords: Tech Field Day, Gestalt IT

Id: rl2ucWoTqyg

Length: 22min 47sec (1367 seconds)

Published: Sun Dec 12 2021