Secure Network Bootstrapping Infrastructure May 15, 2014

 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) Motivation: Secure Network Bootstrapping Infrastructure 2 FE 1 FE 3 FE 5 FE 6 FE 2 FE 4 C1C1 C1C1 C2C2 C2C2

 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. Approach Zero touch secure connectivity establishment FE 1 FE 3 FE 5 FE 6 FE 2 FE 4 C1C1 C1C1 C2C2 C2C2  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 X

Key Components - Overview 4

Automatic Network Bootstrapping 5 Can you connect me ? What’s your Identifier ? I have 802.1AR credentials Perfect, Let’s talk! Michael Controller Forwarding Element Registrar

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

FE 2 Proxy Bootstrap Discovery Hello 802.1AR New Guy! 802.1AR Can you connect me ? Present your Credentials Please ? Controller Registrar FE 1

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

FE 1 FE 2 FE 8 FE 7 FE 9 FE 6 FE 5 FE 4 FE 3 SNBI Build-up … 9 Controller Registrar … automatic discovery of topology as side effect.

 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) SNBI - Key Components 10

 Project Proposal:Secure Network Bootstrapping Infrastructure Project Proposal:Secure Network Bootstrapping Infrastructure  SNBI draft release plan SNBI draft release plan  Project IRC channel on Freenode: #opendaylight-snbi References 11

Q & A 12

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

1. 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. 2. 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. 3. 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”. 4. The new device validates the SNBI-Registrar signature in the invite message and, if valid, decides to join the domain. 5. After accepting the invite message, the new device generates a certificate signing request. It creates a public and private key. 6. The new device then initiates a “Boot strap request” message towards the registrar and provides a PKCS10, PKCS10_signature and the public key. 7. The SNBI-Registrar negotiates to enroll with a Certificate Authority (CA) using the SCEP protocol contained within the SNBI-Registrar component. 8. 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. 9. The device is now a member of the domain and will only repeat the discovery process if it is returned to factory default settings. 10. 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.RPL Details 14