PLNOG15: Simplifying network deployment using Autonomic networking and Plug-and-play - Steinthor Bjarnason

Editor's Notes

• #6: In an increasingly dynamic, complex, fast changing network it will be increasingly difficult to manage the network. Humans will not be able to manage networks the way we do it today. Networks must increasingly manage themselves. Self-managing means four fundamental things: … (see slide) The word “self-*” might be interpreted that the admin loses ; this is not the case: it means that the network takes or proposes default actions, which can always be overridden by a human admin. Autonomic means that the “easy” decisions can be made directly by the network. This is like OSPF
• #7: [click] Typically a deployment involves Purchasing and some Pre-staging of equipment, to allow the device to be booted and become reachable from the NOC. At the expense of Security pre-staging can be skipped, but is that really a risk you want to take in SP Networks? [click] Then the device is shipped on-site (truck-roll) and installed. [click] After installation and booting and discovery of the device, it is reachable from the NOC, and further Service activation and Management/Customization can be done. Also, if a device is deployed and reachable from the NOC, configuring it remotely in the wrong way can often lead to the device becoming unreachable. Another truckroll or sending an engineer on-site is then the only solution. [click] Is there a way to eliminate pre-staging altogether, while not sacrificing security? Can we make sure we do this without requiring any special appliances or servers? And how can we make sure that misconfigurations do not lead to unreachability of newly deployed devices, and consequently another truck-roll or onsite visit? Enter the Autonomic Networking Infrastructure [next slide]
• #18: PnP Agent: Running on the switch, devices ex. switches PnP Server: APP running on APIC-EM (PnP service running on APIC-EM and APP talks to the service. REST API’s can be used to automate the work flows as required by the customers). PnP Protocol: Agent and Server talk using PnP protocol, its an open standard protocol Installer App: to load bootstrap configuration and monitor/troubleshoot (optional) Must only for branch WAN router bring up where it does gets public IP from the ISP, and does not have access to the corporate DHCP server. For all other cases, The App is completely optional, and can be used to monitor, validate and troubleshoot device bring-up. Could redirection server: Device coming on, tries to locate the PnP server, cloud redirection service redirects the agent to the correct server Idea is to migrate all other solutions ex CNS – to PnP solutions. They will coexist for sometime, but will eventually integrate. Prime PnP, agent will communicate with Prime (new App in prime) via the CNS.
• #19: Option 43 format and examples  * Function: pnpa_api_process_dhcp_op43()  *  * Description:  *   dhcpc receiving DHCP Offer with option 43 info, pass these info  *   to PNPA do the special handling here  *  *     5A = PnP DHCP ID  *     1D = PnP DHCP debug on  *     1o = PnP DHCP debug off  *     token.K = <protocol> 1: XMPP-starttls; 2: XMPP-socket; 3:: XMPP-tls; 4: HTTP; 5: HTTPS  *     token.B = <address type> 1:host; 2:ipv4; 3:ipv6  *     token.I = <remote server ip add / hostname>  *     token.J = <remote server port>  *     token.P = <server jid>  *     token.N = user <name>  *     token.O = <password>  *  * Example of expected PNPA DHCP Option 43 commands:  *   1. To build the following  *     pnp profile zero-touch  *      device user pnpagent2@ejabberd.test password 0 cisco  *      transport xmpp socket ipv4 172.19.193.60 port 5222 sasl plain server-jid pnpserver2.ejabberd.test  *  *     Configure one of the following (1D=debug) on DHCP Server  *       option 43 ascii "5A1o;K2;B2;I172.19.193.60;J5222;Ppnpserver2.ejabberd.test;Npnpagent2@ejabberd.test;Ocisco"  *       option 43 ascii "5A1D;K2;B2;I172.19.193.60;J5222;Ppnpserver2.ejabberd.test;Npnpagent2@ejabberd.test;Ocisco"  *  *   2. To build the following  *     pnp profile zero-touch  *      transport http host FE80::2E0:81FF:FE2D:3799 port 6088  *  *     Configure one of the following (1D=debug) on DHCP Server  *       option 43 ascii "5A1o;K4;B3;IFE80::2E0:81FF:FE2D:3799;J6088"  *       option 43 ascii "5A1D;K4;B3;IFE80::2E0:81FF:FE2D:3799;J6088" * IPv4 Address of PnP server * option 43 ascii "5A;I172.19.193.60”  
• #23: Solution should help to mitigate the 3 main attack vectors: Install hacked SW on a device (ref. SYNful, ROMMON) An attacker replaces the current IOS image on a device with an older IOS images which has known vulnerabilities which he can exploit.  An attacker can modify the running image in memory using remote exploits and thereby gain control of the device. A device can be fooled into joining the wrong domain Install a hacked HW module or a spy device into the device. #1 is already done on many device but bricks the device #2 is feasible if AN provides a good mitigation story  Allow SSH access to the devices, block anything else #3 is future, a device should be validated on a regular basis and quarantined #4 can be solved with AN and the MASA server
• #27: SUDI in the ACT2Lite implements that function at manufacturing, providing your platform with certificates, PKI (private and public keys ) to initiate zero-touch secure connections between your platform and satellite boxes or other platforms without manual keying in of keys, a place to securely storing yours and your customers Locally identifiers for other functions such as licensing and auditing, etc. It also can work in concert with Secure Boot to protect against insider malware insertion. Along with Identity and Secure storage, ACT2Lite provides RSA encryption and an strong entropy source. Having ACT2Lite in your platform future proofs you by providing a very strong product security and assurance foundation as we go forward providing secure platforms for SDN/1PK. Initially, Cisco declared that all Cisco products must contain a Unique Device Identifier or UDI. This was simply an 11 character string which was installed somewhere in the FLASH memory of the product during product manufacture. Unfortunately, the adversaries found it all to easy to change. Enter, the Secure UDI or SUDI. SUDI embeds the UDI information within an X.509v3 certificate and signs it with a Cisco controlled private key. This made changing the identity information virtually impossible. But since simply delivering the certificate to the host software would not really prove anything, the cryptographic requirement of Proof of Possession is used to prove that the device private key associated with the certificate is also present. Keeping the private key private and undisclosed is crucial to the success of this cryptographic process. Using the SUDI, a device could also assert its identity to other communications peers. This was a valuable usage. Unfortunately, protection of the device private key was in many way on the same order as the original UDI string. It was stored in FLASH and hopefully protected by software. However, it was relatively easy to lift from the device using a hardware-based attack. Once retrieved from a true piece of Cisco equipment, the attackers could use the SUDI certificate and associated device private key to clone as many copies as desired. Unless there was something in the network which could detect the use of duplicate SUDI identities, there was no protection available. Customer Benefits: - Allows customers to accurately, consistently and electronically identify Cisco products for asset management - Provides version visibility - Enables service entitlement by serial number, quality feedback by version, and inventory management - Consistent device identity and certificates across secured products - SPs: Enables custom deployments, allows for use of a Cisco provisioning service
• #28: Image Signing provides increased integrity and authenticity assurance, supports the requirements of FIPS 140-3 and provides authentic software when securely booting the platform. Cisco builds digitally signed software to protect against the use of counterfeit images, and to assure that the image has not been tampered with. The images are digitally signed. The Cisco IOS image file, generated in the production build process, contains a file extension based on a signing key that is authenticated by the router.
• #29: Immutable -: unable to be changed
• #30: #1 “AN solves 50% of all security problems in one go - secures all management protocols automatically”
• #38: Device deployment is still a challenge: Switches go to a pre staging area, admin (partner/reseller) puts basic configuration, image required etc. Then boxes are shipped it to a final location where expert/skilled person/installer has to go and manually bring up the boxes (final configuration, troubleshooting) 1. Time Consuming/ Complex 2. Expense/Cost Shipping devices first to staging facility and then to final destination. Expert Installer work costs, and cost of his/her travel. 3. Security Expert needs to be given the passwords and access to configuration information etc. 4. Error Prone Auto Install, Smart Install, CNS – tried to provide solution to limitations and make it simple and scalable. Network PnP is a very simple to use, secure and scalable solution that supports end-to-end platforms available for our Enterprise customers It’s an App running on top of APIC-EM and involves few steps from admin (which are optional) and a unskilled installer can install devices at. Troubleshooting can be done by admin sitting in a central location. Advantages: No need of skilled installer End to end platform support Easy and Intuitive GUI access Green field and brown field – SMI proxy for devices that don’t have agent running right now. Secure