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]