< draft-tsou-network-configuration-problem-statement-02.txt   draft-tsou-network-configuration-problem-statement-03.txt >
Internet Engineering Task Force T. Tsou Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational December 22, 2009 Intended status: Informational J. Schoenwaelder
Expires: June 20, 2010 Expires: September 9, 2010 Jacobs University Bremen gGmbH
Y. Shi, Ed.
Hangzhou H3C Tech. Co., Ltd.
March 8, 2010
Plug-and-Play Nodal Deployment Problem Statement Problem Statement for Plug-and-Play Deployment of Network Devices
draft-tsou-network-configuration-problem-statement-02 draft-tsou-network-configuration-problem-statement-03
Abstract 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 This memo describes the problem of plug-and-play deployment of new
nodes. It defines this problem as minimizing the amount of pre- nodes. It defines this problem as minimizing the amount of pre-
configuration required to achieve a successful IKEv2 exchange with a configuration required to achieve a successful security association
central management system. It assumes that part of the solution with a centralized configuration system.
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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 17 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 20, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 5 2. Steps To Safely Complete Node Configuration . . . . . . . . . . 4
2. The Address Configuration Protocol . . . . . . . . . . . . . . 5 2.1. Preconfiguration . . . . . . . . . . . . . . . . . . . . . 4
2.1. The New Network Scenario . . . . . . . . . . . . . . . . . 6 2.2. Installation . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Increments To an Existing Network . . . . . . . . . . . . . 6 2.3. IP Address Acquisition . . . . . . . . . . . . . . . . . . 4
2.3. Attachment To Another Operator's Network . . . . . . . . . 6 2.4. Management Node Discovery . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 2.5. Establishment of a Secure Channel . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Topology Discovery and Configuration . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Before a network management system can configure a new network node, When a new network node is brought into service, it is typically
a link has to be established between the two entities. At a minimum, configured using scripts worked out in advance. These scripts depend
this means that the new node has to acquire an IP address and mask critically upon knowledge of the network topology, that is, the
(or an IPv6 prefix). The demands of security typically mean that the node's address and link information. While this information may be
node also needs to possess pre-shared keying material. In typical derived during advance planning, deviations from plan occur in
practice such information is entered through a command line practice. Correcting the scripts can be expensive, particularly if
interface, and a database relating the device identity to this pre- the corrections have to be reapplied on-site after installation.
configured information is built up and made available to the network When an entire network of tens of thousands of nodes is being brought
management system. In the worst case, a craftsperson has to do the into service, such expenses become a significant part of the
pre-configuration on site after hardware installation is complete. deployment budget.
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.
4. Eventually the new node gets a response and acquires an IP Clearly it is helpful if plug-and-play operation of new nodes can be
address and the address of the network management system. 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.
5. The new node establishes a tunnel between it and the network At a minimum, establishing a link between a new node and a
management system by means of an IKEv2 exchange. The new node is centralized configuration system means that the new node has to
now in a position to relay requests for addresses from other acquire an IP address and mask (or an IPv6 prefix). The demands of
nodes. 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.
6. The network management system queries the new node for the New networks such as 3GPP LTE (Long Term Evolution) are being
identities of the neighbours reachable through its interfaces and deployed today with tens of thousands of network nodes. Pre-
possibly other information. 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.
7. The network management system verifies the validity of the This memo examines the steps required to achieve a secure connection
configuration scripts that have been prepared for this node. If between a new node and a centralized source of configuration data,
the scripts are valid, it passes the scripts to the node. If and complete the configuration of that node within the network.
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 Security considerations are clearly important in determining to what
extent plug-and-play operation is possible. The security extent plug-and-play operation is possible. The security
considerations provided in Section 3 are an integral part of the considerations provided in Section 3 are an integral part of the
analysis provided by this memo. analysis provided by this memo.
1.1. Requirements Language 2. Steps To Safely Complete Node Configuration
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 2.1. Preconfiguration
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 Preconfiguration is defined as that portion of the node's
configuration to start with; 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.
o an existing network to which new nodes are added; 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.
o a scenario where the messaging must pass across another operator's 2.2. Installation
network.
2.1. The New Network Scenario 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.
Section 1 gave a brief description of an algorithm whereby a node 2.3. IP Address Acquisition
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 Before it can set up a secure link to the centralized configuration
node through each of its interfaces needs to contain only the node's system, the new node has to be given an IP address. It may be
MAC address on that link. If a receiving node has established desirable for the centralized configuration system to control the
communication with the network management system, it sends back a address space. Trust requirements for this phase are discussed in
response identifying itself, giving its own MAC address, and Section 3.
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 DHCP is, of course, the candidate means of address acquisition.
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 2.4. Management Node Discovery
poll at suitable intervals until it gets a response.
2.2. Increments To an Existing Network 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
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.
The second scenario is one where the new node is deployed into an 2.5. Establishment of a Secure Channel
existing network. In this case, the address configuration protocol
described above will continue to work.
2.3. Attachment To Another Operator's Network 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.]
The third scenario is one where another operator's network lies along 2.6. Topology Discovery and Configuration
the messaging path. The only interesting case here is when all of
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 Once these steps have been taken, topological discovery and
information provided by the new node to the neighbour has to include configuration can proceed.
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 3. Security Considerations
It is critical that no attacker be able to modify the configuration It is critical that no attacker be able to modify the configuration
of a network router, either through impersonation of the network of a network device, either through impersonation of the centralized
management system or through modification of configuration messages configuration system or through modification of configuration
en route to the new node. This is why the preceding discussion messages en route to the new node. This is why the preceding
assumed that the immediate goal is to set up a tunnel between the new discussion assumed that the immediate goal is to set up a secure
node and the network management system through an IKEv2 exchange. channel between the new node and the centralized configuration
That goal implies that the new node has to be pre-configured with the system. That goal implies that the new device has to be pre-
shared secret and any other parameters needed to carry out the IKEv2 configured with the parameters needed to establish the secure
exchange. channel.
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.
The first opportunity for impersonation comes when the new node sends It is also essential that an attacker not be able to impersonate a
out its initial poll for candidate neighbours. The attacker could new node. Thus the node must authenticate itself to the centralized
send a reply indicating that it is a candidate. The other configuration system as well as the reverse.
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 With all other aspects of configuration protected, the only outcome
attacks is to provide the means for the new node to authenticate its of an attack on the address acquisition process is to prevent
neighbour as a member of the same network. This could be a secret configuration from being carried out. An attacker can accomplish
shared amongst all of the new nodes and their neighbours. The this through attacks on the configuration server, on the
validity of this approach needs further discussion. 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.
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
5. Acknowledgements 5. Acknowledgements
TBD. Depends on who gets listed as author. Thanks to Cathy Zhou and Tom Taylor for help in preparing this memo.
6. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 2131, March 1997.
Author's Address [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 Tina Tsou
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China P.R. China
Email: tena@huawei.com Email: tena@huawei.com
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
 End of changes. 34 change blocks. 
222 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/