Internet DRAFT - draft-behringer-autonomic-bootstrap
draft-behringer-autonomic-bootstrap
tbd BOF M. Behringer
Internet-Draft M. Pritikin
Intended status: Informational S. Bjarnason
Expires: November 10, 2014 Cisco
May 9, 2014
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
Behringer, et al. Expires November 10, 2014 [Page 1]
Internet-Draft AN Bootstrap Use Case May 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Benefits of an Autonomic Solution . . . . . . . . . . . . . . 3
4. Intended User and Administrator Experience . . . . . . . . . 4
5. Analysis of Parameters and Information Involved . . . . . . . 4
5.1. Device Based Self-Knowledge and Decisions . . . . . . . . 4
5.2. Interaction with other devices . . . . . . . . . . . . . 4
5.3. Information needed from Intent . . . . . . . . . . . . . 5
5.4. Monitoring, diagnostics and reporting . . . . . . . . . . 5
6. Comparison with current solutions . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 6
11. Informational References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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
o [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");
Behringer, et al. Expires November 10, 2014 [Page 2]
Internet-Draft AN Bootstrap Use Case May 2014
o [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:
o 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.
o 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:
o 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.
o 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.
Behringer, et al. Expires November 10, 2014 [Page 3]
Internet-Draft AN Bootstrap Use Case May 2014
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:
o 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.
o 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.
Behringer, et al. Expires November 10, 2014 [Page 4]
Internet-Draft AN Bootstrap Use Case May 2014
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
Behringer, et al. Expires November 10, 2014 [Page 5]
Internet-Draft AN Bootstrap Use Case May 2014
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
[I-D.irtf-nmrg-an-gap-analysis]
Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis
for Autonomic Networking", draft-irtf-nmrg-an-gap-
analysis-00 (work in progress), April 2014.
[I-D.irtf-nmrg-autonomic-network-definitions]
Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking - Definitions and Design Goals", draft-irtf-
nmrg-autonomic-network-definitions-00 (work in progress),
December 2013.
[I-D.pritikin-bootstrapping-keyinfrastructures]
Pritikin, M., Behringer, M., and S. Bjarnason,
"Bootstrapping Key Infrastructures", draft-pritikin-
bootstrapping-keyinfrastructures-00 (work in progress),
January 2014.
[IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier",
December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
Behringer, et al. Expires November 10, 2014 [Page 6]
Internet-Draft AN Bootstrap Use Case May 2014
Authors' Addresses
Michael H. Behringer
Cisco
Email: mbehring@cisco.com
Max Pritikin
Cisco
Email: pritikin@cisco.com
Steinthor Bjarnason
Cisco
Email: sbjarnas@cisco.com
Behringer, et al. Expires November 10, 2014 [Page 7]
