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