idnits 2.17.1 draft-ietf-opsawg-automated-network-configuration-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2013) is 4104 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1541 (Obsoleted by RFC 2131) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Area Working Group T. Tsou 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational J. Schoenwaelder, Ed. 5 Expires: July 27, 2013 Jacobs University Bremen 6 Y. Shi 7 T. Taylor 8 Huawei Technologies 9 G. Yang 10 China Telecom 11 January 23, 2013 13 Survey of Possibilities for the Automated Configuration of Large IP 14 Networks 15 draft-ietf-opsawg-automated-network-configuration-05 17 Abstract 19 This memo discusses the steps required to bring a large number of 20 devices into service in IP networks in an automated fashion. The 21 goal of this document is to list known solutions where they exist, to 22 point out approaches proven to be problematic, and to identify gaps 23 that require further specifications. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 27, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Intra-domain and Inter-domain Scenarios . . . . . . . . . . . 5 61 3. Model of the Automated Configuration Process . . . . . . . . . 6 62 4. Phase 1: Pre-configuration . . . . . . . . . . . . . . . . . . 7 63 5. Phase 2: Bootstrapping . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Establishment of Link Layer Connectivity . . . . . . . . . 8 65 5.2. Acquisition of IP Addresses and Basic Routing 66 Information . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.3. Finding the Configuration Server . . . . . . . . . . . . . 9 68 5.4. Establishing a Secure Channel to the Configuration 69 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. Phase 3: Initial Configuration . . . . . . . . . . . . . . . . 12 71 7. Phase 4: Configuration Auditing . . . . . . . . . . . . . . . 15 72 8. Phase 5: Configuration Update . . . . . . . . . . . . . . . . 16 73 9. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 77 13. Informative References . . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 Many large IP networks are being deployed that entail the 83 installation of tens of thousands of new network devices. To keep 84 costs down, it is desirable to automate the establishment of such 85 networks to the maximum extent possible. This naturally raises the 86 question how new devices can pick up the configuration information 87 they need to operate properly in an automated fashion. The goal of 88 this document is to list known solutions where they exist, to point 89 out approaches proven to be problematic, and to identify gaps that 90 require further specifications. 92 The document primarily targets (a) network operators (in the generic 93 sense) who are facing the challenge to roll out a large number of new 94 devices and think about how to implement things properly, (b) network 95 equipment vendors who like to add features to their products that 96 make the roll out of lots of new devices simpler for their customers, 97 and (c) people active in the IETF by identifying gaps where further 98 standards may be useful to develop. The aim of the document is to 99 provide guidance to actors who have not already experienced success 100 in this area by informing about the trade-offs of different 101 approaches. 103 A certain basic amount of configuration information must be pre- 104 configured by the vendor or network operator before the devices are 105 physically deployed. This pre-provisioned configuration can either 106 be stored directly on the device itself or it can be provided to the 107 device during the deployment operation via pluggable memory cards or 108 near field communication technologies. Further device configuration 109 information is best delivered after startup, to ensure that it is 110 consistent with the physical deployment and the desired network 111 configuration. 113 One example where automated configuration is important are new 114 service provider networks. 3GPP work in progress describes 115 requirements [TS_32_500] and an architectural specification 116 [TS_36_300] for the self-configuration of edge node entities called 117 eNodeBs. (The expansion of eNodeB is too unwieldy to spell out.) 118 Specifically, procedures are specified for establishing transport 119 connections to and for exchanging configuration data with control 120 entities called MMEs (Mobility Management Entities) and with 121 neighbouring eNodeBs. [TS_36_300] currently assumes as a starting 122 precondition that the eNodeB knows its own IP address and knows IP 123 address endpoints for the target MMEs and neighbouring eNodeBs. 125 The Broadband Forum has defined a CPE WAN Management Protocol 126 (running over SOAP/HTTP/TLS) to manage customer premise equipment 127 (CPE) terminating broadband access networks (typically DSL access 128 networks) [TR_069]. CPE devices locate and connect to an Auto- 129 Configuration Server (ACS), which provides configuration data and 130 software/firmware images and modules. The ACS also performs status 131 and performance monitoring and diagnostic functions. CPE devices use 132 DHCP to locate an ACS and since both peers, the ACS and CPE, can 133 initiate connections, the protocol can work across network address 134 translators (NATs). The DHCP exchange uses vendor-specific options 135 defined by the Broadband Forum (number 3561 in the IANA Enterprise 136 Numbers registry). 138 Next to service provider networks, many large enterprise networks 139 face the same challenge to roll out a large number of network 140 devices, which often connect to a 3rd party network provider. The 141 current development of IP-based home automation and utility 142 monitoring technologies might carry the problem to roll out large 143 numbers of devices that need to automatically configure themselves to 144 private households. 146 IETF work on automated configuration goes back to BOOTP [RFC0951], 147 followed eight years later by DHCP ([RFC1541] and successors). The 148 years since have seen a steady growth in the number of DHCP options. 149 The Simple Network Management Protocol (SNMP) [RFC3410] was designed 150 to convey management information between SNMP entities such as 151 managers and agents. The number of SNMP MIB modules grew steadily, 152 but SNMP has historically seen only limited use for configuration 153 [RFC3535]. For a period, IETF configuration efforts were focussed on 154 the distribution of policy information in the network. [RFC3139] 155 provides a good insight into this period. More recently, the network 156 configuration protocol NETCONF [RFC6241] was devised as an 157 alternative to SNMP, but the development of standard NETCONF 158 configuration data models is just beginning. 160 Recent IETF work closest in spirit to the 3GPP self-organizing 161 network effort cited above is embodied in CAPWAP [RFC5415]. Like the 162 3GPP work, CAPWAP focusses on the configuration of edge nodes, in a 163 Wi-Fi rather than cellular network. The CAPWAP work goes beyond that 164 of 3GPP by specifying the process of Access Controller (AC) discovery 165 rather than leaving discovery out of scope. A CAPWAP Wireless 166 Termination Point (WTP) may use broadcasts and multicasts to discover 167 local ACs, it may use CAPWAP DHCP options [RFC5417] to obtain IP 168 addresses of ACs, or it may utilize CAPWAP DNS SRV records if a 169 domain name is known. With regard to the configuration process 170 itself, CAPWAP provides for the download of new images to the WTP 171 (Wireless Termination Point). In contrast, [TS_32_500] assumes that 172 this has already been completed for the eNodeB. 174 As can seen, standards for the automated configuration of devices in 175 IP networks have so far been primarily developed for specific network 176 access technologies (3GPP, Broadband, 802.11 WLANs) and the various 177 solutions make different assumptions about the services that are 178 available and they are designed to support a configuration protocol 179 that is specific to a certain access technology. The aim of this 180 document is to analyse the various phases of an automated 181 configuration process and to identify gaps that are currently not 182 covered in standard and general purpose configuration management 183 protocols of the IETF. 185 2. Intra-domain and Inter-domain Scenarios 187 There are two different scenarios to consider. In the first 188 scenario, called the Intra-domain Scenario, the new network device N 189 is attached to the network operated by the service provider which is 190 also operating the new device. In the second scenario, called the 191 Inter-domain Scenario, the new device N is attached to a third party 192 network providing connectivity to the network of the service provider 193 operating the new device. 195 +------+ 196 | CONF | 197 +--+---+ 198 +---+ +---+ | 199 | N +-...-+ R +------+---+---+----... 200 +---+ +---+ | | 201 +--+--+ +--+---+ 202 | DNS | | DHCP | 203 +-----+ +------+ 205 |-- N's Service Provider --| 207 Figure 1: Intra-domain Scenario 209 Figure 1 depicts the Intra-domain Scenario. We assume that the new 210 device N attaches to a link connected to router R. Furthermore, we 211 assume that the service provider provides a Domain Name System (DNS) 212 server, a reachable DHCP server, and a Configuration Server (CONF). 213 Overall, this scenario does not differ much from conventional network 214 scenarios. 216 +------+ 217 | CONF | 218 +--+---+ 219 +---+ +---+ +---+ | 220 | N +-...-+ R +-----+---+---+-----...-+ R +-----+---+---+-----... 221 +---+ +---+ | | +---+ | | 222 +--+--+ +--+---+ +--+--+ +--+---+ 223 | DNS | | DHCP | | DNS | | DHCP | 224 +-----+ +------+ +-----+ +------+ 226 |-- Service Provider X ---| |-- N's Service Provider --| 228 Figure 2: Inter-domain Scenario 230 Figure 2 depicts the Inter-domain Scenario where the new device N 231 attaches to a router R owned by a different service provider X. The 232 service provider X might offer its own DNS service and a reachable 233 DHCP service. We assume that the service provider X has connectivity 234 to the service provider planning to operate the new device. 236 It should be noted that handing out DHCP options specific to N's 237 service provider via X's DHCP service requires some close 238 coordination between the two parties involved. This might be 239 difficult in practice. A more general alternative might be to have 240 X's service provider establish a tunnel such that the new device 241 logically appears to be part of N's service provider network. 243 In both scenarios, the new device N is either directly reachable or 244 it may be behind a middlebox such as a Network Address Translator 245 (NAT) or a firewall. Middleboxes may impose restrictions on which 246 party is able to initiate communication. As detailed in 247 [I-D.kwatsen-reverse-ssh], it is often desirable to allow device- 248 initiated connections. 250 3. Model of the Automated Configuration Process 252 We introduce a model of the configuration process in order to 253 identify the parts that have well-known solutions. The remainder may 254 be worth studying to see if the industry can agree on a solution. 256 Some basic terminology is needed for the discussion. Depending on 257 the implementation, let us agree that "configuration data" consist of 258 software and sets of configured parameters in some combination. This 259 includes firmware, licenses, certificates, and other configuration 260 data. Also, the system that provides the configuration data is 261 called the "configuration server". Finally, the term "joining 262 device" is used to denote a network device that is in the process of 263 being incorporated into the network. 265 Broadly speaking, the configuration process can be broken into five 266 phases: 268 1. Pre-configuration: configuration carried out either by the vendor 269 or by the service provider prior to physical installation. One 270 possible example is the pre-configuration of certificates or 271 licenses or specific firmware. 273 2. Bootstrapping: the portion of the process from the time that 274 physical installation is complete until a secure connection is 275 established between the joining device and the configuration 276 server. 278 3. Initial configuration: downloading of the configuration data that 279 the joining device needs to carry out its function in the 280 network. 282 4. Configuration auditing: tracking image versions and configuration 283 parameters for each network device and verifying that the 284 installed configuration data matches the physical installation, 285 the network plan, and the records of what data was downloaded. 286 It is possible that an initial audit of the physical installation 287 is done before initial configuration, so that the validity of the 288 intended download can be verified. 290 5. Configuration update: transferring configuration data to a fully 291 configured and operating device from time to time as the need 292 arises. 294 4. Phase 1: Pre-configuration 296 This memo identifies a specific requirement for pre-configuration of 297 an invariant device identity and authentication-related material in 298 the form of pre-shared secrets or certificates. There is, as one 299 alternative, also a requirement for pre-configuration of information 300 that permits the joining device to discover the address of the 301 configuration server. 303 Note that pre-configuration may be carried out on the joining device 304 itself or it may be provided to the joining device during the 305 deployment process via pluggable memory cards or nearfield 306 communication. 308 5. Phase 2: Bootstrapping 310 [I-D.sarikaya-core-sbootstrapping] deals with the process of security 311 bootstrapping, with particular emphasis on the requirements for 312 highly resource-constrained devices. The document makes a 313 distinction between a data channel, which is used during network 314 operation, and a control channel, which is used during bootstrapping. 315 While both channels can be the same physical channel, they can also 316 be different (e.g., a wireless access point using an infrared control 317 channel to receive bootstrapping information). The draft discusses a 318 number of possible security bootstrapping protocols for resource 319 constrained devices that can be executed in several bootstrapping 320 rounds and can be adapted to the specific contexts in terms of the 321 resources available within individual devices and for the network as 322 a whole. 324 For network devices in service provider networks or large enterprise 325 networks, bootstrapping consists of several stages: 327 1. establishment of link layer connectivity with neighbouring nodes; 329 2. acquisition of IP addresses and basic routing information; 331 3. discovery of the configuration server; 333 4. establishment of a secure channel to the configuration server. 335 Each of these stages is further discussed below. 337 5.1. Establishment of Link Layer Connectivity 339 The protocol aspects of this phase are out of scope, since it 340 involves non-IETF protocols only. While some link-layer technologies 341 may provide authentication and access control, this cannot be assumed 342 to be available in the general case. 344 5.2. Acquisition of IP Addresses and Basic Routing Information 346 For IPv4, DHCPv4 [RFC2131] is widely deployed and the usual way to 347 obtain an IPv4 address, the IPv4 address of a link- local router and 348 the IPv4 address of a DNS server. For IPv6, a choice has to be made 349 between stateful DHCPv6 [RFC3315] versus stateless DHCPv6 [RFC3736] 350 combined with stateless address autoconfiguration [RFC4862]. In the 351 latter case, DHCPv6 is needed to configure parameters such as DNS 352 server addresses. A routing advertisement option to configure the 353 IPv6 address of a DNS server as part of the stateless address 354 autoconfiguration is defined in [RFC6106]. 356 Some security protection is provided in this stage by using DHCP 357 authentication [RFC3118]. However, security of the configuration 358 process as a whole has to be assured by other means. This is 359 discussed further below. 361 Currently the lack of a stable identifier for use in DHCPv6 messaging 362 is an impediment to authentication of the joining device. [RFC6355] 363 discusses the problems with the current DHCPv6 identifiers (DUIDs) 364 and proposes a new form that could be a more stable alternative. 366 A joining device can also choose to use a pre-configured IP address, 367 a pre-configured link-local router address and a pre- configured DNS 368 server address. This pre-configuration may be hard wired into the 369 device or provided by a pluggable memory card or nearfield 370 communication. However, a static pre-configuration hard- wires 371 assumption about the network a devices operates in and is therefore 372 brittle and not recommended. 374 5.3. Finding the Configuration Server 376 Four alternatives are available for finding the configuration server: 378 o pre-configuration; 380 o DHCP configuration; 382 o Service Location Protocol [RFC2608]; or 384 o DNS service discovery using DNS SRV records [RFC2782]. 386 Pre-configuration of an IP address is brittle and not recommended 387 unless the IP address is used as an anycast address. In the case of 388 an IP anycast address, the routing system will select one out of an 389 anycast cluster of configuration servers the devices connects to. 390 For this to work well, all configuration servers in the anycast 391 cluster should provide the same configuration data. 393 The pre-configuration of a Uniform Resource Identifier (URI) or fully 394 qualified domain name (FQDN) is a slightly better approach than pre- 395 configuring non-anycast IP addresses since this allows for a limited 396 dynamic mapping of the name to an IP address. One variant that has 397 been suggested is to burn the URI of a vendor server into the 398 device's firmware along with a device identifier, and have that 399 server redirect to the URI of the service provider's configuration 400 server based on the device identity. Such an approach requires that 401 the device vendor's redirection server is always reachable, that the 402 device vendor offers such a redirection service for the lifetime of 403 their devices and that service providers are able to update the URI 404 of the service provider's redirection server. Furthermore, this 405 approach can lead to problems if certificates are used to 406 authenticate the involved parties if a service provider tries to 407 prevent the usage of a vendor's redirection service. Finally, this 408 approach also requires a trust relationship between the vendor and 409 the service provider and agreement on a protocol to update the 410 redirect information on the vendor's server. As a consequence of 411 these considerations, using this approach is not recommended. 413 DHCP configuration can use the usual DHCP options and is technically 414 straightforward since DHCP is widely used by end user devices to 415 obtain basic configuration information. There is, however, no 416 standardized DHCP option to communicate the address of a 417 configuration server. 419 The Service Location Protocol (SLP) has seen some usage to locate 420 services such as printers or file system shares. Usage of SLP to 421 locate configuration servers requires to define a new service 422 template [RFC2609]. 424 The use of DNS SRV records requires the joining device to obtain the 425 correct domain suffix first, presumably from DHCP or via Routing 426 Advertisements in the case of IPv6 or pre-configuration. A service 427 type for the desired configuration protocol would have to be defined 428 in the DNS for the purpose. See Section 3.3 of [RFC5415] for a 429 discussion of the corresponding discovery process for CAPWAP. 431 The Inter-domain Scenario requires that the DHCP server or the SLP 432 server of service provider X's network is able to provide the correct 433 information to the joining devices. To accomplish this, the 434 discovery servers need to be able to match a device identification 435 against a list of possible configuration servers. Furthermore, there 436 needs to be a mechanism for the service provider operating the 437 joining device to provision the configuration server's address, e.g., 438 by using an extension of the Extensible Provisioning Protocol (EPP) 439 [RFC5730]. However, if the joining device has pre- configured 440 information about the name of the service provider's network, DNS SRV 441 records may be queried after obtaining IP connectivity, avoiding the 442 need to provision information in service provider X's network. 444 5.4. Establishing a Secure Channel to the Configuration Server 446 It is essential that the configuration server and the joining device 447 authenticate themselves to each other, since the steps leading up to 448 this point in the process may not be fully secure. This raises two 449 issues: how the joining device identifies itself, and how 450 authentication takes place. 452 It seems best if the device has an invariant identity built in and 453 accessible to whatever operating system is running on it. [RFC6355] 454 provides such an identity in the form of a Universally Unique 455 IDentifier (UUID). The vendor should make that identity available in 456 a form that can be read and transferred into a database accessible to 457 the configuration server along with the associated configuration data 458 in advance of the bootstrapping stage (e.g., in bar-coded format on 459 the device packaging). 461 Serial numbers may be used for identification purposes if UUIDs are 462 not available. However, serial numbers often encode information such 463 as model-numbers or manufacturing dates. Hence, it is not 464 recommended to pass serial-numbers in the clear for security reasons. 465 Similar precautions apply to Common Language Equipment Identifier 466 (CLEI) codes that encode information about properties of the device. 468 This leaves the mutual authentication process itself. This has two 469 aspects: the security protocol used to perform authentication, and 470 initial keying methodology. The security protocol is tied together 471 with the choice of configuration data transport, but the basic 472 choices are: 474 o IP Security (IPsec) [RFC4301]; 476 o Transport Layer Security (TLS) [RFC5246]; 478 o Datagram Transport Layer Security (DTLS) [RFC6347]; 480 o Secure Shell (SSH) [RFC4251], [RFC4252], [RFC4253], and [RFC4254]; 481 and 483 o SNMPv3's User-based Security Model (USM) [RFC3414]. 485 For initial keying methodology, the two basic choices are between 486 pre-shared secrets and certificates. All of the security protocols 487 listed above except USM support both methods. USM supports pre- 488 shared secrets only. 490 The usual concern with pre-shared secrets is scalability. In the 491 bootstrapping case, the scale of operation required is linear with 492 the number of devices to be configured, so it would definitely be a 493 feasible approach if connection to the configuration system were the 494 only consideration. The most likely procedure would be for the 495 secret to be configured in the device during pre-configuration and 496 also captured in a database along with the device identity, for use 497 by the configuration server. 499 The problem with the use of pre-shared secrets is that the device 500 needs to authenticate itself at an earlier stage, while it is 501 establishing communications with its neighbours and acquiring IP 502 addresses. It seems undesirable to use the same secret that is used 503 to authenticate the device to the configuration server for that 504 purpose as well, on the basic principle of limiting the potential 505 damage from disclosure of a particular key. 507 This need for additional pre-shared secrets argues for consideration 508 of certificates as an alternative. One issue for certificates is 509 where the trust anchor resides. It seems logical that it should 510 reside with the service provider rather than the vendor, to make it 511 easy to install equipment from multiple vendors. On that basis, pre- 512 configuration requires service provider input. On the other hand, if 513 devices are drop-shipped to the destination from the vendor, having 514 the trust anchor reside with the vendor might be acceptable as well. 516 CAPWAP (Section 2.4.4.3 of [RFC5415]) makes use of the Extended Key 517 Usage (EKU) certificate extension [RFC5280] to distinguish 518 certificates identifying the Access Controllers (i.e., the 519 configuration servers in the CAPWAP case) from the Wireless Transfer 520 Points (the configured devices in the CAPWAP case). Thought should 521 be given to whether such distinctions are required in the general 522 case of network device configuration. 524 CAPWAP (Section 12.8 of [RFC5415]) also discusses the use of the 525 Common Name rather than SubjectAltName field of the certificate to 526 carry device identity, due to lack of a Uniform Resource Name (URN) 527 specification allowing the use of SubjectAltName to carry MAC 528 addresses. This encoding of device identifiers in certifications 529 needs to be investigated further if a new form of device unique 530 identity is used, as discussed above. 532 Middleboxes such as NATs or firewalls may impose restriction on which 533 party is able to initiate communication. In the common case of NATs 534 in IPv4 access networks, communication can only be established from 535 the device to the configuration server. Not all secure transports, 536 in particular those where authentication is not symmetric, support 537 this "call home" mode of operation. A recent proposal to reverse the 538 establishment of the TCP connection for SSH can be found in 539 [I-D.kwatsen-reverse-ssh]. 541 6. Phase 3: Initial Configuration 543 As mentioned at the beginning, the configuration data being 544 downloaded may be a combination of software/firmware and 545 configuration parameters. Some of the data will be vendor-specific 546 and not subject to standardization. It appears that there is a 547 continuing debate on whether the configuration data should be pushed 548 to the joining device or whether the device should pull the 549 configuration data from the configuration server. In the latter 550 case, the device needs to know about the existence of the data and 551 the path to reach it before it can act. One way to acquire this 552 information is through DHCP. DHCPv4 has provided the necessary 553 options from its beginnings, inheriting them from BOOTP. They have 554 been recently added to DHCPv6 [RFC5970]. 556 Protocols that can transport configuration data can be classified as 557 follows: The first class consists of generic file transfer protocols 558 that can carry configuration data serialized into configuration 559 files. The second class consists of protocols that manipulate 560 structured configuration data directly. The structure of the 561 configuration data is defined by some data model. 563 In the first class, we find the following file transfer protocols: 565 o The File Transfer Protocol (FTP) [RFC0959] can be used to move 566 files containing configuration data. It can be secured by running 567 FTP over TLS [RFC4217]. 569 o The Trivial File Transfer Protocol (TFTP) [RFC1350] has been used 570 extensively to load boot images over the network. However, it 571 does not provide security and the only option is to rely on IP 572 layer security (IPsec). 574 o The Hypertext Transfer Protocol (HTTP) [RFC2616] can be used to 575 transfer documents containing configuration data. It is commonly 576 secured by running HTTP over TLS [RFC2817], [RFC2818]. 578 o The SSH File Transfer Protocol (SFTP) [I-D.ietf-secsh-filexfer] 579 provides roughly the same services as FTP but runs over SSH and 580 thus utilizes the security services provided by SSH. 582 o UNIX utilities to transfer files such as RCP and SCP provide 583 limited flexibility and they differ in their degree of integration 584 with SSH. 586 o The Control And Provisioning of Wireless Access Points (CAPWAP) 587 protocol [RFC5415] can be used to control the download of images. 588 CAPWAP can be secured by running CAPWAP over DTLS. 590 In the second class, we find the following configuration protocols: 592 o Version 3 of the Simple Network Management Protocol (SNMPv3) 593 [RFC3411] can be used to manipulate MIB objects and to carry event 594 notifications. SNMPv3 has its own security protocol (USM) 596 [RFC3414] but can also run over the secure transports SSH 597 [RFC5592], TLS, or DTLS [RFC6353]. 599 o The Common Open Policy Service for Policy Provisioning protocol 600 (COPS-PR) [RFC3084] was designed to provision structured policy 601 information from a Policy Decision Point (PDP) to a Policy 602 Enforcement Point (PEP). The COPS protocol [RFC2748] provides an 603 integrity object that can achieve authentication, message 604 integrity, and replay prevention. Optionally, COPS and COPS-PR 605 can run over TLS. 607 o The NETCONF protocol [RFC6241] provides mechanisms to install, 608 manipulate, and delete the configuration of network devices. A 609 protocol extension provides an asynchronous event notification 610 delivery mechanism [RFC5277]. NETCONF by default runs over SSH 611 but can also run over transports secured by TLS. 613 o The Control And Provisioning of Wireless Access Points protocol 614 (CAPWAP) [RFC5415] supports the discovery of so called Access 615 Controller (AC) by Wireless Termination Points (WTPs) and the 616 configuration of WTPs by an AC. While CAPWAP can be extended to 617 configure other devices, its main focus are WTPs. The CAPWAP 618 protocol is protected by using DTLS after the discovery phase. 620 Table 1 lists the protocols plus their basic properties while Table 2 621 lists the security options available for each protocol. 623 +-----------+-------------------------------------------------------+ 624 | Transport | Data Transfer Model | 625 +-----------+-------------------------------------------------------+ 626 | FTP | Push or pull of (configuration) files | 627 | TFTP | Push or pull of (configuration) files | 628 | HTTP | Push or pull of (configuration) files | 629 | SFTP | Push or pull of (configuration) files | 630 | RCP | Push or pull of (configuration) files | 631 | SCP | Push or pull of (configuration) files | 632 | CAPWAP | AC pushes configuration parameters, WTP pulls | 633 | | software | 634 | SNMPv3 | Push of structured configuration parameters, event | 635 | | notifications | 636 | COPS-PR | Push of structured policy information | 637 | NETCONF | Push of structured configuration data, event | 638 | | notifications | 639 +-----------+-------------------------------------------------------+ 641 Table 1: Protocols for transporting configuration data 642 +-----------+-------+-----+------+-----+-------+ 643 | Transport | IPsec | TLS | DTLS | SSH | Other | 644 +-----------+-------+-----+------+-----+-------+ 645 | FTP | + | + | | | | 646 | TFTP | + | | | | | 647 | HTTP | + | + | | | | 648 | SFTP | + | | | + | | 649 | RCP | + | | | | | 650 | SCP | + | | | + | | 651 | CAPWAP | + | | + | | | 652 | SNMPv3 | + | + | + | + | USM | 653 | COPS-PR | + | + | | | | 654 | NETCONF | + | + | | + | | 655 +-----------+-------+-----+------+-----+-------+ 657 Table 2: Security options for configuration transport protocols 659 SNMPv3, NETCONF, and COPS-PR carry structured data specified in pre- 660 defined data models. SNMPv3 and COPS-PR have size limitations on the 661 data objects and thus make the transport of larger software images 662 difficult. NETCONF does not suffer from hard size restrictions and 663 can in principle carry software images inline. However, there is 664 currently no work in progress to standardize the transfer of software 665 images over NETCONF. CAPWAP combines the functions of configuration 666 parameter transport and software download. The parameter transport 667 aspect lacks the generality offered by SNMP, NETCONF, and COPS-PR, 668 since the parameters are specified within the protocol specification 669 itself. The remaining transports are independent of the nature of 670 the information being transferred. 672 7. Phase 4: Configuration Auditing 674 To complete the process, it must be possible to audit the 675 configuration status of the device in some detail. This is likely to 676 begin even before all the configuration data has been downloaded. 677 For instance, configuration management may wish to collect basic 678 information such as the MAC addresses of the device's interfaces, the 679 link-local addresses assigned to them, and similar information for 680 the neighbours of the joining device. 682 SNMP and SNMP MIB modules are obviously one way to collect this 683 information. NETCONF [RFC6241] is an alternative, but the necessary 684 data models have to be defined. YANG modules for NETCONF [RFC6020] 685 can be generated from existing SNMP MIB modules by translating the 686 SNMP modules into YANG modules [RFC6643]. 688 Another important auditing activity is the analysis of system events. 690 The SYSLOG protocol [RFC5424] is widely used for this purpose but 691 SNMPv3 and NETCONF can ship event notifications as well. 692 Translations of SNMP notifications into structured SYSLOG messages 693 and vice versa do exist [RFC5675], [RFC5676]. NETCONF can carry 694 SYSLOG content as well [RFC5277]. 696 NETCONF provides generic notifications that help with tracking 697 configuration changes [RFC6470]. Similar standardized configuration 698 change notifications do not exist for SNMP or SYSLOG. 700 8. Phase 5: Configuration Update 702 Configuration updates can in principle be handled with the same 703 protocol that delivered the initial configuration. However, in some 704 deployments, the mechanism used for initial configuration might be 705 different. 707 An advantage of NETCONF over SNMPv3 and CAPWAP in the context of 708 configuration updates is the support of concurrent updates through 709 explicit locking mechanisms and the support of network wide 710 configuration change transactions through the confirmed commit 711 capability. 713 9. Gap Analysis 715 This document discussed the automated configuration of devices in 716 large IP networks. Several gaps were identified requiring further 717 specification: 719 G1: Definition of a DHCP option to provide the IPv4/IPv6 address of 720 a configuration server. Such an option allows a joining device to 721 pickup the configuration server's address as part of the DHCP 722 exchange. This is particularly interesting for Intra-domain 723 Scenarios. 725 G2: Definition of DNS SRV records for locating configuration 726 servers. Using SRV records, a joining device can lookup the 727 configuration server's address in the DNS. This is particularly 728 useful in an Inter-domain Scenario. 730 G3: Definition of a SLP template for discovering configuration 731 servers. Such a template is useful only in environments where SLP 732 is used also for other purposes. 734 G4: Definition of NETCONF data models to support the download 735 /update of software images through NETCONF. 737 G5: Definition of NETCONF data models for collecting basic system 738 information and integrity information (e.g., checksums of software 739 images). 741 G6: Some management protocols lack a mechanisms for devices to 742 initiate a secure communication channel with a management system 743 ("call home"). 745 10. Security Considerations 747 The security of a configuration management solution is of crucial 748 importance. Section 6 discusses the security options of several 749 protocols that might be used. The relevant protocol definitions 750 should be consulted to learn more about the specific security aspects 751 of the various protocols. 753 It should be noted that some steps in the described process, in 754 particular the bootstrapping phase, may not be secure and it is thus 755 important to verify the identity of the device and the identity of 756 the configuration server when a secure connection to a configuration 757 server is established. Usage of IPsec, which focuses on securing the 758 IP layer, may not be sufficient for this. 760 During the choice of protocols, the available security mechanisms and 761 the required key management infrastructures may play a major role in 762 the selection of protocols. Easy integration into existing 763 Authentication, Authorization and Accounting (AAA) infrastructures 764 can significantly reduce the operational costs associated with the 765 security management of the configuration system. 767 While [I-D.sarikaya-core-sbootstrapping] discusses security 768 bootstrapping mechanisms in the context of constrained devices, many 769 of the mechanisms are also applicable for bootstrapping security in 770 normal devices. 772 Finally, [RFC6092] discusses security capabilities for customer 773 premises equipment providing residential IPv6 Internet service. 775 11. IANA Considerations 777 This memo includes no request to IANA. 779 12. Acknowledgements 781 Thanks to Ronald Bonica, Mehmet Ersue, Wesley George, Yiu Lee, 782 Christopher Liljenstolpe, Kent Watsen, and Cathy Zhou for their 783 comments during the preparation of this memo. 785 13. Informative References 787 [I-D.ietf-secsh-filexfer] 788 Galbraith, J. and O. Saarenmaa, ""SSH File Transfer 789 Protocol", draft-ietf-secsh-filexfer-13 (work in 790 progress)", July 2006. 792 [I-D.kwatsen-reverse-ssh] 793 Watsen, K., ""Reverse Secure Shell (Reverse SSH)", 794 draft-kwatsen-reverse-ssh-01 (work in progress)", 795 June 2011. 797 [I-D.sarikaya-core-sbootstrapping] 798 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. 799 Cragie, "Security Bootstrapping Solution for Resource- 800 Constrained Devices" draft-sarikaya-core-sbootstrapping-05 801 (work in progress)", July 2012. 803 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 804 September 1985. 806 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 807 STD 9, RFC 959, October 1985. 809 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 810 RFC 1350, July 1992. 812 [RFC1541] Droms, R., "Dynamic Host Configuration Protocol", 813 RFC 1541, October 1993. 815 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 816 RFC 2131, March 1997. 818 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 819 "Service Location Protocol, Version 2", RFC 2608, 820 June 1999. 822 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 823 and Service: Schemes", RFC 2609, June 1999. 825 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 826 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 827 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 829 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 830 and A. Sastry, "The COPS (Common Open Policy Service) 831 Protocol", RFC 2748, January 2000. 833 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 834 specifying the location of services (DNS SRV)", RFC 2782, 835 February 2000. 837 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 838 HTTP/1.1", RFC 2817, May 2000. 840 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 842 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 843 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 844 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 845 RFC 3084, March 2001. 847 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 848 Messages", RFC 3118, June 2001. 850 [RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements 851 for Configuration Management of IP-based Networks", 852 RFC 3139, June 2001. 854 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 855 and M. Carney, "Dynamic Host Configuration Protocol for 856 IPv6 (DHCPv6)", RFC 3315, July 2003. 858 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 859 "Introduction and Applicability Statements for Internet- 860 Standard Management Framework", RFC 3410, December 2002. 862 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 863 Architecture for Describing Simple Network Management 864 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 865 December 2002. 867 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 868 (USM) for version 3 of the Simple Network Management 869 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 871 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 872 Management Workshop", RFC 3535, May 2003. 874 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 875 (DHCP) Service for IPv6", RFC 3736, April 2004. 877 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 878 October 2005. 880 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 881 Protocol Architecture", RFC 4251, January 2006. 883 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 884 Authentication Protocol", RFC 4252, January 2006. 886 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 887 Transport Layer Protocol", RFC 4253, January 2006. 889 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 890 Connection Protocol", RFC 4254, January 2006. 892 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 893 Internet Protocol", RFC 4301, December 2005. 895 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 896 Address Autoconfiguration", RFC 4862, September 2007. 898 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 899 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 901 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 902 Notifications", RFC 5277, July 2008. 904 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 905 Housley, R., and W. Polk, "Internet X.509 Public Key 906 Infrastructure Certificate and Certificate Revocation List 907 (CRL) Profile", RFC 5280, May 2008. 909 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 910 Provisioning of Wireless Access Points (CAPWAP) Protocol 911 Specification", RFC 5415, March 2009. 913 [RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access 914 Points (CAPWAP) Access Controller DHCP Option", RFC 5417, 915 March 2009. 917 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 919 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 920 Shell Transport Model for the Simple Network Management 921 Protocol (SNMP)", RFC 5592, June 2009. 923 [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network 924 Management Protocol (SNMP) Notifications to SYSLOG 925 Messages", RFC 5675, October 2009. 927 [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, 928 "Definitions of Managed Objects for Mapping SYSLOG 929 Messages to Simple Network Management Protocol (SNMP) 930 Notifications", RFC 5676, October 2009. 932 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 933 STD 69, RFC 5730, August 2009. 935 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 936 Options for Network Boot", RFC 5970, September 2010. 938 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 939 Network Configuration Protocol (NETCONF)", RFC 6020, 940 October 2010. 942 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 943 Customer Premises Equipment (CPE) for Providing 944 Residential IPv6 Internet Service", RFC 6092, 945 January 2011. 947 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 948 "IPv6 Router Advertisement Options for DNS Configuration", 949 RFC 6106, November 2010. 951 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 952 Bierman, "Network Configuration Protocol (NETCONF)", 953 RFC 6241, June 2011. 955 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 956 Security Version 1.2", RFC 6347, January 2012. 958 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 959 Model for the Simple Network Management Protocol (SNMP)", 960 RFC 6353, July 2011. 962 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 963 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 964 August 2011. 966 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 967 Base Notifications", RFC 6470, February 2012. 969 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 970 Information Version 2 (SMIv2) MIB Modules to YANG 971 Modules", RFC 6643, July 2012. 973 [TR_069] Blackford, J., Ed., Kirksey, H., Ed., and W. Lupton, Ed., 974 ""CPE WAN Management Protocol", Broadband Forum TR-069", 975 November 2010. 977 [TS_32_500] 978 3GPP, ""3rd Generation Partnership Project; Technical 979 Specification Group Services and System Aspects; 980 Telecommunication Management; Self-Organizing Networks 981 (SON); Concepts and requirements (Release 9)", 3GPP TS 982 32.500", 2010. 984 [TS_36_300] 985 3GPP, ""3rd Generation Partnership Project; Technical 986 Specification Group Radio Access Network; Evolved 987 Universal Terrestrial Radio Access (E-UTRA) and Evolved 988 Universal Terrestrial Radio Access Network (E-UTRAN); 989 Overall description; Stage 2 (Release 9)", 3GPP TS 990 36.300", 2010. 992 Authors' Addresses 994 Tina Tsou 995 Huawei Technologies (USA) 996 2330 Central Expressway 997 Santa Clara, CA 95050 998 USA 1000 Phone: 1001 Email: tina.tsou.zouting@huawei.com 1003 Juergen Schoenwaelder (editor) 1004 Jacobs University Bremen 1005 Campus Ring 1 1006 Bremen 28759 1007 Germany 1009 Phone: 1010 Email: j.schoenwaelder@jacobs-university.de 1011 Yang Shi 1012 Huawei Technologies 1013 156, Beiqing Road, Zhongguancun, Haidian District 1014 Beijing 1015 P.R. China 1017 Phone: +86 10 60614043 1018 Email: shiyang1@huawei.com 1020 Tom Taylor 1021 Huawei Technologies 1022 Ottawa, Ontario 1023 Canada 1025 Phone: 1026 Email: tom.taylor.stds@gmail.com 1028 Guoliang Yang 1029 China Telecom 1030 No. 109 Zhongshan Ave. (West), Tianhe District 1031 Guangzhou, 1032 P.R. China 1034 Phone: +86 020 38639615 1035 Email: iamyanggl@gmail.com