One document matched: draft-tsou-network-configuration-problem-statement-03.txt
Differences from draft-tsou-network-configuration-problem-statement-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:05:56 |