14
www.opendaylight .org Secure Network Bootstrapping Infrastructure May 15, 2014
www.opendaylight.org
Secure NetworkBootstrapping Infrastructure
May 15, 2014
www.opendaylight.org
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
FE1FE1
FE3FE3 FE5
FE5
FE6FE6
FE2FE2 FE4
FE4
C1C2
www.opendaylight.org
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.
ApproachZero touch secure connectivity establishment
FE1FE1
FE3FE3 FE5
FE5
FE6FE6
FE2FE2 FE4
FE4
C1C2
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
www.opendaylight.org
Key Components - Overview
4
www.opendaylight.org
Automatic Network Bootstrapping
5
Can you connect me ?
What’s your Identifier ?
I have 802.1AR
credentialsPerfect,
Let’s talk!
Michael
Controller
ForwardingElement
ForwardingElement
Registrar
www.opendaylight.org
Domain Certificates
6
Domain Certificate
Present credentials e.g 802.1AR
Validate credentials
e.g Against Local white list
Controller
ForwardingElement
ForwardingElement
Registrar
www.opendaylight.org
FE2FE2
Proxy Bootstrap
Discovery Hello
802.1AR
New Guy!802.1AR
Can you connect
me ?
Present your Credentials Please ?
Controller
Registrar
FE1FE1
www.opendaylight.org
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
ForwardingElement
FE2
ForwardingElement
FE2
ForwardingElement
FE1
ForwardingElement
FE1
Controller
Registrar
Secure Tunnel 1
Secure Tunnel 2
Physical Link
Physical Link
www.opendaylight.org
FE1FE1
FE2FE2
FE8FE8
FE7FE7
FE9FE9
FE6FE6 FE5
FE5
FE4FE4
FE3FE3
SNBI Build-up …
9
Controller
Registrar
… automatic discovery of topology as side effect.
www.opendaylight.org
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
www.opendaylight.org
Project Proposal:Secure Network Bootstrapping Infrastructure
SNBI draft release plan
Project IRC channel on Freenode: #opendaylight-snbihttp://webchat.freenode.net/?channels=opendaylight-snbi
References
11
www.opendaylight.org
Q & A
12
www.opendaylight.org
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
www.opendaylight.org
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.
Details
14
