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]