[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                       Huawei Technologies
Intended status: Informational                          J. Schoenwaelder
Expires: September 9, 2010                Jacobs University Bremen gGmbH
                                                             Y. Shi, Ed.
                                            Hangzhou H3C Tech. Co., Ltd.
                                                           March 8, 2010


   Problem Statement for Plug-and-Play Deployment of Network Devices
         draft-tsou-network-configuration-problem-statement-03

Abstract

   This memo describes the problem of plug-and-play deployment of new
   nodes.  It defines this problem as minimizing the amount of pre-
   configuration required to achieve a successful security association
   with a centralized configuration system.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 9, 2010.

Copyright Notice

   Copyright (c) 2010 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



Tsou, et al.            Expires September 9, 2010               [Page 1]


Internet-Draft          Plug-and-Play Deployment              March 2010


   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 BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Steps To Safely Complete Node Configuration . . . . . . . . . . 4
     2.1.  Preconfiguration  . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Installation  . . . . . . . . . . . . . . . . . . . . . . . 4
     2.3.  IP Address Acquisition  . . . . . . . . . . . . . . . . . . 4
     2.4.  Management Node Discovery . . . . . . . . . . . . . . . . . 4
     2.5.  Establishment of a Secure Channel . . . . . . . . . . . . . 5
     2.6.  Topology Discovery and Configuration  . . . . . . . . . . . 5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6


























Tsou, et al.            Expires September 9, 2010               [Page 2]


Internet-Draft          Plug-and-Play Deployment              March 2010


1.  Introduction

   When a new network node is brought into service, it is typically
   configured using scripts worked out in advance.  These scripts depend
   critically upon knowledge of the network topology, that is, the
   node's address and link information.  While this information may be
   derived during advance planning, deviations from plan occur in
   practice.  Correcting the scripts can be expensive, particularly if
   the corrections have to be reapplied on-site after installation.
   When an entire network of tens of thousands of nodes is being brought
   into service, such expenses become a significant part of the
   deployment budget.

   Clearly it is helpful if plug-and-play operation of new nodes can be
   enabled, such that a secure link between the node and a centralized
   configuration system is established automatically upon activation.
   In the first place, this allows automated assignment of the node's
   address and acquisition of its link information at the central
   location.  Beyond that, it provides the means for application of
   configuration scripts from a central point, avoiding the cost of
   sending a skilled craftsperson to a remote site.

   At a minimum, establishing a link between a new node and a
   centralized configuration system means that the new node has to
   acquire an IP address and mask (or an IPv6 prefix).  The demands of
   security (see Section 3) typically mean that the node also needs to
   possess keying material in some form.  In typical practice such
   information is entered through a command line interface, and a
   database relating the device identity to this pre-configured
   information is built up and made available to the centralized
   configuration system.  In the worst case, a craftsperson has to do
   the pre-configuration on site after hardware installation is
   complete.

   New networks such as 3GPP LTE (Long Term Evolution) are being
   deployed today with tens of thousands of network nodes.  Pre-
   configuring each of them manually through a command line interface
   would be a costly operation, especially if it requires on-site
   visits.  Moreover, topological considerations complicate the task of
   establishing the management links.  A given node may not be reachable
   until other nodes have been brought into service first.  Just to
   complicate the picture, some nodes may be reachable only across
   another operator's network.  Plug-and-play operation of new network
   nodes is the ideal outcome, but may not be easy in the face of these
   considerations.

   This memo examines the steps required to achieve a secure connection
   between a new node and a centralized source of configuration data,



Tsou, et al.            Expires September 9, 2010               [Page 3]


Internet-Draft          Plug-and-Play Deployment              March 2010


   and complete the configuration of that node within the network.

   Security considerations are clearly important in determining to what
   extent plug-and-play operation is possible.  The security
   considerations provided in Section 3 are an integral part of the
   analysis provided by this memo.


2.  Steps To Safely Complete Node Configuration

2.1.  Preconfiguration

   Preconfiguration is defined as that portion of the node's
   configuration that is installed either at the factory or at a central
   site before the node is installed.  It seems reasonable that a
   considerable amount of information describing the node itself rather
   than its relation to the network can be preconfigured.

   In addition, the node needs to be preconfigured with information
   allowing it to establish a secure channel to the centralized
   configuration system.  Section 12.5 of [RFC5415] provides one example
   of the sort of information that is needed.

2.2.  Installation

   Installation is the process of putting the hardware in place,
   connecting its interfaces, and verifying its operation.  It is
   assumed that the installation phase includes verification of Layer 2
   connectivity across each interface.

2.3.  IP Address Acquisition

   Before it can set up a secure link to the centralized configuration
   system, the new node has to be given an IP address.  It may be
   desirable for the centralized configuration system to control the
   address space.  Trust requirements for this phase are discussed in
   Section 3.

   DHCP is, of course, the candidate means of address acquisition.

2.4.  Management Node Discovery

   Once the node has an IP address, there are several ways for it to
   discover the centralized configuration system.  One is for it to send
   some sort of message out on a multicast channel), looking for a reply
   from the centralized configuration system.  Another possibility is
   that the address or FQDN of the centralized configuration system is
   provided as part of the process of IP address acquisition, e.g., as a



Tsou, et al.            Expires September 9, 2010               [Page 4]


Internet-Draft          Plug-and-Play Deployment              March 2010


   DHCP option.  Finally, especially if the new node is reachable only
   across another provider's network, the Service Location Protocol
   [RFC2608] may be used to find the unicast address of the centralized
   configuration system.

2.5.  Establishment of a Secure Channel

   As Section 3 makes clear, it is essential to establish a secure
   channel of communication between the centralized configuration system
   and the node.  Mutual authentication between the two entities is a
   requirement.  It seems likely that the use of certificates is the
   preferable approach to the necessary mutual authentication.  It may
   be necessary to define new key purpose values to support this.
   [Another thing to check, but seems likely something exists already in
   this case.]

2.6.  Topology Discovery and Configuration

   Once these steps have been taken, topological discovery and
   configuration can proceed.


3.  Security Considerations

   It is critical that no attacker be able to modify the configuration
   of a network device, either through impersonation of the centralized
   configuration system or through modification of configuration
   messages en route to the new node.  This is why the preceding
   discussion assumed that the immediate goal is to set up a secure
   channel between the new node and the centralized configuration
   system.  That goal implies that the new device has to be pre-
   configured with the parameters needed to establish the secure
   channel.

   It is also essential that an attacker not be able to impersonate a
   new node.  Thus the node must authenticate itself to the centralized
   configuration system as well as the reverse.

   With all other aspects of configuration protected, the only outcome
   of an attack on the address acquisition process is to prevent
   configuration from being carried out.  An attacker can accomplish
   this through attacks on the configuration server, on the
   communication path to the server, or by impersonation of the server
   or a relay.  Assuming that DHCP is used, impersonation might be
   countered through use of the capabilities provided by [RFC3118].  A
   perhaps preferable alternative would be to use a method based on
   certificates.




Tsou, et al.            Expires September 9, 2010               [Page 5]


Internet-Draft          Plug-and-Play Deployment              March 2010


4.  IANA Considerations

   This memo includes no request to IANA.


5.  Acknowledgements

   Thanks to Cathy Zhou and Tom Taylor for help in preparing this memo.


6.  Normative References

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
              "Service Location Protocol, Version 2", RFC 2608,
              June 1999.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC5415]  Calhoun, P., Montemurro, M., and D. Stanley, "Control And
              Provisioning of Wireless Access Points (CAPWAP) Protocol
              Specification", RFC 5415, March 2009.

   [RFC5417]  Calhoun, P., "Control And Provisioning of Wireless Access
              Points (CAPWAP) Access Controller DHCP Option", RFC 5417,
              March 2009.


Authors' Addresses

   Tina Tsou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: tena@huawei.com







Tsou, et al.            Expires September 9, 2010               [Page 6]


Internet-Draft          Plug-and-Play Deployment              March 2010


   Juergen Schoenwaelder
   Jacobs University Bremen gGmbH
   Campus Ring 1,
   Bremen  28759
   Germany

   Email: j.schoenwaelder@jacobs-university.de


   Yang Shi (editor)
   Hangzhou H3C Tech. Co., Ltd.
   Beijing R&D Center of H3C, Digital Technology Plaza,
   NO.9 Shangdi 9th Street, Haidian District,
   Beijing
   China(100085)

   Phone: +86 010 82775276
   Email: young@h3c.com

































Tsou, et al.            Expires September 9, 2010               [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/