draft-ietf-opsawg-automated-network-configuration-03.txt   draft-ietf-opsawg-automated-network-configuration-04.txt 
Internet Engineering Task Force T. Tsou Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies (USA)
Intended status: Informational J. Schoenwaelder, Ed. Intended status: Informational J. Schoenwaelder, Ed.
Expires: September 13, 2012 Jacobs University Bremen Expires: January 18, 2013 Jacobs University Bremen
Y. Shi Y. Shi
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
G. Yang G. Yang
China Telecom China Telecom
March 12, 2012 July 17, 2012
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-03 draft-ietf-opsawg-automated-network-configuration-04
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 and goal of this document is to list known solutions where they exist, to
to identify gaps that require further specifications. point out approaches proven to be problematic, and to identify gaps
that require further specifications.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 September 13, 2012. This Internet-Draft will expire on January 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 16 skipping to change at page 2, line 17
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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Intra-domain and Inter-domain Scenarios . . . . . . . . . . . 5 2. Intra-domain and Inter-domain Scenarios . . . . . . . . . . . 5
3. Model of the Automated Configuration Process . . . . . . . . . 6 3. Model of the Automated Configuration Process . . . . . . . . . 6
4. Phase 1: Pre-configuration . . . . . . . . . . . . . . . . . . 7 4. Phase 1: Pre-configuration . . . . . . . . . . . . . . . . . . 7
5. Phase 2: Bootstrapping . . . . . . . . . . . . . . . . . . . . 7 5. Phase 2: Bootstrapping . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . 15 8. Phase 5: Configuration Update . . . . . . . . . . . . . . . . 16
9. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Informative References . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes since -02 . . . . . . . . . . . . . . . . . . 22 14. Informative References . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Changes since -01 . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 and to this document is to list known solutions where they exist, to point
identify gaps that require further specifications. out approaches proven to be problematic, and to identify gaps that
require further specifications.
The document primarily targets (a) network operators (in the generic
sense) who are facing the challenge to roll out a large number of new
devices and think about how to implement things properly, (b) network
equipment vendors who like to add features to their products that
make the roll out of lots of new devices simpler for their customers,
and (c) people active in the IETF by identifying gaps where further
standards may be useful to develop. The aim of the document is to
provide guidance to actors who have not already experienced success
in this area by informing about the trade-offs of different
approaches.
A certain basic amount of configuration information must be pre- A certain basic amount of configuration information must be pre-
configured by the vendor or network operator before the devices are configured by the vendor or network operator before the devices are
physically deployed. This pre-provisioned configuration can either physically deployed. This pre-provisioned configuration can either
be stored directly on the device itself or it can be provided to the be stored directly on the device itself or it can be provided to the
device during the deployment operation via pluggable memory cards or device during the deployment operation via pluggable memory cards or
near field communication technologies. Further device configuration 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 and the desired network consistent with the physical deployment and the desired network
configuration. configuration.
skipping to change at page 15, line 30 skipping to change at page 15, line 48
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 [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 [I-D.ietf-netmod-smi-yang]. 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.
skipping to change at page 16, line 43 skipping to change at page 17, line 16
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 images). software 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. Security Considerations 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
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 17, line 27 skipping to change at page 19, line 10
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.
11. IANA Considerations 12. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. Acknowledgements 13. Acknowledgements
Thanks to Mehmet Ersue, Wesley George, Yiu Lee, Christopher
Liljenstolpe, Kent Watsen, and Cathy Zhou for their help in preparing
this memo.
13. Informative References Thanks to Ronald Bonica, Mehmet Ersue, Wesley George, Yiu Lee,
Christopher Liljenstolpe, Kent Watsen, and Cathy Zhou for their
comments during the preparation of this memo.
[I-D.ietf-netmod-smi-yang] 14. Informative References
Schoenwaelder, J., "Translation of SMIv2 MIB Modules to
YANG Modules", draft-ietf-netmod-smi-yang-04 (work in
progress), January 2012.
[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., Cragie, R., Moskowitz, R., Ohba, Y., and Z. Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
Cao, "Security Bootstrapping of Resource-Constrained Cragie, "Security Bootstrapping Solution for Resource-
Devices", draft-sarikaya-core-sbootstrapping-03 (work in Constrained Devices",
progress), October 2011. draft-sarikaya-core-sbootstrapping-05 (work in progress),
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 21, line 36 skipping to change at page 23, line 16
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011. RFC 6353, July 2011.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
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
Information Version 2 (SMIv2) MIB Modules to YANG
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 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 -02
Incorporated feedback from Christopher Liljenstolpe concerning
anycasts.
Added additional text to the introduction in order to better
clarify the purpose of this document.
Editorial improvements, updated references, etc.
Appendix B. 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 (USA)
Bantian, Longgang District 2330 Central Expressway
Shenzhen 518129 Santa Clara CA 95050
P.R. China USA
Email: tena@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
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 (editor)
 End of changes. 23 change blocks. 
57 lines changed or deleted 113 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/