Internet Engineering Task Force T. Tsou Internet-Draft Huawei Technologies Intended status: Informational December 22, 2009 Expires: June 20, 2010 Plug-and-Play Nodal Deployment Problem Statement draft-tsou-network-configuration-problem-statement-02 Abstract 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 link between the node and a network management 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. 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 IKEv2 exchange with a central management system. It assumes that part of the solution consists of a protocol that distributes addresses from the network management system to the nodes as a preliminary to that exchange. It explores the requirements on that protocol in various network scenarios. 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- Tsou Expires June 20, 2010 [Page 1] Internet-Draft Plug-and-Play Deployment December 2009 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 June 20, 2010. Copyright Notice Copyright (c) 2009 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 BSD License. Tsou Expires June 20, 2010 [Page 2] Internet-Draft Plug-and-Play Deployment December 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 5 2. The Address Configuration Protocol . . . . . . . . . . . . . . 5 2.1. The New Network Scenario . . . . . . . . . . . . . . . . . 6 2.2. Increments To an Existing Network . . . . . . . . . . . . . 6 2.3. Attachment To Another Operator's Network . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Tsou Expires June 20, 2010 [Page 3] Internet-Draft Plug-and-Play Deployment December 2009 1. Introduction Before a network management system can configure a new network node, a link has to be established between the two entities. At a minimum, this means that the new node has to acquire an IP address and mask (or an IPv6 prefix). The demands of security typically mean that the node also needs to possess pre-shared keying material. 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 network management system. In the worst case, a craftsperson has to do the pre-configuration on site after hardware installation is complete. New networks 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 explores a possible solution to the requirement for plug- and-play operation. This is a protocol through which nodes can request and receive addresses from the network management system, allowing them to communicate with that system. It is assumed that the goal is to achieve a successful IKEv2 exchange between the node and the network management system, since once an IPSEC tunnel has been established between the two entities further configuration can proceed safely. The model of operation assumed in this memo consists of the following steps: 1. Some configuration data is entered into the node at the factory or in advance of deployment. One goal of the analysis which follows is to determine the minimum amount of information which must be so configured. To start with, that information includes a node identifier and the MAC address of each of its interfaces. 2. The node is physically deployed and activated. 3. The node begins to poll its neighbours, looking for a neighbour that can relay a request for an address between the new node and the network management system. Tsou Expires June 20, 2010 [Page 4] Internet-Draft Plug-and-Play Deployment December 2009 4. Eventually the new node gets a response and acquires an IP address and the address of the network management system. 5. The new node establishes a tunnel between it and the network management system by means of an IKEv2 exchange. The new node is now in a position to relay requests for addresses from other nodes. 6. The network management system queries the new node for the identities of the neighbours reachable through its interfaces and possibly other information. 7. The network management system verifies the validity of the configuration scripts that have been prepared for this node. If the scripts are valid, it passes the scripts to the node. If they are not valid, corrective action is taken and then the scripts are passed down. The node is now ready for service. 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. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Address Configuration Protocol This section explores the requirements for an initial address configuration protocol. The intention is to provide the information needed to determine whether an existing protocol would do the job, possibly with modifications, or whether a new protocol is needed. The exploration considers three scenarios: o a brand new network where none of the nodes have completed configuration to start with; o an existing network to which new nodes are added; o a scenario where the messaging must pass across another operator's network. Tsou Expires June 20, 2010 [Page 5] Internet-Draft Plug-and-Play Deployment December 2009 2.1. The New Network Scenario Section 1 gave a brief description of an algorithm whereby a node receives its IP address and carries out subsequent communications with the network management system through the first node to respond to it. In a new network, this algorithm implies that address configuration will advance through a tree which eventually spans the complete network. Communications with the network management system will pass along branches of the tree until alternative routing is established. In this specific scenario, the initial poll sent out from the new node through each of its interfaces needs to contain only the node's MAC address on that link. If a receiving node has established communication with the network management system, it sends back a response identifying itself, giving its own MAC address, and indicating that the network management system is reachable through it. If the new node receives more than one such response, it chooses one and sends second message indicating the selection and requesting the allocation of an address. (As a refinement, the responses from the neighbours could contain the round trip time from the neighbour to the network management system, and the new node could select the neighbour that minimizes the new node's own round trip time.) The selected neighbour forwards the new node's address request toward the network management system at the IP level, with its own address as source and the address of the network management system as destination. The request contains the identity and MAC address of the new node. Upon receiving the request, the network management system allocates and returns an address and mask or a prefix, as applicable. The neighbour relays this information along with the network management system's address to the new node, which can now operate at the IP level itself. Configuration continues with an IKEv2 exchange as described above. If there is no response to its initial poll, the new node repeats the poll at suitable intervals until it gets a response. 2.2. Increments To an Existing Network The second scenario is one where the new node is deployed into an existing network. In this case, the address configuration protocol described above will continue to work. 2.3. Attachment To Another Operator's Network The third scenario is one where another operator's network lies along the messaging path. The only interesting case here is when all of Tsou Expires June 20, 2010 [Page 6] Internet-Draft Plug-and-Play Deployment December 2009 the new node's neighbours belong to the third party. In any other case communication with the network management system is protected by the tunnels that have been set up. When the new node and its neighbour belong to different domains, the information provided by the new node to the neighbour has to include either the address or FQDN of the target network management system. Otherwise the neighbour would route the request to the management system for its own network instead. That means the new node has to be configured with this information so it can send it out. One could imagine the address configuration protocol operating as described above, with the neighbouring node faithfully relaying the address request to the indicated management entity. However, it seems simpler in this case to rely on local DHCP to give the new node an initial address, then have the new node contact the network management system directly at the IP level. 3. Security Considerations It is critical that no attacker be able to modify the configuration of a network router, either through impersonation of the network management 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 tunnel between the new node and the network management system through an IKEv2 exchange. That goal implies that the new node has to be pre-configured with the shared secret and any other parameters needed to carry out the IKEv2 exchange. Taking that part as a given, the interesting part of the analysis is what the security considerations are for the address acquisition process. The first point to observe is that, with all other configuration protected, the only outcome of an attack on the address acquisition process is to prevent configuration from being carried out. An attacker with that goal has to be on the messaging path to achieve it. To minimize exposure to such an attack, the vulnerable portion of the path can be restricted to the portion between the new node and its neighbour, by requiring that messages relayed between the neighbour and the network management system pass via the tunnel that the neighbour has set up. With this restriction, the means available to the attacker come down to two: interference with the link between the new node and any neighbour able to reach the network management system, or impersonation of such a neighbour. The latter is the more likely approach, given that the new node probably supports multiple links. Tsou Expires June 20, 2010 [Page 7] Internet-Draft Plug-and-Play Deployment December 2009 The first opportunity for impersonation comes when the new node sends out its initial poll for candidate neighbours. The attacker could send a reply indicating that it is a candidate. The other opportunity is when the new node sends out its second message, the actual request for an address. The attacker could respond before the selected neighbour has an opportunity to do so. In either case, the attacker can provide addresses of its own choosing to the new node. If the allocated address the attacker supplies duplicates the address of another node in the network, subsequent messages from the new node may interfere with messaging to the rightful owner of the address. If the address of the network management system that the attacker supplies is false, the subsequent attempt at an IKEv2 exchange will fail. The obvious, but not necessarily effective way to alleviate these attacks is to provide the means for the new node to authenticate its neighbour as a member of the same network. This could be a secret shared amongst all of the new nodes and their neighbours. The validity of this approach needs further discussion. 4. IANA Considerations This memo includes no request to IANA. 5. Acknowledgements TBD. Depends on who gets listed as author. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Tina Tsou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: tena@huawei.com Tsou Expires June 20, 2010 [Page 8]