draft-ietf-opsawg-automated-network-configuration-01.txt   draft-ietf-opsawg-automated-network-configuration-02.txt 
Internet Engineering Task Force T. Tsou Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational J. Schoenwaelder, Ed. Intended status: Informational J. Schoenwaelder, Ed.
Expires: December 2, 2011 Jacobs University Bremen Expires: May 3, 2012 Jacobs University Bremen
Y. Shi Y. Shi
Hangzhou H3C Tech. Co., Ltd. Hangzhou H3C Tech. Co., Ltd.
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
G. Yang G. Yang
China Telecom China Telecom
May 31, 2011 October 31, 2011
Problem Statement for the Automated Configuration of Large IP Networks Problem Statement for the Automated Configuration of Large IP Networks
draft-ietf-opsawg-automated-network-configuration-01 draft-ietf-opsawg-automated-network-configuration-02
Abstract Abstract
This memo discusses the steps required to bring network devices in a This memo discusses the steps required to bring a large number of
service provider network into service in an automated fashion. The devices into service in IP networks in an automated fashion. The
memo identifies known solutions where they exist, but notes some gaps goal of this document is to list known solutions where they exist and
that require further specification. to identify gaps that require further specifications.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Intra-domain and Inter-domain Scenarios . . . . . . . . . . . 4
3. A Model of the Process . . . . . . . . . . . . . . . . . . . . 5 3. Model of the Automated Configuration Process . . . . . . . . . 6
4. Pre-configuration . . . . . . . . . . . . . . . . . . . . . . 6 4. Phase 1: Pre-configuration . . . . . . . . . . . . . . . . . . 7
5. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Phase 2: Bootstrapping . . . . . . . . . . . . . . . . . . . . 7
5.1. Establishment of Link Layer Connectivity . . . . . . . . . 7 5.1. Establishment of Link Layer Connectivity . . . . . . . . . 8
5.2. Acquisition of IP Addresses and Basic Routing 5.2. Acquisition of IP Addresses and Basic Routing
Information . . . . . . . . . . . . . . . . . . . . . . . 7 Information . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Finding the Configuration Server . . . . . . . . . . . . . 7 5.3. Finding the Configuration Server . . . . . . . . . . . . . 8
5.4. Establishing a Secure Channel to the Configuration 5.4. Establishing a Secure Channel to the Configuration
Server . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Initial Configuration and Configuration Updates . . . . . . . 10 6. Phase 3: Initial Configuration . . . . . . . . . . . . . . . . 12
7. Configuration Auditing . . . . . . . . . . . . . . . . . . . . 13 7. Phase 4: Configuration Auditing . . . . . . . . . . . . . . . 15
8. Missing Specifications . . . . . . . . . . . . . . . . . . . . 13 8. Phase 5: Configuration Update . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Missing Specifications . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Informative References . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes since -01 . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
New service provider networks are being deployed that entail the Many large IP networks are being deployed that entail the
installation of tens of thousands of new network devices. To keep installation of tens of thousands of new network devices. To keep
costs down, it is desirable to automate the establishment of such costs down, it is desirable to automate the establishment of such
networks and the configuration of these network devices to the networks to the maximum extent possible. This naturally raises the
maximum extent possible. A certain amount of the information needed question how new devices can pick up the configuration information
to operate them must be pre-configured by the vendor or service they need to operate properly in an automated fashion. The goal of
provider before the devices are physically deployed. Other this document is to list known solutions where they exist and to
identify gaps that require further specifications.
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 information is best delivered after startup, to ensure that it is
consistent with the physical deployment. consistent with the physical deployment and the desired network
configuration.
3GPP work in progress describes requirements [TS_32_500] and an One example where automated configuration is important are new
architectural specification [TS_36_300] for the self-configuration of service provider networks. 3GPP work in progress describes
edge node entities called eNodeBs. (The expansion of eNodeB is too requirements [TS_32_500] and an architectural specification
unwieldy to spell out.) Specifically, procedures are specified for [TS_36_300] for the self-configuration of edge node entities called
establishing transport connections to and for exchanging eNodeBs. (The expansion of eNodeB is too unwieldy to spell out.)
configuration data with control entities called MMEs (Mobility Specifically, procedures are specified for establishing transport
Management Entities) and with neighbouring eNodeBs. [TS_36_300] connections to and for exchanging configuration data with control
currently assumes as a starting precondition that the eNodeB knows entities called MMEs (Mobility Management Entities) and with
its own IP address and knows IP address endpoints for the target MMEs neighbouring eNodeBs. [TS_36_300] currently assumes as a starting
and neighbouring eNodeBs. precondition that the eNodeB knows its own IP address and knows IP
address endpoints for the target MMEs and neighbouring eNodeBs.
The Broadband Forum has defined a CPE WAN Management Protocol The Broadband Forum has defined a CPE WAN Management Protocol
(running over SOAP/HTTP/TLS) to manage customer premise equipment (running over SOAP/HTTP/TLS) to manage customer premise equipment
(CPE) terminating broadband access networks (typically DSL access (CPE) terminating broadband access networks (typically DSL access
networks) [TR_069]. CPE devices locate and connect to an Auto- networks) [TR_069]. CPE devices locate and connect to an Auto-
Configuration Server (ACS), which provides configuration data and Configuration Server (ACS), which provides configuration data and
software/firmware images and modules. The ACS also performs status software/firmware images and modules. The ACS also performs status
and performance monitoring and diagnostic functions. CPE devices use and performance monitoring and diagnostic functions. CPE devices use
DHCP to locate an ACS and since both peers, the ACS and CPE, can DHCP to locate an ACS and since both peers, the ACS and CPE, can
initiate connections, the protocol can work across network address initiate connections, the protocol can work across network address
translators (NATs). translators (NATs).
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.
IETF work on automated configuration goes back to BOOTP [RFC0951], IETF work on automated configuration goes back to BOOTP [RFC0951],
followed eight years later by DHCP [RFC1531] and successors. The followed eight years later by DHCP [RFC1541] and successors. The
years since have seen a steady growth in the number of DHCP options. years since have seen a steady growth in the number of DHCP options.
The Simple Network Management Protocol (SNMP) [RFC3410] was designed The Simple Network Management Protocol (SNMP) [RFC3410] was designed
to convey management information between SNMP entities such as to convey management information between SNMP entities such as
managers and agents. The number of SNMP MIB modules grew steadily, managers and agents. The number of SNMP MIB modules grew steadily,
but SNMP has not historically seen only limited use for configuration but SNMP has historically seen only limited use for configuration
[RFC3535]. For a period, IETF configuration efforts were focussed on [RFC3535]. For a period, IETF configuration efforts were focussed on
the distribution of policy in the network. [RFC3139] provides a good the distribution of policy information in the network. [RFC3139]
insight into this period. More recently, NETCONF [RFC4741] was provides a good insight into this period. More recently, the network
devised as an alternative to SNMP, but the development of standard configuration protocol NETCONF [RFC6241] was devised as an
NETCONF data models is just beginning. alternative to SNMP, but the development of standard NETCONF
configuration data models is just beginning.
Recent IETF work closest in spirit to the 3GPP self-organizing Recent IETF work closest in spirit to the 3GPP self-organizing
network effort cited above is embodied in CAPWAP [RFC5415]. Like the network effort cited above is embodied in CAPWAP [RFC5415]. Like the
3GPP work, CAPWAP focusses on the configuration of edge nodes, in a 3GPP work, CAPWAP focusses on the configuration of edge nodes, in a
Wi-Fi rather than cellular network. The CAPWAP work goes beyond that Wi-Fi rather than cellular network. The CAPWAP work goes beyond that
of 3GPP by specifying the process of AC (Access Controller) discovery of 3GPP by specifying the process of AC (Access Controller) discovery
rather than leaving discovery out of scope. With regard to the rather than leaving discovery out of scope. With regard to the
configuration process itself, CAPWAP provides for the download of new configuration process itself, CAPWAP provides for the download of new
images to the WTP (Wireless Termination Point). In contrast, images to the WTP (Wireless Termination Point). In contrast,
[TS_32_500] assumes that this has already been completed for the [TS_32_500] assumes that this has already been completed for the
eNodeB. eNodeB.
2. Scenarios 2. Intra-domain and Inter-domain Scenarios
There are two different scenarios to consider. In the first There are two different scenarios to consider. In the first
scenario, called the Intra-domain Scenario, the new network device N scenario, called the Intra-domain Scenario, the new network device N
is attached to the network operated by the service provider which is is attached to the network operated by the service provider which is
also operating the new device. In the second scenario, called the also operating the new device. In the second scenario, called the
Inter-domain Scenario, the new device N is attached to a third party Inter-domain Scenario, the new device N is attached to a third party
network providing connectivity to the network of the service provider network providing connectivity to the network of the service provider
operating the new device. operating the new device.
+------+ +------+
skipping to change at page 4, line 43 skipping to change at page 5, line 22
| DNS | | DHCP | | DNS | | DHCP |
+-----+ +------+ +-----+ +------+
|-- N's Service Provider --| |-- N's Service Provider --|
Figure 1: Intra-domain Scenario Figure 1: Intra-domain Scenario
Figure 1 depicts the Intra-domain Scenario. We assume that the new Figure 1 depicts the Intra-domain Scenario. We assume that the new
decive N attaches to a link connected to router R. Furthermore, we decive N attaches to a link connected to router R. Furthermore, we
assume that the service provider provides a Domain Name System (DNS) assume that the service provider provides a Domain Name System (DNS)
server, a DHCP server, and a Configuration Server (CONF). Overall, server, a reachable DHCP server, and a Configuration Server (CONF).
this scenario does not differ much from conventional network Overall, this scenario does not differ much from conventional network
scenarios. scenarios.
+------+ +------+
| CONF | | CONF |
+--+---+ +--+---+
+---+ +---+ +---+ | +---+ +---+ +---+ |
| N +-...-+ R +-----+---+---+-----...-+ R +-----+---+---+-----... | N +-...-+ R +-----+---+---+-----...-+ R +-----+---+---+-----...
+---+ +---+ | | +---+ | | +---+ +---+ | | +---+ | |
+--+--+ +--+---+ +--+--+ +--+---+ +--+--+ +--+---+ +--+--+ +--+---+
| DNS | | DHCP | | DNS | | DHCP | | DNS | | DHCP | | DNS | | DHCP |
+-----+ +------+ +-----+ +------+ +-----+ +------+ +-----+ +------+
|-- Service Provider X ---| |-- N's Service Provider --| |-- Service Provider X ---| |-- N's Service Provider --|
Figure 2: Inter-domain Scenario Figure 2: Inter-domain Scenario
Figure 2 depicts the Inter-domain Scenario where the new device N Figure 2 depicts the Inter-domain Scenario where the new device N
attaches to a router R owned by a different service provider X. The attaches to a router R owned by a different service provider X. The
service provider X might offer its own DNS and DHCP services. We service provider X might offer its own DNS service and a reachable
assume that the service provider X has connectivity to the service DHCP service. We assume that the service provider X has connectivity
provider planning to operate the new device. to the service provider planning to operate the new device.
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.
In both scenarios, the new device N is either directly reachable or In both scenarios, the new device N is either directly reachable or
it may be behind a middlebox such as a NAT or a firewall. it may be behind a middlebox such as a Network Address Translator
Middleboxes may impose restrictions on which party is able to (NAT) or a firewall. Middleboxes may impose restrictions on which
initiate communication. party is able to initiate communication. As detailed in
[I-D.kwatsen-reverse-ssh], it is often desirable to allow device-
initiated connections.
3. A Model of the Process 3. Model of the Automated Configuration Process
We introduce a model of the configuration process in order to We introduce a model of the configuration process in order to
identify the parts that have well-known solutions. The remainder may identify the parts that have well-known solutions. The remainder may
be worth studying to see if the industry can agree on a solution. be worth studying to see if the industry can agree on a solution.
Some basic terminology is needed for the discussion. Depending on Some basic terminology is needed for the discussion. Depending on
the implementation, let us agree that "configuration data" consist of the implementation, let us agree that "configuration data" consist of
software and sets of configured parameters in some combination. software and sets of configured parameters in some combination. This
Also, the system that provides the configuration data is called the includes firmware, licenses, certificates, and other configuration
"configuration server". Finally, the term "joining device" is used data. Also, the system that provides the configuration data is
to denote a network device that is in the process of being called the "configuration server". Finally, the term "joining
incorporated into the network. device" is used to denote a network device that is in the process of
being incorporated into the network.
Broadly speaking, the configuration process can be broken into five Broadly speaking, the configuration process can be broken into five
phases: phases:
Pre-configuration: configuration carried out either by the vendor or 1. Pre-configuration: configuration carried out either by the vendor
by the service provider prior to physical installation. One or by the service provider prior to physical installation. One
possible example is the pre-provisioning of certificates, as possible example is the pre-configuration of certificates or
described in [RFC5415]. licenses or specific firmware.
Bootstrapping: the portion of the process from the time that 2. Bootstrapping: the portion of the process from the time that
physical installation is complete until a secure connection is physical installation is complete until a secure connection is
established between the joining device and the configuration established between the joining device and the configuration
server. server.
Initial configuration: downloading of the configuration data that 3. Initial configuration: downloading of the configuration data that
the joining device needs to carry out its function in the network. the joining device needs to carry out its function in the
network.
Auditing of installed configuration: tracking image versions and 4. Configuration auditing: tracking image versions and configuration
configuration parameters for each network device and verifying parameters for each network device and verifying that the
that the installed configuration data matches the physical installed configuration data matches the physical installation,
installation, the network plan, and the records of what data was the network plan, and the records of what data was downloaded.
downloaded. It is possible that an initial audit of the physical It is possible that an initial audit of the physical installation
installation is done before initial configuration, so that the is done before initial configuration, so that the validity of the
validity of the intended download can be verified. intended download can be verified.
Configuration update: transferring configuration data to a fully 5. Configuration update: transferring configuration data to a fully
configured and operating device from time to time as the need configured and operating device from time to time as the need
arises. arises.
4. Pre-configuration 4. Phase 1: Pre-configuration
This memo identifies a specific requirement for pre-configuration of This memo identifies a specific requirement for pre-configuration of
an invariant device identity and authentication-related material in an invariant device identity and authentication-related material in
the form of pre-shared secrets or certificates. There is, as one the form of pre-shared secrets or certificates. There is, as one
alternative, a requirement for pre-configuration of information that alternative, also a requirement for pre-configuration of information
permits the joining device to discover the address of the that permits the joining device to discover the address of the
configuration server. configuration server.
5. Bootstrapping 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.
5. Phase 2: Bootstrapping
[I-D.sarikaya-core-sbootstrapping] deals with the process of security [I-D.sarikaya-core-sbootstrapping] deals with the process of security
bootstrapping, with particular emphasis on the requirements for bootstrapping, with particular emphasis on the requirements for
highly resource-constrained devices. The document makes a highly resource-constrained devices. The document makes a
distinction between a data channel, which is used during network distinction between a data channel, which is used during network
operation, and a control channel, which is used during bootstrapping. operation, and a control channel, which is used during bootstrapping.
While both channels can be the same physical channel, they can also While both channels can be the same physical channel, they can also
be different (e.g., a wireless access point using an infrared control be different (e.g., a wireless access point using an infrared control
channel to receive bootstrapping information). The draft discusses a channel to receive bootstrapping information). The draft discusses a
number of possible security bootstrapping protocols for resource number of possible security bootstrapping protocols for resource
constrained devices that can be executed in several bootstrapping constrained devices that can be executed in several bootstrapping
rounds and can be adapted to the specific contexts in terms of the rounds and can be adapted to the specific contexts in terms of the
resources available within individual devices and for the network as resources available within individual devices and for the network as
a whole. a whole.
For network devices in service provider networks, bootstrapping For network devices in service provider networks or large enterprise
consists of several stages: networks, bootstrapping consists of several stages:
1. establishment of link layer connectivity with neighbouring nodes; 1. establishment of link layer connectivity with neighbouring nodes;
2. acquisition of IP addresses and basic routing information; 2. acquisition of IP addresses and basic routing information;
3. discovery of the configuration server; 3. discovery of the configuration server;
4. establishment of a secure channel to the configuration server. 4. establishment of a secure channel to the configuration server.
Each of these stages is further discussed below.
5.1. Establishment of Link Layer Connectivity 5.1. Establishment of Link Layer Connectivity
The protocol aspects of this phase are out of scope, since it The protocol aspects of this phase are out of scope, since it
involves non-IETF protocols only. While some link-layer technologies involves non-IETF protocols only. While some link-layer technologies
may provide authentication and access control, this cannot be assumed may provide authentication and access control, this cannot be assumed
to be available in the general case. to be available in the general case.
5.2. Acquisition of IP Addresses and Basic Routing Information 5.2. Acquisition of IP Addresses and Basic Routing Information
For IPv4, DHCPv4 [RFC2131] is widely deployed and the usual way to For IPv4, DHCPv4 [RFC2131] is widely deployed and the usual way to
skipping to change at page 7, line 39 skipping to change at page 8, line 30
server addresses. A routing advertisement option to configure the server addresses. A routing advertisement option to configure the
IPv6 address of a DNS server as part of the stateless address IPv6 address of a DNS server as part of the stateless address
autoconfiguration is defined in [RFC6106]. autoconfiguration is defined in [RFC6106].
Some security protection is provided in this stage by using DHCP Some security protection is provided in this stage by using DHCP
authentication [RFC3118]. However, security of the configuration authentication [RFC3118]. However, security of the configuration
process as a whole has to be assured by other means. This is process as a whole has to be assured by other means. This is
discussed further below. discussed further below.
Currently the lack of a stable identifier for use in DHCPv6 messaging Currently the lack of a stable identifier for use in DHCPv6 messaging
is an impediment to authentication of the joining device. is an impediment to authentication of the joining device. [RFC6355]
[I-D.ietf-dhc-duid-uuid] discusses the problems with the current discusses the problems with the current DHCPv6 identifiers (DUIDs)
DHCPv6 identifiers (DUIDs) and proposes a new form that could be a and proposes a new form that could be a more stable alternative.
more stable alternative.
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.
5.3. Finding the Configuration Server 5.3. Finding the Configuration Server
Four alternatives are available for finding the configuration server: Four alternatives are available for finding the configuration server:
o pre-configuration; o pre-configuration;
o DHCP configuration; o DHCP configuration;
o Service Location Protocol [RFC2608]; or
o DNS service discovery using SRV records [RFC2782]. o Service Location Protocol [RFC2608]; or
o DNS service discovery using DNS SRV records [RFC2782].
Pre-configuration of an IP address is brittle and not recommended. Pre-configuration of an IP address is brittle and not recommended.
Pre-configuration of a Uniform Resource Identifier (URI) or fully The pre-configuration of a Uniform Resource Identifier (URI) or fully
qualified domain name (FQDN) is a better approach. One variant that qualified domain name (FQDN) is a slightly better approach since this
has been suggested is to burn the URI of a vendor server into the allows for a limited dynamic mapping of the name to an IP address.
device's firmware along with a device identifier, and have that One variant that has been suggested is to burn the URI of a vendor
server redirect to the URI of the service provider's configuration server into the device's firmware along with a device identifier, and
server based on the device identity. Such an approach requires that have that server redirect to the URI of the service provider's
a device vendor offers such a service for the lifetime of their configuration server based on the device identity. Such an approach
devices and that service providers are able to update the URI of the requires that the device vendor's redirection server is always
service provider's configuration server. This requires a trust reachable, that the device vendor offers such a redirection service
relationship between the vendor and the service provider and for the lifetime of their devices and that service providers are able
agreement on a protocol to update the redirect information on the to update the URI of the service provider's redirection server.
vendor's 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.
DHCP configuration can use the usual DHCP options and is technically DHCP configuration can use the usual DHCP options and is technically
straightforward since DHCP is widely used by end user devices to straightforward since DHCP is widely used by end user devices to
obtain basic configuration information. There is, however, no obtain basic configuration information. There is, however, no
standardized DHCP option to communicate the address of a standardized DHCP option to communicate the address of a
configuration server. configuration server.
The Service Location Protocol (SLP) has seen some usage to locate The Service Location Protocol (SLP) has seen some usage to locate
services such as printers or file system shares. Usage of SLP to services such as printers or file system shares. Usage of SLP to
locate configuration servers requires to define a new service locate configuration servers requires to define a new service
template [RFC2609]. template [RFC2609].
The use of DNS SRV records requires the joining device to obtain the The use of DNS SRV records requires the joining device to obtain the
correct domain suffix first, presumably from DHCP or via Routing correct domain suffix first, presumably from DHCP or via Routing
Advertisements in the case of IPv6 or preconfiguration. A service Advertisements in the case of IPv6 or pre-configuration. A service
type for the desired configuration protocol would have to be defined type for the desired configuration protocol would have to be defined
in the DNS for the purpose. See Section 3.3 of [RFC5415] for a in the DNS for the purpose. See Section 3.3 of [RFC5415] for a
discussion of the corresponding discovery process for CAPWAP. discussion of the corresponding discovery process for CAPWAP.
The Inter-domain Scenario requires that the DHCP server or the SLP 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 server of service provider X's network is able to provide the correct
information to the joining devices. To accomplish this, the information to the joining devices. To accomplish this, the
discovery servers need to be able to match a device identification discovery servers need to be able to match a device identification
against a list of possible configuration servers. Furthermore, there against a list of possible configuration servers. Furthermore, there
needs to be a mechanism for the service provider operating the needs to be a mechanism for the service provider operating the
joining device to provision the configuration server's address, e.g. joining device to provision the configuration server's address, e.g.,
by using an extension of the Extensible Provisioning Protocol (EPP) by using an extension of the Extensible Provisioning Protocol (EPP)
[RFC5730]. However, if the joining device has preconfigured
[RFC5730]. However, if the joining device has pre-configured
information about the name of the service provider's network, DNS SRV information about the name of the service provider's network, DNS SRV
records may be queried after obtaining IP connectivity, avoiding the records may be queried after obtaining IP connectivity, avoiding the
need to provision information in service provider X's network. need to provision information in service provider X's network.
5.4. Establishing a Secure Channel to the Configuration Server 5.4. Establishing a Secure Channel to the Configuration Server
It is essential that the configuration server and the joining device It is essential that the configuration server and the joining device
authenticate themselves to each other, since the steps leading up to authenticate themselves to each other, since the steps leading up to
this point in the process may not be fully secure. This raises two this point in the process may not be fully secure. This raises two
issues: how the joining device identifies itself, and how issues: how the joining device identifies itself, and how
authentication takes place. authentication takes place.
It seems best if the device has an invariant identity built in and It seems best if the device has an invariant identity built in and
accessible to whatever operating system is running on it. If accessible to whatever operating system is running on it. [RFC6355]
[I-D.ietf-dhc-duid-uuid], mentioned above, becomes a standard, the provides such an identity in the form of a Universally Unique
UUID on which that proposal is based would be the required invariant IDentifier (UUID). The vendor should make that identity available in
identity. The vendor should make that identity available in a form a form that can be read and transferred into a database accessible to
that can be read and transferred into a database accessible to the the configuration server along with the associated configuration data
configuration server along with the associated configuration data in in advance of the bootstrapping stage (e.g., in bar-coded format on
advance of the bootstrapping stage (e.g., in bar-coded format on the the device packaging).
device packaging).
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.
This leaves the mutual authentication process itself. This has two This leaves the mutual authentication process itself. This has two
aspects: the security protocol used to perform authentication, and aspects: the security protocol used to perform authentication, and
initial keying methodology. The security protocol is tied together initial keying methodology. The security protocol is tied together
with the choice of configuration data transport, but the basic with the choice of configuration data transport, but the basic
choices are: choices are:
o IP Security (IPsec) [RFC4301]; o IP Security (IPsec) [RFC4301];
o Transport Layer Security (TLS) [RFC5246]; o Transport Layer Security (TLS) [RFC5246];
skipping to change at page 9, line 50 skipping to change at page 11, line 12
For initial keying methodology, the two basic choices are between For initial keying methodology, the two basic choices are between
pre-shared secrets and certificates. All of the security protocols pre-shared secrets and certificates. All of the security protocols
listed above except USM support both methods. USM supports pre- listed above except USM support both methods. USM supports pre-
shared secrets only. shared secrets only.
The usual concern with pre-shared secrets is scalability. In the The usual concern with pre-shared secrets is scalability. In the
bootstrapping case, the scale of operation required is linear with bootstrapping case, the scale of operation required is linear with
the number of devices to be configured, so it would definitely be a the number of devices to be configured, so it would definitely be a
feasible approach if connection to the configuration system were the feasible approach if connection to the configuration system were the
only consideration. The most likely procedure would be for the only consideration. The most likely procedure would be for the
secret to be configured in the device during preconfiguration and secret to be configured in the device during pre-configuration and
also captured in a database along with the device identity, for use also captured in a database along with the device identity, for use
by the configuration server. by the configuration server.
The problem with the use of pre-shared secrets is that the device The problem with the use of pre-shared secrets is that the device
needs to authenticate itself at an earlier stage, while it is needs to authenticate itself at an earlier stage, while it is
establishing communications with its neighbours and acquiring IP establishing communications with its neighbours and acquiring IP
addresses. It seems undesirable to use the same secret for that addresses. It seems undesirable to use the same secret that is used
purpose as for the connection to the configuration server, on the to authenticate the device to the configuration server for that
basic principle of limiting the potential damage from disclosure of a purpose as well, on the basic principle of limiting the potential
particular key. damage from disclosure of a particular key.
This need for additional pre-shared secrets argues for consideration This need for additional pre-shared secrets argues for consideration
of certificates as an alternative. One issue for certificates is of certificates as an alternative. One issue for certificates is
where the trust anchor resides. It seems logical that it should where the trust anchor resides. It seems logical that it should
reside with the service provider rather than the vendor, to make it reside with the service provider rather than the vendor, to make it
easy to install equipment from multiple vendors. On that basis, easy to install equipment from multiple vendors. On that basis, pre-
preconfiguration requires service provider input. 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.
CAPWAP (Section 2.4.4.3 of [RFC5415]) makes use of the Extended Key CAPWAP (Section 2.4.4.3 of [RFC5415]) makes use of the Extended Key
Usage (EKU) certificate extension [RFC5280] to distinguish Usage (EKU) certificate extension [RFC5280] to distinguish
certificates identifying the Access Controllers (i.e., the certificates identifying the Access Controllers (i.e., the
configuration servers in the CAPWAP case) from the Wireless Transfer configuration servers in the CAPWAP case) from the Wireless Transfer
Points (the configured devices in the CAPWAP case). Thought should Points (the configured devices in the CAPWAP case). Thought should
be given to whether such distinctions are required in the general be given to whether such distinctions are required in the general
case of network device configuration. case of network device configuration.
CAPWAP (Section 12.8 of [RFC5415]) also discusses the use of the CAPWAP (Section 12.8 of [RFC5415]) also discusses the use of the
Common Name rather than SubjectAltName field of the certificate to Common Name rather than SubjectAltName field of the certificate to
carry device identity, due to lack of specifications allowing the use carry device identity, due to lack of a Uniform Resource Name (URN)
of SubjectAltName to carry MAC addresses. This issue needs to be specification allowing the use of SubjectAltName to carry MAC
investigated further if another form of device unique identity is addresses. This encoding of device identifiers in certifications
used, as discussed above. needs to be investigated further if a new form of device unique
identity is used, as discussed above.
Middleboxes such as NATs or firewalls may impose restriction on which Middleboxes such as NATs or firewalls may impose restriction on which
party is able to initiate communication. In the common case of NATs party is able to initiate communication. In the common case of NATs
in IPv4 access networks, communication can only be established from in IPv4 access networks, communication can only be established from
the device to the configuration server. Not all secure transports, the device to the configuration server. Not all secure transports,
in particular those where authentication is not symmetric, support in particular those where authentication is not symmetric, support
this "call home" mode of operation. A recent proposal to reverse the this "call home" mode of operation. A recent proposal to reverse the
establishment of the TCP connection for SSH can be found in establishment of the TCP connection for SSH can be found in
[I-D.kwatsen-reverse-ssh]. [I-D.kwatsen-reverse-ssh].
6. Initial Configuration and Configuration Updates 6. Phase 3: Initial Configuration
As mentioned at the beginning, the configuration data being As mentioned at the beginning, the configuration data being
downloaded may be a combination of software and configuration downloaded may be a combination of software/firmware and
parameters. Some of the data will be vendor-specific, not subject to configuration parameters. Some of the data will be vendor-specific
standardization. It appears that there is a continuing debate on and not subject to standardization. It appears that there is a
whether the configuration data should be pushed to the joining device continuing debate on whether the configuration data should be pushed
or whether the device should pull the configuration data down. In to the joining device or whether the device should pull the
the latter case, the device needs to know about the existence of the configuration data from the configuration server. In the latter
data and the path to reach it before it can act. One way to acquire case, the device needs to know about the existence of the data and
this information is through DHCP. DHCPv4 has provided the necessary 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 options from its beginnings, inheriting them from BOOTP. They have
been recently added to DHCPv6 [RFC5970]. been recently added to DHCPv6 [RFC5970].
Protocols that can transport configuration data can be classified as Protocols that can transport configuration data can be classified as
follows: The first class consists of generic file transfer protocols follows: The first class consists of generic file transfer protocols
that can carry configuration data serialized into configuration that can carry configuration data serialized into configuration
files. The second class consists of protocols that manipulate files. The second class consists of protocols that manipulate
structured configuration data directly. The structure of the structured configuration data directly. The structure of the
configuration data is defined by some data model. configuration data is defined by some data model.
skipping to change at page 11, line 49 skipping to change at page 13, line 18
o The Control And Provisioning of Wireless Access Points (CAPWAP) o The Control And Provisioning of Wireless Access Points (CAPWAP)
protocol [RFC5415] can be used to control the download of images. protocol [RFC5415] can be used to control the download of images.
CAPWAP can be secured by running CAPWAP over DTLS. CAPWAP can be secured by running CAPWAP over DTLS.
In the second class, we find the following configuration protocols: In the second class, we find the following configuration protocols:
o Version 3 of the Simple Network Management Protocol (SNMPv3) o Version 3 of the Simple Network Management Protocol (SNMPv3)
[RFC3411]-[RFC3418] can be used to manipulate MIB objects and to [RFC3411]-[RFC3418] can be used to manipulate MIB objects and to
carry event notifications. It has its own security protocol (USM) carry event notifications. It has its own security protocol (USM)
but can also run over SSH [RFC5592], TLS, or DTLS [RFC5953]. but can also run over SSH [RFC5592], TLS, or DTLS [RFC6353].
o The Common Open Policy Service for Policy Provisioning protocol o The Common Open Policy Service for Policy Provisioning protocol
(COPS-PR) [RFC3084] was designed to provision structured policy (COPS-PR) [RFC3084] was designed to provision structured policy
information from a Policy Decision Point (PDP) to a Policy information from a Policy Decision Point (PDP) to a Policy
Enforcement Point (PEP). The COPS protocol [RFC2748] provides an Enforcement Point (PEP). The COPS protocol [RFC2748] provides an
integrity object that can achieve authentication, message integrity object that can achieve authentication, message
integrity, and replay prevention. Optionally, COPS and COPS-PR integrity, and replay prevention. Optionally, COPS and COPS-PR
can run over TLS. can run over TLS.
o The NETCONF protocol [RFC4741] provides mechanisms to install, o The NETCONF protocol [RFC6241] provides mechanisms to install,
manipulate, and delete the configuration of network devices. A manipulate, and delete the configuration of network devices. A
protocol extension provides an asychronous even notification protocol extension provides an asynchronous event notification
delivery mechanism [RFC5277]. NETCONF by default runs over SSH delivery mechanism [RFC5277]. NETCONF by default runs over SSH
but can also run over transports secured by TLS. but can also run over transports secured by TLS.
o The Control And Provisioning of Wireless Access Points protocol o The Control And Provisioning of Wireless Access Points protocol
(CAPWAP) [RFC5415] supports the discovery of so called Access (CAPWAP) [RFC5415] supports the discovery of so called Access
Controller (AC) by Wireless Termination Points (WTPs) and the Controller (AC) by Wireless Termination Points (WTPs) and the
configuration of WTPs by an AC. While CAPWAP can be extended to configuration of WTPs by an AC. While CAPWAP can be extended to
configure other devices, its main focus are WTPs. The CAPWAP configure other devices, its main focus are WTPs. The CAPWAP
protocol is protected by using DTLS after the discovery phase. protocol is protected by using DTLS after the discovery phase.
Table 1 lists the protocols plus their security options. Note that Table 1 lists the protocols plus their basic properties while Table 2
all protocols can be secured at the IP layer by using IPsec and hence lists the security options available for each protocol.
this is not mentioned explicitly in Table 1.
+-----------+--------------+----------------------------------------+ +-----------+-------------------------------------------------------+
| Transport | Security | Data Transfer Model | | Transport | Data Transfer Model |
+-----------+--------------+----------------------------------------+ +-----------+-------------------------------------------------------+
| FTP | TLS | Push or pull of (configuration) files | | FTP | Push or pull of (configuration) files |
| TFTP | | Push or pull of (configuration) files | | TFTP | Push or pull of (configuration) files |
| HTTP | TLS | Push or pull of (configuration) files | | HTTP | Push or pull of (configuration) files |
| SFTP | SSH | Push or pull of (configuration) files | | SFTP | Push or pull of (configuration) files |
| RCP | | Push or pull of (configuration) files | | RCP | Push or pull of (configuration) files |
| SCP | SSH | Push or pull of (configuration) files | | SCP | Push or pull of (configuration) files |
| CAPWAP | DTLS | AC pushes configuration parameters, | | CAPWAP | AC pushes configuration parameters, WTP pulls |
| | | WTP pulls software | | | software |
| SNMPv3 | USM [SSH, | Push of structured configuration | | SNMPv3 | Push of structured configuration parameters, event |
| | TLS, DTLS] | parameters, event notifications | | | notifications |
| COPS-PR | TLS | Push of structured policy information | | COPS-PR | Push of structured policy information |
| NETCONF | SSH [TLS] | Push of structured configuration data, | | NETCONF | Push of structured configuration data, event |
| | | event notifications | | | notifications |
+-----------+--------------+----------------------------------------+ +-----------+-------------------------------------------------------+
Table 1: Protocols for transporting configuration data Table 1: Protocols for transporting configuration data
+-----------+-------+-----+------+-----+-------+
| Transport | IPsec | TLS | DTLS | SSH | Other |
+-----------+-------+-----+------+-----+-------+
| FTP | + | + | | | |
| TFTP | + | | | | |
| HTTP | + | + | | | |
| SFTP | + | | | + | |
| RCP | + | | | | |
| SCP | + | | | + | |
| CAPWAP | + | | + | | |
| SNMPv3 | + | + | + | + | USM |
| COPS-PR | + | + | | | |
| NETCONF | + | + | | + | |
+-----------+-------+-----+------+-----+-------+
Table 2: Security options for configuration transport protocols
SNMPv3, NETCONF, and COPS-PR carry structured data specified in pre- SNMPv3, NETCONF, and COPS-PR carry structured data specified in pre-
defined data models. SNMPv3 and COPS-PR have size limitations on the defined data models. SNMPv3 and COPS-PR have size limitations on the
data objects and thus make the transport of larger software images data objects and thus make the transport of larger software images
difficult. NETCONF does not suffer from hard size restrictions and difficult. NETCONF does not suffer from hard size restrictions and
can in principle carry software images inline. However, there is can in principle carry software images inline. However, there is
currently no work in progress to standardize the transfer of software currently no work in progress to standardize the transfer of software
images over NETCONF. An advantage of NETCONF over SNMPv3 and CAPWAP images over NETCONF. CAPWAP combines the functions of configuration
is the support or concurrent updates through locking mechanisms and parameter transport and software download. The parameter transport
the support of network wide configuration change transactions through aspect lacks the generality offered by SNMP, NETCONF, and COPS-PR,
the confirmed commit capability. CAPWAP combines the functions of since the parameters are specified within the protocol specification
configuration parameter transport and software download. The itself. The remaining transports are independent of the nature of
parameter transport aspect lacks the generality offered by SNMP, the information being transferred.
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.
7. Configuration Auditing 7. Phase 4: Configuration Auditing
To complete the process, it must be possible to audit the To complete the process, it must be possible to audit the
configuration status of the device in some detail. This is likely to configuration status of the device in some detail. This is likely to
begin even before all the configuration data has been downloaded. begin even before all the configuration data has been downloaded.
For instance, configuration management may wish to collect basic For instance, configuration management may wish to collect basic
information such as the MAC addresses of the device's interfaces, the information such as the MAC addresses of the device's interfaces, the
link-local addresses assigned to them, and similar information for link-local addresses assigned to them, and similar information for
the neighbours of the joining device. the neighbours of the joining device.
SNMP and SNMP MIB modules are obviously one way to collect this SNMP and SNMP MIB modules are obviously one way to collect this
information. NETCONF [RFC4741] is an alternative, but the necessary information. NETCONF [RFC6241] is an alternative, but the necessary
data models have to be defined. YANG modules for NETCONF [RFC6020] data models have to be defined. YANG modules for NETCONF [RFC6020]
can be prepared relatively quickly from existing SNMP MIB modules by can be generated from existing SNMP MIB modules by translating the
translating the SNMP modules into YANG modules. Work to standardize SNMP modules into YANG modules [I-D.ietf-netmod-smi-yang].
such translations is currently being chartered in the NETMOD working
group.
Another important auditing activity is the analysis of system events. Another important auditing activity is the analysis of system events.
The SYSLOG protocol [RFC5424] is widely used for this purpose but The SYSLOG protocol [RFC5424] is widely used for this purpose but
SNMPv3 and NETCONF can ship event notifications as well. SNMPv3 and NETCONF can ship event notifications as well.
Translations of SNMP notifications into structured SYSLOG messages Translations of SNMP notifications into structured SYSLOG messages
and vice versa do exist [RFC5675] [RFC5676]. NETCONF can carry and vice versa do exist [RFC5675] [RFC5676]. NETCONF can carry
SYSLOG content as well [RFC5277]. SYSLOG content as well [RFC5277].
8. Missing Specifications NETCONF provides generic notifications that help with tracking
configuration changes [I-D.ietf-netconf-system-notifications].
Similar standardized configuration change notifications do not exist
for SNMP or SYSLOG.
8. Phase 5: Configuration Update
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.
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.
9. Missing Specifications
This document discussed the automated configuration of devices in This document discussed the automated configuration of devices in
service provider networks. Several gaps were identified requiring service provider networks. Several gaps were identified requiring
further specification: further specification:
G1: Definition of stable unique device identifiers such as the work G1: Definition of a DHCP option to provide the IPv4/IPv6 address of
described in [I-D.ietf-dhc-duid-uuid].
G2: Definition of a DHCP option to provide the IPv4/IPv6 address of
a configuration server. Such an option allows a joining device a configuration server. Such an option allows a joining device
to pickup the configuration server's address as part of the DHCP to pickup the configuration server's address as part of the DHCP
exchange. This is particularly interesting for Intra-domain exchange. This is particularly interesting for Intra-domain
Scenarios. Scenarios.
G3: Definition of DNS SRV records for locating configuration G2: Definition of DNS SRV records for locating configuration
servers. Such an option allows a joining device to lookup the servers. Such an option allows a joining device to lookup the
configuration server's in the DNS; this is particularly useful configuration server's in the DNS; this is particularly useful
in an Inter-domain Scenario. in an Inter-domain Scenario.
G4: Definition of a SLP template for discovering configuration G3: Definition of a SLP template for discovering configuration
servers. Such a template is useful only in environments where servers. Such a template is useful only in environments where
SLP is used also for other purposes. SLP is used also for other purposes.
G5: Definition of NETCONF data models to support the download / G4: Definition of NETCONF data models to support the download /
update of software images through NETCONF. update of software images through NETCONF.
G6: Definition of NETCONF data models for collecting basic system G5: Definition of NETCONF data models for collecting basic system
information and integrity information (e.g., checksums of information and integrity information (e.g., checksums of
software images) and for sending configuration management software images).
related notifications.
G7: Some management protocols do not provide mechanisms for devices G6: Some management protocols lack a mechanisms for devices to
to initiate a secure communication channel with a management initiate a secure communication channel with a management system
system ("call home"). ("call home").
9. Security Considerations 10. Security Considerations
The security of a configuration management solution is of crucial The security of a configuration management solution is of crucial
importance. Section 6 discusses the security options of several importance. Section 6 discusses the security options of several
protocols that might be used. The relevant protocol definitions protocols that might be used. The relevant protocol definitions
should be consulted to learn more about the specific security aspects should be consulted to learn more about the specific security aspects
of the various protocols. of the various protocols.
It should be noted that some steps in the described process, in It should be noted that some steps in the described process, in
particular the bootstrapping phase, may not be secure and it is thus particular the bootstrapping phase, may not be secure and it is thus
important to verify the identity of the device and the identity of important to verify the identity of the device and the identity of
skipping to change at page 15, line 17 skipping to change at page 17, line 20
security management of the configuration system. security management of the configuration system.
While [I-D.sarikaya-core-sbootstrapping] discusses security While [I-D.sarikaya-core-sbootstrapping] discusses security
bootstrapping mechanisms in the context of constrained devices, many bootstrapping mechanisms in the context of constrained devices, many
of the mechanisms are also applicable for bootstrapping security in of the mechanisms are also applicable for bootstrapping security in
normal devices. normal devices.
Finally, [RFC6092] discusses security capabilities for customer Finally, [RFC6092] discusses security capabilities for customer
premises equipment providing residential IPv6 Internet service. premises equipment providing residential IPv6 Internet service.
10. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Contributors 12. Acknowledgements
Thanks to Mehmet Ersue, Yiu Lee, and Cathy Zhou for their help in Thanks to Mehmet Ersue, Wesley George, Yiu Lee, Kent Watsen, and
preparing this memo. Cathy Zhou for their help in preparing this memo.
12. Informative References 13. Informative References
[I-D.ietf-dhc-duid-uuid] [I-D.ietf-netconf-system-notifications]
Narten, T. and J. Johnson, "Definition of the UUID-based Bierman, A., "Network Configuration Protocol (NETCONF)
DHCPv6 Unique Identifier (DUID-UUID)", Base Notifications",
draft-ietf-dhc-duid-uuid-03 (work in progress), draft-ietf-netconf-system-notifications-06 (work in
February 2011. progress), October 2011.
[I-D.ietf-netmod-smi-yang]
Schoenwaelder, J., "Translation of SMIv2 MIB Modules to
YANG Modules", draft-ietf-netmod-smi-yang-01 (work in
progress), July 2011.
[I-D.ietf-secsh-filexfer] [I-D.ietf-secsh-filexfer]
Galbraith, J. and O. Saarenmaa, "SSH File Transfer Galbraith, J. and O. Saarenmaa, "SSH File Transfer
Protocol", draft-ietf-secsh-filexfer-13 (work in Protocol", draft-ietf-secsh-filexfer-13 (work in
progress), July 2006. progress), July 2006.
[I-D.kwatsen-reverse-ssh] [I-D.kwatsen-reverse-ssh]
Watsen, K., "Reverse Secure Shell (Reverse SSH)", Watsen, K., "Reverse Secure Shell (Reverse SSH)",
draft-kwatsen-reverse-ssh-00 (work in progress), May 2011. draft-kwatsen-reverse-ssh-01 (work in progress),
June 2011.
[I-D.sarikaya-core-sbootstrapping] [I-D.sarikaya-core-sbootstrapping]
Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
Bootstrapping of Resource-Constrained Devices", Cragie, "Security Bootstrapping of Resource-Constrained
draft-sarikaya-core-sbootstrapping-01 (work in progress), Devices", draft-sarikaya-core-sbootstrapping-02 (work in
January 2011. progress), June 2011.
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. September 1985.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992. RFC 1350, July 1992.
[RFC1531] Droms, R., "Dynamic Host Configuration Protocol", [RFC1541] Droms, R., "Dynamic Host Configuration Protocol",
RFC 1531, October 1993. RFC 1541, October 1993.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, "Service Location Protocol, Version 2", RFC 2608,
June 1999. June 1999.
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999. and Service: Schemes", RFC 2609, June 1999.
skipping to change at page 18, line 8 skipping to change at page 20, line 15
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006. Connection Protocol", RFC 4254, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
skipping to change at page 18, line 47 skipping to change at page 20, line 51
Messages", RFC 5675, October 2009. Messages", RFC 5675, October 2009.
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar,
"Definitions of Managed Objects for Mapping SYSLOG "Definitions of Managed Objects for Mapping SYSLOG
Messages to Simple Network Management Protocol (SNMP) Messages to Simple Network Management Protocol (SNMP)
Notifications", RFC 5676, October 2009. Notifications", RFC 5676, October 2009.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009. STD 69, RFC 5730, August 2009.
[RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
RFC 5953, August 2010.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, September 2010. Options for Network Boot", RFC 5970, September 2010.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, Residential IPv6 Internet Service", RFC 6092,
January 2011. January 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, November 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
August 2011.
[TR_069] Blackford, J., Ed., Kirksey, H., Ed., and W. Lupton, Ed., [TR_069] Blackford, J., Ed., Kirksey, H., Ed., and W. Lupton, Ed.,
"CPE WAN Management Protocol", Broadband Forum TR-069, "CPE WAN Management Protocol", Broadband Forum TR-069,
November 2010. November 2010.
[TS_32_500] [TS_32_500]
3rd Generation Partnership Project, "3rd Generation 3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group Partnership Project; Technical Specification Group
Services and System Aspects; Telecommunication Management; Services and System Aspects; Telecommunication Management;
Self-Organizing Networks (SON); Concepts and requirements Self-Organizing Networks (SON); Concepts and requirements
(Release 9)", 3GPP TS 32.500, 2010. (Release 9)", 3GPP TS 32.500, 2010.
[TS_36_300] [TS_36_300]
3rd Generation Partnership Project, "3rd Generation 3rd Generation Partnership Project, "3rd Generation
Partnership Project; Technical Specification Group Radio Partnership Project; Technical Specification Group Radio
Access Network; Evolved Universal Terrestrial Radio Access Access Network; Evolved Universal Terrestrial Radio Access
(E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access
Network (E-UTRAN); Overall description; Stage 2 (Release Network (E-UTRAN); Overall description; Stage 2 (Release
9)", 3GPP TS 36.300, 2010. 9)", 3GPP TS 36.300, 2010.
Appendix A. Changes since -01
Incorporated feedback from Kent Watsen and Wesley George.
Editorial improvements, updated references, etc.
Authors' Addresses Authors' Addresses
Tina Tsou Tina Tsou
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China P.R. China
Email: tena@huawei.com Email: tena@huawei.com
Juergen Schoenwaelder (editor) Juergen Schoenwaelder (editor)
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
Bremen 28759 Bremen 28759
Germany Germany
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
Yang Shi Yang Shi
Hangzhou H3C Tech. Co., Ltd. Hangzhou H3C Tech. Co., Ltd.
 End of changes. 79 change blocks. 
214 lines changed or deleted 319 lines changed or added

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