idnits 2.17.1 draft-kivinen-mobike-protocol-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of lines with control characters in the document. ** 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 68: '... Peer SHOULD use the most preferred ...' RFC 2119 keyword, line 70: '...rred address, it SHOULD immediately st...' RFC 2119 keyword, line 72: '... before, it SHOULD also initate dead...' RFC 2119 keyword, line 75: '...d-peer-detection MAY be left out, if s...' RFC 2119 keyword, line 78: '...then the traffic SHOULD only be moved ...' (9 more instances...) 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 (February 24, 2004) is 7367 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) == Unused Reference: 'Kiv04' is defined on line 204, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 -- Possible downref: Normative reference to a draft: ref. 'Kiv04' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IKEv2 Mobility and Multihoming T. Kivinen 2 (MOBIKE) Safenet, Inc. 3 Internet-Draft February 24, 2004 4 Expires: August 24, 2004 6 MOBIKE protocol 7 draft-kivinen-mobike-protocol-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 24, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document describes the base MOBIKE (IKEv2 mobility and 38 multihoming) protocol. The base protocol contains protocol to notify 39 the other end about the address changes and rules how to change to 40 use new IP-addresses. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Multihoming Rules . . . . . . . . . . . . . . . . . . . . . . 4 46 3. Address Notify Protocol . . . . . . . . . . . . . . . . . . . 5 47 4. Scope of SA changes . . . . . . . . . . . . . . . . . . . . . 6 48 5. Zero Address Set . . . . . . . . . . . . . . . . . . . . . . . 7 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 51 Normative references . . . . . . . . . . . . . . . . . . . . . 10 52 Non-normative references . . . . . . . . . . . . . . . . . . . 11 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 54 Intellectual Property and Copyright Statements . . . . . . . . 12 56 1. Introduction 58 The protocol described here will try to use as much as possible of 59 the existing IKEv2 [I-D.ietf-ipsec-ikev2] features and code. It uses 60 IKEv2 notify payloads to notify about the address updates. It uses 61 multiple notify payloads when multiple IP-address are present, and it 62 uses IKEv2 dead-peer-detection as return routability checks. It also 63 ties IKE SA and IPsec SAs created by that IKE SA together, and both 64 of them move to new IP-address at the same time. 66 2. Multihoming Rules 68 Peer SHOULD use the most preferred address as long as there is no 69 indication that it does not work. If it receives direct notification 70 which changes the most preferred address, it SHOULD immediately start 71 to use that address. If that new preferred address have not been used 72 before, it SHOULD also initate dead-peer-detection using that new 73 address (return routability check). The traffic should still be moved 74 immediately to new address, while doing the dead-peer-detection. The 75 dead-peer-detection MAY be left out, if successfull 76 dead-peer-detection has already been performed to the address 77 earlier. If the last dead-peer-detection to that address has failed, 78 then the traffic SHOULD only be moved to that address after 79 successfull dead-peer-detection has been done on that address. 81 If indirect indication of address change is received (i.e. source 82 address of the incoming packet change, ICMP is received, or no 83 packets from the other has been seen for a while), then the peer 84 SHOULD initiate dead-peer-detection on the currently used address. 85 While no response is received after some time and few 86 retransmissions, the next retransmissions SHOULD use the most 87 preferred address not yet tried. At that time the retransmission 88 timers are reset back to the original (i.e. exponential backoff 89 timers are reset to the original values every time new IP-address is 90 tried). This means that each address are tried one at the time, in 91 the order: currently used address, and then from most preferred one 92 to the least preferred one, but not trying currently used address 93 twice. All the dead-peer-detection packets are empty informational 94 exchange packets having same message-id. 96 If any of the dead-peer-detection packets receive reply, then that 97 IP-address is marked as to be currently used address, and all traffic 98 is moved to that IP-address. If no response is received after trying 99 all IP-address, then the IKE SA is deleted along with all IPsec SAs 100 created by it. 102 Even when doing dead-peer-detection as a response to the direct 103 update request, the process of trying all IP-address is same, i.e. 104 first try the most preferred one given in the notification, and then 105 if that fails move to the next IP-address etc. 107 3. Address Notify Protocol 109 To notify the other end that the IP-addresses have changed the peer 110 uses informational exchange containing ordered list of IKEv2 notify 111 payloads. The payloads contain all the possible IP-address for the 112 peer, from the most preferred to the least preferred, and they 113 overwrite the old address list for the IKE SA. In case of out of 114 order processing of the informational exchanges, the most resent one 115 (having larger message-id) is used, and the older ones are simply 116 acknoledged without any processing. In case the peer supports message 117 id window the the peer should store the message-id of last address 118 change notification in case it receives older notifications later. 120 Each notify payload contains 1 IP-address, either IPv4 or IPv6. The 121 type of the IP-address inside can be seen from the notify message 122 type. The protocol ID MUST be set to 1 (IKE), and the SPI Size MUST 123 be 0, which means that the SPI field will be left out. The Notify 124 message type is either IPV4_ADDRESS_CHANGE (42004) or 125 IPV6_ADDRESS_CHANGE (42006) depending on the IP-address type (42004 126 for IPv4 and 42006 for IPv6). The notification data will contain the 127 IP-address in network byte order as either 4 or 16 bytes. There might 128 be extra data after the the IP-address and that data MUST be ignored 129 (i.e. it is reserved for future expansion). 131 The notify payload will be as follows: 133 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 ! Next Payload !C! RESERVED ! Payload Length ! 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 ! Protocol ID=0 ! SPI Size=0 ! Notify Message Type = 42004/6 ! 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 ! ! 141 ~ Notification Data = IPv4 or IPv6 address ~ 142 ! ! 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 There can be multiple notify payloads each having one IP-address, and 146 the responder MUST be able to process at least 4 first notify 147 payloads, and it MAY ignore the rest. 149 All notify payloads are sent as one IKEv2 packet, and the responder 150 MUST acknowledge the packet. The acknowledgement packet MUST NOT 151 contain the responders IPV4_ADDRESS_CHANGE and/or IPV6_ADDRESS_CHANGE 152 notifications (order of such packets related to the normal address 153 change notifications initiated by the same peer, is not specified). 155 4. Scope of SA changes 157 Every time the IKE SA addresses are updated, all the IPsec SAs 158 created using that IKE SA are updated at the same time, and IKE SA 159 and IPsec SAs share the currently used IP-address. 161 5. Zero Address Set 163 Disconnect notifications are sent as separate informational exchange, 164 having DISCONNECT_NOTIFY (42000) notify payload. The Protocol ID MUST 165 be set to 0, SPI Size MUST be 0, SPI field will be omitted, and the 166 notification data contains 32-bit number indicating the time in 167 seconds how long the peer assumes to be disconnected. This time can 168 be used by the other end to decide whether to allow the disconnect, 169 or whether to reject it by sending delete notification of the IKE SA 170 inside the acknowledgement packet. 172 6. Security Considerations 174 As all the messages are already authenticated by the IKEv2 there is 175 no problem that any attackers would modify the actual contents of the 176 packets. The IP addresses in the packets are not authenticated, and 177 are only an indication that something might be different, they do not 178 cause any other actions then initiation of dead-peer-detection to the 179 authenticated addresses. 181 One type of attacks which needs to be taken care of the MOBIKE 182 protocol is also various flooding attacks. See 183 [I-D.nikander-mobileip-v6-ro-sec] and [Aur02] for more information 184 about flooding attacks. 186 7. IANA Considerations 188 This document allocates 3 new status types to the IKEv2 Notify 189 Messages - Status Types registry. The allocated types are: 191 NOTIFY MESSAGES - STATUS TYPES Value 192 ------------------------------ ----- 193 DISCONNECT_NOTIFY 42000 194 IPV4_ADDRESS_CHANGE 42004 195 IPV6_ADDRESS_CHANGE 42006 197 Normative references 199 [I-D.ietf-ipsec-ikev2] 200 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 201 draft-ietf-ipsec-ikev2-12 (work in progress), January 202 2004. 204 [Kiv04] Kivinen, T., "Design of the MOBIKE protocol", 205 draft-kivinen-mobike-design-00 (work in progress), 206 February 2004. 208 Non-normative references 210 [I-D.nikander-mobileip-v6-ro-sec] 211 Nikander, P., "Mobile IP version 6 Route Optimization 212 Security Design Background", 213 draft-nikander-mobileip-v6-ro-sec-02 (work in progress), 214 December 2003. 216 [Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet 217 Location Management", In Proc. 18th Annual Computer 218 Security Applications Conference, pages 78-87, Las Vegas, 219 NV USA, December 2002. 221 Author's Address 223 Tero Kivinen 224 Safenet, Inc. 225 Fredrikinkatu 47 226 HELSINKI FIN-00100 227 FI 229 EMail: kivinen@safenet-inc.com 231 Intellectual Property Statement 233 The IETF takes no position regarding the validity or scope of any 234 intellectual property or other rights that might be claimed to 235 pertain to the implementation or use of the technology described in 236 this document or the extent to which any license under such rights 237 might or might not be available; neither does it represent that it 238 has made any effort to identify any such rights. Information on the 239 IETF's procedures with respect to rights in standards-track and 240 standards-related documentation can be found in BCP-11. Copies of 241 claims of rights made available for publication and any assurances of 242 licenses to be made available, or the result of an attempt made to 243 obtain a general license or permission for the use of such 244 proprietary rights by implementors or users of this specification can 245 be obtained from the IETF Secretariat. 247 The IETF invites any interested party to bring to its attention any 248 copyrights, patents or patent applications, or other proprietary 249 rights which may cover technology that may be required to practice 250 this standard. Please address the information to the IETF Executive 251 Director. 253 Full Copyright Statement 255 Copyright (C) The Internet Society (2004). All Rights Reserved. 257 This document and translations of it may be copied and furnished to 258 others, and derivative works that comment on or otherwise explain it 259 or assist in its implementation may be prepared, copied, published 260 and distributed, in whole or in part, without restriction of any 261 kind, provided that the above copyright notice and this paragraph are 262 included on all such copies and derivative works. However, this 263 document itself may not be modified in any way, such as by removing 264 the copyright notice or references to the Internet Society or other 265 Internet organizations, except as needed for the purpose of 266 developing Internet standards in which case the procedures for 267 copyrights defined in the Internet Standards process must be 268 followed, or as required to translate it into languages other than 269 English. 271 The limited permissions granted above are perpetual and will not be 272 revoked by the Internet Society or its successors or assignees. 274 This document and the information contained herein is provided on an 275 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 276 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 277 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 278 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 279 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 Acknowledgment 283 Funding for the RFC Editor function is currently provided by the 284 Internet Society.