One document matched: draft-ietf-opsawg-automated-network-configuration-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0951 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0951.xml">
<!ENTITY RFC0959 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0959.xml">
<!ENTITY RFC1350 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1350.xml">
<!ENTITY RFC1541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1541.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2608 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2608.xml">
<!ENTITY RFC2609 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2609.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2748.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC2817 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2817.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC3084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3084.xml">
<!ENTITY RFC3118 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml">
<!ENTITY RFC3139 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3139.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC3414 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3414.xml">
<!ENTITY RFC3535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3535.xml">
<!ENTITY RFC3736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.xml">
<!ENTITY RFC4217 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4217.xml">
<!ENTITY RFC4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY RFC4252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4252.xml">
<!ENTITY RFC4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY RFC4254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4254.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5277 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5277.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5415 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5415.xml">
<!ENTITY RFC5417 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5417.xml">
<!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5592 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5592.xml">
<!ENTITY RFC5675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5675.xml">
<!ENTITY RFC5676 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5676.xml">
<!ENTITY RFC5730 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml">
<!ENTITY RFC5970 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5970.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6092 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6092.xml">
<!ENTITY RFC6106 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6106.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6353 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6353.xml">
<!ENTITY RFC6355 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6355.xml">
<!ENTITY RFC6470 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6470.xml">
<!ENTITY RFC6643 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6643.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-opsawg-automated-network-configuration-05" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Automated Configuration of IP Networks">Survey of Possibilities for the Automated Configuration of Large IP Networks</title>
<author initials="T." surname="Tsou" fullname="Tina Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone></phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder"
role="editor">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>Bremen</city>
<code>28759</code>
<country>Germany</country>
</postal>
<phone></phone>
<email>j.schoenwaelder@jacobs-university.de</email>
</address>
</author>
<author initials="Y." surname="Shi" fullname="Yang Shi">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>156, Beiqing Road, Zhongguancun, Haidian District</street>
<city>Beijing</city>
<country>P.R. China</country>
</postal>
<phone>+86 10 60614043</phone>
<email>shiyang1@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="Tom Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region>Ontario</region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<author initials="G." surname="Yang" fullname="Guoliang Yang">
<organization>China Telecom</organization>
<address>
<postal>
<street>No. 109 Zhongshan Ave. (West), Tianhe District</street>
<city>Guangzhou</city>
<region></region>
<code></code>
<country>P.R. China</country>
</postal>
<phone>+86 020 38639615</phone>
<email>iamyanggl@gmail.com</email>
</address>
</author>
<date month="January" year="2013" />
<!-- Meta-data Declarations -->
<area>Operations and Maintenance</area>
<workgroup>Operations Area Working Group</workgroup>
<keyword>network installation</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This memo discusses the steps required to bring a large number of
devices into service in IP networks in an automated fashion. The goal
of this document is to list known solutions where they exist, to point
out approaches proven to be problematic, and to identify gaps that
require further specifications.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Many large IP networks are being deployed that entail the
installation of tens of thousands of new network devices. To keep
costs down, it is desirable to automate the establishment of such
networks to the maximum extent possible. This naturally raises the
question how new devices can pick up the configuration information
they need to operate properly in an automated fashion. The goal of
this document is to list known solutions where they exist, to point
out approaches proven to be problematic, and to identify gaps that
require further specifications.</t>
<t>The document primarily targets (a) network operators (in the
generic sense) who are facing the challenge to roll out a large number
of new devices and think about how to implement things properly, (b)
network equipment vendors who like to add features to their products
that make the roll out of lots of new devices simpler for their
customers, and (c) people active in the IETF by identifying gaps where
further standards may be useful to develop. The aim of the document
is to provide guidance to actors who have not already experienced
success in this area by informing about the trade-offs of different
approaches.</t>
<t>A certain basic amount of configuration information must be pre-
configured by the vendor or network operator before the devices are
physically deployed. This pre-provisioned configuration can either be
stored directly on the device itself or it can be provided to the
device during the deployment operation via pluggable memory cards or
near field communication technologies. Further device configuration
information is best delivered after startup, to ensure that it is
consistent with the physical deployment and the desired network
configuration.</t>
<t>One example where automated configuration is important are new
service provider networks. 3GPP work in progress describes
requirements <xref target="TS_32_500"/> and an architectural
specification <xref target="TS_36_300"/> for the self-configuration of
edge node entities called eNodeBs. (The expansion of eNodeB is too
unwieldy to spell out.) Specifically, procedures are specified for
establishing transport connections to and for exchanging configuration
data with control entities called MMEs (Mobility Management Entities)
and with neighbouring eNodeBs. <xref target="TS_36_300"/> currently
assumes as a starting precondition that the eNodeB knows its own IP
address and knows IP address endpoints for the target MMEs and
neighbouring eNodeBs.</t>
<t>The Broadband Forum has defined a CPE WAN Management Protocol
(running over SOAP/HTTP/TLS) to manage customer premise equipment
(CPE) terminating broadband access networks (typically DSL access
networks) <xref target="TR_069"/>. CPE devices locate and connect to
an Auto-Configuration Server (ACS), which provides configuration data
and software/firmware images and modules. The ACS also performs
status and performance monitoring and diagnostic functions. CPE
devices use DHCP to locate an ACS and since both peers, the ACS and
CPE, can initiate connections, the protocol can work across network
address translators (NATs). The DHCP exchange uses vendor-specific
options defined by the Broadband Forum (number 3561 in the IANA
Enterprise Numbers registry).</t>
<t>Next to service provider networks, many large enterprise networks
face the same challenge to roll out a large number of network devices,
which often connect to a 3rd party network provider. The current
development of IP-based home automation and utility monitoring
technologies might carry the problem to roll out large numbers of
devices that need to automatically configure themselves to private
households.</t>
<t>IETF work on automated configuration goes back to BOOTP
<xref target="RFC0951"/>, followed eight years later by DHCP
(<xref target="RFC1541"/> and successors). The years since have seen
a steady growth in the number of DHCP options. The Simple Network
Management Protocol (SNMP) <xref target="RFC3410"/> was designed to
convey management information between SNMP entities such as managers
and agents. The number of SNMP MIB modules grew steadily, but SNMP
has historically seen only limited use for configuration
<xref target="RFC3535"/>. For a period, IETF configuration efforts
were focussed on the distribution of policy information in the
network. <xref target="RFC3139"/> provides a good insight into this
period. More recently, the network configuration protocol NETCONF
<xref target="RFC6241"/> was devised as an alternative to SNMP, but
the development of standard NETCONF configuration data models is just
beginning.</t>
<t>Recent IETF work closest in spirit to the 3GPP self-organizing
network effort cited above is embodied in CAPWAP
<xref target="RFC5415"/>. Like the 3GPP work, CAPWAP focusses on the
configuration of edge nodes, in a Wi-Fi rather than cellular network.
The CAPWAP work goes beyond that of 3GPP by specifying the process of
Access Controller (AC) discovery rather than leaving discovery out of
scope. A CAPWAP Wireless Termination Point (WTP) may use broadcasts
and multicasts to discover local ACs, it may use CAPWAP DHCP options
<xref target="RFC5417"/> to obtain IP addresses of ACs, or it may
utilize CAPWAP DNS SRV records if a domain name is known. With regard
to the configuration process itself, CAPWAP provides for the download
of new images to the WTP (Wireless Termination Point). In contrast,
<xref target="TS_32_500"/> assumes that this has already been
completed for the eNodeB.</t>
<t>As can seen, standards for the automated configuration of devices
in IP networks have so far been primarily developed for specific
network access technologies (3GPP, Broadband, 802.11 WLANs) and the
various solutions make different assumptions about the services that
are available and they are designed to support a configuration
protocol that is specific to a certain access technology. The aim of
this document is to analyse the various phases of an automated
configuration process and to identify gaps that are currently not
covered in standard and general purpose configuration management
protocols of the IETF.</t>
</section> <!-- intro -->
<section anchor="scen" title="Intra-domain and Inter-domain Scenarios">
<t>There are two different scenarios to consider. In the first
scenario, called the Intra-domain Scenario, the new network device N
is attached to the network operated by the service provider which is
also operating the new device. In the second scenario, called the
Inter-domain Scenario, the new device N is attached to a third party
network providing connectivity to the network of the service provider
operating the new device.</t>
<figure anchor="fig_intra" title="Intra-domain Scenario">
<artwork>
+------+
| CONF |
+--+---+
+---+ +---+ |
| N +-...-+ R +------+---+---+----...
+---+ +---+ | |
+--+--+ +--+---+
| DNS | | DHCP |
+-----+ +------+
|-- N's Service Provider --|
</artwork>
</figure>
<t><xref target="fig_intra"/> depicts the Intra-domain Scenario. We
assume that the new device N attaches to a link connected to router R.
Furthermore, we assume that the service provider provides a Domain
Name System (DNS) server, a reachable DHCP server, and a Configuration
Server (CONF). Overall, this scenario does not differ much from
conventional network scenarios.</t>
<figure anchor="fig_inter" title="Inter-domain Scenario">
<artwork>
+------+
| CONF |
+--+---+
+---+ +---+ +---+ |
| N +-...-+ R +-----+---+---+-----...-+ R +-----+---+---+-----...
+---+ +---+ | | +---+ | |
+--+--+ +--+---+ +--+--+ +--+---+
| DNS | | DHCP | | DNS | | DHCP |
+-----+ +------+ +-----+ +------+
|-- Service Provider X ---| |-- N's Service Provider --|
</artwork>
</figure>
<t><xref target="fig_inter"/> depicts the Inter-domain Scenario where
the new device N attaches to a router R owned by a different service
provider X. The service provider X might offer its own DNS service and
a reachable DHCP service. We assume that the service provider X has
connectivity to the service provider planning to operate the new
device.</t>
<t>It should be noted that handing out DHCP options specific to N's
service provider via X's DHCP service requires some close coordination
between the two parties involved. This might be difficult in
practice. A more general alternative might be to have X's service
provider establish a tunnel such that the new device logically appears
to be part of N's service provider network.</t>
<t>In both scenarios, the new device N is either directly reachable or
it may be behind a middlebox such as a Network Address Translator
(NAT) or a firewall. Middleboxes may impose restrictions on which
party is able to initiate communication. As detailed in <xref
target="I-D.kwatsen-reverse-ssh"/>, it is often desirable to allow
device-initiated connections.</t>
</section> <!-- scen -->
<section anchor="model" title="Model of the Automated Configuration Process">
<t>We introduce a model of the configuration process in order to
identify the parts that have well-known solutions. The remainder may
be worth studying to see if the industry can agree on a solution.</t>
<t>Some basic terminology is needed for the discussion. Depending on
the implementation, let us agree that "configuration data" consist of
software and sets of configured parameters in some combination. This
includes firmware, licenses, certificates, and other configuration
data. Also, the system that provides the configuration data is called
the "configuration server". Finally, the term "joining device" is
used to denote a network device that is in the process of being
incorporated into the network.</t>
<t>Broadly speaking, the configuration process can be broken into five
phases:
<list style="numbers">
<t>Pre-configuration: configuration carried out either by the vendor
or by the service provider prior to physical installation. One
possible example is the pre-configuration of certificates or licenses
or specific firmware.</t>
<t>Bootstrapping: the portion of the process from the time that
physical installation is complete until a secure connection is
established between the joining device and the configuration
server.</t>
<t>Initial configuration: downloading of the configuration data that
the joining device needs to carry out its function in the network.</t>
<t>Configuration auditing: tracking image versions and configuration
parameters for each network device and verifying that the installed
configuration data matches the physical installation, the network
plan, and the records of what data was downloaded. It is possible that
an initial audit of the physical installation is done before initial
configuration, so that the validity of the intended download can be
verified.</t>
<t>Configuration update: transferring configuration data to a fully
configured and operating device from time to time as the need
arises.</t>
</list>
</t>
</section> <!-- model -->
<section anchor="preconf" title="Phase 1: Pre-configuration">
<t>This memo identifies a specific requirement for pre-configuration
of an invariant device identity and authentication-related material in
the form of pre-shared secrets or certificates. There is, as one
alternative, also a requirement for pre-configuration of information
that permits the joining device to discover the address of the
configuration server.</t>
<t>Note that pre-configuration may be carried out on the joining
device itself or it may be provided to the joining device during the
deployment process via pluggable memory cards or nearfield
communication.</t>
</section> <!-- preconf -->
<section anchor="boot" title="Phase 2: Bootstrapping">
<t><xref target="I-D.sarikaya-core-sbootstrapping"/> deals with the
process of security bootstrapping, with particular emphasis on the
requirements for highly resource-constrained devices. The document
makes a distinction between a data channel, which is used during
network operation, and a control channel, which is used during
bootstrapping. While both channels can be the same physical channel,
they can also be different (e.g., a wireless access point using an
infrared control channel to receive bootstrapping information). The
draft discusses a number of possible security bootstrapping protocols
for resource constrained devices that can be executed in several
bootstrapping rounds and can be adapted to the specific contexts in
terms of the resources available within individual devices and for the
network as a whole.</t>
<t>For network devices in service provider networks or large
enterprise networks, bootstrapping consists of several stages:
<list style="numbers">
<t>establishment of link layer connectivity with neighbouring
nodes;</t>
<t>acquisition of IP addresses and basic routing information;</t>
<t>discovery of the configuration server;</t>
<t>establishment of a secure channel to the configuration server.</t>
</list>
Each of these stages is further discussed below.</t>
<section anchor="llconn" title="Establishment of Link Layer Connectivity">
<t>The protocol aspects of this phase are out of scope, since it
involves non-IETF protocols only. While some link-layer technologies
may provide authentication and access control, this cannot be assumed
to be available in the general case.</t>
</section> <!-- llconn -->
<section anchor="addracq" title="Acquisition of IP Addresses and Basic Routing Information">
<t>For IPv4, DHCPv4 <xref target="RFC2131"/> is widely deployed and
the usual way to obtain an IPv4 address, the IPv4 address of a link-
local router and the IPv4 address of a DNS server. For IPv6, a choice
has to be made between stateful DHCPv6 <xref target="RFC3315"/> versus
stateless DHCPv6 <xref target="RFC3736"/> combined with stateless
address autoconfiguration <xref target="RFC4862"/>. In the latter
case, DHCPv6 is needed to configure parameters such as DNS server
addresses. A routing advertisement option to configure the IPv6
address of a DNS server as part of the stateless address
autoconfiguration is defined in <xref target="RFC6106"/>.</t>
<t>Some security protection is provided in this stage by using DHCP
authentication <xref target="RFC3118"/>. However, security of the
configuration process as a whole has to be assured by other means.
This is discussed further below.</t>
<t>Currently the lack of a stable identifier for use in DHCPv6
messaging is an impediment to authentication of the joining device.
<xref target="RFC6355"/> discusses the problems with the current
DHCPv6 identifiers (DUIDs) and proposes a new form that could be a
more stable alternative.</t>
<t>A joining device can also choose to use a pre-configured IP
address, a pre-configured link-local router address and a pre-
configured DNS server address. This pre-configuration may be hard
wired into the device or provided by a pluggable memory card or
nearfield communication. However, a static pre-configuration hard-
wires assumption about the network a devices operates in and is
therefore brittle and not recommended.</t>
</section> <!-- addracq -->
<section anchor="figdis" title="Finding the Configuration Server">
<t>Four alternatives are available for finding the configuration
server:
<list style="symbols">
<t>pre-configuration;</t>
<t>DHCP configuration;</t>
<t>Service Location Protocol <xref target="RFC2608"/>; or</t>
<t>DNS service discovery using DNS SRV records
<xref target="RFC2782"/>.</t>
</list></t>
<t>Pre-configuration of an IP address is brittle and not recommended
unless the IP address is used as an anycast address. In the case of
an IP anycast address, the routing system will select one out of an
anycast cluster of configuration servers the devices connects to. For
this to work well, all configuration servers in the anycast cluster
should provide the same configuration data.</t>
<t>The pre-configuration of a Uniform Resource Identifier (URI) or
fully qualified domain name (FQDN) is a slightly better approach than
pre-configuring non-anycast IP addresses since this allows for a
limited dynamic mapping of the name to an IP address. One variant
that has been suggested is to burn the URI of a vendor server into the
device's firmware along with a device identifier, and have that server
redirect to the URI of the service provider's configuration server
based on the device identity. Such an approach requires that the
device vendor's redirection server is always reachable, that the
device vendor offers such a redirection service for the lifetime of
their devices and that service providers are able to update the URI of
the service provider's redirection server. Furthermore, this approach
can lead to problems if certificates are used to authenticate the
involved parties if a service provider tries to prevent the usage of a
vendor's redirection service. Finally, this approach also requires a
trust relationship between the vendor and the service provider and
agreement on a protocol to update the redirect information on the
vendor's server. As a consequence of these considerations, using this
approach is not recommended.</t>
<t>DHCP configuration can use the usual DHCP options and is
technically straightforward since DHCP is widely used by end user
devices to obtain basic configuration information. There is, however,
no standardized DHCP option to communicate the address of a
configuration server.</t>
<t>The Service Location Protocol (SLP) has seen some usage to locate
services such as printers or file system shares. Usage of SLP to
locate configuration servers requires to define a new service template
<xref target="RFC2609"/>.</t>
<t>The use of DNS SRV records requires the joining device to obtain
the correct domain suffix first, presumably from DHCP or via Routing
Advertisements in the case of IPv6 or pre-configuration. A service
type for the desired configuration protocol would have to be defined
in the DNS for the purpose. See Section 3.3 of
<xref target="RFC5415"/> for a discussion of the corresponding
discovery process for CAPWAP.</t>
<t>The Inter-domain Scenario requires that the DHCP server or the SLP
server of service provider X's network is able to provide the correct
information to the joining devices. To accomplish this, the discovery
servers need to be able to match a device identification against a
list of possible configuration servers. Furthermore, there needs to
be a mechanism for the service provider operating the joining device
to provision the configuration server's address, e.g., by using an
extension of the Extensible Provisioning Protocol (EPP)
<xref target="RFC5730"/>. However, if the joining device has pre-
configured information about the name of the service provider's
network, DNS SRV records may be queried after obtaining IP
connectivity, avoiding the need to provision information in service
provider X's network.</t>
</section> <!-- figdis -->
<section anchor="secchan" title="Establishing a Secure Channel to the Configuration Server">
<t>It is essential that the configuration server and the joining
device authenticate themselves to each other, since the steps leading
up to this point in the process may not be fully secure. This raises
two issues: how the joining device identifies itself, and how
authentication takes place.</t>
<t>It seems best if the device has an invariant identity built in and
accessible to whatever operating system is running on it.
<xref target="RFC6355"/> provides such an identity in the form of a
Universally Unique IDentifier (UUID). The vendor should make that
identity available in a form that can be read and transferred into a
database accessible to the configuration server along with the
associated configuration data in advance of the bootstrapping stage
(e.g., in bar-coded format on the device packaging).</t>
<t>Serial numbers may be used for identification purposes if UUIDs are
not available. However, serial numbers often encode information such
as model-numbers or manufacturing dates. Hence, it is not recommended
to pass serial-numbers in the clear for security reasons. Similar
precautions apply to Common Language Equipment Identifier (CLEI) codes
that encode information about properties of the device.</t>
<t>This leaves the mutual authentication process itself. This has two
aspects: the security protocol used to perform authentication, and
initial keying methodology. The security protocol is tied together
with the choice of configuration data transport, but the basic choices
are:
<list style="symbols">
<t>IP Security (IPsec) <xref target="RFC4301"/>;</t>
<t>Transport Layer Security (TLS) <xref target="RFC5246"/>;</t>
<t>Datagram Transport Layer Security (DTLS)
<xref target="RFC6347"/>;</t>
<t>Secure Shell (SSH) <xref target="RFC4251"/>,
<xref target="RFC4252"/>, <xref target="RFC4253"/>, and
<xref target="RFC4254"/>; and</t>
<t>SNMPv3's User-based Security Model (USM)
<xref target="RFC3414"/>.</t>
</list> </t>
<t>For initial keying methodology, the two basic choices are between
pre-shared secrets and certificates. All of the security protocols
listed above except USM support both methods. USM supports pre-shared
secrets only.</t>
<t>The usual concern with pre-shared secrets is scalability. In the
bootstrapping case, the scale of operation required is linear with the
number of devices to be configured, so it would definitely be a
feasible approach if connection to the configuration system were the
only consideration. The most likely procedure would be for the secret
to be configured in the device during pre-configuration and also
captured in a database along with the device identity, for use by the
configuration server.</t>
<t>The problem with the use of pre-shared secrets is that the device
needs to authenticate itself at an earlier stage, while it is
establishing communications with its neighbours and acquiring IP
addresses. It seems undesirable to use the same secret that is used
to authenticate the device to the configuration server for that
purpose as well, on the basic principle of limiting the potential
damage from disclosure of a particular key.</t>
<t>This need for additional pre-shared secrets argues for
consideration of certificates as an alternative. One issue for
certificates is where the trust anchor resides. It seems logical that
it should reside with the service provider rather than the vendor, to
make it easy to install equipment from multiple vendors. On that
basis, pre-configuration requires service provider input. On the
other hand, if devices are drop-shipped to the destination from the
vendor, having the trust anchor reside with the vendor might be
acceptable as well.</t>
<t>CAPWAP (Section 2.4.4.3 of <xref target="RFC5415"/>) makes use of
the Extended Key Usage (EKU) certificate extension
<xref target="RFC5280"/> to distinguish certificates identifying the
Access Controllers (i.e., the configuration servers in the CAPWAP
case) from the Wireless Transfer Points (the configured devices in the
CAPWAP case). Thought should be given to whether such distinctions
are required in the general case of network device configuration.</t>
<t>CAPWAP (Section 12.8 of <xref target="RFC5415"/>) also discusses
the use of the Common Name rather than SubjectAltName field of the
certificate to carry device identity, due to lack of a Uniform
Resource Name (URN) specification allowing the use of SubjectAltName
to carry MAC addresses. This encoding of device identifiers in
certifications needs to be investigated further if a new form of
device unique identity is used, as discussed above.</t>
<t>Middleboxes such as NATs or firewalls may impose restriction on
which party is able to initiate communication. In the common case of
NATs in IPv4 access networks, communication can only be established
from the device to the configuration server. Not all secure
transports, in particular those where authentication is not symmetric,
support this "call home" mode of operation. A recent proposal to
reverse the establishment of the TCP connection for SSH can be found
in <xref target="I-D.kwatsen-reverse-ssh"/>.</t>
</section> <!-- secchan -->
</section> <!-- boot -->
<section anchor="iniconfig" title="Phase 3: Initial Configuration">
<t>As mentioned at the beginning, the configuration data being
downloaded may be a combination of software/firmware and configuration
parameters. Some of the data will be vendor-specific and not subject
to standardization. It appears that there is a continuing debate on
whether the configuration data should be pushed to the joining device
or whether the device should pull the configuration data from the
configuration server. In the latter case, the device needs to know
about the existence of the data and the path to reach it before it can
act. One way to acquire this information is through DHCP. DHCPv4 has
provided the necessary options from its beginnings, inheriting them
from BOOTP. They have been recently added to DHCPv6
<xref target="RFC5970"/>.</t>
<t>Protocols that can transport configuration data can be classified
as follows: The first class consists of generic file transfer
protocols that can carry configuration data serialized into
configuration files. The second class consists of protocols that
manipulate structured configuration data directly. The structure of
the configuration data is defined by some data model.</t>
<t>In the first class, we find the following file transfer protocols:
<list style="symbols">
<t>The File Transfer Protocol (FTP) <xref target="RFC0959"/> can be
used to move files containing configuration data. It can be secured
by running FTP over TLS <xref target="RFC4217"/>.</t>
<t>The Trivial File Transfer Protocol (TFTP) <xref target="RFC1350"/>
has been used extensively to load boot images over the network.
However, it does not provide security and the only option is to rely
on IP layer security (IPsec).</t>
<t>The Hypertext Transfer Protocol (HTTP) <xref target="RFC2616"/> can
be used to transfer documents containing configuration data. It is
commonly secured by running HTTP over TLS <xref target="RFC2817"/>,
<xref target="RFC2818"/>.</t>
<t>The SSH File Transfer Protocol (SFTP)
<xref target="I-D.ietf-secsh-filexfer"/> provides roughly the same
services as FTP but runs over SSH and thus utilizes the security
services provided by SSH.</t>
<t>UNIX utilities to transfer files such as RCP and SCP provide
limited flexibility and they differ in their degree of integration
with SSH.</t>
<t>The Control And Provisioning of Wireless Access Points (CAPWAP)
protocol <xref target="RFC5415"/> can be used to control the download
of images. CAPWAP can be secured by running CAPWAP over DTLS.</t>
</list> </t>
<t>In the second class, we find the following configuration protocols:
<list style="symbols">
<t>Version 3 of the Simple Network Management Protocol (SNMPv3)
<xref target="RFC3411"/> can be used to manipulate MIB objects and to
carry event notifications. SNMPv3 has its own security protocol (USM)
<xref target="RFC3414"/> but can also run over the secure transports
SSH <xref target="RFC5592"/>, TLS, or DTLS <xref
target="RFC6353"/>.</t>
<t>The Common Open Policy Service for Policy Provisioning protocol
(COPS-PR) <xref target="RFC3084"/> was designed to provision
structured policy information from a Policy Decision Point (PDP) to a
Policy Enforcement Point (PEP). The COPS protocol
<xref target="RFC2748"/> provides an integrity object that can achieve
authentication, message integrity, and replay prevention. Optionally,
COPS and COPS-PR can run over TLS.</t>
<t>The NETCONF protocol <xref target="RFC6241"/> provides mechanisms
to install, manipulate, and delete the configuration of network
devices. A protocol extension provides an asynchronous event
notification delivery mechanism <xref target="RFC5277"/>. NETCONF by
default runs over SSH but can also run over transports secured by
TLS.</t>
<t>The Control And Provisioning of Wireless Access Points protocol
(CAPWAP) <xref target="RFC5415"/> supports the discovery of so called
Access Controller (AC) by Wireless Termination Points (WTPs) and the
configuration of WTPs by an AC. While CAPWAP can be extended to
configure other devices, its main focus are WTPs. The CAPWAP protocol
is protected by using DTLS after the discovery phase.</t>
</list>
</t>
<t><xref target="tab_prot"/> lists the protocols plus their basic
properties while <xref target="tab_opt"/> lists the security options
available for each protocol.</t>
<texttable anchor="tab_prot" title="Protocols for transporting configuration data">
<ttcol align="left">Transport</ttcol>
<ttcol align="left">Data Transfer Model</ttcol>
<c>FTP</c>
<c>Push or pull of (configuration) files</c>
<c>TFTP</c>
<c>Push or pull of (configuration) files</c>
<c>HTTP</c>
<c>Push or pull of (configuration) files</c>
<c>SFTP</c>
<c>Push or pull of (configuration) files</c>
<c>RCP</c>
<c>Push or pull of (configuration) files</c>
<c>SCP</c>
<c>Push or pull of (configuration) files</c>
<c>CAPWAP</c>
<c>AC pushes configuration parameters, WTP pulls software</c>
<c>SNMPv3</c>
<c>Push of structured configuration parameters, event notifications</c>
<c>COPS-PR</c>
<c>Push of structured policy information</c>
<c>NETCONF</c>
<c>Push of structured configuration data, event notifications</c>
</texttable>
<texttable anchor="tab_opt" title="Security options for configuration transport protocols">
<ttcol align="left">Transport</ttcol>
<ttcol align="center">IPsec</ttcol>
<ttcol align="center">TLS</ttcol>
<ttcol align="center">DTLS</ttcol>
<ttcol align="center">SSH</ttcol>
<ttcol align="center">Other</ttcol>
<c>FTP</c>
<c>+</c>
<c>+</c>
<c> </c>
<c> </c>
<c> </c>
<c>TFTP</c>
<c>+</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
<c>HTTP</c>
<c>+</c>
<c>+</c>
<c> </c>
<c> </c>
<c> </c>
<c>SFTP</c>
<c>+</c>
<c> </c>
<c> </c>
<c>+</c>
<c> </c>
<c>RCP</c>
<c>+</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
<c>SCP</c>
<c>+</c>
<c> </c>
<c> </c>
<c>+</c>
<c> </c>
<c>CAPWAP</c>
<c>+</c>
<c> </c>
<c>+</c>
<c> </c>
<c> </c>
<c>SNMPv3</c>
<c>+</c>
<c>+</c>
<c>+</c>
<c>+</c>
<c>USM</c>
<c>COPS-PR</c>
<c>+</c>
<c>+</c>
<c> </c>
<c> </c>
<c> </c>
<c>NETCONF</c>
<c>+</c>
<c>+</c>
<c> </c>
<c>+</c>
<c> </c>
</texttable>
<t>SNMPv3, NETCONF, and COPS-PR carry structured data specified in
pre-defined data models. SNMPv3 and COPS-PR have size limitations on
the data objects and thus make the transport of larger software images
difficult. NETCONF does not suffer from hard size restrictions and
can in principle carry software images inline. However, there is
currently no work in progress to standardize the transfer of software
images over NETCONF. CAPWAP combines the functions of configuration
parameter transport and software download. The parameter transport
aspect lacks the generality offered by SNMP, NETCONF, and COPS-PR,
since the parameters are specified within the protocol specification
itself. The remaining transports are independent of the nature of the
information being transferred.</t>
</section> <!-- iniconfig -->
<section anchor="aud" title="Phase 4: Configuration Auditing">
<t>To complete the process, it must be possible to audit the
configuration status of the device in some detail. This is likely to
begin even before all the configuration data has been downloaded. For
instance, configuration management may wish to collect basic
information such as the MAC addresses of the device's interfaces, the
link-local addresses assigned to them, and similar information for the
neighbours of the joining device.</t>
<t>SNMP and SNMP MIB modules are obviously one way to collect this
information. NETCONF <xref target="RFC6241"/> is an alternative, but
the necessary data models have to be defined. YANG modules for
NETCONF <xref target="RFC6020"/> can be generated from existing SNMP
MIB modules by translating the SNMP modules into YANG modules
<xref target="RFC6643"/>.</t>
<t>Another important auditing activity is the analysis of system
events. The SYSLOG protocol <xref target="RFC5424"/> is widely used
for this purpose but SNMPv3 and NETCONF can ship event notifications
as well. Translations of SNMP notifications into structured SYSLOG
messages and vice versa do exist <xref target="RFC5675"/>,
<xref target="RFC5676"/>. NETCONF can carry SYSLOG content as well
<xref target="RFC5277"/>.</t>
<t>NETCONF provides generic notifications that help with tracking
configuration changes <xref target="RFC6470"/>. Similar standardized
configuration change notifications do not exist for SNMP or
SYSLOG.</t>
</section> <!-- aud -->
<section anchor="upd" title="Phase 5: Configuration Update">
<t>Configuration updates can in principle be handled with the same
protocol that delivered the initial configuration. However, in some
deployments, the mechanism used for initial configuration might be
different.</t>
<t>An advantage of NETCONF over SNMPv3 and CAPWAP in the context of
configuration updates is the support of concurrent updates through
explicit locking mechanisms and the support of network wide
configuration change transactions through the confirmed commit
capability.</t>
</section> <!-- upd -->
<section anchor="gaps" title="Gap Analysis">
<t>This document discussed the automated configuration of devices in
large IP networks. Several gaps were identified requiring further
specification:
<list style="hanging">
<t hangText="G1:">Definition of a DHCP option to provide the IPv4/IPv6
address of a configuration server. Such an option allows a joining
device to pickup the configuration server's address as part of the
DHCP exchange. This is particularly interesting for Intra-domain
Scenarios.</t>
<t hangText="G2:"> Definition of DNS SRV records for locating
configuration servers. Using SRV records, a joining device can lookup
the configuration server's address in the DNS. This is particularly
useful in an Inter-domain Scenario.</t>
<t hangText="G3:"> Definition of a SLP template for discovering
configuration servers. Such a template is useful only in environments
where SLP is used also for other purposes.</t>
<t hangText="G4:"> Definition of NETCONF data models to support the
download /update of software images through NETCONF.</t>
<t hangText="G5:"> Definition of NETCONF data models for collecting
basic system information and integrity information (e.g., checksums of
software images).</t>
<t hangText="G6:"> Some management protocols lack a mechanisms for
devices to initiate a secure communication channel with a management
system ("call home").</t>
</list>
</t>
</section> <!-- gaps -->
<!-- 10. Conclusions
This section summarized the previous discussions and provides some
concrete recommendations. The following recommendations are given to
network operators and equipment vendors who have not yet experienced
success in this area:
o Hard-wired non-anycast IP addresses are brittle and not
recommended for finding a configuration server. Hard-wired URIs
or domain names allow one level of indirection but can still be
problematic during the lifetime of a product. Using DHCP to
provision the IP address of a configuration server dynamically or
using DNS SRV records to query the DNS for a suitable
configuration server is preferred over solutions that use hard-
wired information.
o For device identification, identifiers are generally preferred
that do not carry further semantics about a device, such as UUIDs
produced by cryptographic hash functions.
o A number of protocols can be used to transfer the initial
configuration (software/firmware and configuration parameters).
Selection of a suitable protocol should take into account (i)
whether a push or pull model or both are needed (e.g., to support
working around middleboxes such as Network Address Translators,
NATs) and (ii) how the security options and their key management
mechanisms integrate into the target network.
Section 9 identifies gaps where additional standardization work might
be useful. The first three (G1-G3) all address the need to locate a
configuration server. Out of the three options, G3 seems to be
mostly of theoretical value since SLP does not appear to be widely
used for this purpose. For G1, however, there is some usage evidence
coming from the CPE WAN Management Protocol [TR_069]. The usage of
DNS SRV records requires to obtain the domain name via other means
first. As such, the it seems that G1 is more meaningful to address
at this point in time.
Addressing G4 and G5 does not seem to be of high priority at this
point in time. NETCONF's strength are its operations to make
incremental configuration changes on a large number of devices in a
robust manner. As such, NETCONF is a good protocol for incremental
configuration updates. For transferring files or software images,
other protocols work reasonably well. At this point in time, the
only benefits of addressing G4 or G5 would be the reuse of the
security and authorization mechanisms provided by NETCONF.
Due to the prevalence of middleboxes such as NATs, it is often
required that devices establish the management sessions to their
management systems. A BoF covering this topic was held at the 64th
IETF meeting, which was triggered in part by work in the ISMS working
group on alternate secure transports for SNMP. While the ISMS
working group, after consultation with security experts, decided to
not address this problem, the issue resurfaced later in the NETCONF
working group but was not addressed there either. Vendors meanwhile
seem to ship proprietary solutions. As such, G6 seems worthwhile to
address but it is also known to be a difficult topic, requiring
extensive support from the security area.
-->
<section anchor="seccons" title="Security Considerations">
<t>The security of a configuration management solution is of crucial
importance. <xref target="iniconfig"/> discusses the security options
of several protocols that might be used. The relevant protocol
definitions should be consulted to learn more about the specific
security aspects of the various protocols.</t>
<t>It should be noted that some steps in the described process, in
particular the bootstrapping phase, may not be secure and it is thus
important to verify the identity of the device and the identity of the
configuration server when a secure connection to a configuration
server is established. Usage of IPsec, which focuses on securing the
IP layer, may not be sufficient for this.</t>
<t>During the choice of protocols, the available security mechanisms
and the required key management infrastructures may play a major role
in the selection of protocols. Easy integration into existing
Authentication, Authorization and Accounting (AAA) infrastructures can
significantly reduce the operational costs associated with the
security management of the configuration system.</t>
<t>While <xref target="I-D.sarikaya-core-sbootstrapping"/> discusses
security bootstrapping mechanisms in the context of constrained
devices, many of the mechanisms are also applicable for bootstrapping
security in normal devices.</t>
<t>Finally, <xref target="RFC6092"/> discusses security capabilities
for customer premises equipment providing residential IPv6 Internet
service.</t>
</section> <!-- seccons -->
<section anchor="iana" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section> <!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>Thanks to Ronald Bonica, Mehmet Ersue, Wesley George, Yiu Lee,
Christopher Liljenstolpe, Kent Watsen, and Cathy Zhou for their
comments during the preparation of this memo.</t>
</section> <!-- ack -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Informative References">
<reference anchor="I-D.ietf-secsh-filexfer">
<front>
<title>"SSH File Transfer Protocol", draft-ietf-secsh-filexfer-13 (work in progress)</title>
<author initials="J." surname="Galbraith" fullname="J. Galbraith">
<organization>VanDyke Software</organization>
</author>
<author initials="O." surname="Saarenmaa" fullname="O. Saarenmaa">
<organization>F-Secure</organization>
</author>
<date month="July" year="2006"/>
</front>
</reference>
<reference anchor="I-D.kwatsen-reverse-ssh">
<front>
<title>"Reverse Secure Shell (Reverse SSH)", draft-kwatsen-reverse-ssh-01 (work in progress)</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<date month="June" year="2011"/>
</front>
</reference>
<reference anchor="I-D.sarikaya-core-sbootstrapping">
<front>
<title>Security Bootstrapping Solution for Resource-Constrained Devices" draft-sarikaya-core-sbootstrapping-05 (work in progress)</title>
<author initials="B." surname="Sarikaya" fullname="Behcet Sarikaya">
<organization>Huawei USA</organization>
</author>
<author initials="Y." surname="Ohba" fullname="Yoshihiro Ohba">
<organization>Toshiba</organization>
</author>
<author initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
<organization>Verizon Business Systems</organization>
</author>
<author initials="Z." surname="Cao" fullname="Zhen Cao">
<organization>China Mobile</organization>
</author>
<author initials="R." surname="Cragie" fullname="Robert Cragie">
<organization>Pacific Gas and Electric</organization>
</author>
<date month="July" year="2012"/>
</front>
</reference>
&RFC0951;
&RFC0959;
&RFC1350;
&RFC1541;
&RFC2131;
&RFC2608;
&RFC2609;
&RFC2616;
&RFC2748;
&RFC2782;
&RFC2817;
&RFC2818;
&RFC3084;
&RFC3118;
&RFC3139;
&RFC3315;
&RFC3410;
&RFC3411;
&RFC3414;
&RFC3535;
&RFC3736;
&RFC4217;
&RFC4251;
&RFC4252;
&RFC4253;
&RFC4254;
&RFC4301;
&RFC4862;
&RFC5246;
&RFC5277;
&RFC5280;
&RFC5415;
&RFC5417;
&RFC5424;
&RFC5592;
&RFC5675;
&RFC5676;
&RFC5730;
&RFC5970;
&RFC6020;
&RFC6092;
&RFC6106;
&RFC6241;
&RFC6347;
&RFC6353;
&RFC6355;
&RFC6470;
&RFC6643;
<reference anchor="TR_069">
<front>
<title>"CPE WAN Management Protocol", Broadband Forum TR-069</title>
<author initials="J." surname="Blackford" role="editor">
<organization></organization>
</author>
<author initials="H." surname="Kirksey" role="editor">
<organization></organization>
</author>
<author initials="W." surname="Lupton" role="editor">
<organization></organization>
</author>
<date month="November" year="2010"/>
</front>
</reference>
<reference anchor="TS_32_500">
<front>
<title>"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Self-Organizing Networks (SON); Concepts and requirements (Release 9)", 3GPP TS 32.500</title>
<author initials="" surname="" fullname="">
<organization>3GPP</organization>
</author>
<date year="2010"/>
</front>
</reference>
<reference anchor="TS_36_300">
<front>
<title>"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 9)", 3GPP TS 36.300</title>
<author initials="" surname="" fullname="">
<organization>3GPP</organization>
</author>
<date year="2010"/>
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 06:49:02 |