valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...
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
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
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
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
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)
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.
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
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
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
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