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. 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
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.1AR 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
X
C2
C1
FE2
FE4
FE1
FE6
FE3
FE5
Scalable connectivity (e.g. no star topology overlay)
Routing over tunneled network ensures “alwayson” reachability in case of topology changes.
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
www.opendaylight.org
Key Components - Overview
www.opendaylight.org
4
Automatic Network Bootstrapping
Can you connect
me ?
What’s your
Identifier ?
Forwarding
Element
Michael
Registrar
I have
802.1AR
credentials
Controller
Perfect,
Let’s talk!
www.opendaylight.org
5
Domain Certificates
Validate
credentials
Forwarding
Element
e.g Against Local
white list
Registrar
Controller
www.opendaylight.org
6
Proxy Bootstrap
Present your
Credentials Please ?
Can you connect
me ?
FE1
FE2
Registrar
Controller
www.opendaylight.org
Virtual Out Of Band Channel
Forwarding
Element
FE2
Michael
Secure Tunnel 1
Physical Link
Forwarding
Element
FE1
1.
2.
3.
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
Secure Tunnel 2
Physical Link
Registrar
Controller
www.opendaylight.org
8
SNBI Build-up …
FE8
FE1
FE2
Registrar
Controller
FE7
FE3
FE9
FE4
FE6
FE5
… 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 for
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
.1AR 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.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.
www.opendaylight.org
14