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

1. Simplifying network deployment using Autonomic networking and Plug-and-play Steinthor Bjarnason sbjarnas@cisco.com PLNOG Krakow, September 28th 2015 … or how to make the network do the boring, time- consuming and repetitive stuff…
2. Requirements for simplified deployment Increased focus on centralized intelligence Need secure and zero config deployments Access Cloud Data Centers of opex budget is needed for deployments only Average number of days to get a new device into operation Of deployments have repetitive tasks Pressures on Day 0 deployment ScaleFaster deploymentsCustomer Spend Source: Informa, Gartner, Cisco AS Analytics
3. Average cost of deploying a network device (Figures from FY2013) 0 5 10 15 20 Current Deployments Using PnP Preconfiguration Truckroll Second Truckroll [$ in hundreds] Source: Telstra Account team. Suddenlink Account team, TWT account team, Dbahn Account team
4. Autonomic Networking
5. Self-Managing Self-Configuring Self-Protecting History: IBM’s “Autonomic Computing” (2001) http://www.research.ibm.com/autonomic/ Self-Optimizing Self-Healing
6. AN and PnP solve typical SP pain points: Deployment and Operations Purchase Installation (Truck Roll) Service Activation Management/ Customization Pre-Staging Handling Misconfigurations (Truck Roll)
7. Autonomic Networking Internals
8. “True” Zero Touch Bootstrap overview RegistrarDark Layer 2 Cloud hmm, do I need a bootstrap Config ? Nope! Do you have a unique identifier? I have a SUDI! Perfect, Let’s talk! Michael
9. ZTB: Channel Discovery RegistrarDark Layer 2 Cloud VLAN noted VLAN noted Michael
10. ZTB: Domain Certificates – Secure by default 10 RegistrarDark Layer 2 Cloud Validate UDI against local whitelist Michael
11. ZTB: Autonomic Control Plane (ACP) RegistrarDark Layer 2 Cloud Router # show autonomic device UDI <UDI> Device ID Router-1 Domain ID cisco.com Domain Certificate (sub:) cn=Router-1:cisco.com Device Address FD08:2EEF:C2EE::D253:5185:5472 Michael
12. ZTB: Proxy Bootstrap RegistrarDark Layer 2 Cloud Hi Michael, I’m Steve. What do I need to configure to join ? Nothing! Welcome to AN. I’ll be your guide. Michael Steve 12
13. ZTB: Tree-like Control plane build-up RegistrarDark Layer 2 Cloud Michael Steve
14. Virtual Out Of Band Channel (VOOB) RegistrarDark Layer 2 Cloud Michael Steve AAA Misconfig / routing protocol issues `
15. Service Discovery (SD) (uses mDNS) RegistrarDark Layer 2 Cloud AAA Server Michael Steve Router#show autonomic service Service IP-Addr Syslog 2000::1 AAA 2000::1 AAA Accounting Port 1813 AAA Authorization Port 1812 Autonomic registrar FD08:2EEF:C2EE::D253:5185:5472 TFTP Server 2000::1 DNS Server 2000::1
16. Network Plug-and-Play (PnP)
17. Network PnP – Components PnP Agent Automates Deployment Process Runs on Cisco Switches and Routers PnP Server Manages Sites, Devices, Images, Licenses Located centrally (standalone, APIC-EM, Tail-f, Prime) Provides north bound REST APIs PnP Protocol Open Schema Runs between Agent and Server PnP Helper App Status/Troubleshooting checks Deliver Boot Strap
18. Autonomic Networking Infrastructure* Allows automated discovery of PnP/APIC EM server and provides a secure control plane. If ANI is not available device follows the next set of discovery procedures DHCP with Options 60 & 43 Option 60 – Vendor Class ID matching Networking Device – configured on DHCP Server Option 43 – IP Address of PnP Server DNS Lookup DNS lookup for pnpserver.local domain, expected response is PnP Server IP address – customer adds this entry to their DNS server Cloud re-direction* Device contacts url: https://pnp.cisco.com, Device reaches out to Cisco cloud URL when local discovery fails (ANI, DHCP, DNS). Expected response is PnP Server IP with additional variables Manual - using Installer App An iPhone,iPad application connects to device console, PnP server IP address is pushed to device along with an custom config. (e.g. WAN link configuration) Network-PnP Discovery Options * Roadmap Switches (Catalyst) Routers (ISR/ASR/ CSR1Kv)
19. Automated network deployment 19 INTERNET ANRA Head-end Customer HQ Remote office #3 (Internet) L3 WAN PnP Cloud Controller Remote office #2 (L3 WAN) Remote office #1 (L2) PNP/DNS/TFT P .2
20. Secure by default
21. In recent news… SYNful ROMMON NSA…
22. 1. Install modified IOS image on a device (ref. SYNful, ROMMON)  Gain full control of the device 2. Downgrade attack: Replace valid image with a vulnerable image  Allows for remote exploits 3. Install a hacked HW module or a spy device into the device  Run ssh server on a line card/packet capture 4. A device can be hijacked and fooled into joining the wrong domain  Modify the IOS or other SW on the device Attack vectors
23. Need to change the game – “Secure by default” • Create an an automated, self- protecting networking architecture which actively protect customer networks • Automatically secure the device itself, the control/management planes and lay the foundation for securing the data plane Vision: "A network shall automatically secure itself and actively protect the data being carried”
24. A Secure Network device Device Security: • Secure Hardware: Ensure underlying hardware and bootloader is secure • Secure boot: Validation of signed operating code and tamper proof storage of cryptographic key information Network Security • Autonomic Network Infrastructure: Asserts a domain identity, providing the foundation for a secure control plane • Attestation: Shares security health of the device Secure Hardware
25. Secure Hardware The “Tam” – Hardware based Trust Anchor • Provides Immutable Identity with IEEE 802.1AR (Secure UDI- X.509 cert) • Secure Storage for Certificates and Objects (50KB) • Anti-Theft & Anti-Tamper Chip Design • Certifiable Entropy for Random Number Generation
26. Secure Hardware provides Immutable Identity • Secure Unique Device Identifier (SUDI) - Currently deployed in TAm for immutable device identity • Connections with the device can be authenticated by the SUDI credential • Binds the hardware identity to a key pair in a cryptographically secure X.509 certificate PID during manufacturing Provides device identity that can be used to establish secure communication in the authentication, audit, and attestation of the device's identity to the network
27. • Software developed via Cisco Secure Development Lifecycle • The image is hashed to a unique 64 byte object using a SHA-512 algorithm • The “hash” is then encrypted using a Cisco corporate private key • A digital signature with the hash is appended to the image as part of the production build process • The image is not encrypted • The public key used to decrypt the digital signature is stored on the router • Available on all ISR series routers IOS Digitally Signed Software Counterfeit images Tampered images Protect Against:
28. • Enables Detection and Recovery of boot code integrity. • Hardware that validates the integrity of the Bootloader ensures an anchor of trust for the boot chain. • Hardware is considered immutable, not able to be changed. Using hardware Root of Trust for secure Boot
29.  A Secure Network 1. Secure control plane: Allows secure inter-device communication, automatically securing all network control and management protocols 2. Network protection: Automatically shield the network and attached devices against attacks 3. Security response: Actively detect and respond to attacks against the network and its services.
30. Integration of Trusted Boot with Autonomic Networking
31. Secure Networks Validate devices before allowed to join the network Device 31 Neighbor • Validate domain certificate • Basic level health validation • Pass to Policy controller for in- depth validation Certificate + Health • Validate health information according to Policy • Either allow normal connectivity or quarantine Enforce policy • Allow network connectivity OR • Quarantine X On power on: • Perform hardware validation using ACT2 chip • Validate and load bootloader • Perform secure boot • Results: Signed Health information Policy Server
32. Open Source and Standardization
33. Autonomic Control Plane Autonomic Node “Standard” Network OS Features Intent Parsing Discovery Autonomic Networking Layering Model Autonomic Service Agents (switching, routing, multicast, monitoring, …) Autonomic Service Agents (switching, routing, multicast, monitoring, reporting, …) Message Bus Naming + Addressing Domain Identity Aggregated Reporting API Autonomic Networking Infrastructure RFC7575: Autonomic Networking: Definitions and Design Goals
34. OpenDayLight: Secure Network Bootstrapping Infrastructure (SNBI) 34 https://wiki.opendaylight.org/view/SecureNetworkBootstrapping:Main
35. Standardization ANIMA Working Group: http://tools.ietf.org/wg/anima/ Early work • A Framework for Autonomic Networking http://tools.ietf.org/html/draft-behringer-autonomic-network-framework • Making the Internet Secure by Default http://tools.ietf.org/html/draft-behringer-default-secure NMRG work • RFC7575: Autonomic Networking: Definitions and Design Goals https://tools.ietf.org/html/rfc7575 • RFC7576: Gap Analysis for Autonomic Networking https://tools.ietf.org/html/rfc75756 Use case drafts: Those are used to derive requirements for the Autonomic Networking Infrastructure • Autonomic Networking Use Case for Network Bootstrap https://tools.ietf.org/html/draft-behringer-autonomic-bootstrap • Autonomic Network Stable Connectivity https://tools.ietf.org/html/draft-eckert-anima-stable-connectivity • Autonomic Prefix Management in Large-scale Networks https://tools.ietf.org/html/draft-jiang-anima-prefix-management Solution drafts: • An Autonomic Control Plane https://tools.ietf.org/html/draft-behringer-anima-autonomic-control-plane • Bootstrapping Key Infrastructures http://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfrastructures • Bootstrapping Trust on a Homenet (this is in homenet, not ANIMA) https://tools.ietf.org/html/draft-behringer-homenet- trust-bootstrap • A Generic Discovery and Neg. Protocol for Autonomic Networking https://tools.ietf.org/html/draft-carpenter-anima-gdn- protocol 35
36. Summary
37. AN RegistrarController CONSISTENT REACHABILITY • Foundation for “Secure by default” networks • Automated secure deployment of domain certificates • Automated and secure device deployment across all network types • Attestation of devices before they join the network • Provides access to all devices without data plane configuration • Allows controllers to reach all devices in a secure, reliable way • Protects against mishaps • Automated Service Discovery AN, PnP and Trusted boot Autonomic Control Plane Networking Simplification summary
38. References • www.cisco.com/go/autonomic/ • IEFT Drafts: See earlier slide • OpenDayLight Project SNBI: https://wiki.opendaylight.org/view/SecureNetworkBootstrapping:Main • Autonomic Networking Configuration Guide, Cisco IOS Release 15S www.cisco.com/en/US/partner/docs/ios-xml/ios/auto_net/configuration/15-s/an-auto-net- 15-s-book.html • Cisco IOS Autonomic Networking Command Reference www.cisco.com/en/US/partner/docs/ios-xml/ios/auto_net/command/an-cr-book.html • autonomic-team@cisco.com

Notas del editor

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
[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]
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.
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”
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
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
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.
Immutable -: unable to be changed
#1 “AN solves 50% of all security problems in one go - secures all management protocols automatically”
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

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

Estás leyendo una previsualización.

Eche un vistazo a continuación

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

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)

Similares a PLNOG15: Simplifying network deployment using Autonomic networking and Plug-and-play - Steinthor Bjarnason (20)

Más reciente (20)

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

Notas del editor

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

Estás leyendo una previsualización.

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

Recomendado

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)

Similares a PLNOG15: Simplifying network deployment using Autonomic networking and Plug-and-play - Steinthor Bjarnason (20)

Más reciente (20)

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

Notas del editor