draft-ietf-opsawg-automated-network-configuration-04.txt   draft-ietf-opsawg-automated-network-configuration-05.txt 
Internet Engineering Task Force T. Tsou Operations Area Working Group T. Tsou
Internet-Draft Huawei Technologies (USA) Internet-Draft Huawei Technologies (USA)
Intended status: Informational J. Schoenwaelder, Ed. Intended status: Informational J. Schoenwaelder, Ed.
Expires: January 18, 2013 Jacobs University Bremen Expires: July 27, 2013 Jacobs University Bremen
Y. Shi Y. Shi
T. Taylor, Ed. T. Taylor
Huawei Technologies Huawei Technologies
G. Yang G. Yang
China Telecom China Telecom
July 17, 2012 January 23, 2013
Problem Statement for the Automated Configuration of Large IP Networks Survey of Possibilities for the Automated Configuration of Large IP
draft-ietf-opsawg-automated-network-configuration-04 Networks
draft-ietf-opsawg-automated-network-configuration-05
Abstract Abstract
This memo discusses the steps required to bring a large number of This memo discusses the steps required to bring a large number of
devices into service in IP networks in an automated fashion. The devices into service in IP networks in an automated fashion. The
goal of this document is to list known solutions where they exist, to goal of this document is to list known solutions where they exist, to
point out approaches proven to be problematic, and to identify gaps point out approaches proven to be problematic, and to identify gaps
that require further specifications. that require further specifications.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 18, 2013. This Internet-Draft will expire on July 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 28 skipping to change at page 2, line 29
5.1. Establishment of Link Layer Connectivity . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 8 Information . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Finding the Configuration Server . . . . . . . . . . . . . 9 5.3. Finding the Configuration Server . . . . . . . . . . . . . 9
5.4. Establishing a Secure Channel to the Configuration 5.4. Establishing a Secure Channel to the Configuration
Server . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Phase 3: Initial Configuration . . . . . . . . . . . . . . . . 12 6. Phase 3: Initial Configuration . . . . . . . . . . . . . . . . 12
7. Phase 4: Configuration Auditing . . . . . . . . . . . . . . . 15 7. Phase 4: Configuration Auditing . . . . . . . . . . . . . . . 15
8. Phase 5: Configuration Update . . . . . . . . . . . . . . . . 16 8. Phase 5: Configuration Update . . . . . . . . . . . . . . . . 16
9. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 13. Informative References . . . . . . . . . . . . . . . . . . . . 18
14. Informative References . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Many large IP 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 to the maximum extent possible. This naturally raises the networks to the maximum extent possible. This naturally raises the
question how new devices can pick up the configuration information question how new devices can pick up the configuration information
they need to operate properly in an automated fashion. The goal of they need to operate properly in an automated fashion. The goal of
this document is to list known solutions where they exist, to point this document is to list known solutions where they exist, to point
skipping to change at page 4, line 23 skipping to change at page 4, line 23
Next to service provider networks, many large enterprise networks Next to service provider networks, many large enterprise networks
face the same challenge to roll out a large number of network face the same challenge to roll out a large number of network
devices, which often connect to a 3rd party network provider. The devices, which often connect to a 3rd party network provider. The
current development of IP-based home automation and utility current development of IP-based home automation and utility
monitoring technologies might carry the problem to roll out large monitoring technologies might carry the problem to roll out large
numbers of devices that need to automatically configure themselves to numbers of devices that need to automatically configure themselves to
private households. 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 [RFC1541] 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 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 information in the network. [RFC3139] the distribution of policy information in the network. [RFC3139]
provides a good insight into this period. More recently, the network provides a good insight into this period. More recently, the network
configuration protocol NETCONF [RFC6241] was devised as an configuration protocol NETCONF [RFC6241] was devised as an
alternative to SNMP, but the development of standard NETCONF alternative to SNMP, but the development of standard NETCONF
skipping to change at page 5, line 23 skipping to change at page 5, line 23
2. Intra-domain and Inter-domain 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.
+------+ +------+
| CONF | | CONF |
+--+---+ +--+---+
+---+ +---+ | +---+ +---+ |
| N +-...-+ R +------+---+---+----... | N +-...-+ R +------+---+---+----...
+---+ +---+ | | +---+ +---+ | |
+--+--+ +--+---+ +--+--+ +--+---+
| 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 device 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 reachable DHCP server, and a Configuration Server (CONF). server, a reachable DHCP server, and a Configuration Server (CONF).
Overall, 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 service and a reachable service provider X might offer its own DNS service and a reachable
DHCP service. We assume that the service provider X has connectivity DHCP service. We assume that the service provider X has connectivity
to the service 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 It should be noted that handing out DHCP options specific to N's
skipping to change at page 8, line 44 skipping to change at page 8, line 44
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
obtain an IPv4 address, the IPv4 address of a link-local router and 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 the IPv4 address of a DNS server. For IPv6, a choice has to be made
between stateful DHCPv6 [RFC3315] versus stateless DHCPv6 [RFC3736] between stateful DHCPv6 [RFC3315] versus stateless DHCPv6 [RFC3736]
combined with stateless address autoconfiguration [RFC4862]. In the combined with stateless address autoconfiguration [RFC4862]. In the
latter case, DHCPv6 is needed to configure parameters such as DNS latter case, DHCPv6 is needed to configure parameters such as DNS
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. [RFC6355] is an impediment to authentication of the joining device. [RFC6355]
discusses the problems with the current DHCPv6 identifiers (DUIDs) discusses the problems with the current DHCPv6 identifiers (DUIDs)
and proposes a new form that could be a more stable alternative. and proposes a new form that could be a more stable alternative.
A joining device can also choose to use a pre-configured IP address, 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 a pre-configured link-local router address and a pre- configured DNS
server address. This pre-configuration may be hard wired into the server address. This pre-configuration may be hard wired into the
device or provided by a pluggable memory card or nearfield device or provided by a pluggable memory card or nearfield
communication. However, a static pre-configuration hard-wires communication. However, a static pre-configuration hard- wires
assumption about the network a devices operates in and is therefore assumption about the network a devices operates in and is therefore
brittle and not recommended. 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;
skipping to change at page 10, line 39 skipping to change at page 10, line 39
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 pre-configured [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
skipping to change at page 13, line 33 skipping to change at page 13, line 33
files containing configuration data. It can be secured by running files containing configuration data. It can be secured by running
FTP over TLS [RFC4217]. FTP over TLS [RFC4217].
o The Trivial File Transfer Protocol (TFTP) [RFC1350] has been used o The Trivial File Transfer Protocol (TFTP) [RFC1350] has been used
extensively to load boot images over the network. However, it extensively to load boot images over the network. However, it
does not provide security and the only option is to rely on IP does not provide security and the only option is to rely on IP
layer security (IPsec). layer security (IPsec).
o The Hypertext Transfer Protocol (HTTP) [RFC2616] can be used to o The Hypertext Transfer Protocol (HTTP) [RFC2616] can be used to
transfer documents containing configuration data. It is commonly transfer documents containing configuration data. It is commonly
secured by running HTTP over TLS [RFC2817] [RFC2818]. secured by running HTTP over TLS [RFC2817], [RFC2818].
o The SSH File Transfer Protocol (SFTP) [I-D.ietf-secsh-filexfer] o The SSH File Transfer Protocol (SFTP) [I-D.ietf-secsh-filexfer]
provides roughly the same services as FTP but runs over SSH and provides roughly the same services as FTP but runs over SSH and
thus utilizes the security services provided by SSH. thus utilizes the security services provided by SSH.
o UNIX utilities to transfer files such as RCP and SCP provide o UNIX utilities to transfer files such as RCP and SCP provide
limited flexibility and they differ in their degree of integration limited flexibility and they differ in their degree of integration
with SSH. with SSH.
o The Control And Provisioning of Wireless Access Points (CAPWAP) o The Control And Provisioning of Wireless Access Points (CAPWAP)
skipping to change at page 16, line 8 skipping to change at page 16, line 8
information. NETCONF [RFC6241] 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 generated from existing SNMP MIB modules by translating the can be generated from existing SNMP MIB modules by translating the
SNMP modules into YANG modules [RFC6643]. SNMP modules into YANG modules [RFC6643].
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].
NETCONF provides generic notifications that help with tracking NETCONF provides generic notifications that help with tracking
configuration changes [RFC6470]. Similar standardized configuration configuration changes [RFC6470]. Similar standardized configuration
change notifications do not exist for SNMP or SYSLOG. change notifications do not exist for SNMP or SYSLOG.
8. Phase 5: Configuration Update 8. Phase 5: Configuration Update
Configuration updates can in principle be handled with the same Configuration updates can in principle be handled with the same
protocol that delivered the initial configuration. However, in some protocol that delivered the initial configuration. However, in some
skipping to change at page 16, line 35 skipping to change at page 16, line 35
configuration change transactions through the confirmed commit configuration change transactions through the confirmed commit
capability. capability.
9. Gap Analysis 9. Gap Analysis
This document discussed the automated configuration of devices in This document discussed the automated configuration of devices in
large IP networks. Several gaps were identified requiring further large IP networks. Several gaps were identified requiring further
specification: specification:
G1: Definition of a DHCP option to provide the IPv4/IPv6 address of G1: 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
to pickup the configuration server's address as part of the DHCP 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.
G2: Definition of DNS SRV records for locating configuration G2: Definition of DNS SRV records for locating configuration
servers. Using SRV records, a joining device can lookup the servers. Using SRV records, a joining device can lookup the
configuration server's address in the DNS. This is particularly configuration server's address in the DNS. This is particularly
useful in an Inter-domain Scenario. useful in an Inter-domain Scenario.
G3: 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
SLP is used also for other purposes. is used also for other purposes.
G4: 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.
G5: 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
software images). images).
G6: Some management protocols lack a mechanisms for devices to G6: Some management protocols lack a mechanisms for devices to
initiate a secure communication channel with a management system initiate a secure communication channel with a management system
("call home"). ("call home").
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.
11. 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 19, line 10 skipping to change at page 17, line 46
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.
12. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
13. Acknowledgements 12. Acknowledgements
Thanks to Ronald Bonica, Mehmet Ersue, Wesley George, Yiu Lee, Thanks to Ronald Bonica, Mehmet Ersue, Wesley George, Yiu Lee,
Christopher Liljenstolpe, Kent Watsen, and Cathy Zhou for their Christopher Liljenstolpe, Kent Watsen, and Cathy Zhou for their
comments during the preparation of this memo. comments during the preparation of this memo.
14. Informative References 13. Informative References
[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-01 (work in progress), draft-kwatsen-reverse-ssh-01 (work in progress)",
June 2011. June 2011.
[I-D.sarikaya-core-sbootstrapping] [I-D.sarikaya-core-sbootstrapping]
Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
Cragie, "Security Bootstrapping Solution for Resource- Cragie, "Security Bootstrapping Solution for Resource-
Constrained Devices", Constrained Devices" draft-sarikaya-core-sbootstrapping-05
draft-sarikaya-core-sbootstrapping-05 (work in progress), (work in progress)", July 2012.
July 2012.
[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.
skipping to change at page 23, line 21 skipping to change at page 22, line 7
August 2011. August 2011.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, February 2012. Base Notifications", RFC 6470, February 2012.
[RFC6643] Schoenwaelder, J., "Translation of Structure of Management [RFC6643] Schoenwaelder, J., "Translation of Structure of Management
Information Version 2 (SMIv2) MIB Modules to YANG Information Version 2 (SMIv2) MIB Modules to YANG
Modules", RFC 6643, July 2012. Modules", RFC 6643, July 2012.
[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 3GPP, ""3rd Generation Partnership Project; Technical
Partnership Project; Technical Specification Group Specification Group Services and System Aspects;
Services and System Aspects; Telecommunication Management; Telecommunication Management; Self-Organizing Networks
Self-Organizing Networks (SON); Concepts and requirements (SON); Concepts and requirements (Release 9)", 3GPP TS
(Release 9)", 3GPP TS 32.500, 2010. 32.500", 2010.
[TS_36_300] [TS_36_300]
3rd Generation Partnership Project, "3rd Generation 3GPP, ""3rd Generation Partnership Project; Technical
Partnership Project; Technical Specification Group Radio Specification Group Radio Access Network; Evolved
Access Network; Evolved Universal Terrestrial Radio Access Universal Terrestrial Radio Access (E-UTRA) and Evolved
(E-UTRA) and Evolved Universal Terrestrial Radio Access Universal Terrestrial Radio Access Network (E-UTRAN);
Network (E-UTRAN); Overall description; Stage 2 (Release Overall description; Stage 2 (Release 9)", 3GPP TS
9)", 3GPP TS 36.300, 2010. 36.300", 2010.
Authors' Addresses Authors' Addresses
Tina Tsou Tina Tsou
Huawei Technologies (USA) Huawei Technologies (USA)
2330 Central Expressway 2330 Central Expressway
Santa Clara CA 95050 Santa Clara, CA 95050
USA USA
Phone:
Email: tina.tsou.zouting@huawei.com Email: tina.tsou.zouting@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
Phone:
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
Yang Shi Yang Shi
Huawei Technologies Huawei Technologies
156, Beiqing Road, Zhongguancun, Haidian District 156, Beiqing Road, Zhongguancun, Haidian District
Beijing Beijing
P.R. China P.R. China
Phone: +86 10 60614043 Phone: +86 10 60614043
Email: shiyang1@huawei.com Email: shiyang1@huawei.com
Tom Taylor (editor) Tom Taylor
Huawei Technologies Huawei Technologies
1852 Lorraine Ave. Ottawa, Ontario
Ottawa K1H 6Z8
Canada Canada
Email: tom111.taylor@bell.net Phone:
Email: tom.taylor.stds@gmail.com
Guoliang Yang Guoliang Yang
China Telecom China Telecom
No. 109 Zhongshan Ave. (West), Tianhe District No. 109 Zhongshan Ave. (West), Tianhe District
Guangzhou Guangzhou,
P.R. China P.R. China
Phone: +86 020 38639615 Phone: +86 020 38639615
Email: iamyanggl@gmail.com Email: iamyanggl@gmail.com
 End of changes. 46 change blocks. 
146 lines changed or deleted 88 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/