Autonomic Networking Use Case for Network Bootstrap
draft-behringer-autonomic-bootstrap-00

Abstract

This document describes a use case for a specific autonomic functionality: Securely bootstrapping new devices into a network, without the need for pre-staging. The goal is to illustrate a requirement from network operators, and to illustrate how autonomic approaches can solve this use case.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 10, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Problem Statement
• 3. Benefits of an Autonomic Solution
• 4. Intended User and Administrator Experience
• 5. Analysis of Parameters and Information Involved
• 5.1. Device Based Self-Knowledge and Decisions
• 5.2. Interaction with other devices
• 5.3. Information needed from Intent
• 5.4. Monitoring, diagnostics and reporting
• 6. Comparison with current solutions
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. Change log [RFC Editor: Please remove]
• 11. Informational References
• Authors' Addresses

1. Introduction

Autonomic Networking (AN) is a new way to manage network devices or functions, by making them self-managing. Rather than centralising all intelligence on a controller, the idea is to distribute intelligence across the network. The fundamental concepts of Autonomic Networking are described in [I-D.irtf-nmrg-autonomic-network-definitions]. A gap analysis for AN has been documented in [I-D.irtf-nmrg-an-gap-analysis].

This document describes a use case for a specific autonomic functionality: Securely bootstrapping new devices into a network, without the need for pre-staging. The goal is to illustrate a requirement from network operators, and to illustrate how autonomic approaches can solve this use case.

Bootstrapping in the context of this document refers to the process in which a new device joins a network in a secure way. A secure, zero-touch bootstrap process is defined here as a process without pre-staging, where the a new device can

• [A] authenticate itself securely, such that no other entity can perform a man-in-the-middle attack or masquerade as an expected device. (see [RFC4949] for definitions of "man-in-the-middle attack" and "masquerade");
• [B] authenticate the network securely, such that the device joins only the correct network.

It is required to bootstrap a device to make it securely manageable by a controller or network management system. There are networks where requirement [A] is a must, requirement [B] a should. In some networks both [A] and [B] are a must. In either case the behavior of a new device must be the same, to prevent possible downgrade attacks.

2. Problem Statement

Today, there are two main ways to bootstrap a device:

• Pre-configuring the device with a minimum or full configuration, so that it can be at least securely reached and managed. This process can be secure, as defined in the introduction.
• Using so called "zero-touch" methods. Many of those are derived from some form of DHCP interaction. DHCP however is not suitable to establish trust between the network and the new device. As a result, any device can join the domain through this process. Additionally DHCP, as many other bootstrap methods today, does not provide a mechanism for identifying the network.

In some networks it is not acceptable to not be able to authenticate new devices. Examples are:

• In Metro Ethernet and Mobile RAN scenarios many network nodes are deployed outside traditional data-center like environments, for example in the basement of an office building. While still typically in a locked cabinet or room, the operator has less control in these environments, and there is increasing concern that hackers might be able to connect their own devices, to receive valuable configuration details and possibly infiltrate the network.
• In industrial automation, certain wireless sensors and actuators fulfill mission critical tasks and it must be assured that only legitimate devices can connect.

3. Benefits of an Autonomic Solution

For a secure, zero-touch device enrolment, a device must act "autonomically". It cannot rely on a central entity such as a controller or DHCP server, because the problem is exactly to establish trust with this controller in the first place. Therefore, in this use case an autonomic solution is absolutely required.

4. Intended User and Administrator Experience

On the side of the new network element, an unskilled person should be able to connect the device following a simple cabling scheme, perhaps only supplying power to a wireless device. Once connected, the device must be powered on. There should be no need for any configuration tasks.

On the network side, the operator of the network must have full control over which element joins the network in which location. It must be possible to securely identify the new device, such that no other device can take its role. This can be achieved by validating unique device identifiers (UDI), for example serial numbers. While authorization of the UDI is required, it can be further automated, for example providing a white list of valid device UDIs. The actual process of enrolment and bootstrapping should be zero-touch for the operator.

5. Analysis of Parameters and Information Involved

5.1. Device Based Self-Knowledge and Decisions

Each device has self-knowledge about its own identity. This can be a unique device identifier such as a serial number. For a fully secure process, the device requires an IEEE 802.1AR [IDevID] credential.

5.2. Interaction with other devices

A new device interacts only with a neighbouring domain device. All communications are link local, therefore the new device does not require a routable IP address. The neighbouring device acts as a proxy for the below information flows.

A new device exchanges data through the neighboring proxy with two entities:

• A "Registrar" device, acting as the trust anchor of the domain. The new device sends its own credentials to the Registrar, and after successful authentication, receives domain information, to enable subsequent enrolment to the domain. The Registrar sends all required information: a device name, domain name, plus some parameters for the enrolment.
• A cloud service provided by the vendor to facilitate autonomic mechanisms. The new device may receive a signed authorization token from the vendor cloud service, telling the device its target domain. The authorization token can be obtained at the time of deployment or a priori at the time of white list authorization.

Based on the above interactions with a network a device can decide locally whether or not to join a domain, and a domain can decide whether to enrol a device or not.

5.3. Information needed from Intent

Intent is not required for this autonomic process.

5.4. Monitoring, diagnostics and reporting

The process can be monitored in several points:

• The new device logs all transactions locally. Since it does not have a trust relationship with a domain at the beginning, it cannot report its data anywhere at the beginning of the process. Such data should be logged locally.
• The proxy device logs all data relating to the connection of new devices, information received, etc. The proxy is also a potential attack point, since by nature it must listen to packets from unauthenticated nodes. All such information must be logged in the domain, and there must be local diagnostic tools to validate the state of each transaction and node.
• The Registrar device logs all connection attempts, as well as successful connections. Also here, local diagnostic tools are required.
• The vendor cloud service also logs all interactions with domains.

6. Comparison with current solutions

Today, the task of bootstrapping a new device is either done through pre-staging or in an insecure way, where any device could join the domain. An autonomic approach allows the process to be secure, while still being zero-touch.

The document [I-D.pritikin-bootstrapping-keyinfrastructures] outlines a possible solution to the use case described here.

7. Security Considerations

An autonomic approach can used to make a bootstrap process secure. As only link local addresses are used in the process, only nodes directly adjacent to a potentially malicious node can be attacked. Denial of service prevention must be applied on the proxy nodes. The other network elements must be secured according to general best practices, but require no specific security with regard to this approach.

8. IANA Considerations

This document requests no action by IANA.

9. Acknowledgements

This document has been written with the XML2RFC tool [RFC2629].

10. Change log [RFC Editor: Please remove]

version 0: Initial version.

11. Informational References

Authors' Addresses