idnits 2.17.1 draft-tsou-opsawg-network-configuration-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (September 15, 2010) is 4971 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TLS' is mentioned on line 521, but not defined == Unused Reference: 'RFC3411' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC3418' is defined on line 726, but no explicit reference was found in the text -- No information found for draft-SFTP - is the name correct? -- No information found for draft-YANG - is the name correct? -- No information found for draft-dhc-duid-uuid - is the name correct? -- No information found for draft-dhcpv6-opt-netboot - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1531 (Obsoleted by RFC 1541) -- 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 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5953 (Obsoleted by RFC 6353) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou 3 Internet-Draft Huawei Technologies 4 Intended status: Informational J. Schoenwaelder 5 Expires: March 19, 2011 Jacobs University Bremen 6 Y. Shi 7 Hangzhou H3C Tech. Co., Ltd. 8 T. Taylor, Ed. 9 Huawei Technologies 10 September 15, 2010 12 Problem Statement for the Configuration of Large-Scale IP Networks 13 draft-tsou-opsawg-network-configuration-01 15 Abstract 17 This memo discusses the steps required to bring network devices in a 18 service provider network into service in an automated fashion. The 19 memo identifies known solutions where they exist, but notes some gaps 20 that require further specification. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on March 19, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. A Model of the Process . . . . . . . . . . . . . . . . . . . . 5 65 4. Pre-configuration . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Establishment of Link Layer Connectivity . . . . . . . . . 6 68 5.2. Acquisition of IP Addresses and Basic Routing 69 Information . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.3. Finding the Configuration Server . . . . . . . . . . . . . 7 71 5.4. Establishing a Secure Channel to the Configuration 72 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Initial Configuration and Configuration Updates . . . . . . . 10 74 7. Configuration Auditing . . . . . . . . . . . . . . . . . . . . 12 75 8. Missing Specifications . . . . . . . . . . . . . . . . . . . . 13 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 12. Informative References . . . . . . . . . . . . . . . . . . . . 14 80 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 New service provider networks are being deployed that entail the 86 installation of tens of thousands of new network devices. To keep 87 costs down, it is desirable to automate the establishment of such 88 networks and the configuration of these network devices to the 89 maximum extent possible. A certain amount of the information needed 90 to operate them must be pre-configured by the vendor or service 91 provider before the devices are physically deployed. Other 92 information is best delivered after startup, to ensure that it is 93 consistent with the physical deployment. 95 3GPP work in progress describes requirements [TS_32_500] and an 96 architectural specification [TS_36_300] for the self-configuration of 97 edge node entities called eNodeBs. (The expansion of eNodeB is too 98 unwieldy to spell out.) Specifically, procedures are specified for 99 establishing transport connections to and for exchanging 100 configuration data with control entities called MMEs (Mobility 101 Management Entities) and with neighbouring eNodeBs. [TS_36_300] 102 currently assumes as a starting precondition that the eNodeB knows 103 its own IP address and knows IP address endpoints for the target MMEs 104 and neighbouring eNodeBs. 106 IETF work on automated configuration goes back to BOOTP [RFC0951], 107 followed eight years later by DHCP [RFC1531] and successors. The 108 years since have seen a steady growth in the number of DHCP options. 110 The Simple Network Management Protocol (SNMP) [RFC3410] was designed 111 to convey management information between SNMP entities such as 112 managers and agents. The number of SNMP MIB modules grew steadily, 113 but SNMP has not historically seen only limited use for configuration 114 [RFC3535]. For a period, IETF configuration efforts were focussed on 115 the distribution of policy in the network. [RFC3139] provides a good 116 insight into this period. More recently, NETCONF [RFC4741] was 117 devised as an alternative to SNMP, but the development of standard 118 NETCONF data models is just beginning. 120 Recent IETF work closest in spirit to the 3GPP self-organizing 121 network effort cited above is embodied in CAPWAP [RFC5415]. Like the 122 3GPP work, CAPWAP focusses on the configuration of edge nodes, in a 123 Wi-Fi rather than cellular network. The CAPWAP work goes beyond that 124 of 3GPP by specifying the process of AC (Access Controller) discovery 125 rather than leaving discovery out of scope. With regard to the 126 configuration process itself, CAPWAP provides for the download of new 127 images to the WTP (Wireless Termination Point). In contrast, 128 [TS_32_500] assumes that this has already been completed for the 129 eNodeB. 131 2. Scenarios 133 There are two different scenarios to consider. In the first 134 scenario, called the Intra-domain Scenario, the new network device N 135 is attached to the network operated by the service provider which is 136 also operating the new device. In the second scenario, called the 137 Inter-domain Scenario, the new device N is attached to a third party 138 network providing connectivity to the network of the service provider 139 operating the new device. 141 +------+ 142 | CONF | 143 +--+---+ 144 +---+ +---+ | 145 | N +-...-+ R +------+---+---+----... 146 +---+ +---+ | | 147 +--+--+ +--+---+ 148 | DNS | | DHCP | 149 +-----+ +------+ 151 |-- N's Service Provider --| 153 Figure 1: Intra-domain Scenario 155 Figure 1 depicts the Intra-domain Scenario. We assume that the new 156 decive N attaches to a link connected to router R. Furthermore, we 157 assume that the service provider provides a Domain Name System (DNS) 158 server, a DHCP server, and a Configuration Server (CONF). Overall, 159 this scenario does not differ much from conventional network 160 scenarios. 162 +------+ 163 | CONF | 164 +--+---+ 165 +---+ +---+ +---+ | 166 | N +-...-+ R +-----+---+---+-----...-+ R +-----+---+---+-----... 167 +---+ +---+ | | +---+ | | 168 +--+--+ +--+---+ +--+--+ +--+---+ 169 | DNS | | DHCP | | DNS | | DHCP | 170 +-----+ +------+ +-----+ +------+ 172 |-- Service Provider X ---| |-- N's Service Provider --| 174 Figure 2: Inter-domain Scenario 176 Figure 2 depicts the Inter-domain Scenario where the new device N 177 attaches to a router R owned by a different service provider X. The 178 service provider X might offer its own DNS and DHCP services. We 179 assume that the service provider X has connectivity to the service 180 provider planning to operate the new device. 182 3. A Model of the Process 184 We introduce a model of the configuration process in order to 185 identify the parts that have well-known solutions. The remainder may 186 be worth studying to see if the industry can agree on a solution. 188 Some basic terminology is needed for the discussion. Depending on 189 the implementation, let us agree that "configuration data" consist of 190 software and sets of configured parameters in some combination. 191 Also, the system that provides the configuration data is called the 192 "configuration server". Finally, the term "joining device" is used 193 to denote a network device that is in the process of being 194 incorporated into the network. 196 Broadly speaking, the configuration process can be broken into five 197 phases: 199 Pre-configuration: configuration carried out either by the vendor or 200 by the service provider prior to physical installation. One 201 possible example is the pre-provisioning of certificates, as 202 described in [RFC5415]. 204 Bootstrapping: the portion of the process from the time that 205 physical installation is complete until a secure connection is 206 established between the joining device and the configuration 207 server. 209 Initial configuration: downloading of the configuration data that 210 the joining device needs to carry out its function in the network. 212 Auditing of installed configuration: tracking image versions and 213 configuration parameters for each network device and verifying 214 that the installed configuration data matches the physical 215 installation, the network plan, and the records of what data was 216 downloaded. It is possible that an initial audit of the physical 217 installation is done before initial configuration, so that the 218 validity of the intended download can be verified. 220 Configuration update: transferring configuration data to a fully 221 configured and operating device from time to time as the need 222 arises. 224 4. Pre-configuration 226 This memo identifies a specific requirement for pre-configuration of 227 an invariant device identity and authentication-related material in 228 the form of pre-shared secrets or certificates. There is, as one 229 alternative, a requirement for pre-configuration of information that 230 permits the joining device to discover the address of the 231 configuration server. 233 5. Bootstrapping 235 [I-D.oflynn-core-bootstrapping] deals with the process of 236 bootstrapping, with particular emphasis on the requirements for 237 highly resource-constrained devices. The document makes a 238 distinction between a data channel, which is used during network 239 operation, and a control channel, which is used during bootstrapping. 240 While both channels can be the same physical channel, they can also 241 be different (e.g., a wireless access point using an infrared control 242 channel to receive bootstrapping information). The draft proposes to 243 define a generic secure bootstrapping protocol for resource 244 constrained devices that can be executed in several bootstrapping 245 rounds and can be adapted to the specific contexts in terms of the 246 resources available within individual devices and for the network as 247 a whole. 249 For network devices in service provider networks, bootstrapping 250 consists of several stages: 252 1. establishment of link layer connectivity with neighbouring nodes; 254 2. acquisition of IP addresses and basic routing information; 256 3. discovery of the configuration server; 258 4. establishment of a secure channel to the configuration server. 260 5.1. Establishment of Link Layer Connectivity 262 The protocol aspects of this phase are out of scope, since it 263 involves non-IETF protocols only. While some link-layer technologies 264 may provide authentication and access control, this cannot be assumed 265 to be available in the general case. 267 5.2. Acquisition of IP Addresses and Basic Routing Information 269 For IPv4, DHCPv4 [RFC2131] is widely deployed and the usual way to 270 obtain an IPv4 address, the IPv4 address of a link-local router and 271 the IPv4 address of a DNS server. For IPv6, a choice has to be made 272 between stateful DHCPv6 [RFC3315] versus stateless DHCPv6 [RFC3736] 273 combined with stateless address autoconfiguration [RFC4862]. In the 274 latter case, DHCPv6 is needed to configure parameters such as DNS 275 server addresses. An experimental routing advertisement option to 276 configure the IPv6 address of a DNS server as part of the stateless 277 address autoconfiguration is defined in [RFC5006] and may become a 278 standards-track specification. 280 Some security protection is provided in this stage by using DHCP 281 authentication [RFC3118]. However, security of the configuration 282 process as a whole has to be assured by other means. This is 283 discussed further below. 285 Currently the lack of a stable identifier for use in DHCPv6 messaging 286 is an impediment to authentication of the joining device. 287 [I-D.dhc-duid-uuid] discusses the problems with the current DHCPv6 288 identifiers (DUIDs) and proposes a new form that could be a more 289 stable alternative. 291 5.3. Finding the Configuration Server 293 Four alternatives are available for finding the configuration server: 295 o pre-configuration; 297 o DHCP configuration; 299 o Service Location Protocol [RFC2608]; or 301 o DNS service discovery using SRV records [RFC2782]. 303 Pre-configuration of an IP address is brittle and not recommended. 304 Pre-configuration of a Uniform Resource Identifier (URI) or fully 305 qualified domain name (FQDN) is a better approach. One variant that 306 has been suggested is to burn the URI of a vendor server into the 307 device's firmware along with a device identifier, and have that 308 server redirect to the URI of the service provider's configuration 309 server based on the device identity. Such an approach requires that 310 a device vendor offers such a service for the lifetime of their 311 devices and that service providers are able to update the URI of the 312 service provider's configuration server. This requires a trust 313 relationship between the vendor and the service provider and 314 agreement on a protocol to update the redirect information on the 315 vendor's server. 317 DHCP configuration can use the usual DHCP options and is technically 318 straightforward since DHCP is widely used by end user devices to 319 obtain basic configuration information. There is, however, no 320 standardized DHCP option to communicate the address of a 321 configuration server. 323 The Service Location Protocol (SLP) has seen some usage to locate 324 services such as printers or file system shares. Usage of SLP to 325 locate configuration servers requires to define a new service 326 template [RFC2609]. 328 The use of DNS SRV records requires the joining device to obtain the 329 correct domain suffix first, presumably from DHCP or via Routing 330 Advertisements in the case of IPv6 or preconfiguration. A service 331 type for the desired configuration protocol would have to be defined 332 in the DNS for the purpose. See Section 3.3 of [RFC5415] for a 333 discussion of the corresponding discovery process for CAPWAP. 335 The Inter-domain Scenario requires that the DHCP server or the SLP 336 server of service provider X's network is able to provide the correct 337 information to the joining devices. To accomplish this, the 338 discovery servers need to be able to match a device identification 339 against a list of possible configuration servers. Furthermore, there 340 needs to be a mechanism for the service provider operating the 341 joining device to provision the configuration server's address, e.g. 342 by using an extension of the Extensible Provisioning Protocol (EPP) 343 [RFC5730]. However, if the joining device has preconfigured 344 information about the name of the service provider's network, DNS SRV 345 records may be queried after obtaining IP connectivity, avoiding the 346 need to provision information in service provider X's network. 348 5.4. Establishing a Secure Channel to the Configuration Server 350 It is essential that the configuration server and the joining device 351 authenticate themselves to each other, since the steps leading up to 352 this point in the process may not be fully secure. This raises two 353 issues: how the joining device identifies itself, and how 354 authentication takes place. 356 It seems best if the device has an invariant identity built in and 357 accessible to whatever operating system is running on it. If 358 [I-D.dhc-duid-uuid], mentioned above, becomes a standard, the UUID on 359 which that proposal is based would be the required invariant 360 identity. The vendor should make that identity available in a form 361 that can be read and transferred into a database accessible to the 362 configuration server along with the associated configuration data in 363 advance of the bootstrapping stage (e.g., in bar-coded format on the 364 device packaging). 366 This leaves the mutual authentication process itself. This has two 367 aspects: the security protocol used to perform authentication, and 368 initial keying methodology. The security protocol is tied together 369 with the choice of configuration data transport, but the basic 370 choices are: 372 o IP Security (IPsec) [RFC4301]; 374 o Transport Layer Security (TLS) [RFC5246]; 376 o Datagram Transport Layer Security (DTLS) [RFC4347]; 378 o Secure Shell (SSH) [RFC4251], [RFC4252], [RFC4253], and [RFC4254]; 379 and 381 o SNMPv3's User-based Security Model (USM) [RFC3414]. 383 For initial keying methodology, the two basic choices are between 384 pre-shared secrets and certificates. All of the security protocols 385 listed above except USM support both methods. USM supports pre- 386 shared secrets only. 388 The usual concern with pre-shared secrets is scalability. In the 389 bootstrapping case, the scale of operation required is linear with 390 the number of devices to be configured, so it would definitely be a 391 feasible approach if connection to the configuration system were the 392 only consideration. The most likely procedure would be for the 393 secret to be configured in the device during preconfiguration and 394 also captured in a database along with the device identity, for use 395 by the configuration server. 397 The problem with the use of pre-shared secrets is that the device 398 needs to authenticate itself at an earlier stage, while it is 399 establishing communications with its neighbours and acquiring IP 400 addresses. It seems undesirable to use the same secret for that 401 purpose as for the connection to the configuration server, on the 402 basic principle of limiting the potential damage from disclosure of a 403 particular key. 405 This need for additional pre-shared secrets argues for consideration 406 of certificates as an alternative. One issue for certificates is 407 where the trust anchor resides. It seems logical that it should 408 reside with the service provider rather than the vendor, to make it 409 easy to install equipment from multiple vendors. On that basis, 410 preconfiguration requires service provider input. 412 CAPWAP (Section 2.4.4.3 of [RFC5415]) makes use of the Extended Key 413 Usage (EKU) certificate extension [RFC5280] to distinguish 414 certificates identifying the Access Controllers (i.e., the 415 configuration servers in the CAPWAP case) from the Wireless Transfer 416 Points (the configured devices in the CAPWAP case). Thought should 417 be given to whether such distinctions are required in the general 418 case of network device configuration. 420 CAPWAP (Section 12.8 of [RFC5415]) also discusses the use of the 421 Common Name rather than SubjectAltName field of the certificate to 422 carry device identity, due to lack of specifications allowing the use 423 of SubjectAltName to carry MAC addresses. This issue needs to be 424 investigated further if another form of device unique identity is 425 used, as discussed above. 427 6. Initial Configuration and Configuration Updates 429 As mentioned at the beginning, the configuration data being 430 downloaded may be a combination of software and configuration 431 parameters. Some of the data will be vendor-specific, not subject to 432 standardization. It appears that there is a continuing debate on 433 whether the configuration data should be pushed to the joining device 434 or whether the device should pull the configuration data down. In 435 the latter case, the device needs to know about the existence of the 436 data and the path to reach it before it can act. One way to acquire 437 this information is through DHCP. DHCPv4 has provided the necessary 438 options from its beginnings, inheriting them from BOOTP. They are 439 currently being added to DHCPv6; see [I-D.dhcpv6-opt-netboot]. 441 Protocols that can transport configuration data can be classified as 442 follows: The first class consists of generic file transfer protocols 443 that can carry configuration data serialized into configuration 444 files. The second class consists of protocols that manipulate 445 structured configuration data directly. The structure of the 446 configuration data is defined by some data model. 448 In the first class, we find the following file transfer protocols: 450 o The File Transfer Protocol (FTP) [RFC0959] can be used to move 451 files containing configuration data. It can be secured by running 452 FTP over TLS [RFC4217]. 454 o The Trivial File Transfer Protocol (TFTP) [RFC1350] has been used 455 extensively to load boot images over the network. However, it 456 does not provide security and the only option is to rely on IP 457 layer security (IPsec). 459 o The Hypertext Transfer Protocol (HTTP) [RFC2616] can be used to 460 transfer documents containing configuration data. It is commonly 461 secured by running HTTP over TLS [RFC2817] [RFC2818]. 463 o The SSH File Transfer Protocol (SFTP) [I-D.SFTP] provides roughly 464 the same services as FTP but runs over SSH and thus utilizes the 465 security services provided by SSH. 467 o UNIX utilities to transfer files such as RCP and SCP provide 468 limited flexibility and they differ in their degree of integration 469 with SSH. 471 o The Control And Provisioning of Wireless Access Points (CAPWAP) 472 protocol [RFC5415] can be used to control the download of images. 473 CAPWAP can be secured by running CAPWAP over DTLS. 475 In the second class, we find the following configuration protocols: 477 o Version 3 of the Simple Network Management Protocol (SNMPv3) 478 [RFC3411]-[RFC3418] can be used to manipulate MIB objects and to 479 carry event notifications. It has its own security protocol (USM) 480 but can also run over SSH [RFC5592], TLS, or DTLS [RFC5953]. 482 o The Common Open Policy Service for Policy Provisioning protocol 483 (COPS-PR) [RFC3084] was designed to provision structured policy 484 information from a Policy Decision Point (PDP) to a Policy 485 Enforcement Point (PEP). The COPS protocol [RFC2748] provides an 486 integrity object that can achieve authentication, message 487 integrity, and replay prevention. Optionally, COPS and COPS-PR 488 can run over TLS. 490 o The NETCONF protocol [RFC4741] provides mechanisms to install, 491 manipulate, and delete the configuration of network devices. A 492 protocol extension provides an asychronous even notification 493 delivery mechanism [RFC5277]. NETCONF by default runs over SSH 494 but can also run over transports secured by TLS. 496 o The Control And Provisioning of Wireless Access Points protocol 497 (CAPWAP) [RFC5415] supports the discovery of so called Access 498 Controller (AC) by Wireless Termination Points (WTPs) and the 499 configuration of WTPs by an AC. While CAPWAP can be extended to 500 configure other devices, its main focus are WTPs. The CAPWAP 501 protocol is protected by using DTLS after the discovery phase. 503 Table 1 lists the protocols plus their security options. Note that 504 all protocols can be secured at the IP layer by using IPsec and hence 505 this is not mentioned explicitly in Table 1. 507 +-----------+--------------+----------------------------------------+ 508 | Transport | Security | Data Transfer Model | 509 +-----------+--------------+----------------------------------------+ 510 | FTP | TLS | Push or pull of (configuration) files | 511 | TFTP | | Push or pull of (configuration) files | 512 | HTTP | TLS | Push or pull of (configuration) files | 513 | SFTP | SSH | Push or pull of (configuration) files | 514 | RCP | | Push or pull of (configuration) files | 515 | SCP | SSH | Push or pull of (configuration) files | 516 | CAPWAP | DTLS | AC pushes configuration parameters, | 517 | | | WTP pulls software | 518 | SNMPv3 | USM [SSH, | Push of structured configuration | 519 | | TLS, DTLS] | parameters, event notifications | 520 | COPS-PR | TLS | Push of structured policy information | 521 | NETCONF | SSH [TLS] | Push of structured configuration data, | 522 | | | event notifications | 523 +-----------+--------------+----------------------------------------+ 525 Table 1: Protocols for transporting configuration data 527 SNMPv3, NETCONF, and COPS-PR carry structured data specified in pre- 528 defined data models. SNMPv3 and COPS-PR have size limitations on the 529 data objects and thus make the transport of larger software images 530 difficult. NETCONF does not suffer from hard size restrictions and 531 can in principle carry software images inline. However, there is 532 currently no work in progress to standardize the transfer of software 533 images over NETCONF. An advantage of NETCONF over SNMPv3 and CAPWAP 534 is the support or concurrent updates through locking mechanisms and 535 the support of network wide configuration change transactions through 536 the confirmed commit capability. CAPWAP combines the functions of 537 configuration parameter transport and software download. The 538 parameter transport aspect lacks the generality offered by SNMP, 539 NETCONF, and COPS-PR, since the parameters are specified within the 540 protocol specification itself. The remaining transports are 541 independent of the nature of the information being transferred. 543 7. Configuration Auditing 545 To complete the process, it must be possible to audit the 546 configuration status of the device in some detail. This is likely to 547 begin even before all the configuration data has been downloaded. 548 For instance, configuration management may wish to collect basic 549 information such as the MAC addresses of the device's interfaces, the 550 link-local addresses assigned to them, and similar information for 551 the neighbours of the joining device. 553 SNMP and SNMP MIB modules are obviously one way to collect this 554 information. NETCONF [RFC4741] is an alternative, but the necessary 555 data models have to be defined. YANG modules for NETCONF [I-D.YANG] 556 can be prepared relatively quickly from existing SNMP MIB modules by 557 translating the SNMP modules into YANG modules. Work to standardize 558 such translations is currently being chartered in the NETMOD working 559 group. 561 Another important auditing activity is the analysis of system events. 562 The SYSLOG protocol [RFC5424] is widely used for this purpose but 563 SNMPv3 and NETCONF can ship event notifications as well. 564 Translations of SNMP notifications into structured SYSLOG messages 565 and vice versa do exist [RFC5675] [RFC5676]. NETCONF can carry 566 SYSLOG content as well [RFC5277]. 568 8. Missing Specifications 570 This document discussed the automated configuration of devices in 571 service provider networks. Several gaps were identified requiring 572 further specification: 574 G1: Definition of stable unique device identifiers such as the work 575 described in [I-D.dhc-duid-uuid]. 577 G2: Definition of a DHCP option to provide the IPv4/IPv6 address of 578 a configuration server. Such an option allows a joining device 579 to pickup the configuration server's address as part of the DHCP 580 exchange. This is particularly interesting for Intra-domain 581 Scenarios. 583 G3: Definition of DNS SRV records for locating configuration 584 servers. Such an option allows a joining device to lookup the 585 configuration server's in the DNS; this is particularly useful 586 in an Inter-domain Scenario. 588 G4: Definition of a SLP template for discovering configuration 589 servers. Such a template is useful only in environments where 590 SLP is used also for other purposes. 592 G5: Definition of NETCONF data models to support the download / 593 update of software images through NETCONF. 595 G6: Definition of NETCONF data models for collecting basic system 596 information and integrity information (e.g., checksums of 597 software images) and for sending configuration management 598 related notifications. 600 9. Security Considerations 602 The security of a configuration management solution is of crucial 603 importance. Section 6 discusses the security options of several 604 protocols that might be used. The relevant protocol definitions 605 should be consulted to learn more about the specific security aspects 606 of the various protocols. 608 It should be noted that some steps in the described process, in 609 particular the bootstrapping phase, may not be secure and it is thus 610 important to verify the identity of the device and the identity of 611 the configuration server when a secure connection to a configuration 612 server is established. Usage of IPsec, which is focusses on securing 613 the IP layer, may not be sufficient for this. 615 During the choice of protocols, the available security mechanisms and 616 the required key management infrastructures may play a major role in 617 the selection of protocols. Easy integration into existing 618 Authentication, Authorization and Accounting (AAA) infrastructures 619 can significantly reduce the operational costs associated with the 620 security management of the configuration system. 622 10. IANA Considerations 624 This memo includes no request to IANA. 626 11. Contributors 628 Thanks to Cathy Zhou and Mehmet Ersue for help in preparing this 629 memo. 631 12. Informative References 633 [I-D.SFTP] 634 Galbraith, J. and O. Saarenmaa, "SSH File Transfer 635 Protocol (Work in progress)", July 2006. 637 http://tools.ietf.org/id/draft-ietf-secsh-filexfer-13.txt 639 [I-D.YANG] 640 Bjorklund, M., "YANG - A data modeling language for the 641 Network Configuration Protocol (NETCONF) (Work in 642 progress)", June 2010. 644 [I-D.dhc-duid-uuid] 645 Narten, T. and J. Johnson, "Definition of the UUID-based 646 DHCPv6 Unique Identifier (DUID-UUID) (Work in progress)", 647 May 2010. 649 [I-D.dhcpv6-opt-netboot] 650 Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 651 option for network boot (Work in progress)", June 2010. 653 [I-D.oflynn-core-bootstrapping] 654 O'Flynn, C. and B. Sarikawa, "Initial Configuration of 655 Resource-Constrained Devices (Work in progress)", 656 July 2010. 658 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 659 September 1985. 661 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 662 STD 9, RFC 959, October 1985. 664 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 665 RFC 1350, July 1992. 667 [RFC1531] Droms, R., "Dynamic Host Configuration Protocol", 668 RFC 1531, October 1993. 670 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 671 RFC 2131, March 1997. 673 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 674 "Service Location Protocol, Version 2", RFC 2608, 675 June 1999. 677 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 678 and Service: Schemes", RFC 2609, June 1999. 680 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 681 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 682 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 684 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 685 and A. Sastry, "The COPS (Common Open Policy Service) 686 Protocol", RFC 2748, January 2000. 688 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 689 specifying the location of services (DNS SRV)", RFC 2782, 690 February 2000. 692 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 693 HTTP/1.1", RFC 2817, May 2000. 695 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 697 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 698 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 699 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 700 RFC 3084, March 2001. 702 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 703 Messages", RFC 3118, June 2001. 705 [RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements 706 for Configuration Management of IP-based Networks", 707 RFC 3139, June 2001. 709 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 710 and M. Carney, "Dynamic Host Configuration Protocol for 711 IPv6 (DHCPv6)", RFC 3315, July 2003. 713 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 714 "Introduction and Applicability Statements for Internet- 715 Standard Management Framework", RFC 3410, December 2002. 717 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 718 Architecture for Describing Simple Network Management 719 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 720 December 2002. 722 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 723 (USM) for version 3 of the Simple Network Management 724 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 726 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 727 Simple Network Management Protocol (SNMP)", STD 62, 728 RFC 3418, December 2002. 730 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 731 Management Workshop", RFC 3535, May 2003. 733 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 734 (DHCP) Service for IPv6", RFC 3736, April 2004. 736 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 737 October 2005. 739 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 740 Protocol Architecture", RFC 4251, January 2006. 742 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 743 Authentication Protocol", RFC 4252, January 2006. 745 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 746 Transport Layer Protocol", RFC 4253, January 2006. 748 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 749 Connection Protocol", RFC 4254, January 2006. 751 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 752 Internet Protocol", RFC 4301, December 2005. 754 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 755 Security", RFC 4347, April 2006. 757 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 758 December 2006. 760 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 761 Address Autoconfiguration", RFC 4862, September 2007. 763 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 764 "IPv6 Router Advertisement Option for DNS Configuration", 765 RFC 5006, September 2007. 767 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 768 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 770 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 771 Notifications", RFC 5277, July 2008. 773 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 774 Housley, R., and W. Polk, "Internet X.509 Public Key 775 Infrastructure Certificate and Certificate Revocation List 776 (CRL) Profile", RFC 5280, May 2008. 778 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 779 Provisioning of Wireless Access Points (CAPWAP) Protocol 780 Specification", RFC 5415, March 2009. 782 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 784 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 785 Shell Transport Model for the Simple Network Management 786 Protocol (SNMP)", RFC 5592, June 2009. 788 [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network 789 Management Protocol (SNMP) Notifications to SYSLOG 790 Messages", RFC 5675, October 2009. 792 [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, 793 "Definitions of Managed Objects for Mapping SYSLOG 794 Messages to Simple Network Management Protocol (SNMP) 795 Notifications", RFC 5676, October 2009. 797 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 798 STD 69, RFC 5730, August 2009. 800 [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport 801 Model for the Simple Network Management Protocol (SNMP)", 802 RFC 5953, August 2010. 804 [TS_32_500] 805 3rd Generation Partnership Project, "3rd Generation 806 Partnership Project; Technical Specification Group 807 Services and System Aspects; Telecommunication Management; 808 Self-Organizing Networks (SON); Concepts and requirements 809 (Release 9)", 3GPP TS 32.500, 2010. 811 [TS_36_300] 812 3rd Generation Partnership Project, "3rd Generation 813 Partnership Project; Technical Specification Group Radio 814 Access Network; Evolved Universal Terrestrial Radio Access 815 (E-UTRA) and Evolved Universal Terrestrial Radio Access 816 Network (E-UTRAN); Overall description; Stage 2 (Release 817 9)", 3GPP TS 36.300, 2010. 819 Appendix A. Open Issues 821 The document should discuss the usage of VPNs in the Inter-domain 822 scenario. 824 Authors' Addresses 826 Tina Tsou 827 Huawei Technologies 828 Bantian, Longgang District 829 Shenzhen 518129 830 P.R. China 832 Email: tena@huawei.com 833 Juergen Schoenwaelder 834 Jacobs University Bremen 835 Campus Ring 1 836 Bremen 28759 837 Germany 839 Email: j.schoenwaelder@jacobs-university.de 841 Yang Shi 842 Hangzhou H3C Tech. Co., Ltd. 843 Beijing R&D Center of H3C, Digital Technology Plaza, 844 NO.9 Shangdi 9th Street, Haidian District, 845 Beijing 846 China(100085) 848 Phone: +86 010 82775276 849 Email: young@h3c.com 851 Tom Taylor (editor) 852 Huawei Technologies 853 1852 Lorraine Ave. 854 Ottawa K1H 6Z8 855 Canada 857 Email: tom111.taylor@bell.net