idnits 2.17.1 draft-iab-ip-config-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 811. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba 3 INTERNET-DRAFT D. Thaler 4 Category: Informational Microsoft Corporation 5 Expires: September 15, 2008 Loa Andersson 6 15 March 2008 Acreo AB 7 Internet Architecture Board 9 Principles of Internet Host Configuration 10 draft-iab-ip-config-02.txt 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes principles of Internet host configuration. 42 It covers issues relating to configuration of Internet layer 43 parameters, as well as parameters affecting higher layer protocols. 45 Table of Contents 47 1. Introduction.............................................. 3 48 1.1 Terminology ........................................ 3 49 2. Principles ............................................... 6 50 2.1 Minimize Configuration ............................. 6 51 2.2 Less is More ....................................... 6 52 2.3 Diversity is Not a Benefit ......................... 7 53 2.4 Lower Layer Independence ........................... 8 54 2.5 Configuration is Not Access Control ................ 9 55 3. Additional Discussion .................................... 10 56 3.1 General Purpose Mechanisms ......................... 10 57 3.2 Service Discovery .................................. 10 58 4. Security Considerations .................................. 12 59 4.1 Configuration Authentication ....................... 13 60 5. IANA Considerations ...................................... 14 61 6. References ............................................... 14 62 6.1 Informative References ............................. 14 63 Acknowledgments .............................................. 16 64 Appendix A - IAB Members ..................................... 17 65 Authors' Addresses ........................................... 17 66 Full Copyright Statement ..................................... 18 67 Intellectual Property ........................................ 18 68 1. Introduction 70 This document describes principles of Internet host configuration. 71 It covers issues relating to configuration of Internet layer 72 parameters, as well as parameters affecting higher layer protocols. 74 In recent years, a number of architectural questions have arisen, for 75 which we provide guidance to protocol developers: 77 o What protocol layers and general approaches are most appropriate 78 for configuration of various parameters. 80 o The relationship between parameter configuration and service 81 discovery. 83 o The relationship between network access authentication and host 84 configuration. 86 o The role of link-layer protocols and tunneling protocols 87 in Internet host configuration. 89 The role of the link-layer and tunneling protocols is particularly 90 important, since it can affect the properties of a link as seen by 91 higher layers (for example, whether privacy extensions specified in 92 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" 93 [RFC4941] are available to applications). 95 1.1. Terminology 97 link A communication facility or medium over which nodes can 98 communicate at the link-layer, i.e., the layer immediately 99 below IP. Examples are Ethernets (simple or bridged), PPP 100 links, X.25, Frame Relay, or ATM networks as well as Internet 101 (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 102 itself. 104 on link An address that is assigned to an interface on a specified 105 link. 107 off link The opposite of "on link"; an address that is not assigned to 108 any interfaces on the specified link. 110 Internet layer configuration is defined as the configuration required 111 to support the operation of the Internet layer. This includes IP 112 address(es), subnet prefix(es), default gateway(s), mobility 113 agent(s), boot service configuration and other parameters. 115 IP address(es) 116 Internet Protocol (IP) address configuration includes both 117 configuration of link-scope addresses as well as global 118 addresses. Configuration of IP addresses is an important 119 step, since this enables a host to fill in the source address 120 in the packets it sends, as well as to receive packets 121 destined to that address. As a result, the host can receive 122 unicast IP packets, rather than requiring that IP packets be 123 sent to the broadcast or multicast address. Configuration of 124 an IP address also enables the use of IP fragmentation, since 125 packets sent from the unknown address cannot be reliably 126 reassembled (since fragments from multiple hosts using the 127 unknown address might be reassembled into a single IP packet). 128 Configuration of an IP address also enables use of Internet 129 layer security facilities such as IPsec specified in "Security 130 Architecture for the Internet Protocol" [RFC4301]. 132 Subnet prefix(es) 133 Once a subnet prefix is configured, hosts with an IP address 134 can exchange unicast IP packets with on-link hosts. 136 Default gateway(s) 137 Once a default gateway is configured, hosts with an IP address 138 can send and receive unicast IP packets from off-link hosts, 139 assuming unobstructed connectivity. 141 Mobility agent(s) 142 While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] include 143 their own mechanisms for locating home agents, it is also 144 possible for mobile nodes to utilize dynamic home agent 145 configuration. 147 Other parameters 148 Internet layer parameter configuration also includes 149 configuration of per-host parameters (e.g. hostname) and per- 150 interface parameters (e.g. IP Time-To-Live (TTL), 151 enabling/disabling of IP forwarding and source routing, and 152 Maximum Transmission Unit (MTU)). 154 Boot service configuration 155 Boot service configuration is defined as the configuration 156 necessary for a host to obtain and perhaps also to verify an 157 appropriate boot image. This is appropriate for diskless 158 hosts looking to obtain a boot image via mechanisms such as 159 the Trivial File Transfer Protocol (TFTP) [RFC1350], Network 160 File System (NFS) [RFC3530] and Internet Small Computer 161 Systems Interface (iSCSI) [RFC3720][RFC4173]. It also may be 162 useful in situations where it is necessary to update the boot 163 image of a host that supports a disk, such as in the Preboot 164 eXecution Environment (PXE) [PXE][RFC4578]. While strictly 165 speaking boot services operate above the Internet layer, where 166 boot service is used to obtain the Internet layer code, it may 167 be considered part of Internet layer configuration. 169 Higher-layer configuration is defined as the configuration required 170 to support the operation of other components above the Internet 171 layer. This includes, for example: 173 Name Service Configuration 174 The configuration required for the host to resolve names. 175 This includes configuration of the addresses of name 176 resolution servers, including IEN 116, Domain Name Service 177 (DNS), Windows Internet Name Service (WINS), Internet Storage 178 Name Service (iSNS) and Network Information Service (NIS) 179 servers, and the setting of name resolution parameters such as 180 the NetBIOS node type, the DNS domain and search list, etc. 181 It may also include the transmission or setting of the host's 182 own name. Note that Link local name resolution services (such 183 as NetBIOS [RFC1001], LLMNR [RFC4795] and mDNS [mDNS]) 184 typically do not require configuration. 186 Once the host has completed name service configuration, it is 187 capable of resolving names using name resolution protocols 188 that require configuration. This not only allows the host to 189 communicate with off-link hosts whose IP address is not known, 190 but to the extent that name services requiring configuration 191 are utilized for service discovery, this also enables the host 192 to discover services available on the network or elsewhere. 194 Time Service Configuration 195 Time service configuration includes configuration of servers 196 for protocols such as the Simple Network Time Protocol (SNTP) 197 and the Network Time Protocol (NTP). Since accurate 198 determination of the time may be important to operation of the 199 applications running on the host (including security 200 services), configuration of time servers may be a prerequisite 201 for higher layer operation. However, it is typically not a 202 requirement for Internet layer configuration. 204 Other service configuration 205 This can include discovery of additional servers and devices, 206 such as printers, Session Initiation Protocol (SIP) proxies, 207 etc. 209 2. Principles 211 This section describes basic principles of Internet host 212 configuration. 214 2.1. Minimize Configuration 216 Anything that can be configured can be misconfigured. RFC 1958 217 [RFC1958] Section 3.8 states: "Avoid options and parameters whenever 218 possible. Any options and parameters should be configured or 219 negotiated dynamically rather than manually." 221 That is, to minimize the possibility of configuration errors, 222 parameters should be automatically computed (or at least have 223 reasonable defaults) whenever possible. For example, the 224 Transmission Control Protocol (TCP) [RFC793] does not require 225 configuration of the Maximum Segment Size, but is able to compute an 226 appropriate value. 228 Some protocols support self-configuration mechanisms, such as 229 capability negotiation or discovery of other hosts that implement the 230 same protocol. 232 2.2. Less is More 234 The availability of standardized, simple mechanisms for general- 235 purpose Internet host configuration is highly desirable. RFC 1958 236 [RFC1958] states, "Performance and cost must be considered as well as 237 functionality" and "Keep it simple. When in doubt during design, 238 choose the simplest solution." 240 To allow protocol support in more types of devices, it is important 241 to minimize the footprint requirement. For example, Internet hosts 242 span a wide range of devices, from embedded devices operating with 243 minimal footprint to supercomputers. Since the resources (e.g. 244 memory and code size) available for host configuration may be very 245 small, it is desirable for a host to be able to configure itself in 246 as simple a manner as possible. 248 One interesting example is IP support in pre-boot execution 249 environments. Since by definition boot configuration is required in 250 hosts that have not yet fully booted, it is often necessary for pre- 251 boot code to be executed from Read Only Memory (ROM), with minimal 252 available memory. In PXE, prior to obtaining a boot image, the host 253 is typically only able to communicate using IP and the User Datagram 254 Protocol (UDP). This is one reason why Internet layer configuration 255 mechanisms typically depend only on IP and UDP. After obtaining the 256 boot image, the host will have the full facilities of TCP/IP 257 available to it, including support for reliable transport protocols, 258 IPsec, etc. 260 In order to reduce complexity, it is desirable for Internet layer 261 configuration mechanisms to avoid dependencies on higher layers. 262 Since embedded hosts may wish to minimize the code included within a 263 boot ROM, availability of higher layer facilities cannot be 264 guaranteed during Internet layer configuration. In fact, it cannot 265 even be guaranteed that all Internet layer facilities will be 266 available. For example, IP fragmentation and reassembly may not work 267 reliably until a host has obtained an IP address. 269 2.3. Diversity is Not a Benefit 271 The number of host configuration mechanisms should be minimized. 272 Diversity in Internet host configuration mechanisms presents several 273 problems: 275 Interoperability 276 As configuration diversity increases, it becomes likely that a 277 host will not support the configuration mechanism(s) available 278 on the network to which it has attached, creating 279 interoperability problems. 281 Footprint In order to interoperate, hosts need to implement all 282 configuration mechanisms used on the link layers they support. 283 This increases the required footprint, a burden for embedded 284 devices. 286 Redundancy 287 To support diversity in host configuration mechanisms, 288 operators would need to support multiple configuration 289 services to ensure that hosts connecting to their networks 290 could configure themselves. This represents an additional 291 expense for little benefit. 293 Latency As configuration diversity increases, hosts supporting 294 multiple configuration mechanisms may spend increasing effort 295 to determine which mechanism(s) are supported. This adds to 296 configuration latency. 298 Conflicts Whenever multiple mechanisms are available, it is possible 299 that multiple configuration(s) will be returned. To handle 300 this, hosts would need to merge potentially conflicting 301 configurations. This would require conflict resolution logic, 302 such as ranking of potential configuration sources, increasing 303 implementation complexity. 305 Additional traffic 306 To limit configuration latency, hosts may simultaneously 307 attempt to obtain configuration by multiple mechanisms. This 308 can result in increasing on-the-wire traffic, both from use of 309 multiple mechanisms as well as from retransmissions within 310 configuration mechanisms not implemented on the network. 312 Security Support for multiple configuration mechanisms increases the 313 attack surface of the host. 315 2.4. Lower Layer Independence 317 RFC 1958 [RFC1958] states, "Modularity is good. If you can keep 318 things separate, do so." 320 It is becoming increasingly common for hosts to support multiple 321 network access mechanisms, including dialup, wireless and wired local 322 area networks, wireless metropolitan and wide area networks, etc. As 323 a result, it is desirable for hosts to be able to configure 324 themselves on multiple networks without adding configuration code 325 specific to a new link layer. 327 As a result, it is highly desirable for Internet host configuration 328 mechanisms to be independent of the underlying lower layer. That is, 329 the link layer protocol (whether it be a physical link, or a virtual 330 tunnel link) should only be explicitly aware of link-layer parameters 331 (although it may configure link-layer parameters - see Section 2.1). 332 Introduction of lower layer dependencies increases the likelihood of 333 interoperability problems and adds to the number of Internet layer 334 configuration mechanisms that hosts need to implement. 336 Lower layer dependencies can be best avoided by keeping Internet host 337 configuration above the link layer, thereby enabling configuration to 338 be handled for any link layer that supports IP. In order to provide 339 media independence, Internet host configuration mechanisms should be 340 link-layer protocol independent. 342 While there are examples of IP address assignment within the link 343 layer (such as in the Point-to-Point Protocol (PPP) IPv4CP 344 [RFC1332]), the disadvantages of this approach have now become 345 apparent. The main disadvantages include the extra complexity of 346 implementing different mechanisms on different link layers, and the 347 difficulty in adding new parameters which would require defining a 348 mechanism in each link layer protocol. 350 For example, PPP IPv4CP and Internet Protocol Control Protocol (IPCP) 351 extensions for name service configuration [RFC1877] were developed at 352 a time when the Dynamic Host Configuration Protocol (DHCP) [RFC2131] 353 had not yet been widely implemented on access devices or in service 354 provider networks. However, in IPv6 where link layer independent 355 mechanisms such as stateless address configuration [RFC4862] and 356 DHCPv6 [RFC3736] are available, PPP IPv6CP [RFC5072] instead simply 357 configures an Interface-Identifier which is similar to a MAC address. 358 This enables PPP IPv6CP to avoid having to duplicate DHCPv6 359 functionality. 361 In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306] 362 utilizes the same approach as PPP IPv4CP by defining a Configuration 363 Payload for Internet host configuration for both IPv4 and IPv6. As 364 pointed out in [RFC3456], leveraging DHCP has advantages in terms of 365 address management integration, address pool management, 366 reconfiguration and fail-over. On the other hand, the IKEv2 approach 367 reduces the number of exchanges. 369 Extensions to link layer protocols for the purpose of Internet, 370 transport or application layer configuration (including server 371 configuration) should be avoided. Such extensions can negatively 372 affect the properties of a link as seen by higher layers. For 373 example, if a link layer protocol (or tunneling protocol) configures 374 individual IPv6 addresses and precludes using any other addresses, 375 then applications that desire "Privacy Extensions for Stateless 376 Address Autoconfiguration in IPv6" [RFC4941] may not function well. 377 Similar issues may arise for other types of addresses, such as 378 Cryptographically Generated Addresses [RFC3972]. 380 Avoiding lower layer dependencies is desirable even where the lower 381 layer is link independent. For example, while the Extensible 382 Authentication Protocol (EAP) [RFC3748] may be run over any link 383 satisfying the requirements of [RFC3748] Section 3.1, many link 384 layers do not support EAP and therefore Internet layer configuration 385 mechanisms with EAP dependencies would not be usable on all links 386 that support IP. 388 2.5. Configuration is Not Access Control 390 Network access authentication is a distinct problem from Internet 391 host configuration. Network access authentication is best handled 392 independently of the configuration mechanisms in use for the Internet 393 and higher layers. 395 For example, attempting to control access by requiring authentication 396 in order to obtain configuration parameters (such as an IP address) 397 has little value if the user can manually configure the host. Having 398 an Internet (or higher) layer protocol authenticate clients is 399 appropriate to prevent resource exhaustion of a scarce resource on 400 the server, but not for preventing rogue hosts from obtaining access 401 to a link. Note that client authentication is not required for 402 Stateless DHCPv6 [RFC3736] since it does not result in allocation of 403 any limited resources on the server. 405 3. Additional Discussion 407 3.1. General Purpose Mechanisms 409 Protocols should either be self-configuring (especially where fate 410 sharing is important), or use general-purpose configuration 411 mechanisms (such as DHCP or a service discovery protocol, as noted in 412 Section 3.2). The choice should be made taking into account the 413 architectural principles discussed in Section 2. 415 Given the number of Internet host configuration mechanisms that have 416 already been defined, there is no justification for hard coding of 417 service IP addresses or domain names. Taking into account the 418 problems resulting from the proliferation of these mechanisms, there 419 is no apparent need for the development of additional general-purpose 420 configuration mechanisms. 422 When defining a new host parameter, protocol designers should first 423 consider whether configuration is indeed necessary (see Section 2.1). 424 If configuration is necessary, in addition to considering fate 425 sharing (see Section 3.3), protocol designers should consider: 427 1. The organizational implications for administrators. For 428 example, routers and servers are often administered by 429 different sets of individuals, so that configuring a router 430 with server parameters may require cross-group collaboration. 432 2. Whether the parameter is a per-interface or a global 433 parameter. For example, most standard general purpose 434 configuration protocols run on a per-interface basis and hence 435 are more appropriate for per-interface parameters. 437 3.2. Service Discovery 439 Higher-layer configuration often includes configuring server 440 addresses. The question arises as to how this differs from "service 441 discovery" as provided by Service Discovery protocols such as the 442 Service Location Protocol Version 2 (SLPv2) [RFC2608]. 444 In general-purpose configuration mechanisms such as DHCP, server 445 instances are considered equivalent. In service discovery protocols, 446 on the other hand, a host desires to find a server satisfying a 447 particular set of criteria, which may vary by request. 449 Service discovery protocols such as SLPv2 can support discovery of 450 servers on the Internet [RFC3832], not just those within the local 451 administrative domain. General-purpose configuration mechanisms such 452 as DHCP, on the other hand, typically assume the server(s) in the 453 local administrative domain contain the authoritative set of 454 information. 456 For the service discovery problem (i.e., where the criteria varies on 457 a per-request basis, even from the same host), protocols should 458 either be self-discovering (if fate sharing is critical), or use 459 general purpose service discovery mechanisms. 461 In order to avoid a dependency on multicast routing, it is necessary 462 for a host to either restrict discovery to services on the local link 463 or to discover the location of a Directory Agent (DA). Therefore the 464 use of service discovery protocols beyond the local link is typically 465 dependent on a parameter configuration mechanism. As a result, 466 service discovery protocols are typically not appropriate for use in 467 obtaining basic Internet layer configuration, although they can be 468 used to obtain higher-layer configuration for parameters that don't 469 meet the assumptions above made by general-purpose configuration 470 mechanisms. 472 3.2.1. Fate Sharing 474 If a server (or set of servers) is needed to get a set of 475 configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is 476 preserved if the servers are ones without which the parameters could 477 not be used, even if they were obtained via other means. The 478 possibility of incorrect information being configured is minimized if 479 there is only one machine which is authoritative for the information 480 (i.e., there is no need to keep multiple authoritative servers in 481 sync). For example, learning default gateways via Router 482 Advertisements provides perfect fate sharing. That is, gateway 483 addresses can be obtained if and only if they can actually be used. 484 Similarly, obtaining DNS server configuration from a DNS server would 485 provide fate sharing since the configuration would only be obtainable 486 if the DNS server were available. 488 While fate sharing is a desirable property of a configuration 489 mechanism, in many situations fate sharing is imperfect or 490 unavailable. When utilized to discover services on the local link, 491 service discovery protocols typically provide for fate sharing, since 492 hosts providing service information typically also provide the 493 services. However, where service discovery is assisted by a DA, the 494 ability to discover services is dependent on whether the DA is 495 operational, even though the DA is typically not involved in the 496 delivery of the service. Since the DA's list of operational servers 497 may not be current, it is possible for the DA to provide clients with 498 service information that is out of date. For example, service 499 descriptions provided to the DA by servers might be included in 500 response to service discovery queries sent by clients even after the 501 servers were no longer operational. Similarly, recently introduced 502 servers might not yet have registered themselves with the DA. Thus, 503 fate sharing can be imperfect. 505 Similar limitations exist for other server-based configuration 506 mechanisms such as DHCP. Typically DHCP servers do not check for the 507 liveness of the configuration information they provide, or do not 508 discover new configuration information automatically. As a result, 509 there is no guarantee that configuration information will be current. 511 "IPv6 Host configuration of DNS Server Information Approaches" 512 [RFC4339] Section 3.3 discusses the use of well-known anycast 513 addresses for discovery of DNS servers. The use of anycast addresses 514 enables fate sharing, even where the anycast address is provided by 515 an unrelated server. However, in order to be universally useful, 516 this approach would require allocation of a well-known anycast 517 address for each service. 519 3.2.2. Discovering Names vs. Addresses 521 In discovering servers other than name resolution servers, it is 522 possible to either discover the IP addresses of the server(s), or to 523 discover a name that resolves to a list of addresses. 525 It is typically more secure and efficient to obtain the list of 526 addresses directly, since this avoids the extra name resolution step 527 and the accompanying latency, security and fate sharing issues. 529 In obtaining the IP addresses for a set of servers, it is desirable 530 to distinguish which IP addresses belong to which servers. If a 531 server IP address is unreachable, this enables the host to try the IP 532 address of another server, rather than another IP address of the same 533 server, in case the server is down. This can be enabled by 534 distinguishing which addresses belong to the same server. 536 4. Security Considerations 538 Secure IP configuration presents a number of challenges. In addition 539 to denial-of-service and man-in-the-middle attacks, attacks on 540 configuration mechanisms may target particular parameters. For 541 example, attackers may target DNS server configuration in order to 542 support subsequent phishing or pharming attacks. A number of issues 543 exist with various classes of parameters, as discussed in Section 544 2.6, [RFC3756] Section 4.2.7, [RFC3118] Section 1.1, and [RFC3315] 545 Section 23. Given the potential vulnerabilities resulting from 546 implementation of these options, it is currently common for hosts to 547 restrict support for DHCP options to the minimum set required to 548 provide basic TCP/IP configuration. 550 Since boot configuration determines the boot image to be run by the 551 host, a successful attack on boot configuration could result in an 552 attacker gaining complete control over a host. As a result, it is 553 particularly important that boot configuration be secured. 555 4.1. Configuration Authentication 557 The techniques available for securing Internet layer configuration 558 are limited, since transmission layer security protocols such as 559 IPsec [RFC4301] or TLS [RFC4346] cannot be used until an IP address 560 has been configured. As a result, configuration security is 561 typically implemented within the configuration protocols themselves. 563 PPP [RFC1661] does not support secure negotiation within IPv4CP 564 [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to 565 the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] 566 provides encryption, integrity and replay protection for 567 configuration exchanges. 569 In situations where link layer security is provided, and the Network 570 Access Server (NAS) acts as a DHCP relay or server, protection can be 571 provided against rogue DHCP servers, provided that the NAS filters 572 incoming DHCP packets from unauthorized sources. However, explicit 573 dependencies on lower layer security mechanisms are limited by the 574 "lower layer independence" principle (see Section 2.4). 576 Internet layer secure configuration mechanisms include SEcure 577 Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address 578 autoconfiguration [RFC4862], or DHCP authentication for stateful 579 address configuration. DHCPv4 [RFC2131] initially did not include 580 support for security; this was added in [RFC3118]. DHCPv6 [RFC3315] 581 included security support. However, DHCP authentication is not 582 widely implemented for either DHCPv4 or DHCPv6. 584 Higher layer configuration can make use of a wider range of security 585 techniques. When DHCP authentication is supported, higher-layer 586 configuration parameters provided by DHCP can be secured. However, 587 even if a host does not support DHCPv6 authentication, higher-layer 588 configuration via Stateless DHCPv6 [RFC3736] can still be secured 589 with IPsec. 591 Possible exceptions can exist where security facilities are not 592 available until later in the boot process. It may be difficult to 593 secure boot configuration even once the Internet layer has been 594 configured, if security functionality is not available until after 595 boot configuration has been completed. For example, it is possible 596 that Kerberos, IPsec or TLS will not be available until later in the 597 boot process. 599 Where public key cryptography is used to authenticate and integrity 600 protect configuration, hosts need to be configured with trust anchors 601 in order to validate received configuration messages. For a node 602 that visits multiple administrative domains, acquiring the required 603 trust anchors may be difficult. This is left as an area for future 604 work. 606 5. IANA Considerations 608 This document has no actions for IANA. 610 6. References 612 6.1. Informative References 614 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. 615 http://files.multicastdns.org/draft-cheshire-dnsext- 616 multicastdns.txt 618 [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment 619 (PXE) Specification", September 1999, 620 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 622 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 623 September 1981. 625 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 626 Projects Agency, Internet Activities Board, and End-to-End 627 Services Task Force, "Protocol standard for a NetBIOS service 628 on a TCP/UDP transport: Concepts and methods", STD 19, RFC 629 1001, March 1987. 631 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 632 Merit, May 1992. 634 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 635 1350, July 1992. 637 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 638 1661, July 1994. 640 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions 641 for Name Server Addresses", RFC 1877, December 1995. 643 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 644 1958, June 1996. 646 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 647 March 1997. 649 [RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2", 650 RFC 2608, June 1999. 652 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 653 RFC 3118, June 2001. 655 [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. 656 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 657 (DHCPv6)", RFC 3315, July 2003. 659 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 660 2002. 662 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host 663 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 664 Mode", RFC 3456, January 2003. 666 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 667 C., Eisler, M. and D. Noveck, "Network File System (NFS) 668 version 4 Protocol", RFC 3530, April 2003. 670 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. 671 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 672 RFC 3720, April 2004. 674 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 675 (DHCP) Service for IPv6", RFC 3736, April 2004. 677 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 678 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 679 3748, June 2004. 681 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 682 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 684 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 685 IPv6", RFC 3775, June 2004. 687 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. 688 Jerome, "Remote Service Discovery in the Service Location 689 Protocol (SLP) via DNS SRV", RFC 3832, July 2004. 691 [RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 692 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 693 2005. 695 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 696 3972, March 2005. 698 [RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping 699 Clients using the iSCSI Protocol", RFC 4173, September 2005. 701 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 702 Protocol", RFC 4301, December 2005. 704 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 705 4306, December 2005. 707 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information 708 Approaches", RFC 4339, February 2006. 710 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 711 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 713 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 714 Protocol (DHCP) Options for the Intel Preboot eXecution 715 Environment (PXE)", RFC 4578, November 2006. 717 [RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-Local Multicast 718 Name Resolution (LLMNR)", RFC 4795, January 2007. 720 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address 721 Autoconfiguration", RFC 4862, September 2007. 723 [RFC4941] Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions 724 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 725 September 2007. 727 [RFC5072] Varada, S., Haskins D. and E. Allen, "IP Version 6 over PPP", 728 RFC 5072, September 2007. 730 Acknowledgments 732 Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola and James Kempf 733 provided valuable input on this document. 735 Appendix A - IAB Members at the time of this writing 737 Loa Andersson 738 Leslie Daigle 739 Elwyn Davies 740 Kevin Fall 741 Olaf Kolkman 742 Barry Leiba 743 Kurtis Lindqvist 744 Danny McPherson 745 David Oran 746 Eric Rescorla 747 Dave Thaler 748 Lixia Zhang 750 Authors' Addresses 752 Bernard Aboba 753 Microsoft Corporation 754 One Microsoft Way 755 Redmond, WA 98052 757 EMail: bernarda@microsoft.com 758 Phone: +1 425 706 6605 759 Fax: +1 425 936 7329 761 Dave Thaler 762 Microsoft Corporation 763 One Microsoft Way 764 Redmond, WA 98052 766 EMail: dthaler@microsoft.com 768 Loa Andersson 769 Acreo AB 771 EMail: loa@pi.se 773 Full Copyright Statement 775 Copyright (C) The IETF Trust (2008). 777 This document is subject to the rights, licenses and restrictions 778 contained in BCP 78, and except as set forth therein, the authors 779 retain all their rights. 781 This document and the information contained herein are provided on an 782 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 783 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 784 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 785 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 786 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 787 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 789 Intellectual Property 791 The IETF takes no position regarding the validity or scope of any 792 Intellectual Property Rights or other rights that might be claimed to 793 pertain to the implementation or use of the technology described in 794 this document or the extent to which any license under such rights 795 might or might not be available; nor does it represent that it has 796 made any independent effort to identify any such rights. Information 797 on the procedures with respect to rights in RFC documents can be 798 found in BCP 78 and BCP 79. 800 Copies of IPR disclosures made to the IETF Secretariat and any 801 assurances of licenses to be made available, or the result of an 802 attempt made to obtain a general license or permission for the use of 803 such proprietary rights by implementers or users of this 804 specification can be obtained from the IETF on-line IPR repository at 805 http://www.ietf.org/ipr. 807 The IETF invites any interested party to bring to its attention any 808 copyrights, patents or patent applications, or other proprietary 809 rights that may cover technology that may be required to implement 810 this standard. Please address the information to the IETF at 811 ietf-ipr@ietf.org. 813 Acknowledgment 815 Funding for the RFC Editor function is currently provided by the 816 Internet Society.