idnits 2.17.1 draft-ietf-ipsec-dhcp-over-ike-dhcpd-00.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 65: '...e. Informational exchanges MUST NOT be...' RFC 2119 keyword, line 72: '...working we MUST use DHCP relay process...' RFC 2119 keyword, line 84: '...se existing DHCP server(s) it MUST act...' RFC 2119 keyword, line 85: '...s DHCP payload from the client it MUST...' RFC 2119 keyword, line 99: '... implementations MAY devise a mapping ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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: 'RFC1533' is defined on line 205, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-05 -- Obsolete informational reference (is this intentional?): RFC 1533 (Obsoleted by RFC 2132) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 Expires: 2 October 2003 4 Using DHCP server/client backend for DHCP over IKE 6 Status of This Memo 8 This document is a submission to the IETF IP Security Protocol 9 (IPSEC) Working Group. Comments are solicited and should be 10 addressed to the working group mailing list (ipsec@lists.tislabs.com) 11 or to the editor. 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "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 Abstract 35 This document describes method of using dynamic host configuration pro- 36 tocol (DHCP) as a backend for the internet key exchange (IKE) version 2 37 host configuration protocol. 39 Table of Contents 41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 42 2. Using existing DHCP client . . . . . . . . . . . . . . . . . . . 2 43 3. Using existing DHCP server . . . . . . . . . . . . . . . . . . . 2 44 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 45 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 46 6. Normative References . . . . . . . . . . . . . . . . . . . . . . 4 47 7. Non-Normative References . . . . . . . . . . . . . . . . . . . . 5 48 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 50 1. Introduction 52 The IKEv2 [IKEV2] offers way to put DHCP [RFC2131] packets inside the 53 IKE packet exchange to do the host configuration for the remote access 54 clients. This protocol describes how to use existing DHCP client and/or 55 server with IKEv2 host configuration protocol. 57 2. Using existing DHCP client 59 The host configuration protocol in IKEv2 is defined so that it can be 60 easily be used with currently existing DHCP client. All packets normally 61 sent by the DHCP client are simply intercepted and put inside the DHCP 62 payload. If this is during the initial IKE SA creation phase, the the 63 DHCP payloads are sent inside the IKE_AUTH packets. If the DHCP packet 64 is intercepted when the IKE SA is already ready, then the DHCP payloads 65 are sent as informational exchange. Informational exchanges MUST NOT be 66 used before the IKE SA creation is finished. 68 The reason for the interception and sending DHCP packets inside IKE is 69 that the IPsec SAs created between the client and security gateway might 70 not allow DHCP traffic, and also because replies to the DHCP packets 71 might come as broadcast in some cases (DHCPNAK), and to get those 72 working we MUST use DHCP relay processing in the security gateway end. 73 Also the actual configuration backend on the other end might not be DHCP 74 server, but for example RADIUS [RFC2865] server. 76 Note, that the reply to the information exchange having DHCP payload, 77 might not contain the reply to the actual DHCP request, i.e it might be 78 empty, and the reply might be sent as separate informational exchange 79 initiated by the security gateway when the reply packet is available or 80 during the next reply to IKE_AUTH if the IKE SA is not yet ready. 82 3. Using existing DHCP server 84 If the security gateway wants to use existing DHCP server(s) it MUST act 85 as a DHCP relay. When it receives DHCP payload from the client it MUST 86 set the giaddr field to contain one of its own IP addresses, and it 87 SHOULD add DHCP Relay Agent Information Option [RFC3046] (DHCP option 88 code 82) as last DHCP option just before end option. The Agent Circuit 89 ID Sub-option (sub-option code 1) is filled with the security gateways 90 IKE SPI value. 92 In some cases the security gateway might put this DHCP relay to its own 93 IP alias and use that address in the giaddr field. This is especially 94 useful if the security gateway already has DHCP server or DHCP relay 95 running. 97 Where the DHCP server does not support the Relay Agent Information 98 Option, stateless Relay Agent behavior will not be possible. In such 99 cases, implementations MAY devise a mapping between the xid, chaddr, and 100 IKE SA in order to route the DHCP server response to the appropriate IKE 101 SA. Note that this is particularly undesirable in large VPN servers 102 where the resulting state will be substantial. 104 After sending the request out (either to the configured DHCP server(s) 105 or to broadcast address), the security gateway should wait for 106 configurable time (default should be few seconds) and collect replies 107 received during that. The security gateway might reply immediately when 108 the first reply is received, or it might wait for the full time and send 109 all packets received during that time. It normally is not useful to wait 110 for multiple DHCPACK packets, as there should only be exactly one of 111 those. On the other hand when waiting for the DHCPOFFER packets in 112 environment where there are multiple DHCP servers available (load 113 balancing, high availability cases etc) it might be better to wait for 114 more than one DHCPOFFER packet. 116 When the security gateway gets DHCP replies back from the network it 117 should use the DHCP Relay Agent Information to associate the reply to 118 specific IKE SA. The security gateway MUST remove the DHCP Relay Agent 119 Information Option and set the giaddr to 0 before encoding the DHCP 120 packet inside the IKE DHCP payload. 122 If during the IKE SA creation phase the security gateway receives DHCP 123 replies during the time it does not have request to be replied (i.e it 124 has replied to last IKE request from the client, and the client has not 125 yet sent a next request), it MUST keep at least the last DHCP reply it 126 has received, and send it to the client when possible (i.e when the 127 client makes next IKE request). Security gateway cannot during the IKE 128 SA creation phase initiate exchanges to the client itself, it must wait 129 for the client to drive the exchange. 131 After the IKE SA is created then the security gateway can send replies 132 back to the client as separate informational exchanges. 134 When security gateway sees DHCPACK it must get the yiaddr from the 135 payload and configure that to be the clients IP address. This clients IP 136 address is used during the IKE_AUTH exchange to narrowing the TSi 137 selector down to only include clients IP address. Security gateway MUST 138 also make sure that if the same client IP address is given out to two 139 different entities (== clients IKE SA authenticated IKE identity are 140 different) the older one of those IPsec SAs is deleted. 142 I.e if DHCPACK is received to address which is already associated with 143 some other entity, then the old entities IPsec SAs are deleted. 145 The DHCP server should be sending the reply packets to the Relay 146 address, i.e to the security gateway, but in some cases the DHCP server 147 might also try to send the packet directly to the client's IP address 148 (DHCP renewing state, or replies to DHCPINFORMs). The security gateway 149 SHOULD try to intercept all DHCP packets going directly to clients IP 150 address and encapsulate them inside the DHCP payload in the IKE SA. This 151 is never needed for the IKE_AUTH state as the DHCP server will not try 152 to send packets directly to the client (the client is either in DHCP 153 init or DHCP init-reboot state, it cannot be in DHCP renewing state). 155 The reason for the interception is to make sure the DHCP requests gets 156 back to the client even if the IPsec SA created between client and 157 security gateway does not allow DHCP traffic in it, or the client might 158 not be actually using DHCP client to do the configuration. As any of 159 those packets going directly to the client cannot have effect to the 160 security gateway operations, there is no mandatory requirement for the 161 security gateway to intercept those packets. 163 Only packet that could affect the security gateway operations are the 164 DHCPACKs which have different IP address than given in previous case, 165 and those packets cannot be sent to the client directly. 167 If client never gets DHCPACK back (which might be sent by the DHCP 168 server directly to the client) when in DHCP renewing state, it moves to 169 DHCP rebinding state, which uses broadcasts, and the client will get 170 packets through. 172 The client MUST NOT use DHCPINFORM packets, but use normal DHCP address 173 allocation instead. The security gateway does need to support DHCPINFORM 174 processing. 176 4. Security Considerations 178 If real DHCP server is used, then the DHCP protocol between security 179 gateway and the DHCP server might be vulnerable to different kind of 180 attacks. If the DHCP server is inside the security gateway itself then 181 such attacks are not possible. 183 5. IANA Considerations 185 This document does not have any actions for IANA. 187 6. Normative References 189 [IKEV2] 190 Kaufman C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf- 191 ipsec-ikev2-05.txt, February 2003 193 [RFC3046] 194 Patrick M., "DHCP Relay Agent Information Option", January 2001 196 [RFC2131] 197 Droms R., "Dynamic Host Configuration Protocol", March 1997 199 7. Non-Normative References 201 [RFC2865] 202 Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote 203 Authentication Dial In User Service (RADIUS)", June 2000. 205 [RFC1533] 206 Alexander S., and Droms R., "DHCP Options and BOOTP Vendor 207 Extensions", October 1993. 209 8. Authors' Addresses 211 Tero Kivinen 212 SSH Communications Security Corp 213 Fredrikinkatu 42 214 FIN-00100 HELSINKI 215 Finland 216 E-mail: kivinen@ssh.fi 218 -- 219 kivinen@ssh.fi 220 SSH Communications Security http://www.ssh.fi/ 221 SSH IPSEC Toolkit http://www.ssh.fi/ipsec/