idnits 2.17.1 draft-ietf-ipsec-dhcp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 507 has weird spacing: '...ade any secur...' == Line 537 has weird spacing: '...imed to perta...' == Line 775 has weird spacing: '...>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 587, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 590, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 1877 (ref. '7') == Outdated reference: A later version (-12) exists of draft-ietf-dhc-failover-08 -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2402 (ref. '9') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '11') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '12') (Obsoleted by RFC 4306) == Outdated reference: A later version (-02) exists of draft-dukes-ike-mode-cfg-00 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-06) exists of draft-ietf-dhc-pv4-reconfigure-04 -- Possible downref: Non-RFC (?) normative reference: ref. '18' == Outdated reference: A later version (-07) exists of draft-ietf-dhc-csr-04 == Outdated reference: A later version (-04) exists of draft-ietf-ipsra-reqmts-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsra-reqmts (ref. '21') ** Downref: Normative reference to an Informational RFC: RFC 2230 (ref. '23') Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group Baiju Patel 3 INTERNET-DRAFT Intel 4 Category: Standards Track Bernard Aboba 5 Microsoft 6 Scott Kelly 7 RedCreek Communications 8 Vipul Gupta 9 Sun Microsystems, Inc. 11 DHCPv4 Configuration of IPsec Tunnel Mode 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 This document is an Internet-Draft. Internet-Drafts are working docu- 17 ments of the Internet Engineering Task Force (IETF), its areas, and its 18 working groups. Note that other groups may also distribute working 19 documents as Internet-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 material 24 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 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 In many remote access scenarios, a mechanism for making the remote host 39 appear to be present on the local corporate network is quite useful. 40 This may be accomplished by assigning the host a "virtual" address from 41 the corporate network, and then tunneling traffic via IPsec from the 42 host's ISP-assigned address to the corporate security gateway. In IPv4, 43 Dynamic Host Configuration Protocol (DHCP) provides for such remote host 44 configuration. This draft explores the requirements for host 45 configuration in IPsec tunnel mode, and describes how DHCPv4 may be 46 leveraged for configuration. 48 Table of contents 50 1 Introduction........................................... 2 51 1.1 Terminology............................................ 2 52 1.2 Requirements Language.................................. 3 53 2.0 IPsec tunnel mode configuration requirements........... 3 54 2.1 DHCP configuration evaluation.......................... 3 55 2.2 Summary................................................ 4 56 3.0 Scenario overview...................................... 4 57 3.1 Configuration walk-through............................. 5 58 4.0 Detailed description................................... 6 59 4.1 DHCPDISCOVER message processing........................ 7 60 4.2 DHCP Relay behavior.................................... 9 61 4.3 DHCPREQUEST message processing......................... 10 62 4.4 DHCPACK message processing............................. 10 63 4.5 Configuration policy................................... 10 64 5.0 Security Considerations................................ 11 65 6.0 IANA Considerations.................................... 11 66 7.0 Intellectual Property Statement........................ 12 67 8.0 References............................................. 12 68 9.0 Acknowledgments........................................ 14 69 10.0 Author's Address...................................... 14 70 11.0 Appendix - IKECFG evaluation.......................... 15 71 12.0 Full Copyright Statement ............................. 16 73 1. Introduction 75 In many remote access scenarios, a mechanism for making the remote host 76 appear to be present on the local corporate network is quite useful. 77 This may be accomplished by assigning the host a "virtual" address from 78 the corporate network, and then tunneling traffic via IPsec from the 79 host's ISP-assigned address to the corporate security gateway. In IPv4, 80 Dynamic Host Configuration Protocol (DHCP) [3] provides for such remote 81 host configuration. This draft explores the requirements for host 82 configuration in IPsec tunnel mode, and describes how DHCPv4 may be 83 leveraged for configuration. 85 1.1. Terminology 87 This document uses the following terms: 89 DHCP client 90 A DHCP client or "client" is an Internet host using DHCP to 91 obtain configuration parameters such as a network address. 93 DHCP server 94 A DHCP server or "server" is an Internet host that returns 95 configuration parameters to DHCP clients. 97 1.2. Requirements language 99 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 100 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 101 described in [1]. 103 2. IPsec tunnel mode configuration requirements 105 As described in [21], the configuration requirements of a host with an 106 IPsec tunnel mode interface include the need to obtain an IPv4 address 107 and other configuration parameters appropriate to the class of host. In 108 addition to meeting the basic requirements [21], the following 109 additional capabilities may be desirable: 111 a. integration with existing IPv4 address management facilities 112 b. support for address pool management 113 c. reconfiguration when required 114 d. support for fail-over 115 e. maintaining security and simplicity in the IKE implementation. 116 f. authentication where required 118 2.1. DHCP configuration evaluation 120 Leveraging DHCP for configuration of IPsec tunnel mode meets the basic 121 requirements described in [21]. It also provides the additional 122 capabilities described above. 124 Basic configuration 125 In IPv4, leveraging DHCPv4 [3] for the configuration of IPsec 126 tunnel mode satisfies the basic requirements described in 127 [21]. Since the required configuration parameters described 128 in [21] are a subset of those already supported in DHCPv4 129 options [5], no new DHCPv4 options are required, and no 130 modifications to DHCPv4 [3] are required. 132 Address management integration 133 Since DHCPv4 is widely deployed for address management today, 134 reuse of DHCPv4 for IPsec tunnel mode address management 135 enables compatibility and integration with existing addressing 136 implementations and IPv4 address management software. 138 Address pool management 139 As described in [18], DHCPv4 implementations support 140 conditional behavior so that the address and configuration 141 parameters assigned can be dependent on parameters included in 142 the DHCPDISCOVER. This makes it possible for the security 143 gateway to ensure that the remote host receives an IP address 144 assignment from the appropriate address pool, such as via the 145 User Class option, described in [16]. 147 Reconfiguration 148 DHCP supports the concept of configuration leases, and there 149 is a proposal for handling forced reconfiguration [14]. 151 Fail-over support 152 When leveraging DHCPv4, configuration and addressing state is 153 kept on the DHCP server, not within the IKE implementation. As 154 a result, the loss of a tunnel server does not result in the 155 loss of configuration and addressing state, thus making it 156 easier to support fail-over [8]. 158 Security and simplicity 159 Leveraging DHCPv4 also makes it easier to maintain security in 160 the IKE implementation since no IKE modifications are required 161 to support configuration. 163 Authentication 164 Where DHCPv4 authentication [6] is required, this can be 165 supported on an IPsec tunnel mode interface as it would be on 166 any other interface. 168 2.2. Summary 170 As described, DHCPv4 [3] meets the IPsec tunnel mode configuration 171 requirements [21], as well as providing additional capabilities. As 172 described in the Appendix, IKECFG [13] does not meet the basic 173 requirements, nor does it provide the additional capabilities. As a 174 result, DHCPv4 is the superior alternative for IPsec tunnel mode 175 configuration. 177 3. Scenario overview 179 IPsec [2], [9]-[12] is a protocol suite defined to secure communication 180 at the network layer between communicating peers. Among many 181 applications enabled by IPsec, a useful application is to connect a 182 remote host to a corporate intranet via a security gateway, using IPsec 183 tunnel mode. This host is then configured in such a manner so as to 184 provide it with a virtual presence on the internal network. This is 185 accomplished in the following manner: 187 A remote host on the Internet will connect to the security gateway and 188 then establish an IPsec tunnel to it. The remote host then interacts 189 via the IPsec tunnel with a DHCPv4 server which provides the remote host 190 with an address from the corporate network address space. The remote 191 host subsequently uses this as the source address for all interactions 192 with corporate resources. Note that this implies that the corporate 193 security gateway continues to recognize the host's original, routable IP 194 address as the tunnel endpoint. The virtual identity assumed by the 195 remote host when using the assigned address appears to the corporate 196 network as though it were situated behind a security gateway bearing the 197 original routable IP address. All the traffic between the remote host 198 and the intranet will be carried over the IPsec tunnel via the security 199 gateway as shown below: 201 corporate net 202 +------------------+ | 203 | externally | +--------+ | !~~~~~~~~~~! 204 |+-------+ visible | | | | ! rmt host ! 205 ||virtual| host | |security| |---! virtual ! 206 || host | |--------|gateway/| | ! presence ! 207 || |<================>| DHCP |----| !~~~~~~~~~~! 208 |+-------+ |--------| Relay | | 209 +------------------+ ^ +--------+ | +--------+ 210 | |---| DHCPv4 | 211 IPsec tunnel | | server | 212 with encapsulated | +--------+ 213 traffic inside 215 This scenario assumes that the remote host already has Internet 216 connectivity and the host Internet interface is appropriately 217 configured. The mechanisms for configuration of the remote host's 218 address for the Internet interface are well defined; i.e., PPP IP 219 control protocol (IPCP), described in [4], DHCPv4, described in [3], and 220 static addressing. The mechanisms for auto-configuration of the intranet 221 are also standardized. It is also assumed that the remote host has 222 knowledge of the location of the security gateway. This can be 223 accomplished via DNS, using either A, KX [23], or SRV [24] records. 225 A typical configuration of the remote host in this application would use 226 two addresses: 1) an interface to connect to the Internet (Internet 227 interface), and 2) a virtual interface to connect to the intranet 228 (intranet interface). The IP address of the Internet and intranet 229 interfaces are used in the outer and inner headers of the IPsec tunnel 230 mode packet, respectively. 232 3.1. Configuration walk-through 234 The configuration of the intranet interface of the IPsec tunnel mode 235 host is accomplished in the following steps: 237 a. The remote host establishes an IKE security association with 238 the security gateway in a main mode or aggressive mode exchange. 239 This IKE SA then serves to secure additional quick mode IPsec SAs. 241 b. The remote host establishes a DHCP SA with the IPsec tunnel mode 242 server in a quick mode exchange. The DHCP SA is an IPsec tunnel mode 243 SA established to protect initial DHCPv4 traffic between the 244 security gateway and the remote host. The DHCP SA MUST 245 only be used for DHCP traffic. The details of how this 246 SA is set up are described in Section 4.1. 248 c. DHCP messages are sent back and forth between the remote host and the 249 DHCPv4 server. The traffic is protected between the remote host and the 250 security gateway using the DHCP SA established in step b. After 251 the DHCP conversation completes, the remote host's intranet interface 252 obtains an IP address as well as other configuration parameters. 254 d. The remote host MAY request deletion of the DHCP SA since 255 future DHCP messages will be carried over a new IPsec tunnel. 256 Alternatively, the remote host and the security gateway 257 MAY continue to use the same SA for all subsequent traffic 258 by adding temporary SPD selectors in the same manner as is 259 provided for name ID types in [2]. 261 e. If a new IPsec tunnel is required, the remote host establishes 262 a tunnel mode SA to the security gateway in a quick mode exchange. 263 In this case, the new address assigned via DHCPv4 SHOULD be used 264 in the quick mode ID. 266 At the end of the last step, the remote host is ready to communicate 267 with the intranet using an IPsec tunnel. All the IP traffic (including 268 future DHCPv4 messages) between the remote host and the intranet are now 269 tunneled over this IPsec tunnel mode SA. 271 Since the security parameters used for different SAs are based on the 272 unique requirements of the remote host and the security gateway, they 273 are not described in this document. The mechanisms described here work 274 best when the VPN is implemented using a virtual interface. 276 4. Detailed description 278 This section provides details relating to the messages exchanged during 279 the setup and teardown of the DHCP SAs. 281 4.1. DHCPDISCOVER message processing 283 The events begin with the remote host intranet interface generating a 284 DHCPDISCOVER message. Details are described below: 286 FIELD OCTETS DESCRIPTION 287 ----- ------ ----------- 289 op 1 Message op code / message type. 290 1 = BOOTREQUEST, 2 = BOOTREPLY 291 htype 1 Hardware address type. Set to value (TBD) 292 signifying an IPsec tunnel mode virtual interface. 293 hlen 1 Hardware address length 294 hops 1 Client sets to zero, optionally used by relay agents 295 when booting via a relay agent. 296 xid 4 Transaction ID, a random number chosen by the 297 client, used by the client and server to associate 298 messages and responses between a client and a 299 server. 300 secs 2 Filled in by client, seconds elapsed since client 301 began address acquisition or renewal process. 302 flags 2 Flags. Broadcast bit MUST be set to zero. 303 ciaddr 4 Client IP address; only filled in if client is in 304 BOUND, RENEW or REBINDING state. 305 yiaddr 4 'your' (client) IP address. 306 siaddr 4 IP address of next server to use in bootstrap; 307 returned in DHCPOFFER, DHCPACK by server. 308 giaddr 4 Security gateway interface IPv4 address, used in booting 309 via a relay agent. 310 chaddr 16 Client hardware address. Should be unique. 311 sname 64 Optional server host name, null terminated string. 312 file 128 Boot file name, null terminated string; "generic" 313 name or null in DHCPDISCOVER, fully qualified 314 directory-path name in DHCPOFFER. 315 options var Optional parameters field. 317 Table 1: Description of fields in the DHCP message 319 The htype value is set to the value TBD, signifying a virtual IPsec 320 tunnel mode interface, in order to enable the DHCP server to 321 differentiate VPN from non-VPN requests. The chaddr field of the 322 DHCPDISCOVER MUST include an identifier unique to the virtual subnet. 323 The client MUST use the same chaddr field in all subsequent messages 324 within the same DHCPv4 exchange. In addition, the chaddr SHOULD be 325 persistent between reboots so that the DHCP server will be able to re- 326 assign the same address if desired. 328 The hlen and chaddr fields SHOULD be determined as follows: 330 a. If one or more LAN interfaces are available, the hlen and chaddr 331 fields SHOULD be determined from the active LAN interface with 332 the lowest interface number. If no active LAN interface is 333 available, then the parameters SHOULD be determined from the LAN 334 interface with the lowest interface number. This enables the 335 chaddr to be persistent between reboots, as long as the LAN 336 interface hardware is not removed. 338 b. If there is no LAN interface, the chaddr field SHOULD be 339 determined by concatenating x'4000', the IPv4 address of the 340 interface supplying network connectivity, and an additional 341 octet. The x'4000' value indicates a locally administered 342 unicast MAC address, thus guaranteeing that the constructed 343 chaddr value will not conflict with a globally assigned value. 345 The additional octet (which MAY represent an interface number) 346 SHOULD be persistent between reboots, so that the chaddr value 347 will be persistent across reboots if the assigned IPv4 348 address remains consistent. 350 If the above prescription is followed, then the chaddr will always be 351 unique on the virtual subnet provided that the remote host only brings 352 up a single tunnel to the security gateway. Where a LAN interface is 353 available, the chaddr will be globally unique. When a non-LAN interface 354 is available and a unique Internet address is assigned to the remote 355 host, the chaddr will also be globally unique. Where a private IP 356 address [22] is assigned to a non-LAN interface, it will not be globally 357 unique. However, in this case packets will not be routed back and forth 358 between the remote host and the security gateway unless the external 359 network and corporate network have a consistent addressing plan. In 360 this case the private IP address assigned to the remote host will be 361 unique on the virtual subnet. 363 For use in DHCPv4 configuration of IPsec tunnel mode, the client- 364 identifier option MUST be unique within the virtual subnet and SHOULD be 365 persistent across reboots. Possibilities include: 367 a. The htype/chaddr combination. If assigned as described above, 368 this will be unique on the virtual subnet. It will be 369 persistent across reboots for a LAN interface. If a 370 non-LAN interface is used, it may not be persistent across 371 reboots if the assigned IP address changes. 373 b. The machine FQDN concatenated with an interface number. 374 Assuming that the machine FQDN does not conflict with that 375 of another machine, this will be unique on the virtual 376 subnet as well as persistent across reboots. 378 c. The user NAI concatenated with an interface number. Assuming 379 that the user is only connected to the VPN at one location, 380 this will be unique on the subnet as well as persistent across 381 reboots. 383 In order to deliver the DHCPDISCOVER packet from the intranet interface 384 to the security gateway, an IKE Phase 1 SA is established between the 385 Internet interface and the security gateway. A phase 2 (quick mode) DHCP 386 SA tunnel mode SA is then established. The key lifetime for the DHCP SA 387 SHOULD be on the order of minutes since it will only be temporary. The 388 remote host SHOULD use an IDci payload of 0.0.0.0/UDP/port 68 in the 389 quick mode exchange. The security gateway will use an IDcr payload of 390 its own Internet address/UDP/port 67 The DHCP SA is established as a 391 tunnel mode SA with filters set as follows: 393 From remote host to security gateway: Any to Any, destination: UDP port 67 394 From security gateway to remote host: Any to Any, destination: UDP port 68 396 Note that these filters will work not only for a client without 397 configuration, but also with a client that has previously obtained a 398 configuration lease, and is attempting to renew it. In the latter case, 399 the DHCP SA will initially be used to send a DHCPREQUEST rather than a 400 DHCPDISCOVER message. The initial DHCPv4 message (DHCPDISCOVER or 401 DHCPREQUEST) is then tunneled to the security gateway using the tunnel 402 mode SA. Note that since the DHCPDISCOVER packet has a broadcast address 403 destination, the IPsec implementations on both the remote host and the 404 security gateway must be capable of handling this. 406 4.2. DHCP Relay behavior 408 While other configurations are possible, typically the DHCPv4 server 409 will not reside on the same machine as the security gateway, which will 410 act as a DHCPv4 relay, inserting its address in the "giaddr" field. In 411 this case, the security gateway relays packets between the client and 412 the DHCPv4 server, but does not request or renew addresses on the 413 client's behalf. While acting as a DHCP Relay, the security gateway MAY 414 implement DHCP Relay load balancing as described in [19]. 416 Since DHCP Relays are stateless, the security gateway SHOULD insert 417 appropriate information in the DHCP message prior to forwarding to one 418 or more DHCP servers. This enables the security gateway to route the 419 corresponding DHCPOFFER message(s) back to the remote host on the 420 correct IPsec tunnel, without having to keep state gleaned from the 421 DISCOVER, such as a table of the xid, chaddr and tunnel. 423 If the security gateway maintains a separate subnet for each IPsec 424 tunnel, then this can be accomplished by inserting the appropriate 425 interface address in the giaddr field. Alternatively, the security 426 gateway can utilize the DHCP Relay Agent Information Option [17]. In 427 this case, the virtual port number of the tunnel is inserted in the 428 Agent Circuit ID Sub-option (sub-option code 1). 430 To learn the internal IP address of the client in order to route packets 431 to it, the security gateway will typically snoop the yiaddr field within 432 the DHCPACK and plumb a corresponding route as part of DHCP Relay 433 processing. 435 Where allocating a separate subnet for each tunnel is not feasible, and 436 the DHCP server does not support the Relay Agent Information Option, 437 stateless Relay Agent behavior will not be possible. In such cases, 438 implementations MAY devise a mapping between the xid, chaddr, and tunnel 439 in order to route the DHCP server response to the appropriate tunnel 440 endpoint. Note that this is particularly undesirable in large VPN 441 servers where the resulting state will be substantial. 443 4.3. DHCPREQUEST message processing 445 After the Internet interface has received the DHCPOFFER message, it 446 forwards this to the intranet interface after IPsec processing. The 447 intranet interface then responds by creating a DHCPREQUEST message, 448 which is tunneled to security gateway using the DHCP SA. 450 4.4. DHCPACK message processing 452 The DHCPv4 server then replies with a DHCPACK or DHCPNAK message, which 453 is forwarded down the DHCP SA by the security gateway. The remote host 454 Internet interface then forwards the DHCPACK or DHCPNAK message to the 455 intranet interface after IPsec processing. 457 After processing of the DHCPACK, the intranet interface is configured 458 and the Internet interface can establish a new IPsec tunnel mode SA to 459 the security gateway. The remote host may now delete the DHCP tunnel 460 mode SA. All future DHCP messages sent by the client, including 461 DHCPREQUEST, DHCPINFORM, DHCPDECLINE, and DHCPRELEASE messages will use 462 the newly established VPN SA. Similarly, all DHCP messages subsequently 463 sent by the DHCPv4 server will be forwarded by the security gateway 464 (acting as a DHCP Relay) using the IPsec tunnel mode SA, including 465 DHCPOFFER, DHCPACK, and DHCPNAK messages. 467 It SHOULD be possible to configure the remote host to forward all 468 Internet-bound traffic through the tunnel. While this adds overhead to 469 round-trips between the remote host and the Internet, it provides some 470 added security in return for this, in that the corporate security 471 gateway may now filter traffic as it would if the remote host were 472 physically located on the corporate network. 474 4.5. Configuration policy 476 Several mechanisms can be used to enable remote hosts to be assigned 477 different configurations. For example, clients may use the User Class 478 Option [16] to request various configuration profiles. The DHCPv4 479 server may also take a number of other variables into account, including 480 the htype/chaddr; the host name option; the client-identifier option; 481 the DHCP Relay Agent Information option [17]; the vendor-class- 482 identifier option; the vendor-specific information option; or the subnet 483 selection option [15]. 485 Conditional configuration of clients, described in [18], can be used to 486 solve a number of problems, including assignment of options based on the 487 client operating system; assignment of groups of clients to address 488 ranges subsequently used to determine quality of service; allocation of 489 special address ranges for remote hosts; assignment of static routes to 490 clients [20], etc. As noted in the security considerations, these 491 mechanisms, while useful, do not enhance security since they can be 492 evaded by a remote host choosing its own IP address. 494 5. Security Considerations 496 This protocol is secured using IPsec, and as a result the DHCP packets 497 flowing between the remote host and the security gateway are 498 authenticated and integrity protected. 500 However, since the security gateway acts as a DHCP Relay, no protection 501 is afforded the DHCP packets in the portion of the path between the 502 security gateway and the DHCP server, unless DHCP authentication is 503 used. 505 Note that authenticated DHCP cannot be used as an access control 506 mechanism. This is because a remote host can always set its own IP 507 address and thus evade any security measures based on DHCP 508 authentication. 510 As a result, the assigned address MUST NOT be depended upon for 511 security. Instead, the security gateway can use other techniques such as 512 instantiating packet filters or quick mode selectors on a per-tunnel 513 basis. 515 As described in [17], a number of issues arise when forwarding DHCP 516 client requests from untrusted sources. These include DHCP exhaustion 517 attacks, and spoofing of the client identifier option or client MAC 518 address. These issues can be partially addressed through use of the DHCP 519 Relay Information Option [17]. 521 6. IANA Considerations 523 This draft requires that an htype value be allocated for use with IPsec 524 tunnel mode, as described in section 4.1. Note that DHCP relies on the 525 arp-parameters registry for definition of both the hrd parameter in ARP 526 and the htype parameter in BOOTP/DHCP. As a result, an assignment in the 527 arp-parameters registry is required, even though IPsec-DHCP will never 528 use that parameter for ARP purposes, since conceptually BOOTP/DHCP and 529 ARP share the arp-parameters registry. 531 This draft does not create any new number spaces for IANA 532 administration. 534 7. Intellectual Property Statement 536 The IETF takes no position regarding the validity or scope of any 537 intellectual property or other rights that might be claimed to pertain 538 to the implementation or use of the technology described in this 539 document or the extent to which any license under such rights might or 540 might not be available; neither does it represent that it has made any 541 effort to identify any such rights. Information on the IETF's 542 procedures with respect to rights in standards-track and standards- 543 related documentation can be found in BCP-11. Copies of claims of 544 rights made available for publication and any assurances of licenses to 545 be made available, or the result of an attempt made to obtain a general 546 license or permission for the use of such proprietary rights by 547 implementors or users of this specification can be obtained from the 548 IETF Secretariat. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary rights 552 which may cover technology that may be required to practice this 553 standard. Please address the information to the IETF Executive 554 Director. 556 8. References 558 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 559 Levels", BCP 14, RFC 2119, March 1997. 561 [2] Atkinson, R., Kent, S., "Security Architecture for the Internet 562 Protocol", RFC 2401, November 1998. 564 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 565 1997. 567 [4] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", 568 RFC 1332, May 1992. 570 [5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 571 Extensions", RFC 2132, March 1997. 573 [6] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 574 Internet draft (work in progress), draft-ietf-dhc- 575 authentication-16.txt, January 2001. 577 [7] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for 578 Name Server Addresses", RFC 1877, December 1995. 580 [8] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., 581 Dooley, M., Kapur, A., "DHCP Failover Protocol", Internet draft 582 (work in progress), draft-ietf-dhc-failover-08.txt, July 2000. 584 [9] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 585 November 1998. 587 [10] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 588 RFC 2406, November 1998. 590 [11] Piper, D., "The Internet IP Security Domain of Interpretation of 591 ISAKMP", RFC 2407, November 1998. 593 [12] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 594 2409, November 1998. 596 [13] Dukes, D., Pereira, R., "The ISAKMP Configuration Method", Internet 597 draft (work in progress), draft-dukes-ike-mode-cfg-00.txt, October 598 2000. 600 [14] De Schrijver, P., T'Joens, Y., Hublet, C., "Dynamic host 601 configuration : DHCP reconfigure extension", Internet draft (work 602 in progress), draft-ietf-dhc-pv4-reconfigure-04.txt, April 2001. 604 [15] Waters, G., "The IPv4 Subnet Selection Option for DHCP", RFC 3011, 605 November 2000. 607 [16] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., 608 Beser, B., Privat, J., "The User Class Option for DHCP", RFC 3004, 609 November 2000. 611 [17] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 612 January 2001. 614 [18] Droms, R., and Lemon, T., The DHCP Handbook, Macmillan, 615 Indianapolis, Indiana, 1999. 617 [19] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load Balancing 618 Algorithm", RFC 3074, February 2001. 620 [20] Lemon, T., "The Classless Static Route Option for DHCP", Internet 621 draft (work in progress), draft-ietf-dhc-csr-04.txt, February 2001. 623 [21] Kelly, S., Ramamoorthi, S., "Requirements for IPsec Remote Access 624 Scenarios", Internet draft (work in progress), draft-ietf-ipsra- 625 reqmts-03.txt, January 2001. 627 [22] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and E. 628 Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, 629 February 1996. 631 [23] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 632 2230, November 1997. 634 [24] Gulbrandsen , A., . Vixie, P., Esibov, L. "A DNS RR for specifying 635 the location of services (DNS SRV)", RFC 2782, February 2000. 637 9. Acknowledgments 639 This draft has been enriched by comments from John Richardson and 640 Prakash Iyer of Intel, Gurdeep Pall and Peter Ford of Microsoft. 642 10. Authors' Addresses 644 Baiju V. Patel 645 Intel Corp, JF3-206 646 2511 NE 25th Ave 647 Hillsboro, OR 97124 649 Phone: +1 503 264-2422 650 EMail: baiju.v.patel@intel.com 652 Bernard Aboba 653 Microsoft Corporation 654 One Microsoft Way 655 Redmond, WA 98052 657 Phone: +1 425 936-6605 658 EMail: bernarda@microsoft.com 660 Scott Kelly 661 RedCreek Communications 662 3900 Newpark Mall Road 663 Newark, CA 94560 665 Phone: +1 510 745-3969 666 Email: skelly@redcreek.com 668 Vipul Gupta 669 Sun Microsystems, Inc. 670 901 San Antonio Rd. 671 Palo Alto, CA 94303 673 Phone: +1 650 786 3614 674 Fax: +1 650 786 6445 675 EMail: vipul.gupta@eng.sun.com 677 11. Appendix - IKECFG evaluation 679 Alternatives to DHCPv4, such as ISAKMP CFG, described in [13], do not 680 meet the basic requirements described in [21], nor do they provide the 681 additional capabilities of DHCPv4. 683 Basic configuration 684 While ISAKMP CFG can provide for IP address assignment as well 685 as configuration of a few additional parameters such as the 686 DNS server and WINS server addresses, the rich configuration 687 facilities of DHCPv4 are not supported. Past experience with 688 similar configuration mechanisms within PPP IPCP [7] has 689 taught us that it is not viable merely to support minimal 690 configuration. Eventually, either much of the functionality 691 embodied in the DHCPv4 options [5] is duplicated or support 692 for DHCPINFORM [3] will be required. 694 Address management integration 695 Since IKECFG is not integrated with existing IP address 696 management facilities, it is difficult to integrate it with 697 policy management services that may be dependent on the user 698 to IP address binding. 700 Address pool management 701 IKECFG does not provide a mechanism for the remote host to 702 indicate a preference for a particular address pool. This 703 makes it difficult to support address pool management. 705 Reconfiguration 706 IKECFG does not support the concept of configuration leases or 707 reconfiguration. 709 Fail-over support 710 Since IKECFG creates a separate pool of address state, it 711 complicates the provisioning of network utility-class 712 reliability, both in the IP address management system and in 713 the security gateways themselves. 715 Security and simplicity 716 As past history with PPP IPCP demonstrates, once it is decided 717 to provide non-integrated address management and configuration 718 facilities within IKE, it will be difficult to limit the 719 duplication of effort to address assignment. Instead, it will 720 be tempting to also duplicate the configuration, 721 authentication and fail-over facilities of DHCPv4. This 722 duplication will greatly increase the scope of work, 723 eventually compromising the security of IKE. 725 Authentication 726 While IKECFG can support mutual authentication of the IPsec 727 tunnel endpoints, it is difficult to integrate IKECFG with 728 DHCPv4 authentication [6]. This is because the security 729 gateway will not typically have access to the client 730 credentials necessary to issue an DHCPv4 authentication option 731 on the client's behalf. 733 As a result, security gateways implementing IKECFG typically request 734 allocation of an IP address on their own behalf, and then assign this to 735 the client via IKECFG. Since IKECFG does not support the concept of an 736 address lease, the security gateway will need to do the renewal itself. 737 This complicates the renewal process. 739 Since RFC 2131 [3] assumes that a DHCPREQUEST will not contain a filled 740 in giaddr field when generated during RENEWING state, the DHCPACK will 741 be sent directly to the client, which will not be expecting it. As a 742 result, it is either necessary for the security gateway to add special 743 code to avoid forwarding such packets, or to wait until REBINDING state. 744 Since [3] does not specify that the giaddr field cannot be filled in 745 when in the REBINDING state, the security gateway may put its own 746 address in the giaddr field when in REBINDING state, thereby ensuring 747 that it can receive the renewal response without treating it as a 748 special case. 750 12. Full Copyright Statement 752 Copyright (C) The Internet Society (2001). All Rights Reserved. 753 This document and translations of it may be copied and furnished to 754 others, and derivative works that comment on or otherwise explain it or 755 assist in its implementation may be prepared, copied, published and 756 distributed, in whole or in part, without restriction of any kind, 757 provided that the above copyright notice and this paragraph are included 758 on all such copies and derivative works. However, this document itself 759 may not be modified in any way, such as by removing the copyright notice 760 or references to the Internet Society or other Internet organizations, 761 except as needed for the purpose of developing Internet standards in 762 which case the procedures for copyrights defined in the Internet 763 Standards process must be followed, or as required to translate it into 764 languages other than English. The limited permissions granted above are 765 perpetual and will not be revoked by the Internet Society or its 766 successors or assigns. This document and the information contained 767 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 768 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 769 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 770 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 771 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 773 13. Expiration Date 775 This memo is filed as , and expires 776 November 1, 2001.