idnits 2.17.1 draft-iab-ip-config-00.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 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. 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 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 (==), 19 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 7 Internet Architecture Board 9 Principles of Internet Host Configuration 10 draft-iab-ip-config-00.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 April 11, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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 Protocols ........................ 10 58 3.3 Fate Sharing ....................................... 11 59 4. Security Considerations .................................. 12 60 4.1 Configuration Authentication ....................... 13 61 5. IANA Considerations ...................................... 14 62 6. References ............................................... 14 63 6.1 Informative References ............................. 14 64 Acknowledgments .............................................. 16 65 Appendix A - IAB Members ..................................... 16 66 Authors' Addresses ........................................... 17 67 Full Copyright Statement ..................................... 18 68 Intellectual Property ........................................ 18 69 1. Introduction 71 This document describes principles of Internet host configuration. 72 It covers issues relating to configuration of Internet layer 73 parameters, as well as parameters affecting higher layer protocols. 75 In recent years, a number of architectural questions have arisen, for 76 which we provide guidance to protocol developers: 78 o What protocol layers and general approaches are most appropriate 79 for configuration of various parameters. 81 o The relationship between parameter configuration and service 82 discovery. 84 o The relationship between network access authentication and host 85 configuration. 87 o The role of link-layer protocols and tunneling protocols 88 in Internet host configuration. 90 The role of the link-layer and tunneling protocols is particularly 91 important, since it can affect the properties of a link as seen by 92 higher layers (for example, whether privacy extensions specified in 93 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" 94 [RFC3041] are available to applications). 96 1.1. Terminology 98 link A communication facility or medium over which nodes can 99 communicate at the link-layer, i.e., the layer immediately 100 below IP. Examples are Ethernets (simple or bridged), PPP 101 links, X.25, Frame Relay, or ATM networks as well as internet 102 (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 103 itself. 105 on link An address that is assigned to an interface on a specified 106 link. 108 off link The opposite of "on link"; an address that is not assigned to 109 any interfaces on the specified link. 111 Internet layer configuration is defined as the configuration required 112 to support the operation of the Internet layer. This includes IP 113 address(es), subnet prefix(es), default gateway(s), mobility 114 agent(s), boot service configuration and other parameters. 116 IP address(es) 117 Internet Protocol (IP) address configuration includes both 118 configuration of link-scope addresses as well as global 119 addresses. Configuration of IP addresses is an important 120 step, since this enables a host to fill in the source address 121 in the packets it sends, as well as to receive packets 122 destined to that address. As a result, the host can receive 123 unicast IP packets, rather than requiring that IP packets be 124 sent to the broadcast or multicast address. Configuration of 125 an IP address also enables the use of IP fragmentation, since 126 packets sent from the unknown address cannot be reliably 127 reassembled (since fragments from multiple hosts using the 128 unknown address might be reassembled into a single IP packet). 129 Configuration of an IP address also enables use of Internet 130 layer security facilities such as IPsec specified in "Security 131 Architecture for the Internet Protocol" [RFC4301]. 133 Subnet prefix(es) 134 Once a subnet prefix is configured, hosts with an IP address 135 can exchange unicast IP packets with on-link hosts. 137 Default gateway(s) 138 Once a default gateway is configured, hosts with an IP address 139 can send and receive unicast IP packets from off-link hosts, 140 assuming unobstructed connectivity. 142 Mobility agent(s) 143 While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] include 144 their own mechanisms for locating home agents, it is also 145 possible for mobile nodes to utilize dynamic home agent 146 configuration. 148 Other parameters 149 Internet layer parameter configuration also includes 150 configuration of per-host parameters (e.g. hostname) and per- 151 interface parameters (e.g. IP Time-To-Live (TTL), 152 enabling/disabling of IP forwarding and source routing, and 153 Maximum Transmission Unit (MTU)). 155 Boot service configuration 156 Boot service configuration is defined as the configuration 157 necessary for a host to obtain and perhaps also to verify an 158 appropriate boot image. This is appropriate for diskless 159 hosts looking to obtain a boot image via mechanisms such as 160 the Trivial File Transfer Protocol (TFTP) [RFC1350], Network 161 File System (NFS) [RFC3530] and Internet Small Computer 162 Systems Interface (iSCSI) [RFC3720][RFC4173]. It also may be 163 useful in situations where it is necessary to update the boot 164 image of a host that supports a disk, such as in the Preboot 165 eXecution Environment (PXE) [PXE][RFC4578]. While strictly 166 speaking boot services operate above the Internet layer, where 167 boot service is used to obtain the Internet layer code, it may 168 be considered part of Internet layer configuration. 170 Higher-layer configuration is defined as the configuration required 171 to support the operation of other components above the Internet 172 layer. This includes, for example: 174 Name Service Configuration 175 The configuration required for the host to resolve names. 176 This includes configuration of the addresses of name 177 resolution servers, including IEN 116, Domain Name Service 178 (DNS), Windows Internet Name Service (WINS), Internet Storage 179 Name Service (iSNS) and Network Information Service (NIS) 180 servers, and the setting of name resolution parameters such as 181 the NetBIOS node type, the DNS domain and search list, etc. 182 It may also include the transmission or setting of the host's 183 own name. Note that Link local name resolution services (such 184 as NetBIOS [RFC1001], LLMNR [RFC4795] and mDNS [mDNS]) 185 typically do not require configuration. 187 Once the host has completed name service configuration, it is 188 capable of resolving names using name resolution protocols 189 that require configuration. This not only allows the host to 190 communicate with off-link hosts whose IP address is not known, 191 but to the extent that name services requiring configuration 192 are utilized for service discovery, this also enables the host 193 to discover services available on the network or elsewhere. 195 Time Service Configuration 196 Time service configuration includes configuration of servers 197 for protocols such as the Simple Network Time Protocol (SNTP) 198 and the Network Time Protocol (NTP). Since accurate 199 determination of the time may be important to operation of the 200 applications running on the host (including security 201 services), configuration of time servers may be a prerequisite 202 for higher layer operation. However, it is typically not a 203 requirement for Internet layer configuration. 205 Other service configuration 206 This can include discovery of additional servers and devices, 207 such as printers, Session Initiation Protocol (SIP) proxies, 208 etc. 210 2. Principles 212 This section describes basic principles of Internet host 213 configuration. 215 2.1. Minimize Configuration 217 Anything that can be configured can be misconfigured. RFC 1958 218 [RFC1958] Section 3.8 states: "Avoid options and parameters whenever 219 possible. Any options and parameters should be configured or 220 negotiated dynamically rather than manually." 222 That is, to minimize the possibility of configuration errors, 223 parameters should be automatically computed (or at least have 224 reasonable defaults) whenever possible. For example, the 225 Transmission Control Protocol (TCP) [RFC793] does not require 226 configuration of the Maximum Segment Size, but is able to compute an 227 appropriate value. 229 Some protocols support self-configuration mechanisms, such as 230 capability negotiation or discovery of other hosts that implement the 231 same protocol. 233 2.2. Less is More 235 The availability of standardized, simple mechanisms for general- 236 purpose Internet host configuration is highly desirable. RFC 1958 237 [RFC1958] states, "Performance and cost must be considered as well as 238 functionality" and "Keep it simple. When in doubt during design, 239 choose the simplest solution." 241 To allow protocol support in more types of devices, it is important 242 to minimize the footprint requirement. For example, Internet hosts 243 span a wide range of devices, from embedded devices operating with 244 minimal footprint to supercomputers. Since the resources (e.g. 245 memory and code size) available for host configuration may be very 246 small, it is desirable for a host to be able to configure itself in 247 as simple a manner as possible. 249 One interesting example is IP support in pre-boot execution 250 environments. Since by definition boot configuration is required in 251 hosts that have not yet fully booted, it is often necessary for pre- 252 boot code to be executed from Read Only Memory (ROM), with minimal 253 available memory. In PXE, prior to obtaining a boot image, the host 254 is typically only able to communicate using IP and the User Datagram 255 Protocol (UDP). This is one reason why Internet layer configuration 256 mechanisms typically depend only on IP and UDP. After obtaining the 257 boot image, the host will have the full facilities of TCP/IP 258 available to it, including support for reliable transport protocols, 259 IPsec, etc. 261 In order to reduce complexity, it is desirable for Internet layer 262 configuration mechanisms to avoid dependencies on higher layers. 263 Since embedded hosts may wish to minimize the code included within a 264 boot ROM, availability of higher layer facilities cannot be 265 guaranteed during Internet layer configuration. In fact, it cannot 266 even be guaranteed that all Internet layer facilities will be 267 available. For example, IP fragmentation and reassembly may not work 268 reliably until a host has obtained an IP address. 270 2.3. Diversity is Not a Benefit 272 The number of host configuration mechanisms should be minimized. 273 Diversity in Internet host configuration mechanisms presents several 274 problems: 276 Interoperability 277 As configuration diversity increases, it becomes likely that a 278 host will not support the configuration mechanism(s) available 279 on the network to which it has attached, creating 280 interoperability problems. 282 Footprint In order to interoperate, hosts need to implement all 283 configuration mechanisms used on the link layers they support. 284 This increases the required footprint, a burden for embedded 285 devices. 287 Redundancy 288 To support diversity in host configuration mechanisms, 289 operators would need to support multiple configuration 290 services to ensure that hosts connecting to their networks 291 could configure themselves. This represents an additional 292 expense for little benefit. 294 Latency As configuration diversity increases, hosts supporting 295 multiple configuration mechanisms may spend increasing effort 296 to determine which mechanism(s) are supported. This adds to 297 configuration latency. 299 Conflicts Whenever multiple mechanisms are available, it is possible 300 that multiple configuration(s) will be returned. To handle 301 this, hosts would need to merge potentially conflicting 302 configurations. This would require conflict resolution logic, 303 such as ranking of potential configuration sources, increasing 304 implementation complexity. 306 Additional traffic 307 To limit configuration latency, hosts may simultaneously 308 attempt to obtain configuration by multiple mechanisms. This 309 can result in increasing on-the-wire traffic, both from use of 310 multiple mechanisms as well as from retransmissions within 311 configuration mechanisms not implemented on the network. 313 Security Support for multiple configuration mechanisms increases the 314 attack surface of the host. 316 2.4. Lower Layer Independence 318 RFC 1958 [RFC1958] states, "Modularity is good. If you can keep 319 things separate, do so." 321 It is becoming increasingly common for hosts to support multiple 322 network access mechanisms, including dialup, wireless and wired local 323 area networks, wireless metropolitan and wide area networks, etc. As 324 a result, it is desirable for hosts to be able to configure 325 themselves on multiple networks without adding configuration code 326 specific to a new link layer. 328 As a result, it is highly desirable for Internet host configuration 329 mechanisms to be independent of the underlying lower layer. That is, 330 the link layer protocol (whether it be a physical link, or a virtual 331 tunnel link) should only be explicitly aware of link-layer parameters 332 (although it may configure link-layer parameters - see Section 2.1). 333 Introduction of lower layer dependencies increases the likelihood of 334 interoperability problems and adds to the number of Internet layer 335 configuration mechanisms that hosts need to implement. 337 Lower layer dependencies can be best avoided by keeping Internet host 338 configuration above the link layer, thereby enabling configuration to 339 be handled for any link layer that supports IP. In order to provide 340 media independence, Internet host configuration mechanisms should be 341 link-layer protocol independent. 343 While there are examples of IP address assignment within the link 344 layer (such as in the Point-to-Point Protocol (PPP) IPv4CP 345 [RFC1332]), the disadvantages of this approach have now become 346 apparent. The main disadvantages include the extra complexity of 347 implementing different mechanisms on different link layers, and the 348 difficulty in adding new parameters which would require defining a 349 mechanism in each link layer protocol. 351 For example, PPP IPv4CP and Internet Protocol Control Protocol (IPCP) 352 extensions for name service configuration [RFC1877] were developed at 353 a time when the Dynamic Host Configuration Protocol (DHCP) [RFC2131] 354 had not yet been widely implemented on access devices or in service 355 provider networks. However, in IPv6 where link layer independent 356 mechanisms such as stateless address configuration [RFC2462] and 357 DHCPv6 [RFC3736] are available, PPP IPv6CP [RFC2472] instead simply 358 configures an Interface-Identifier which is similar to a MAC address. 359 This enables PPP IPv6CP to avoid having to duplicate DHCPv6 360 functionality. 362 In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306] 363 utilizes the same approach as PPP IPv4CP by defining a Configuration 364 Payload for Internet host configuration for both IPv4 and IPv6. As 365 pointed out in [RFC3456], leveraging DHCP has advantages in terms of 366 address management integration, address pool management, 367 reconfiguration and fail-over. On the other hand, the IKEv2 approach 368 reduces the number of exchanges. 370 Extensions to link layer protocols for the purpose of Internet, 371 transport or application layer configuration (including server 372 configuration) should be avoided. Such extensions can negatively 373 affect the properties of a link as seen by higher layers. For 374 example, if a link layer protocol (or tunneling protocol) configures 375 individual IPv6 addresses and precludes using any other addresses, 376 then applications that desire privacy extensions [RFC3041] may not 377 function well. Similar issues may arise for other types of 378 addresses, such as 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 usable on all links that 386 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 Protocols 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 the Directory Agent (DA). Therefore 464 the use of service discovery protocols beyond the local link is 465 typically dependent on a parameter configuration mechanism. As a 466 result, service discovery protocols are typically not appropriate for 467 use in obtaining basic Internet layer configuration, although they 468 can be used to obtain higher-layer configuration for parameters that 469 don't meet the assumptions above made by general-purpose 470 configuration mechanisms. 472 3.3. 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 and service agents (SAs) can 497 be out of synchronization, it is possible for the DA to provide user 498 agents (UAs) with service information that is no longer current. For 499 example, service descriptions provided to the DA by SAs might be 500 included in response to service discovery queries sent by UAs even 501 after the SAs were no longer operational. Similarly, recently 502 introduced SAs might not yet have registered their services with the 503 DA. Thus, 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 4. Security Considerations 521 Secure IP configuration presents a number of challenges. Secure 522 configuration mechanisms include SEcure Neighbor Discovery (SEND) 523 [RFC3971] for stateless address autoconfiguration, or DHCP 524 authentication for stateful address configuration. DHCPv4 [RFC2131] 525 initially did not include support for security; this was added in 526 [RFC3118]. DHCPv6 [RFC3736] included security support. However, 527 DHCP authentication is not widely implemented for either DHCPv4 or 528 DHCPv6. 530 PPP [RFC1661] does not support secure negotiation within IPv4CP 531 [RFC1332] or IPv6CP [RFC2472], enabling an attacker with access to 532 the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] 533 provides encryption, integrity and replay protection for 534 configuration exchanges. 536 A number of issues exist with various classes of parameters, as 537 discussed in Section 2.6, [RFC3756] Section 4.2.7, [RFC3118] Section 538 1.1, and [RFC3315] Section 23. Given the potential vulnerabilities 539 resulting from implementation of these options, it is currently 540 common for hosts to restrict support for DHCP options to the minimum 541 set required to provide basic TCP/IP configuration. 543 4.1. Configuration Authentication 545 In addition to denial-of-service and man-in-the-middle attacks, 546 attacks on configuration mechanisms may target particular parameters. 547 Since boot configuration determines the boot image to be run by the 548 host, a successful attack on boot configuration could result in an 549 attacker gaining complete control over a host. As a result, it is 550 particularly important that boot configuration be secured. 552 The techniques available for securing Internet layer configuration 553 are inherently limited, since classic security protocols such as 554 IPsec [RFC4301] or TLS [RFC4346] cannot be used since an IP address 555 is not yet available. 557 In situations where link layer security is provided, and the Network 558 Access Server (NAS) acts as a DHCP relay or server, protection can be 559 provided against rogue DHCP servers, provided that the NAS filters 560 incoming DHCP packets from unauthorized sources. However, explicit 561 dependencies on lower layer security mechanisms are limited by the 562 "lower layer independence" principle (section 2.4). 564 As a result, configuration security is typically implemented within 565 the configuration protocols themselves. For example, IPv6 supports 566 SEcure Neighbor Discovery (SEND) [RFC3971], DHCPv4 supports DHCP 567 authentication [RFC3118], and DHCPv6 supports an equivalent facility 568 [RFC3315]. 570 Higher layer configuration typically does not have this problem. 571 When DHCP authentication is supported, higher-layer configuration 572 parameters provided by DHCP can be secured. However, even if a host 573 does not support DHCPv6 authentication, higher-layer configuration 574 via Stateless DHCPv6 [RFC2462] can still be secured with IPsec. 575 Possible exceptions can exist where security facilities are not 576 available until later in the boot process. 578 For example, it may be difficult to secure boot configuration even 579 once the Internet layer has been configured, if security 580 functionality is not available until after boot configuration has 581 been completed. For example, it is possible that Kerberos, IPsec or 582 TLS will not be available until later in the boot process. 584 Where public key cryptography is used to authenticate and integrity 585 protect configuration, hosts need to be configured with trust anchors 586 in order to validate received configuration messages. For a node 587 that visits multiple administrative domains, acquiring the required 588 trust anchors may be difficult. This is left as an area for future 589 work. 591 5. IANA Considerations 593 This document has no actions for IANA. 595 6. References 597 6.1. Informative References 599 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. 600 http://files.multicastdns.org/draft-cheshire-dnsext- 601 multicastdns.txt 603 [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment 604 (PXE) Specification", September 1999, 605 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 607 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 608 September 1981. 610 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 611 Projects Agency, Internet Activities Board, and End-to-End 612 Services Task Force, "Protocol standard for a NetBIOS service 613 on a TCP/UDP transport: Concepts and methods", STD 19, RFC 614 1001, March 1987. 616 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 617 Merit, May 1992. 619 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 620 1350, July 1992. 622 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 623 1661, July 1994. 625 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions 626 for Name Server Addresses", RFC 1877, December 1995. 628 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 629 1958, June 1996. 631 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 632 March 1997. 634 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 635 Autoconfiguration", RFC 2462, December 1998. 637 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 638 December 1998. 640 [RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2", 641 RFC 2608, June 1999. 643 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless 644 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 646 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 647 RFC 3118, June 2001. 649 [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. 650 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 651 (DHCPv6)", RFC 3315, July 2003. 653 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 654 2002. 656 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host 657 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 658 Mode", RFC 3456, January 2003. 660 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 661 C., Eisler, M. and D. Noveck, "Network File System (NFS) 662 version 4 Protocol", RFC 3530, April 2003. 664 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. 665 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 666 RFC 3720, April 2004. 668 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 669 (DHCP) Service for IPv6", RFC 3736, April 2004. 671 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 672 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 673 3748, June 2004. 675 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 676 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 678 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 679 IPv6", RFC 3775, June 2004. 681 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. 682 Jerome, "Remote Service Discovery in the Service Location 683 Protocol (SLP) via DNS SRV", RFC 3832, July 2004. 685 [RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 686 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 687 2005. 689 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 690 3972, March 2005. 692 [RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping 693 Clients using the iSCSI Protocol", RFC 4173, September 2005. 695 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 696 Protocol", RFC 4301, December 2005. 698 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 699 4306, December 2005. 701 [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information 702 Approaches", RFC 4339, February 2006. 704 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 705 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 707 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 708 Protocol (DHCP) Options for the Intel Preboot eXecution 709 Environment (PXE)", RFC 4578, November 2006. 711 [RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-Local Multicast 712 Name Resolution (LLMNR)", RFC 4795, January 2007. 714 Acknowledgments 716 Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola and James Kempf 717 provided valuable input on this document. 719 Appendix A - IAB Members at the time of this writing 721 Loa Andersson 722 Leslie Daigle 723 Elwyn Davies 724 Kevin Fall 725 Olaf Kolkman 726 Barry Leiba 727 Kurtis Lindqvist 728 Danny McPherson 729 David Oran 730 Eric Rescorla 731 Dave Thaler 732 Lixia Zhang 734 Authors' Addresses 736 Bernard Aboba 737 Microsoft Corporation 738 One Microsoft Way 739 Redmond, WA 98052 741 EMail: bernarda@microsoft.com 742 Phone: +1 425 706 6605 743 Fax: +1 425 936 7329 745 Dave Thaler 746 Microsoft Corporation 747 One Microsoft Way 748 Redmond, WA 98052 750 EMail: dthaler@microsoft.com 752 Loa Andersson 753 Acreo AB 755 EMail: loa@pi.se 757 Full Copyright Statement 759 Copyright (C) The IETF Trust (2007). 761 This document is subject to the rights, licenses and restrictions 762 contained in BCP 78, and except as set forth therein, the authors 763 retain all their rights. 765 This document and the information contained herein are provided on an 766 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 767 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 768 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 769 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 770 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 771 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 773 Intellectual Property 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org. 797 Acknowledgment 799 Funding for the RFC Editor function is currently provided by the 800 Internet Society.