idnits 2.17.1 draft-iab-ip-config-01.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 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. 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: August 11, 2008 Loa Andersson 6 11 February 2008 Acreo AB 7 Internet Architecture Board 9 Principles of Internet Host Configuration 10 draft-iab-ip-config-01.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 August 11, 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 [RFC4941] may not 376 function well. Similar issues may arise for other types of 377 addresses, such as Cryptographically Generated Addresses [RFC3972]. 379 Avoiding lower layer dependencies is desirable even where the lower 380 layer is link independent. For example, while the Extensible 381 Authentication Protocol (EAP) [RFC3748] may be run over any link 382 satisfying the requirements of [RFC3748] Section 3.1, many link 383 layers do not support EAP and therefore Internet layer configuration 384 mechanisms with EAP dependencies would not usable on all links that 385 support IP. 387 2.5. Configuration is Not Access Control 389 Network access authentication is a distinct problem from Internet 390 host configuration. Network access authentication is best handled 391 independently of the configuration mechanisms in use for the Internet 392 and higher layers. 394 For example, attempting to control access by requiring authentication 395 in order to obtain configuration parameters (such as an IP address) 396 has little value if the user can manually configure the host. Having 397 an Internet (or higher) layer protocol authenticate clients is 398 appropriate to prevent resource exhaustion of a scarce resource on 399 the server, but not for preventing rogue hosts from obtaining access 400 to a link. Note that client authentication is not required for 401 Stateless DHCPv6 [RFC3736] since it does not result in allocation of 402 any limited resources on the server. 404 3. Additional Discussion 406 3.1. General Purpose Mechanisms 408 Protocols should either be self-configuring (especially where fate 409 sharing is important), or use general-purpose configuration 410 mechanisms (such as DHCP or a service discovery protocol, as noted in 411 Section 3.2). The choice should be made taking into account the 412 architectural principles discussed in Section 2. 414 Given the number of Internet host configuration mechanisms that have 415 already been defined, there is no justification for hard coding of 416 service IP addresses or domain names. Taking into account the 417 problems resulting from the proliferation of these mechanisms, there 418 is no apparent need for the development of additional general-purpose 419 configuration mechanisms. 421 When defining a new host parameter, protocol designers should first 422 consider whether configuration is indeed necessary (see Section 2.1). 423 If configuration is necessary, in addition to considering fate 424 sharing (see Section 3.3), protocol designers should consider: 426 1. The organizational implications for administrators. For 427 example, routers and servers are often administered by 428 different sets of individuals, so that configuring a router 429 with server parameters may require cross-group collaboration. 431 2. Whether the parameter is a per-interface or a global 432 parameter. For example, most standard general purpose 433 configuration protocols run on a per-interface basis and hence 434 are more appropriate for per-interface parameters. 436 3.2. Service Discovery 438 Higher-layer configuration often includes configuring server 439 addresses. The question arises as to how this differs from "service 440 discovery" as provided by Service Discovery protocols such as the 441 Service Location Protocol Version 2 (SLPv2) [RFC2608]. 443 In general-purpose configuration mechanisms such as DHCP, server 444 instances are considered equivalent. In service discovery protocols, 445 on the other hand, a host desires to find a server satisfying a 446 particular set of criteria, which may vary by request. 448 Service discovery protocols such as SLPv2 can support discovery of 449 servers on the Internet [RFC3832], not just those within the local 450 administrative domain. General-purpose configuration mechanisms such 451 as DHCP, on the other hand, typically assume the server(s) in the 452 local administrative domain contain the authoritative set of 453 information. 455 For the service discovery problem (i.e., where the criteria varies on 456 a per-request basis, even from the same host), protocols should 457 either be self-discovering (if fate sharing is critical), or use 458 general purpose service discovery mechanisms. 460 In order to avoid a dependency on multicast routing, it is necessary 461 for a host to either restrict discovery to services on the local link 462 or to discover the location of a Directory Agent (DA). Therefore the 463 use of service discovery protocols beyond the local link is typically 464 dependent on a parameter configuration mechanism. As a result, 465 service discovery protocols are typically not appropriate for use in 466 obtaining basic Internet layer configuration, although they can be 467 used to obtain higher-layer configuration for parameters that don't 468 meet the assumptions above made by general-purpose configuration 469 mechanisms. 471 3.2.1. Fate Sharing 473 If a server (or set of servers) is needed to get a set of 474 configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is 475 preserved if the servers are ones without which the parameters could 476 not be used, even if they were obtained via other means. The 477 possibility of incorrect information being configured is minimized if 478 there is only one machine which is authoritative for the information 479 (i.e., there is no need to keep multiple authoritative servers in 480 sync). For example, learning default gateways via Router 481 Advertisements provides perfect fate sharing. That is, gateway 482 addresses can be obtained if and only if they can actually be used. 483 Similarly, obtaining DNS server configuration from a DNS server would 484 provide fate sharing since the configuration would only be obtainable 485 if the DNS server were available. 487 While fate sharing is a desirable property of a configuration 488 mechanism, in many situations fate sharing is imperfect or 489 unavailable. When utilized to discover services on the local link, 490 service discovery protocols typically provide for fate sharing, since 491 hosts providing service information typically also provide the 492 services. However, where service discovery is assisted by a DA, the 493 ability to discover services is dependent on whether the DA is 494 operational, even though the DA is typically not involved in the 495 delivery of the service. Since the DA's list of operational servers 496 may not be current, it is possible for the DA to provide clients with 497 service information that is out of date. For example, service 498 descriptions provided to the DA by servers might be included in 499 response to service discovery queries sent by clients even after the 500 servers were no longer operational. Similarly, recently introduced 501 servers might not yet have registered themselves with the DA. Thus, 502 fate sharing can be imperfect. 504 Similar limitations exist for other server-based configuration 505 mechanisms such as DHCP. Typically DHCP servers do not check for the 506 liveness of the configuration information they provide, or do not 507 discover new configuration information automatically. As a result, 508 there is no guarantee that configuration information will be current. 510 "IPv6 Host configuration of DNS Server Information Approaches" 511 [RFC4339] Section 3.3 discusses the use of well-known anycast 512 addresses for discovery of DNS servers. The use of anycast addresses 513 enables fate sharing, even where the anycast address is provided by 514 an unrelated server. However, in order to be universally useful, 515 this approach would require allocation of a well-known anycast 516 address for each service. 518 3.2.2. Discovering Names vs. Addresses 520 In discovering servers other than name resolution servers, it is 521 possible to either discover the IP addresses of the server(s), or to 522 discover a name that resolves to a list of addresses. 524 It is typically more secure and efficient to obtain the list of 525 addresses directly, since this avoids the extra name resolution step 526 and the accompanying latency, security and fate sharing issues. 528 In obtaining the IP addresses for a set of servers, it is desirable 529 to distinguish which IP addresses belong to which servers. If a 530 server IP address is unreachable, this enables the host to try the IP 531 address of another server, rather than another IP address of the same 532 server, in case the server is down. This can be enabled by 533 distinguishing which addresses belong to the same server. 535 4. Security Considerations 537 Secure IP configuration presents a number of challenges. In addition 538 to denial-of-service and man-in-the-middle attacks, attacks on 539 configuration mechanisms may target particular parameters. For 540 example, attackers may target DNS server configuration in order to 541 support subsequent phishing or pharming attacks. A number of issues 542 exist with various classes of parameters, as discussed in Section 543 2.6, [RFC3756] Section 4.2.7, [RFC3118] Section 1.1, and [RFC3315] 544 Section 23. Given the potential vulnerabilities resulting from 545 implementation of these options, it is currently common for hosts to 546 restrict support for DHCP options to the minimum set required to 547 provide basic TCP/IP configuration. 549 Since boot configuration determines the boot image to be run by the 550 host, a successful attack on boot configuration could result in an 551 attacker gaining complete control over a host. As a result, it is 552 particularly important that boot configuration be secured. 554 4.1. Configuration Authentication 556 The techniques available for securing Internet layer configuration 557 are limited, since transmission layer security protocols such as 558 IPsec [RFC4301] or TLS [RFC4346] cannot be used until an IP address 559 has been configured. As a result, configuration security is 560 typically implemented within the configuration protocols themselves. 562 PPP [RFC1661] does not support secure negotiation within IPv4CP 563 [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to 564 the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] 565 provides encryption, integrity and replay protection for 566 configuration exchanges. 568 In situations where link layer security is provided, and the Network 569 Access Server (NAS) acts as a DHCP relay or server, protection can be 570 provided against rogue DHCP servers, provided that the NAS filters 571 incoming DHCP packets from unauthorized sources. However, explicit 572 dependencies on lower layer security mechanisms are limited by the 573 "lower layer independence" principle (see Section 2.4). 575 Internet layer secure configuration mechanisms include SEcure 576 Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address 577 autoconfiguration [RFC4862], or DHCP authentication for stateful 578 address configuration. DHCPv4 [RFC2131] initially did not include 579 support for security; this was added in [RFC3118]. DHCPv6 [RFC3315] 580 included security support. However, DHCP authentication is not 581 widely implemented for either DHCPv4 or DHCPv6. 583 Higher layer configuration can make use of a wider range of security 584 techniques. When DHCP authentication is supported, higher-layer 585 configuration parameters provided by DHCP can be secured. However, 586 even if a host does not support DHCPv6 authentication, higher-layer 587 configuration via Stateless DHCPv6 [RFC3736] can still be secured 588 with IPsec. 590 Possible exceptions can exist where security facilities are not 591 available until later in the boot process. It may be difficult to 592 secure boot configuration even once the Internet layer has been 593 configured, if security functionality is not available until after 594 boot configuration has been completed. For example, it is possible 595 that Kerberos, IPsec or TLS will not be available until later in the 596 boot process. 598 Where public key cryptography is used to authenticate and integrity 599 protect configuration, hosts need to be configured with trust anchors 600 in order to validate received configuration messages. For a node 601 that visits multiple administrative domains, acquiring the required 602 trust anchors may be difficult. This is left as an area for future 603 work. 605 5. IANA Considerations 607 This document has no actions for IANA. 609 6. References 611 6.1. Informative References 613 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. 614 http://files.multicastdns.org/draft-cheshire-dnsext- 615 multicastdns.txt 617 [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment 618 (PXE) Specification", September 1999, 619 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 621 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 622 September 1981. 624 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 625 Projects Agency, Internet Activities Board, and End-to-End 626 Services Task Force, "Protocol standard for a NetBIOS service 627 on a TCP/UDP transport: Concepts and methods", STD 19, RFC 628 1001, March 1987. 630 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 631 Merit, May 1992. 633 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 634 1350, July 1992. 636 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 637 1661, July 1994. 639 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions 640 for Name Server Addresses", RFC 1877, December 1995. 642 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 643 1958, June 1996. 645 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 646 March 1997. 648 [RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2", 649 RFC 2608, June 1999. 651 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 652 RFC 3118, June 2001. 654 [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. 655 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 656 (DHCPv6)", RFC 3315, July 2003. 658 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 659 2002. 661 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host 662 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 663 Mode", RFC 3456, January 2003. 665 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 666 C., Eisler, M. and D. Noveck, "Network File System (NFS) 667 version 4 Protocol", RFC 3530, April 2003. 669 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. 670 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 671 RFC 3720, April 2004. 673 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 674 (DHCP) Service for IPv6", RFC 3736, April 2004. 676 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 677 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 678 3748, June 2004. 680 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 681 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 683 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 684 IPv6", RFC 3775, June 2004. 686 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. 687 Jerome, "Remote Service Discovery in the Service Location 688 Protocol (SLP) via DNS SRV", RFC 3832, July 2004. 690 [RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 691 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 692 2005. 694 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 695 3972, March 2005. 697 [RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping 698 Clients using the iSCSI Protocol", RFC 4173, September 2005. 700 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 701 Protocol", RFC 4301, December 2005. 703 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 704 4306, December 2005. 706 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information 707 Approaches", RFC 4339, February 2006. 709 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 710 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 712 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 713 Protocol (DHCP) Options for the Intel Preboot eXecution 714 Environment (PXE)", RFC 4578, November 2006. 716 [RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-Local Multicast 717 Name Resolution (LLMNR)", RFC 4795, January 2007. 719 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address 720 Autoconfiguration", RFC 4862, September 2007. 722 [RFC4941] Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions 723 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 724 September 2007. 726 [RFC5072] Varada, S., Haskins D. and E. Allen, "IP Version 6 over PPP", 727 RFC 5072, September 2007. 729 Acknowledgments 731 Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola and James Kempf 732 provided valuable input on this document. 734 Appendix A - IAB Members at the time of this writing 736 Loa Andersson 737 Leslie Daigle 738 Elwyn Davies 739 Kevin Fall 740 Olaf Kolkman 741 Barry Leiba 742 Kurtis Lindqvist 743 Danny McPherson 744 David Oran 745 Eric Rescorla 746 Dave Thaler 747 Lixia Zhang 749 Authors' Addresses 751 Bernard Aboba 752 Microsoft Corporation 753 One Microsoft Way 754 Redmond, WA 98052 756 EMail: bernarda@microsoft.com 757 Phone: +1 425 706 6605 758 Fax: +1 425 936 7329 760 Dave Thaler 761 Microsoft Corporation 762 One Microsoft Way 763 Redmond, WA 98052 765 EMail: dthaler@microsoft.com 767 Loa Andersson 768 Acreo AB 770 EMail: loa@pi.se 772 Full Copyright Statement 774 Copyright (C) The IETF Trust (2008). 776 This document is subject to the rights, licenses and restrictions 777 contained in BCP 78, and except as set forth therein, the authors 778 retain all their rights. 780 This document and the information contained herein are provided on an 781 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 782 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 783 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 784 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 785 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 786 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 788 Intellectual Property 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Acknowledgment 814 Funding for the RFC Editor function is currently provided by the 815 Internet Society.