One document matched: draft-behringer-autonomic-bootstrap-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->

<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-behringer-autonomic-bootstrap-00" category="info"  >


<front>
<title abbrev="AN Bootstrap Use Case">Autonomic Networking Use Case for Network Bootstrap</title>

    <author fullname="Michael H. Behringer" initials="M.H."
            surname="Behringer">
      <organization>Cisco</organization>

      <address>
        <email>mbehring@cisco.com</email>
      </address>
    </author>

    <author fullname="Max Pritikin" initials="M." surname="Pritikin">
      <organization>Cisco</organization>

      <address>
        <email>pritikin@cisco.com</email>
      </address>
    </author>

    <author fullname="Steinthor Bjarnason" initials="S." surname="Bjarnason">
      <organization>Cisco</organization>

      <address>
        <email>sbjarnas@cisco.com</email>
      </address>
    </author>

<date day="9" month="May" year="2014" />

<area>Operations and Management</area>
<workgroup>tbd BOF</workgroup>


<abstract>
<t>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. </t>
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/>. A gap analysis for AN has been documented in <xref target="I-D.irtf-nmrg-an-gap-analysis"/>.</t>
<t>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. </t>
<t>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 
<list style="symbols">
   <t>[A] authenticate itself securely, such that no other entity can perform a man-in-the-middle attack or masquerade as an expected device. (see <xref target="RFC4949" /> for definitions of "man-in-the-middle attack" and "masquerade"); </t>
   <t>[B] authenticate the network securely, such that the device joins only the correct network.</t> 
</list>
</t>
<t>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. </t>
</section> <!-- intro -->

<section anchor="problem" title="Problem Statement">
<t>Today, there are two main ways to bootstrap a device: 
<list style="symbols">
   <t>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. </t>
   <t>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.
</t>
</list>
</t>
<t>In some networks it is not acceptable to not be able to authenticate new devices. Examples are: 
<list style="symbols">
   <t>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. </t>
   <t>In industrial automation, certain wireless sensors and actuators fulfill mission critical tasks and it must be assured that only legitimate devices can connect. </t>
</list>
</t>
</section> <!-- problem -->

<section anchor="benefits" title="Benefits of an Autonomic Solution">
<t>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.</t>
</section>

<section anchor="experience" title="Intended User and Administrator Experience">
<t>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.</t>
<t>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. </t>
</section> <!-- experience -->

<section anchor="params" title="Analysis of Parameters and Information Involved">
<t></t>

<section anchor="device" title="Device Based Self-Knowledge and Decisions">
<t>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 <xref target="IDevID"/> credential. </t>
</section> <!-- device -->

<section anchor="interact" title="Interaction with other devices">
<t>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. </t>

<t>A new device exchanges data through the neighboring proxy with two entities: 
<list style="symbols">
   <t>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. </t>
   <t>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.
</t>
</list>
</t>
<t>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. </t>
</section> <!-- interact -->

<section anchor="intent" title="Information needed from Intent">
<t>Intent is not required for this autonomic process. </t>
</section> <!-- intent -->

<section anchor="monitor" title="Monitoring, diagnostics and reporting">
<t>The process can be monitored in several points: 
<list>
   <t>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.</t>
   <t>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. </t>
   <t>The Registrar device logs all connection attempts, as well as successful connections. Also here, local diagnostic tools are required. </t>
   <t>The vendor cloud service also logs all interactions with domains. </t>
</list>
</t>
</section> <!-- params -->

</section> <!-- interact -->

<section anchor="compare" title="Comparison with current solutions">
<t>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.</t>
<t>The document <xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/> outlines a possible solution to the use case described here.</t>
</section> <!-- compare -->

<section anchor="security" title="Security Considerations">
<t>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.</t>
</section> <!-- security -->

<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA. </t>
</section> <!-- iana -->

<section anchor="ack" title="Acknowledgements">
<t>This document has been written with the XML2RFC tool <xref target="RFC2629"/>.</t>
</section> <!-- ack -->

<section anchor ="changes" title="Change log [RFC Editor: Please remove]">
<t>version 0: Initial version.</t>
</section> <!-- changes -->

</middle>

<back>

<references title="Informational References">
<?rfc include="reference.RFC.2629"?>
<?rfc include="reference.RFC.4949"?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>
<?rfc include="reference.I-D.irtf-nmrg-an-gap-analysis.xml"?>
<?rfc include="reference.I-D.pritikin-bootstrapping-keyinfrastructures.xml"?>

      <reference anchor="IDevID"
                 target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
        <front>
          <title>IEEE 802.1AR Secure Device Identifier</title>

          <author surname="IEEE Standard"/>

          <date month="December" year="2009"/>
        </front>
      </reference>

</references>

</back>
</rfc>