Secure Network Bootstrapping Infrastructure May 15 2014 www

Secure Network Bootstrapping Infrastructure May 15, 2014 www. opendaylight. org

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. Open. Flow, 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 has joined a particular domain ? (Reachability) How do we ensure that devices once connected do not get silently swapped? (Security) C 2 C 1 FE 2 FE 4 FE 1 FE 3 FE 6 FE 5 www. opendaylight. org 2

Approach Zero touch secure connectivity establishment § § § Fully automatic: Incremental discovery and attachment of devices to a network domain Manufacturer installed IEEE 802. 1 AR credentials for device identification Automatic enrollment of certificates to devices to secure communication and device identity § § Virtual out-of-band channel (VOOBC) to connect devices – “hop-by-hop” tunneling § § § Automatic assignment of IP-addresses Scalable connectivity (e. g. no star topology overlay) Routing over tunneled network ensures “alwayson” reachability in case of topology changes. X C 2 C 1 FE 2 FE 4 FE 1 FE 3 FE 6 FE 5 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, Open. Flow); i. e. we bootstrap the management network over which Open. Flow, Netconf, etc. can run www. opendaylight. org

Key Components - Overview www. opendaylight. org 4

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

Domain Certificates Pres ent c rede Forwarding Element Dom Validate credentials ntial s e. g 802. 1 AR e. g Against Local white list Registrar ain C ertif icate Controller www. opendaylight. org 6

Proxy Bootstrap Present your Credentials Please ? Can you connect me ? Discovery Hello FE 1 FE 2 802. 1 AR Registrar Controller New Guy! 802. 1 AR www. opendaylight. org

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

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

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 forwarding element, using containers § Test environment for system test (controller and forwarding element) § www. opendaylight. org 10

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

Q&A www. opendaylight. org 12

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

Details 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 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, factoryprovided 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. 1 AR 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 PKCS 10, PKCS 10_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. www. opendaylight. org 14