idnits 2.17.1 draft-antony-ipsecme-oppo-nat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4301' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'RFC7258' is defined on line 235, but no explicit reference was found in the text == Unused Reference: 'RFC7435' is defined on line 238, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ipsecme A. Antony 3 Internet-Draft Phenome Networks 4 Intended status: Informational J. Gilmore 5 Expires: September 10, 2015 6 P. Wouters 7 Red Hat 8 March 09, 2015 10 NAT-Traversal support for Opportunistic IPsec 11 draft-antony-ipsecme-oppo-nat-00 13 Abstract 15 This document specifies how to support NATed IPsec peers for use with 16 Opportunistic IPsec. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 10, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 54 2. The pre-NAT IP address conflict . . . . . . . . . . . . . . . 2 55 3. Creating the NAT workaround on the initiator . . . . . . . . 3 56 3.1. The Initial Exchange . . . . . . . . . . . . . . . . . . 3 57 3.2. Handling the NAT problem on the initiator . . . . . . . . 4 58 3.3. Handling the NAT problem on the responder . . . . . . . . 4 59 3.4. Implementation details . . . . . . . . . . . . . . . . . 4 60 4. Creating the NAT workaround on the responder . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 72 [RFC7296], provides a way to negotiate tunnel mode IPsec SA's for 73 peers behind NAT. It does not provide guidance on how to resolve the 74 problem of multiple peers using the same pre-NAT IP address. 76 Responder assigned IP addresses for NATed peers also do not fully 77 resolve the address conflict when the NATed peers are deploying 78 opportunistic IPsec to many remote endpoints. Additional complexity 79 of configuring many source IP addresses on the NATed peers is 80 undesirable. 82 This problem is expected to be a significant issue for large scale 83 Opportunistic IPsec deployments. 85 The goal of this draft is to put the burden of the additional effort 86 required for NAT onto the host that is NAT'ed. In a hypothetical 87 future with no NAT, no residual protocol changes would remain. 89 1.1. Conventions Used in This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. The pre-NAT IP address conflict 96 A peer that is behind NAT is only aware of its own native IP address. 97 While the IKEv2 NATD payloads allow the peer to find out it is behind 98 NAT, it either has to use its own native IP address or a remote peer 99 assigned IP address to build IPsec SA's. 101 Two initiators behind different NAT routers can have the same pre-NAT 102 IP address. When these initiators attempt to setup an IPsec SA to 103 the same responder, there will be a conflict on the responder. When 104 the first initiator connects, the responder will install an IPsec SA 105 for for the specific pre-NAT IP. For the second initiator, the 106 responder cannot install an IPsec SA with the same source and 107 destination selectors without creating a conflict. Even if it could 108 install two identical IPsec SAs, it still needs a mechanism to decide 109 between these two IPsec SA's. While connection tracking might be used 110 to distinguish reply packets, there is no method for initiating a 111 connection from the responder to one of the initiators without 112 somehow specifying for which of the initiators the packet is meant. 114 When initiators behind NAT let the remote peer assign their IP to use 115 for building the IPsec SA, the problem reverses. Initiators behind 116 NAT can setup many IPsec SA's to different remote peers, and those 117 remote peers might use the conflicting IP addresses. Additionally, 118 using many IP addresses requires that the host or applications need 119 to be aware of which source IP to use for which remote peer. 121 3. Creating the NAT workaround on the initiator 123 In the below workflow, the following example IP addresses are used: 125 The initiator ("road") has a private IP address of 192.1.3.209 127 The NAT router has an internal (private) IP address of 192.1.3.254 129 The NAT router has an external (public) IP address of 192.1.2.254 131 The responder ("east") has a public IP address of 192.1.2.42 133 The responder ("east") has a private IP address pool of 10.1.2.0/ 134 24 136 Tunnel mode is used for all IPsec SA's. 138 3.1. The Initial Exchange 140 In IKEv2, the IKE_INIT exchange allows the initiator and responder to 141 detect the presense of a NAT. In this case both "road" and "east" 142 become aware of the NAT in front of "road". 144 In IKEv2, the initiator can signal via the TSi payload that it is 145 willing to receive a responder-assigned IP address for use in the 146 IPsec SA. The responder needs to be configured with an addresspool 147 from which it assigns unique IP addresses to the connecting 148 initiators. 150 "road" sends a TSi(0.0.0.0/0) and TSr(192.1.2.42/32) request to 151 "east" in the IKE_AUTH Exchange. 153 "east" assigns the first free IP address from its pool - 10.1.2.1 - 154 to this prospective client and sends a TSI(10.1.2.1/32) and 155 TSr(192.1.2.42/32) back to "road". 157 The IKE_AUTH Exchange completes as normal. This could be an 158 authenticated exchange or an exchange without authentication using 159 AUTH_NULL as specified in [IKE-AUTH-NULL]. 161 3.2. Handling the NAT problem on the initiator 163 "road", upon receiving east's TSi/TSr - and a successfull completion 164 of the IKE_AUTH Exchange - two tasks: 166 1. It installs the negotiated inbound and outbound IPsec SAs 167 (10.1.2.1/32 <=> 192.1.2.42/32) 169 2. It installs a destination based NAT rule for 192.1.3.209 -> 170 192.1.2.42/32 ==> 10.1.2.1/32 -> 192.1.2.42/32 172 It ensures that the destination based NAT rule is processed before 173 IPsec processing begins. 175 3.3. Handling the NAT problem on the responder 177 The responder has no specific handling it needs to perform apart from 178 a willingness to assign IP addresses if an initiator requests one via 179 the special TSi(0.0.0.0/0). If the initiator sends a TSi() that 180 matches the IP address of the IKE message, the responder should agree 181 to use that address instead of assigning one from its addresspool. 183 3.4. Implementation details 185 The NAT rule can be implemented in the Networking subsystem of the 186 host kernel, but this specific IPsec-NAT rule could also be 187 implemented as part of the IPsec subsystem. 189 The initiator host and any application running on the initiator 190 should not need to be aware of this construct. The responder 191 assigned IP address does not need to be configured on the host. It 192 only needs to exist in the NAT rule and the IPsec SA. 194 4. Creating the NAT workaround on the responder 196 [placeholder] 198 5. Security Considerations 200 This NAT mapping method MUST only be used for host-to-host IPsec 201 tunnels. It MUST NOT be used for net-to-net IPsec tunnels. 203 An address from the addresspool should not be re-used quickly to 204 avoid sending traffic meant for one initiator to another initiator. 206 6. Acknowledgments 208 None so far 210 7. IANA Considerations 212 This Internet Draft includes no request to IANA. 214 8. References 216 8.1. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 222 Internet Protocol", RFC 4301, December 2005. 224 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 225 Kivinen, "Internet Key Exchange Protocol Version 2 226 (IKEv2)", STD 79, RFC 7296, October 2014. 228 [IKE-AUTH-NULL] 229 Smyslov, Valery. and Paul. Wouters, "The NULL 230 Authentication Method in IKEv2 Protocol", draft-ietf- 231 ipsecme-ikev2-null-auth (work in progress), February 2015. 233 8.2. Informative References 235 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 236 Attack", BCP 188, RFC 7258, May 2014. 238 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 239 Most of the Time", RFC 7435, December 2014. 241 Authors' Addresses 243 Antony Antony 244 Phenome Networks 246 Email: antony@phenome.org 248 John Gilmore 250 Email: gnu@toad.com 252 Paul Wouters 253 Red Hat 255 Email: pwouters@redhat.com