RFC 3456
Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode
RFC 3456 🎀 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode
okay bestie, this one's from January 2003 📅 and it's a Standards Track doc from the Network Working Group, so it's a real Internet standard and not just vibes ✨. It was written by B. Patel (Intel Corp), B. Aboba (Microsoft), S. Kelly (Airespace), and V. Gupta (Sun Microsystems, Inc.) 👯♀️. The title block doesn't list anything it obsoletes or updates.
Status of this Memo 💅
this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
Copyright Notice 🦋
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract ✨
this memo looks at the requirements for host configuration in IPsec tunnel mode, and it explains how the Dynamic Host Configuration Protocol (DHCPv4) can be used for configuration 🔥. In a lot of remote access setups, it's super useful to make the remote host act like it's sitting on the local corporate network 🏢. To do that, you give the host a "virtual" address from the corporate network, then tunnel its traffic over IPsec from its ISP-assigned address to the corporate security gateway 🚇. In IPv4, DHCP handles this remote host configuration, and it's iconic for it 👑.
Table of Contents 📖
1. Introduction................................................... 2
1.1 Terminology................................................. 2
1.2 Requirements Language....................................... 3
2. IPsec tunnel mode configuration requirements................... 3
2.1 DHCP configuration evaluation............................... 3
2.2 Summary..................................................... 4
3. Scenario overview.............................................. 4
3.1 Configuration walk-through.................................. 5
4. Detailed description........................................... 6
4.1 DHCPDISCOVER message processing............................. 6
4.2 DHCP Relay behavior......................................... 9
4.3 DHCPREQUEST message processing.............................. 10
4.4 DHCPACK message processing.................................. 10
4.5 Configuration policy........................................ 11
5. Security Considerations........................................ 11
6. IANA Considerations............................................ 12
7. Intellectual Property Statement................................ 12
8. References..................................................... 13
8.1 Normative References........................................ 13
8.2 Informative References...................................... 13
9. Acknowledgments................................................ 14
Appendix - IKECFG evaluation...................................... 15
Authors' Addresses................................................ 17
Full Copyright Statement ......................................... 181. Introduction 🌸
in a lot of remote access setups, making the remote host look like it's on the local corporate network is super useful 💖. You do it by giving the host a "virtual" address from the corporate network, then tunneling traffic over IPsec from the host's ISP-assigned address to the corporate security gateway 🔐. In IPv4, Dynamic Host Configuration Protocol (DHCP) [3] handles that remote host configuration 🧚. This document digs into the requirements for host configuration in IPsec tunnel mode, and shows how DHCPv4 can be used for it ✨.
1.1. Terminology 📝
this doc uses the following terms:
DHCP client A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address 💜.
DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients 🍓.
1.2. Requirements language 🎀
okay so the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [1] 🫶.
2. IPsec tunnel mode configuration requirements 💎
as described in [21], a host with an IPsec tunnel mode interface needs to obtain an IPv4 address and other configuration parameters that fit its class of host 🧸. On top of the basic requirements [21], these extra capabilities may be desirable 👑:
- a. integration with existing IPv4 address management facilities
- b. support for address pool management
- c. reconfiguration when required
- d. support for fail-over
- e. maintaining security and simplicity in the IKE implementation
- f. authentication where required
2.1. DHCP configuration evaluation 🔍
using DHCP to configure IPsec tunnel mode meets the basic requirements in [21], and it also gives you those extra capabilities we just talked about 💅.
Basic configuration in IPv4, using DHCPv4 [3] to configure IPsec tunnel mode satisfies the basic requirements in [21] 🌈. The required configuration parameters in [21] are a subset of what DHCPv4 options [4] already support, so no new DHCPv4 options are required, and no modifications to DHCPv4 [3] are required either 🙌.
Address management integration DHCPv4 is widely deployed for address management today 📡, so reusing it for IPsec tunnel mode address management means it plays nicely with existing addressing implementations and IPv4 address management software 🦋.
Address pool management as described in [18], DHCPv4 implementations support conditional behavior, so the address and configuration parameters assigned can depend on parameters included in the DHCPDISCOVER 🧠. This lets the security gateway make sure the remote host gets an IP address from the right address pool, for example through the User Class option described in [16] 🌸.
Reconfiguration DHCP supports the concept of configuration leases, and there's a proposal for handling forced reconfiguration [14] 🔄.
Fail-over support with DHCPv4, configuration and addressing state lives on the DHCP server, not inside the IKE implementation 🏠. So losing a tunnel server doesn't mean losing configuration and addressing state, which makes fail-over easier to support [12] 🛟.
Security and simplicity using DHCPv4 also makes it easier to keep the IKE implementation secure, since no IKE modifications are required to support configuration 🔐.
Authentication where DHCPv4 authentication [5] is required, it can be supported on an IPsec tunnel mode interface the same way it would be on any other interface 🪪.
2.2. Summary 🌟
as described, DHCPv4 [3] meets the IPsec tunnel mode configuration requirements [21] and gives you extra capabilities on top 🎀. As described in the Appendix, IKECFG [13] doesn't meet the basic requirements, and it doesn't provide the additional capabilities either 💀. So DHCPv4 is the superior alternative for IPsec tunnel mode configuration 👑.
3. Scenario overview 🗺️
IPsec [2], [6]-[9] is a protocol suite defined to secure communication at the network layer between communicating peers 🔒. Among the many things IPsec enables, one really useful use case is connecting a remote host to a corporate intranet through a security gateway using IPsec tunnel mode 🏢. The host then gets configured so it has a virtual presence on the internal network 🦋. Here's how that goes down:
a remote host on the Internet connects to the security gateway and then establishes an IPsec tunnel to it 🌐. Through that tunnel, the remote host talks to a DHCPv4 server, which gives it an address from the corporate network address space 💫. After that, the remote host uses that address as the source address for all its interactions with corporate resources 💼. Note that the corporate security gateway keeps recognizing the host's original, routable IP address as the tunnel endpoint 🧐. So the virtual identity the remote host takes on with its assigned address looks, to the corporate network, like it's sitting behind a security gateway that has the original routable IP address (iykyk) 🙈. All the traffic between the remote host and the intranet gets carried over the IPsec tunnel through the security gateway, like this:
corporate net
+------------------+ |
| externally | +--------+ | !~~~~~~~~~~!
|+-------+ visible | | | | ! rmt host !
||virtual| host | |security| |---! virtual !
|| host | |--------|gateway/| | ! presence !
|| |<================>| DHCP |----| !~~~~~~~~~~!
|+-------+ |--------| Relay | |
+------------------+ ^ +--------+ | +--------+
| |---| DHCPv4 |
IPsec tunnel | | server |
with encapsulated | +--------+
traffic insidethis scenario assumes the remote host already has Internet connectivity and its Internet interface is set up properly ⭐. The mechanisms for configuring the remote host's address on the Internet interface are well defined: PPP IP control protocol (IPCP), described in [10], DHCPv4, described in [3], and static addressing 📶. The mechanisms for auto-configuration of the intranet are also standardized 🧩. It's also assumed that the remote host knows where the security gateway is 📍. That can be done via DNS, using A, KX [23], or SRV [24] records 🧁.
a typical setup for the remote host in this application uses two addresses 💅: 1) an interface to connect to the Internet (Internet interface), and 2) a virtual interface to connect to the intranet (intranet interface) 🌈. The IP addresses of the Internet and intranet interfaces go in the outer and inner headers of the IPsec tunnel mode packet, respectively 🫶.
✨ Part 1 of 4 ✨ more parts are coming, so stay tuned, bestie 💖
3.1. Configuration walk-through 🎀
Okay bestie, so here's how the intranet interface of the IPsec tunnel mode host gets set up, step by step. It's giving very organized energy 💅
a. First, the remote host sets up an IKE security association with the security gateway, using either a main mode or aggressive mode exchange. ✨ This IKE SA then basically serves as the secure base that protects any extra quick mode IPsec SAs that come after it. 🫶
b. Next, the remote host makes a DHCP SA with the IPsec tunnel mode server in a quick mode exchange. 🦋 The DHCP SA is an IPsec tunnel mode SA set up to protect the early DHCPv4 traffic between the security gateway and the remote host. The DHCP SA MUST only be used for DHCP traffic. Not me using it for anything else 🙈 The details of how this SA gets set up are in Section 4.1. 💖
c. Now the DHCP messages go back and forth between the remote host and the DHCPv4 server. 🌸 The traffic is protected between the remote host and the security gateway using the DHCP SA from step b. Once the DHCP conversation is done, the remote host's intranet interface gets an IP address plus other configuration parameters. Iconic 👑
d. The remote host MAY request deletion of the DHCP SA, since future DHCP messages will travel over a new IPsec tunnel. 🧚 Or, alternatively, the remote host and the security gateway MAY keep using the same SA for all later traffic, by adding temporary SPD selectors the same way it's done for name ID types in [2]. Main character energy ⭐
e. If a new IPsec tunnel is needed, the remote host sets up a tunnel mode SA to the security gateway in a quick mode exchange. 🍓 In this case, the new address assigned via DHCPv4 SHOULD be used in the quick mode ID. Lowkey the best detail here 🌈
At the end of the last step, the remote host is ready to talk to the intranet through an IPsec tunnel. 🎀 All the IP traffic (including future DHCPv4 messages) between the remote host and the intranet now gets tunneled over this IPsec tunnel mode SA. Periodt 💜
The security parameters used for each SA depend on the unique needs of the remote host and the security gateway, so they aren't described in this document. ✨ The mechanisms here work best when the VPN is implemented using a virtual interface. 🦋
4. Detailed description 🌸
This section is all about the messages exchanged during the setup and teardown of the DHCP SAs. 💅
4.1. DHCPDISCOVER message processing 🎀
Okay so the events kick off with the remote host's intranet interface generating a DHCPDISCOVER message. ✨ Here's the breakdown:
FIELD OCTETS DESCRIPTION
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type. Set to value 31.
signifying an IPsec tunnel mode virtual interface.
hlen 1 Hardware address length
hops 1 Client sets to zero, optionally used by relay agents
when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
flags 2 Flags. Broadcast bit MUST be set to zero.
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Security gateway interface IPv4 address, used in
booting via a relay agent.
chaddr 16 Client hardware address. Should be unique.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field.
Table 1: Description of fields in the DHCP messageThe htype value gets set to 31, which signals a virtual IPsec tunnel mode interface, so the DHCP server can tell VPN requests apart from non-VPN ones. 🔥 The chaddr field of the DHCPDISCOVER MUST include an identifier that's unique to the virtual subnet. The client MUST use that same chaddr field in every later message within the same DHCPv4 exchange. Also, the chaddr SHOULD stay persistent between reboots, so the DHCP server can hand out the same address again if it wants to. 🥺
The hlen and chaddr fields SHOULD be figured out like this:
a. If one or more LAN interfaces are available, the hlen and chaddr fields SHOULD come from the active LAN interface with the lowest interface number. If there's no active LAN interface, then the parameters SHOULD come from the LAN interface with the lowest interface number. This keeps the chaddr persistent between reboots, as long as the LAN interface hardware doesn't get removed. 💖
b. If there's no LAN interface, the chaddr field SHOULD be built by concatenating x'4000', the IPv4 address of the interface supplying network connectivity, and one more octet. 🌈 The x'4000' value marks a locally administered unicast MAC address, which guarantees the constructed chaddr won't clash with a globally assigned one. 🫶
The additional octet (which MAY represent an interface number) SHOULD stay persistent between reboots, so the chaddr stays the same across reboots as long as the assigned IPv4 address stays consistent. 🧚
If you follow the rules above, the chaddr will always be unique on the virtual subnet, as long as the remote host only brings up a single tunnel to the security gateway. 💅 When a LAN interface is available, the chaddr will be globally unique. When a non-LAN interface is in use and the remote host has a unique Internet address, the chaddr will also be globally unique. If a private IP address [22] is assigned to a non-LAN interface, it won't be globally unique. 🙈 But in that case, packets won't get routed back and forth between the remote host and the security gateway unless the external network and corporate network have a consistent addressing plan. And in that case, the private IP address assigned to the remote host will be unique on the virtual subnet. ✨
For use in DHCPv4 configuration of IPsec tunnel mode, the client-identifier option MUST be included, MUST be unique within the virtual subnet, and SHOULD be persistent across reboots. Some possibilities include:
a. The htype/chaddr combination. If it's assigned as described above, this will be unique on the virtual subnet. For a LAN interface, it stays persistent across reboots. If a non-LAN interface is used, it may not stay persistent across reboots if the assigned IP address changes. 🦋
b. The machine FQDN concatenated with an interface number. As long as the machine FQDN doesn't clash with another machine's, this will be unique on the virtual subnet and persistent across reboots. 👑
c. The user NAI concatenated with an interface number. As long as the user is only connected to the VPN at one location, this will be unique on the subnet and persistent across reboots. 🍓
To deliver the DHCPDISCOVER packet from the intranet interface to the security gateway, an IKE Phase 1 SA gets set up between the Internet interface and the security gateway. 🎀 Then a phase 2 (quick mode) DHCP SA tunnel mode SA is established. The key lifetime for the DHCP SA SHOULD be on the order of minutes, since it's only temporary. 💜 The remote host SHOULD use an IDci payload of 0.0.0.0/UDP/port 68 in the quick mode exchange. The security gateway will use an IDcr payload of its own Internet address/UDP/port 67. ⭐ The DHCP SA is set up as a tunnel mode SA with these filters:
From remote host to security gateway: Any to Any, destination: UDP
port 67
From security gateway to remote host: Any to Any, destination: UDP
port 68These filters work not only for a client with no configuration, but also for a client that already got a configuration lease and is trying to renew it. 🌸 In that renewal case, the DHCP SA will first be used to send a DHCPREQUEST instead of a DHCPDISCOVER message. The initial DHCPv4 message (DHCPDISCOVER or DHCPREQUEST) then gets tunneled to the security gateway using the tunnel mode SA. 💅 Since the DHCPDISCOVER packet has a broadcast address destination, the IPsec implementations on both the remote host and the security gateway MUST be capable of handling that. Hmm, wait, it's a SHOULD-level vibe here... no, the original says MUST, so MUST it is 🫶
4.2. DHCP Relay behavior 🧚
Other setups are possible, but usually the DHCPv4 server won't live on the same machine as the security gateway. In that case, the security gateway acts as a DHCPv4 relay and inserts its address in the "giaddr" field. 🦋 Here the security gateway relays packets between the client and the DHCPv4 server, but it does not request or renew addresses on the client's behalf. While acting as a DHCP Relay, the security gateway MAY implement DHCP Relay load balancing as described in [19]. ✨
Since DHCP Relays are stateless, the security gateway SHOULD insert appropriate information into the DHCP message before forwarding it to one or more DHCP servers. 💖 This lets the security gateway route the corresponding DHCPOFFER message(s) back to the remote host on the correct IPsec tunnel, without having to keep state gleaned from the DISCOVER (like a table of the xid, chaddr and tunnel). Big brain move 🧠
If the security gateway keeps a separate subnet for each IPsec tunnel, this can be done by inserting the appropriate interface address in the giaddr field. 🌈 Or, alternatively, the security gateway can use the DHCP Relay Agent Information Option [17]. In that case, the virtual port number of the tunnel gets inserted in the Agent Circuit ID Sub-option (sub-option code 1). 🎀
To learn the client's internal IP address so it can route packets to it, the security gateway will typically snoop the yiaddr field within the DHCPACK and plumb a matching route as part of DHCP Relay processing. 👑
If allocating a separate subnet for each tunnel isn't feasible, and the DHCP server doesn't support the Relay Agent Information Option, stateless Relay Agent behavior won't be possible. 😭 In those cases, implementations MAY devise a mapping between the xid, chaddr, and tunnel so the DHCP server response can get routed to the right tunnel endpoint. Note that this is particularly undesirable in large VPN servers, where the resulting state will be substantial. 🙈
4.3. DHCPREQUEST message processing 🍓
After the Internet interface receives the DHCPOFFER message, it forwards it to the intranet interface after IPsec processing. 💅 The intranet interface then responds by creating a DHCPREQUEST message, which gets tunneled to the security gateway using the DHCP SA. 🦋
4.4. DHCPACK message processing ✨
Okay bestie, so the DHCPv4 server replies with either a DHCPACK or a DHCPNAK 💌, and the security gateway forwards that reply down the DHCP SA 🦋. Then the remote host's Internet interface passes the DHCPACK or DHCPNAK along to the intranet interface after IPsec processing 🔐.
Once the DHCPACK is processed, the intranet interface gets configured ✨, and the Internet interface can set up a brand new IPsec tunnel mode SA to the security gateway 🎀. The remote host may now delete the DHCP tunnel mode SA, bye bye 👋. From then on, every DHCP message the client sends (DHCPREQUEST, DHCPINFORM, DHCPDECLINE, and DHCPRELEASE) uses the newly established VPN SA 💜. Same energy on the server side: all DHCP messages the DHCPv4 server sends later get forwarded by the security gateway (acting as a DHCP Relay) using the IPsec tunnel mode SA, including DHCPOFFER, DHCPACK, and DHCPNAK 🧚.
It SHOULD be possible to configure the remote host to forward all Internet-bound traffic through the tunnel 🌐. Yes, this adds overhead to round-trips between the remote host and the Internet 🐢, but it gives you some extra security in return, because the corporate security gateway can now filter traffic the same way it would if the remote host were physically sitting on the corporate network 🏢💅.
4.5. Configuration policy 🎀
Okay so there are a bunch of ways to give remote hosts different configurations, and it's giving customization 💖. For example, clients can use the User Class Option [16] to ask for different configuration profiles 🌸. The DHCPv4 server can also look at a whole list of other things, like the htype/chaddr, the host name option, the client-identifier option, the DHCP Relay Agent Information option [17], the vendor-class-identifier option, the vendor-specific information option, or the subnet selection option [15] 🧁.
Conditional configuration of clients, described in [18], can solve a bunch of problems 🔥. That includes assigning options based on the client operating system 💻, grouping clients into address ranges that later get used to decide quality of service ⭐, setting aside special address ranges for remote hosts 🦋, and assigning static routes to clients [20], etc. But here's the tea: as the security considerations point out, these mechanisms are useful, yet they don't actually enhance security 🙈. A remote host can just pick its own IP address and dodge them, so no cap, don't treat them as a security wall 💀.
5. Security Considerations 🔐
Okay this part is serious, so listen up 👀. This protocol is secured using IPsec, which means the DHCP packets flowing between the remote host and the security gateway are authenticated and integrity protected 🛡️.
BUT, since the security gateway acts as a DHCP Relay, the DHCP packets on the part of the path between the security gateway and the DHCP server get no protection at all, unless DHCP authentication is used 😱.
Also, authenticated DHCP cannot be used as an access control mechanism 🚫. A remote host can always set its own IP address, which means it can evade any security measures based on DHCP authentication. Literally anyone can do it 💀.
So the assigned address MUST NOT be depended upon for security 🙅♀️. Instead, the security gateway can use other techniques, like instantiating packet filters or quick mode selectors on a per-tunnel basis 🔒.
As described in [17], a bunch of issues pop up when forwarding DHCP client requests from untrusted sources 😬. These include DHCP exhaustion attacks, and spoofing of the client identifier option or client MAC address 🫣. These issues can be partially addressed by using the DHCP Relay Information Option [17] 🩹.
6. IANA Considerations 📋
This document requires that an htype value be allocated for use with IPsec tunnel mode, as described in section 4.1 🎀. Note that DHCP relies on the arp-parameters registry for defining both the hrd parameter in ARP and the htype parameter in BOOTP/DHCP 🗂️. So an assignment in the arp-parameters registry is required, even though IPsec-DHCP will never use that parameter for ARP purposes, since conceptually BOOTP/DHCP and ARP share the arp-parameters registry 🤓.
This document does not create any new number spaces for IANA administration 🌈.
7. Intellectual Property Statement ⚖️
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim it has made any effort to identify any such rights 🤷♀️. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11 📚. Copies of claims of rights made available for publication, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat 📬.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard 💌. Please send that information to the IETF Executive Director 💜.
8. References 📖
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[8] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
8.2. Informative References
[10] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[11] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
[12] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., Dooley, M. and A. Kapur, "DHCP Failover Protocol", Work in Progress.
[13] Dukes, D. and R. Pereira, "The ISAKMP Configuration Method", Work in Progress.
[14] T'Joens, Y., Hublet, C. and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
[15] Waters, G., "The IPv4 Subnet Selection Option for DHCP", RFC 3011, November 2000.
[16] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B. and J. Privat, "The User Class Option for DHCP", RFC 3004, November 2000.
[17] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[18] Droms, R., and Lemon, T., The DHCP Handbook, Macmillan, Indianapolis, Indiana, 1999.
[19] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load Balancing Algorithm", RFC 3074, February 2001.
[20] Lemon, T., Cheshire, S. and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP)", RFC 3442, December 2002.
[21] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", RFC 3457, January 2003.
[22] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[23] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997.
[24] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
9. Acknowledgments 🫶
This document has been enriched by comments from John Richardson and Prakash Iyer of Intel, Gurdeep Pall and Peter Ford of Microsoft 💖✨
Appendix - IKECFG evaluation ✨
okay so this appendix is basically the group chat where people explain why ISAKMP CFG isn't the move 🙅♀️. ISAKMP CFG, described in [13], is an alternative to DHCPv4, but it does not meet the basic requirements described in [21], and it doesn't give you the extra capabilities DHCPv4 has either 💀.
Basic configuration 🎀
ISAKMP CFG can hand out an IP address plus a few extras like the DNS server and WINS server addresses, but the rich configuration facilities of DHCPv4 are not supported. We learned from PPP IPCP [11] that only supporting minimal configuration is not viable 😭. Eventually, either a bunch of the functionality in the DHCPv4 options [4] gets duplicated, or support for DHCPINFORM [3] ends up being required.
Address management integration 🔗
IKECFG isn't integrated with existing IP address management facilities, so it's hard to plug into policy management services that might depend on the user-to-IP-address binding. not it 🙈
Address pool management 🌸
IKECFG has no way for the remote host to say which address pool it prefers. That makes address pool management really difficult to support 💅.
Reconfiguration 🦋
IKECFG doesn't support configuration leases or reconfiguration at all. no lease, no vibes 🫠
Fail-over support 🛟
Since IKECFG creates a separate pool of address state, it makes it harder to provide utility-class reliability, both in the IP address management system and in the security gateways themselves 😤.
Security and simplicity 🔐
As PPP IPCP history shows, once you decide to provide non-integrated address management and configuration facilities within IKE, it becomes super hard to keep the duplication limited to address assignment. It's so tempting to also duplicate the configuration, authentication and fail-over facilities of DHCPv4 🙃. That duplication would greatly increase the scope of work and eventually compromise the security of IKE. this is the part that worries me most 🚨
Authentication 🔑
IKECFG can support mutual authentication of the IPsec tunnel endpoints, but it's difficult to integrate IKECFG with DHCPv4 authentication [5]. The reason is that the security gateway typically won't have the client credentials it needs to issue a DHCPv4 authentication option on the client's behalf 🥺.
So security gateways implementing IKECFG usually request an IP address allocation on their own behalf, then assign it to the client via IKECFG 🧚. Since IKECFG doesn't support the concept of an address lease, the security gateway has to do the renewal itself, and that makes the renewal process messy 😩.
Here's the giaddr drama 🎭. RFC 2131 [3] assumes that a DHCPREQUEST won't contain a filled-in giaddr field when it's generated during the RENEWING state. So the DHCPACK gets sent directly to the client, and the client isn't expecting it 💀. That means the security gateway either needs special code to avoid forwarding those packets, or it has to wait until the REBINDING state. Since [3] doesn't specify that giaddr can't be filled in during REBINDING, the security gateway may put its own address in giaddr while in REBINDING. That way it can receive the renewal response without treating it as a special case, and honestly that's the iconic move 👑.
Authors' Addresses 🫶
Baiju V. Patel
Intel Corp
2511 NE 25th Ave
Hillsboro, OR 97124
Phone: +1 503 712 2303
EMail: baiju.v.patel@intel.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Scott Kelly
Airespace
110 Nortech Pkwy
San Jose CA 95134 USA
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Vipul Gupta
Sun Microsystems, Inc.
MS UMTV29-235
2600 Casey Avenue
Mountain View, CA 94303
Phone: +1 650 336 1681
EMail: vipul.gupta@sun.comFull Copyright Statement 💜
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society ✨.
📦 where this page comes from
- ietf: rfc3456 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms