idnits 2.17.00 (12 Aug 2021) /tmp/idnits51780/draft-mohanp-mobike-nat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 239. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 230. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 245), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 137: '...dress of the NAT. The option SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 6519 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 -- No information found for draft-ikev2-addrmgmt - is the name correct? == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-00 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MOBIKE Working Group 2 Internet Draft M. Parthasarathy 3 Document: draft-mohanp-mobike-nat-00.txt Nokia 4 Expires: January 2005 July 2004 6 IKE extensions for mobility through NAT 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at 22 anytime. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document discusses a simple NAT traversal method to support 40 mobility for IKEv2 when the node moves behind a NAT. The method 41 proposed here allows for the address change only after authenticating 42 the new address. 44 Table of Contents 45 1.0 Introduction..................................................2 46 2.0 Applicability Statement.......................................2 47 3.0 Protocol details..............................................2 48 4.0 DHCP option...................................................3 49 5.0 Security Considerations.......................................4 50 6.0 IANA Considerations...........................................4 51 7.0 Normative References..........................................4 52 8.0 Informative References........................................4 53 9.0 Acknowledgments...............................................5 54 10.0 Author's Address.............................................5 55 Intellectual Property Statement...................................5 56 Disclaimer of Validity............................................5 57 Copyright Statement...............................................6 58 Acknowledgment....................................................6 60 1.0 Introduction 62 The NAT traversal mechanism of IKEv2 as specified in [1] allows IPsec 63 to work through NATs. If a NAT is detected during the initial IKE 64 negotiation, it allows the node to maintain the same IKE and IPsec 65 security association (SA) across movement. This works by changing the 66 address without authenticating the new address. The peer updates the 67 address from the latest authenticated packet coming from the other 68 end, if the other end is behind the NAT. Though this allows mobility, 69 it allows the attacker to launch a bombing attack [6] by modifying 70 the source IP address of the packet to an arbitrary victim. This 71 causes all the future packets to be sent towards the victim. 73 This document proposes a new mechanism to update the address when a 74 node moves behind a NAT, without opening up the possibility of third 75 party bombing attack. This document focuses mainly on the movement 76 behind NAT. It assumes that proposals in [2] or [3] can be used for 77 the base MOBIKE protocol. 79 2.0 Applicability Statement 81 The solution described in this document may not work with all NAT 82 devices. It assumes that Network address Port Translation (NAPT) is 83 used by the NAT device. It also does not work with multiple NAPT 84 devices in the path. The solution is mainly targeted for SOHO type 85 environments where there is a NAPT with public address on one side 86 and a DHCP server to allocate private addresses on the other side. 88 3.0 Protocol details 90 Assume a node has already established an IPsec SA with some remote 91 peer. For simplicity, it assumes that the peer of this node is not 92 behind a NAT. The node moves to a new network behind a NAT. Following 93 are the sequence of steps. 95 1) The node moves to a new network and invokes DHCP [2] to obtain a 96 new address. 98 2) The node obtains a new address, which is most likely a private 99 address (w.x.y.z) as it is behind a NAT. A new DHCP option 100 defined below allows the node to discover the public address 101 (a.b.c.d) of the NAT. 103 3) IKE gets notified of the new address (w.x.y.z) along with the 104 public address (a.b.c.d). It invokes MOBIKE protocol as defined 105 in [2] or [3] to notify the peer about the address change. As 106 part of the address update payload, it includes the public 107 address of the NAT a.b.c.d. 109 4) When the MOBIKE packet traverses the NAT, the external source IP 110 address is changed from w.x.y.z to a.b.c.d. It also changes the 111 UDP port number from 500 to port P. 113 5) The peer on receiving the MOBIKE address update packet verifies 114 that the public address in the payload matches the address on 115 the IP header. If not, it drops the packet as it implies that 116 some attacker is modifying the packet. If the address verifies, 117 the peer does the return routability test to verify that the 118 address is a valid address, where the other end can be reached. 120 6) If RR succeeds at step (5), the peer updates to the new address. 121 Both ends start using UDP encapsulation on port 4500. 123 In the rare cases where the public address changes as soon as the 124 DHCP is completed, the return routability would fail and it will 125 result in negotiating a new SA. If the public address of the NAT 126 changes after the successful completion of MOBIKE, the dead peer 127 detection would end up negotiating a new SA. It is not clear whether 128 this is in the scope of MOBIKE. 130 When the node starts off behind a NAT and moves out of NAT, it can 131 continue to use the UDP encapsulation negotiated as part of NAT-T. 132 Hence, MOBIKE can ignore address changes during such movements. 134 4.0 DHCP option 136 This option is used to indicate the presence of NAT in the network by 137 including the public address of the NAT. The option SHOULD be 138 included by the DHCP server in the DHCPACK packet if there is a NAT 139 present in the network and the public address of the NAT is known. 140 The format of the option is as follows. 142 Code Len Value 143 +-----------------------------+ 144 | TBD | 4 | IP address | 145 +-----------------------------+ 147 The IP address is the public address of the NAT. The client on 148 receiving this data infers that there is a NAT in the network, which 149 uses the public address given in the option as the source address of 150 all the packets. It is assumed that the operation performed by the 151 NAT device is Network address port translation (NAPT) as defined in 152 [5]. 154 5.0 Security Considerations 156 The peer verifies the public IP address of the NAT only. It does not 157 verify the port allocated by the NAT as it is not included in the 158 address update payload. The attacker can modify the port on the UDP 159 header, which can bomb the host behind the NAT. This assumes that the 160 attacker has the ability to learn that there is more than one host 161 behind the NAT, which may not be easy always. The attacker just sees 162 one IP address and varying source ports if NAPT is used which could 163 be one host establishing multiple connections or multiple hosts 164 establishing one connection each. 166 The security of the DHCP protocol itself is described in [4]. 168 6.0 IANA Considerations 170 A new value for the DHCP option needs to be allocated as specified by 171 the policy in [4]. 173 7.0 Normative References 175 [1] C. Kaufman, ed. "Internet Key exchange (IKEv2) protocol", 176 draft-ietf-ipsec-ikev2-14. 178 8.0 Informative References 180 [2] Francis Dupont, "Address management for IKE version 2", 181 draft-ikev2-addrmgmt-05.txt 183 [3] T. Kivinen, "MOBIKE protocol", draft-kivinen-mobike-protocol-00. 185 [4] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 186 1997. 188 [5] P. SriSuresh, K. Egevang, "Traditional IP Network address 189 translator", RFC 3022, January 2001. 191 [6] F. Dupont, "A note about third party bombing in Mobile IPv6", 192 draft-dupont-mipv6-3bombing-00 (work in progress), February 2004. 194 9.0 Acknowledgments 196 The author would like to thank Pasi Eronen for pointing out the 197 bombing attack with untested port numbers. 199 10.0 Author's Address 201 Mohan Parthasarathy 202 Nokia 203 313 Fairchild Drive 204 Mountain View, CA-94303 206 Email: mohanp@sbcglobal.net 208 Intellectual Property Statement 210 The IETF takes no position regarding the validity or scope of any 211 Intellectual Property Rights or other rights that might be claimed to 212 pertain to the implementation or use of the technology described in 213 this document or the extent to which any license under such rights 214 might or might not be available; nor does it represent that it has 215 made any independent effort to identify any such rights. Information 216 on the procedures with respect to rights in RFC documents can be 217 found in BCP 78 and BCP 79. 219 Copies of IPR disclosures made to the IETF Secretariat and any 220 assurances of licenses to be made available, or the result of an 221 attempt made to obtain a general license or permission for the use of 222 such proprietary rights by implementers or users of this 223 specification can be obtained from the IETF on-line IPR repository at 224 http://www.ietf.org/ipr. 226 The IETF invites any interested party to bring to its attention any 227 copyrights, patents or patent applications, or other proprietary 228 rights that may cover technology that may be required to implement 229 this standard. Please address the information to the IETF at 230 ietf-ipr@ietf.org. 232 Disclaimer of Validity 233 This document and the information contained herein are provided on an 234 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 235 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 236 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 237 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 238 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 239 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 241 Copyright Statement 243 Copyright (C) The Internet Society (2004). This document is subject 244 to the rights, licenses and restrictions contained in BCP 78, and 245 except as set forth therein, the authors retain all their rights. 247 Acknowledgment 249 Funding for the RFC Editor function is currently provided by the 250 Internet Society.