wdiff draft-tsou-network-configuration-problem-statement-02.txt draft-tsou-network-configuration-problem-statement-03.txt

Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies
Intended status: Informational December 22, 2009 J. Schoenwaelder
Expires: June 20, 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
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 Plug-and-Play Deployment of sending a skilled
craftsperson to a remote site. 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 IKEv2 exchange security association
with a
central management centralized configuration 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-
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, September 9, 2010.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Steps To Safely Complete Node Configuration . . . . . . . . . . 4
1.1. Requirements Language
2.1. Preconfiguration . . . . . . . . . . . . . . . . . . . 5
2. The . . 4
2.2. Installation . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. IP Address Configuration Protocol Acquisition . . . . . . . . . . . . . . 5
2.1. The New Network Scenario . . . . 4
2.4. Management Node Discovery . . . . . . . . . . . . . 6
2.2. Increments To an Existing Network . . . . 4
2.5. Establishment of a Secure Channel . . . . . . . . . 6
2.3. Attachment To Another Operator's Network . . . . 5
2.6. Topology Discovery and Configuration . . . . . 6 . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 6

1. Introduction

Before

When a new network management system 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 configure 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 network node, nodes can be
enabled, such that a secure link has to be established between the two entities. 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,
this 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 pre-shared keying material. 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 pre-configured
information is built up and made available to the network
management 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 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 examines 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 steps required to achieve a successful IKEv2 exchange between the node
and the network management system, since once an IPSEC tunnel has
been established secure connection
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
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 centralized source of the neighbours reachable through its interfaces configuration data,
and
possibly other information.

7. The network management system verifies the validity of complete the configuration scripts of 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. 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.

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 Steps To Safely Complete Node Configuration Protocol

This section explores

2.1. Preconfiguration

Preconfiguration is defined as that portion of the requirements for an initial address node's
configuration protocol. The intention that is to provide the information
needed to determine whether an existing protocol would do installed either at the job,
possibly with modifications, factory or whether at a new protocol central
site before the node is needed.
The exploration considers three scenarios:

o installed. It seems reasonable that a brand new network where none
considerable amount of information describing 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.

2.1. The New Network Scenario

Section 1 gave a brief description of an algorithm whereby a node
receives itself rather
than its IP address and carries out subsequent communications
with relation to the network management system through can be preconfigured.

In addition, the first node needs to respond be preconfigured with information
allowing it to it. In establish a new network, this algorithm implies that address
configuration will advance through a tree which eventually spans the
complete network. Communications with secure channel to the network management system
will pass along branches centralized
configuration system. Section 12.5 of [RFC5415] provides one example
of the tree until alternative routing sort of information that is needed.

2.2. Installation

Installation is
established.

In this specific scenario, the initial poll sent out from the new
node through each process of its interfaces needs to contain only the node's
MAC address on that link. If a receiving node has established
communication with putting the network management system, it sends back a
response identifying itself, giving hardware in place,
connecting its own MAC address, interfaces, and
indicating that the network management system verifying its operation. It 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
assumed that the allocation installation phase includes verification of an address. (As Layer 2
connectivity across each interface.

2.3. IP Address Acquisition

Before it can set up a refinement, the responses from
the neighbours could contain the round trip time from the neighbour secure link to the network management centralized configuration
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 has to be given an IP level, with its own address
as source and the address of address. It may be
desirable for the network management centralized configuration system as
destination. The request contains the identity and MAC address of
the new node. Upon receiving the request, to control the network management
system allocates and returns an
address and mask or a prefix, as
applicable. The neighbour relays space. Trust requirements for this information along with phase are discussed in
Section 3.

DHCP is, of course, the
network management system's candidate means of address to the new node, which can now
operate at acquisition.

2.4. Management Node Discovery

Once the IP level itself. Configuration continues with node has an
IKEv2 exchange as described above.

If IP address, there is no response are several ways for it to its initial poll, the new node repeats
discover the
poll at suitable intervals until centralized configuration system. One is for it gets to send
some sort of message out on 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, multicast channel), looking for a reply
from the address centralized configuration protocol
described above will continue to work.

2.3. Attachment To system. Another Operator's Network

The third scenario possibility is one where another operator's network lies along
that the messaging path. The only interesting case here is when all address or FQDN of the new node's neighbours belong to the third party. In any other
case communication with the network management centralized configuration 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 as part of the process of IP address acquisition, e.g., as a
DHCP option. Finally, especially if the new node to is reachable only
across another provider's network, the neighbour has Service Location Protocol
[RFC2608] may be used to include
either find the unicast address or FQDN of the target network management centralized
configuration system.
Otherwise the neighbour would route the request

2.5. Establishment of a Secure Channel

As Section 3 makes clear, it is essential to establish a secure
channel of communication between the management centralized configuration system for its own network instead. That means
and the new node has to
be configured with this information so it can send it out. One could
imagine node. Mutual authentication between the address configuration protocol operating as described
above, with two entities is a
requirement. It seems likely that the neighbouring node faithfully relaying use of certificates is the address
request
preferable approach to the indicated management entity. However, it necessary mutual authentication. It may
be necessary to define new key purpose values to support this.
[Another thing to check, but seems
simpler likely something exists already in
this case to rely on local DHCP to give the new node an
initial address, then case.]

2.6. Topology Discovery and Configuration

Once these steps have the new node contact the network
management system directly at the IP level. 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 router, device, either through impersonation of the network
management 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 tunnel secure
channel between the new node and the network management system through an IKEv2 exchange. centralized configuration
system. That goal implies that the new node device has to be pre-configured pre-
configured with the
shared secret and any other parameters needed to carry out establish the IKEv2
exchange.

Taking secure
channel.

It is also essential that part as an attacker not be able to impersonate a given, the interesting part of
new node. Thus the analysis is
what node must authenticate itself to the security considerations are for centralized
configuration system as well as the address acquisition
process. The first point to observe is that, with 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 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 accomplish
this restriction, the means available to the attacker come down
to two: interference with through attacks on the link between configuration server, on the new node and any
neighbour able
communication path to reach the network management system, server, or by 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
out its initial poll for candidate neighbours. The attacker could
send a reply indicating that it is server
or 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 relay. Assuming 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 DHCP is to provide the means for the new node to authenticate its
neighbour as a member used, impersonation might be
countered through use of the same network. This could capabilities provided by [RFC3118]. A
perhaps preferable alternative would be to use a secret
shared amongst all of the new nodes and their neighbours. The
validity of this approach needs further discussion. method based on
certificates.

4. IANA Considerations

This memo includes no request to IANA.

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14,

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2119, 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
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China

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