Secure Network Bootstrapping Infrastructure

1. Secure NetworkBootstrapping Infrastructure May 15, 2014

2. Motivation:Secure Network Bootstrapping Infrastructure • How do devices get initial secure IP connectivity? • Several southbound protocols assume IP connectivity exist for the control protocol (e.g. OpenFlow, Netconf, ..) • How do we ensure devices associate with the “right” controller and get an appropriate IP address to do so? (Join a particular Domain) • How do we ensure connectivity to all the devices which have joined a particular domain ? (Reachability) • How do we ensure that devices once connected do not get silently swapped? (Security) C2 C1 FE2 FE4 FE1 FE6 FE3 FE5

3. ApproachZero touch secure connectivity establishment • Fully automatic: Incremental discovery and attachment of devices to a network domain • Manufacturer installed IEEE 802.1AR credentials for device identification • Automatic enrollment of certificates to devices to secure communication and device identity • Automatic assignment of IP-addresses • Virtual out-of-band channel (VOOBC) to connect devices – “hop-by-hop” tunneling • Scalable connectivity (e.g. no star topology overlay) • Routing over tunneled network ensures “always-on” reachability in case of topology changes. X C2 C1 FE2 FE4 FE1 FE6 FE3 FE5 • Nice “side effects”: • Topology discovery • Virtual out-of-band channel can be used by other control protocols running between Controller and Forwarding Elements (e.g. Netconf, OpenFlow); i.e. we bootstrap the management network over which OpenFlow, Netconf, etc. can run

4. Key Components - Overview

5. Automatic Network Bootstrapping Can you connect me ? What’s your Identifier ? ForwardingElement Michael Controller Registrar I have 802.1ARcredentials Perfect, Let’s talk!

6. Domain Certificates Validate credentials e.g Against Local white list ForwardingElement Present credentials e.g 802.1AR Controller Registrar Domain Certificate

7. Proxy Bootstrap Present your Credentials Please ? Can you connect me ? Discovery Hello FE1 FE2 802.1AR Controller Registrar New Guy! 802.1AR

8. Virtual Out Of Band Channel ForwardingElement FE2 Secure Tunnel 1 Michael ForwardingElement FE1 Physical Link Secure Tunnel 2 Secure Tunnel Infra is created Hop by Hop. Each Element gets a IPv6 ULA address (Hash of domain name and device number) Enabling Routing over this Infra provides end-to-end connectivity Controller Registrar Physical Link

9. SNBI Build-up … FE8 FE1 FE2 FE7 FE3 FE9 FE4 Controller FE6 Registrar FE5 … automatic discovery of topology as side effect.

10. SNBI - Key Components • Controller • SNBI Registrar – Trust anchor of the domain • SNBI SB plugin – Device discovery/handshake, certificate distribution, virtual out of band channel • Forwarding Element • SNBI client/proxy - Device discovery/handshake, certificate distribution, virtual out of band channel • Portable foundation – Reference environment for forwarding element, using containers • Test environment for system test (controller and forwarding element)

11. References • Project Proposal:Secure Network Bootstrapping Infrastructure • SNBI draft release plan • Project IRC channel on Freenode: #opendaylight-snbihttp://webchat.freenode.net/?channels=opendaylight-snbi

12. Q & A

13. Details New device Domain edgedevice (proxy) SNBI Registrar Domain Discovery .1AR credential Device belongs to domain? Authorization tokenDomain information Domain enrollment Domain certificate Establish virtual out of band channel

14. Details • The new device discovers the Domain. This starts with a search for a SNBI-Registrar. Contact to the SNBI-Registrar will typically be supplied via a “domain edge device” which is already part of the Domain, has the SNBI active, and acts as a proxy for the SNBI-Registrar. Discovery will first try to locate a “domain edge device” on the local link using neighbor discovery, in case this fails, it will try to obtain an address using DHCP and search for a registrar using DNS service discovery. If this is also not successful, it could search for a predefined, factory-provided global registrar using DNS. Note that the latter two methods already require some form of IP connectivity to the DNS server. • The new device presents its 802.1AR credentials to the discovered SNBI-Registrar. The message can be relayed by the “domain edge device” serving as proxy. • The SNBI-Registrar checks whether device belongs to the Domain. If true, invites the new device to join the “Domain” and provides it with a “device id”. • The new device validates the SNBI-Registrar signature in the invite message and, if valid, decides to join the domain. • After accepting the invite message, the new device generates a certificate signing request. It creates a public and private key. • The new device then initiates a “Boot strap request” message towards the registrar and provides a PKCS10, PKCS10_signature and the public key. • The SNBI-Registrar negotiates to enroll with a Certificate Authority (CA) using the SCEP protocol contained within the SNBI-Registrar component. • The result of the negotiation provides a “Domain certificate”, which is relayed from the SNBI-Registrar to the new device using a “Bootstrap response” message. • The device is now a member of the domain and will only repeat the discovery process if it is returned to factory default settings. • Once enrolled, the new device establishes a “virtual out-of-band channel” to the domain edge device, which connects it securely to the Domain and configures basic IP connectivity: • Create a loopback interface on the new device and assign it an address from an SNBI specific address prefix (e.g. combining the prefix with a hash of the device serial number and domain name). • Establish a secure tunnel between the new device and the domain-edge device. • Automatically configure a routing protocol (e.g. RPL) over the newly established tunnel.