idnits 2.17.1 draft-kivinen-mobike-design-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 : ---------------------------------------------------------------------------- No issues found here. 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 7357 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: 'RFC0768' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'Kiv04' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'I-D.dupont-mipv6-3bombing' is defined on line 460, 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' == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-00 Summary: 1 error (**), 0 flaws (~~), 7 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 Design of the MOBIKE protocol 7 draft-kivinen-mobike-design-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 discusses the potential design decisions in the base 38 MOBIKE (IKEv2 Mobility and Multihoming) protocol. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 1.1 Roaming Laptop Scenario . . . . . . . . . . . . . . . . . . . 3 44 1.2 Multihoming SGW Scenario . . . . . . . . . . . . . . . . . . . 4 45 2. Major Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5 46 2.1 Adopting a new address / multihoming support . . . . . . . . . 5 47 2.2 Message representation . . . . . . . . . . . . . . . . . . . . 6 48 2.3 Scope of SA changes . . . . . . . . . . . . . . . . . . . . . 8 49 3. Miscallaneous issues . . . . . . . . . . . . . . . . . . . . . 10 50 3.1 Zero Address Set . . . . . . . . . . . . . . . . . . . . . . . 10 51 3.2 When to do Return Routability Checks . . . . . . . . . . . . . 10 52 3.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . . . 11 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 55 Normative references . . . . . . . . . . . . . . . . . . . . . 14 56 Non-normative references . . . . . . . . . . . . . . . . . . . 15 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 58 Intellectual Property and Copyright Statements . . . . . . . . 16 60 1. Introduction 62 The current IKEv2 and IPsec documents explictly say that the IPsec 63 and IKE SAs created implicitly between the IP-addresses used in the 64 IKEv2 SA. This means that there is only one IP-address pair attached 65 for the IKEv2 SA, and the only one IP-address pair used as a gateway 66 endpoint address for tunnel mode IPsec SAs. 68 There are scenarios which requires that the IP address might change 69 rapidly. In some cases the problem could be solved by rekeying all 70 the IPsec and IKE SAs after the IP-address has changed. In some 71 scenarios this might be problematic, as the device might be too slow 72 to rekey the SAs that often, and other scenarios the rekeying and 73 required IKEv2 authentication might require user interaction (SecurID 74 cards etc). Because of those reason the way to update the 75 IP-addresses tied to the IPsec and IKEv2 SAs is required. 77 MOBIKE protocol provides solution to the problem of the updating the 78 IP-addresses. The MOBIKE protocol takes care following: 80 o Notifying the other end of IP-address list changes 82 o Update the IKE SA endpoint addresses based on the notifications 84 o Automatically switching to use new IP-address if old one does not 85 work anymore 87 o Updating the tunnel mode IPsec SA tunnel endpoint addresses 89 o Return routability checks of new addresses if needed 91 The MOBIKE protocol can be used in different scenarios. Two such 92 scenarios are discussed below. 94 1.1 Roaming Laptop Scenario 96 In the roaming laptop scenario the device that moves around is 97 laptop, which might have several ways to connect to internet. It 98 might for example have fixed ethernet, WLAN and GPRS access to net, 99 and some of those can be used in different times. It tries to use the 100 most efficent connection it has all the time, but that connection 101 might change when user for example disconnects himself from the fixed 102 ethernet and uses the office WLAN, and then later leaves the office 103 and starts using GPRS during the trip to home. In home he might again 104 use WLAN (but with different IP-addresses) etc. 106 The device does not use Mobile IP or anything similar, it simply 107 wants to keep the VPN connection to the corporate security gateway 108 (SGW) up and running all the time. Even if the interface or the 109 IP-addresses change the internal addresses used inside the IPsec 110 tunnel remains same (allocated from the SGW), i.e. the applications 111 will not detect the changes at all. 113 1.2 Multihoming SGW Scenario 115 Another possible scenario which might use MOBIKE is the SGW of the 116 other end of the roaming laptop scenario. I.e. the SGW might have 117 multiple interfaces to different ISPs, and wants to provide 118 connection even when some of those connections are broken. The SGW 119 will know beforehand what set of IP-addresses it will use, but it 120 might need to dynamically update the clients to tell them which 121 addresses to use. It might also use this to do some sort of load 122 balancing, i.e. giving different clients different preferred address, 123 to utilize all the connections. This kind of load balancing is 124 completely internal to the SGW (i.e. the clients will simply see that 125 the preferred IP-address to be used for tunnel endpoint changes, but 126 they do not know why or how the SGW decided to do that), and the 127 actual algorithms how to do that is outside the scope of MOBIKE 128 protocol (i.e. MOBIKE does not disallow the SGW to give different 129 sets of IP-addresses in different preference order to different 130 clients). 132 Note, that the load-balancing inside the one IKE SA (i.e. one client) 133 is not handled in the MOBIKE protocol. Each client uses only one of 134 the IP-addresses given by the SGW at one time. 136 2. Major Issues 138 The base protocol needs to be doing following things: 140 o Ability to inform the peer about the current or changed address 141 set of the sender 143 o Ability to infor the peer about the preferred address 145 o Ability to detect an outage situation and fall back to the use of 146 another address 148 o Ability to prevent flooding attacks based on announcing someone 149 else's address 151 o Ability to affect both the IKE and IPsec SAs 153 2.1 Adopting a new address / multihoming support 155 From the MOBIKE's point of view the multihoming support is the set of 156 rules how and when to change to use new IP-address from the list. The 157 other end provides a list of addresses which can be used as a 158 destination address, and the local end needs to decide which of them 159 to use. The MOBIKE does not include load-balancing, i.e. the local 160 end only uses one IP-address at time, and it only changes to use new 161 IP-address after some indication from the other end. 163 That indication might be direct, i.e. the other end sending address 164 update notification, which have different preferred address than 165 which was used before. The local end should try to use the preferred 166 address specified by the other end. 168 The indication might also be indirect, i.e. the local end notices 169 that suddenly the other ends start using different source address for 170 the packets than what it used before. 172 Another type of indirect information might that there has been no 173 traffic from the other end for some time (i.e. the current connection 174 might be broken). 176 This indirect information should not directly cause any changes to 177 the IP-addresses, but they should be used as indication that there 178 might be need to do dead-peer-detection for the currently used 179 address. I.e. when the local end detects that the other end started 180 to use different source IP-address than which was used before, it 181 should initiate dead-peer-detection for the preferred address from 182 the other ends IP-address list (i.e. to the address which it is now 183 using). If that dead-peer-detection tells that the connection is 184 alive, then there is no need to do anything. If local end does not 185 receive any reply to the dead-peer-detection, then it should do 186 dead-peer-detection for the other addresses in the list (in the 187 preferred order). If it can find an address which works, it will 188 switch to that. 190 The IKEv2 dead-peer-detection is done by sending empty informational 191 exchange packet to the other end, in which case the other end will 192 acknowledge that. If no acknowledge is received after certain timeout 193 (and after couple of retransmissions), the local end should try other 194 IP-addresses. The packets to other IP-addresses must use the same 195 message-id as the original dead-peer-detection (i.e. they are simply 196 retransmissions of the dead-peer-detection packet using different 197 destination IP-address). 199 If the local end does not receive acknowledge message back from any 200 of the IP-addresses, it should mark the IKE SA dead, and delete it 201 (as mandated by the IKEv2 specification). 203 The dead-peer-detection for the other IP-addresses can also be done 204 simultaneously, meaning that after the initial timeout of the 205 preferred address expires, we send packets simultaneously to all 206 other IP-addresses. The problem here is that we need to distinguish 207 from the acknowledge packets which IP-address actually works now 208 (i.e. we will check the acknowledge packets source IP-address, as it 209 should match the destination IP we sent out). 211 Also the other end is most likely going to reply only to the first 212 packet it receives, and that first packet might not be the most 213 preferred IP-address. The reason the other end is only responding to 214 the first packet it receives is that implementatins should not send 215 retransmissions if they have just sent out identical retranmissions. 216 This is to protect the packet multiplication problem, which can 217 happen if some node in the network queues up packets and then send 218 them to the destination. If destination will reply to all of them 219 then the other end will again see multiple packets, and will reply to 220 all of them etc. 222 2.2 Message representation 224 One of the basic design choices that is needed for the MOBIKE is the 225 format of the messages. The IKEv2 offeres some formatting 226 alternatives for the protocol. The basic IP-address change 227 notifications can be sent either via informational exchange already 228 specified in the IKEv2, or we could also have our own MOBIKE specific 229 exchange. Using informational exchange has the main advantage that it 230 is already specified in the IKEv2 and the implementations should 231 already have code for those. 233 One advantage of creation of the new exchange would be that we could 234 incorporate the return routability checks to the exchange in this 235 state (i.e. create 3-4 packet exchange). The problem here is that we 236 might need to do the return routability checks for each IP-address 237 separately, thus we might not be able to do it in this phase. 239 Another choice which needs to be done, is the basic format of the 240 address update notifications. The address update notifications 241 include multiple addresses, which some can be IPv4 and some IPv6 242 addresses. The number of addresses is most likely going to be quite 243 small (less than 10). The format needs to give out senders preference 244 of the use of the addresses, i.e. the sender will tell this is the 245 preferred address to be used. The format could either contain the 246 preference number, giving out the relative order of the addresses, or 247 it could simply be ordered list of IP-addresses in the order of the 248 most preferred first. In the authors opinion, the last option appears 249 to be the best one. This is because then we do not need to define 250 what happens if the preference numbers are identical, and we do not 251 need to reserve space for the numbers. We do not need any priority 252 values, we simply need ordered list. 254 Even when the load-balancing inside the one connection is outside the 255 scope of the MOBIKE, there might be future work to include that. The 256 format selected needs to be flexible enough to allow addition of some 257 kind of extra information for the load-balancing features in the 258 future. This might be something like one reserved field, which can 259 later be used to store that information. 261 There are two basic formats for putting IP-address list in to the 262 exchange, we can include each IP-address as separate payload (where 263 the payload order indicates the preference value, or the payload 264 itself might include the preference value), or we can put the 265 IP-address list as one payload to the exchange, and that one payload 266 will then have internal format which includes the list of 267 IP-addresses. 269 Having multiple payloads each having one IP-address makes the 270 protocol propably easier to parse, as we can already use the normal 271 IKEv2 payload parsing procedures to get the list out. It also offers 272 easy way for the extensions, as the payload propably contains only 273 the type of the IP-address (or the type is encoded to the payload 274 type), and the IP-address itself, and as each payload already has 275 length associated to it, we can detect if there is any extra data 276 after the IP-address. Some implementations might have problems 277 parsing too long list of IKEv2 payloads, but if the sender sends them 278 in the most preferred first, the other end can simply only take n 279 first addresses and use them. It might loose connection in some cases 280 if all the n first address are not in use anymore, and the other end 281 hasn't sent new list, but in most cases everything will still work. 283 Having all IP-addresses in one big payload having MOBIKE specified 284 internal format, provides more compact encoding, and keeps the MOBIKE 285 implementation more concentrated to one module. 287 The next choice is which type of payloads to use. IKEv2 already 288 specifies a notify payload, which could be used for that. It includes 289 some extra fields (SPI size, SPI, protocol etc), which gives 4 bytes 290 of the extra overhead, but then there is the notify data field, which 291 could include the MOBIKE specific data. 293 Another option would be to have our own payload type, which then 294 include the information needed for the MOBIKE protocol. 296 The basic protocol is most likely going to be something where we send 297 list of all IP-addresses every time the list changes (either 298 addresses are added, removed, or the preferred order changes). 299 Another option is that we send some kind of incremental updates to 300 the IP-address list. Sending incremental updates provides more 301 compact packets (meaning we can support more IP-addresses), but on 302 the other hand have more problems in the syncronization and packet 303 reordering cases i.e. the incremental updates must be processed in 304 order, but for full updates we can simply use the most recent one, 305 and ignore old ones, even if they arrive after the most recent one 306 (IKEv2 packets have message id which is incremented for each packet, 307 thus we know the sending order easily). 309 The address update notification protocol is not restricted to only 310 one way, i.e. both ends might have multiple IP-addresses and both 311 ends might send address updates. Example of that is when the roaming 312 laptop connects to the multihoming SGW. 314 2.3 Scope of SA changes 316 When the IKE SA address set changes, do we automatically change all 317 the IPsec SAs negotiated with the IKE SA, or do separately request a 318 change in each IPsec SA separately. 320 If we want to update each IPsec SA separately, we propably need more 321 efficient format than notification payload, as it can only store one 322 SPI per payload. I.e. we want separate payload which have list of 323 IPsec SA SPIs and new address set for them. If we have lots of IPsec 324 SAs, those payloads can be quite large unless we support ranges in 325 SPIs or at least have some kind of notation of move those SAs not 326 moved separately (i.e. rest of the SA indication). We also have some 327 problems that we need to keep state per IPsec SA which IP-addresses 328 are used for that SA. If we automatically move all IPsec SAs when the 329 IKE SA moves, then we only need to keep track which IKE SA was used 330 to create the IPsec SA, and fetch the IP-addresses from that (Note, 331 that IKEv2 [I-D.ietf-ipsec-ikev2] already requires implemenations to 332 keep track which IPsec SAs are created using which IKE SA). 334 If we do allow each IPsec SAs address sets to be updated separately, 335 then we can support scenarios, where the machine have fast and/or 336 cheap connection and slow and/or expensive connection, and it wants 337 to allow moving some of the SAs to the slower and/or more expensive 338 connection, and forbid some SAs to move. I.e. never move the news 339 video stream from the WLAN to the GPRS link. 341 On the other hand, even if we tie the IKE SA update to the IPsec SA 342 update, then we need to create separate IKE SAs for this scenario, 343 i.e. we create one IKE SA which have both links as endpoints, and it 344 is used for important traffic, and then we create another IKE SA 345 which have only the fast and/or cheap connection, which is then used 346 for that kind of bulk traffic. 348 3. Miscallaneous issues 350 There are also some smaller issues, which needs to be decided in the 351 MOBIKE protocol. Those issues include whether we allow disconnection 352 notifications, do we need to do return routablity checks always, and 353 what shall we do with simultaneous movement. 355 3.1 Zero Address Set 357 One of the features which might be usefull would be for the peer to 358 announce the other end that it will now disconnect for some time, 359 i.e. it will not be reachable at all. For instance, a laptop might go 360 to suspend mode. In this case the peer could send address 361 notification with zero new addressess, which means that it will not 362 have any valid addresses anymore. The responder of that kind of 363 notification would then acknoledge that, and could then temporarely 364 disable all SAs. If any of the SAs gets any packets they are simply 365 dropped. This could also include some kind of ACK faking to keep the 366 TCP/IP sessions alive, or it could simply be left to the 367 applications, i.e. allow TCP/IP sessions to notice the link is 368 broken. 370 The local policy could then decide how long the peer would allow 371 other peers to be disconnected, i.e. whether this is only allowed for 372 few minutes, or do they allow users to disconnect Friday evening and 373 reconnect Monday morning (consuming resources during that, but on the 374 other hand not more than is normally used during week days). 376 3.2 When to do Return Routability Checks 378 One of the decisions that needs to be done, when to do return 379 routability checks. The simple approach is to do it always. Another 380 option is to do it every time new IP-address is taken in to use. The 381 basic format of the return routability check could be similar than 382 dead-peer-detection, but the problem is that if that fails then the 383 IKEv2 specification requires the IKE SA to be deleted. Because of 384 this we might need to do some kind of other exchange. 386 If the other end is SGW with limited set of fixed IP-addresses, then 387 the SGW can get certificate having all the IP-addresses in the 388 certificate. If the certificate includes all the IP-addresses, it is 389 no point to do weaker return routability check, the data in the 390 certificate is already properly authenticated after the IKE SA is 391 created, so the peer might simply use that and ignore return 392 routability checks. 394 Another option is to use draft-dupont-mipv6-3bombing 395 [I.D.dupont-mipv6-3bombing] approach: do it only if you had to send 396 the update from some other address than indicated preferred address. 398 Final option would simply not to do return routability checks at all. 399 If we use indirect change notifications then we only move to the new 400 IP address after successfull dead-peer-detection on the new address, 401 which is already return routability check. In the direct change 402 notifications the authenticated peer have given out authenticated 403 IP-address, thus we could simply trust the other end. There is no way 404 external attacker can cause any attacks, but we are not protected by 405 the internal attacker, i.e. the authenticatede peer forwarding its 406 traffic to the new address. On the other hand we do know the identity 407 of the peer in that case. 409 3.3 Simultaneous Movements 411 As we are not creating full mobility solution, but are instead 412 concentrating on the VPN style scenarios, we do not need to solve the 413 simultaneous movement recovery problem. We assume that the one end 414 (SGW) will have fixed set of addresses (from which some subset might 415 be in use), thus it cannot move to the address not known by the other 416 end. This means that the solutions how to recover from cases where 417 both ends move and the movement notifications do not reach other 418 ends, is outside the scope of the MOBIKE WG. 420 4. Security Considerations 422 As all the messages are already authenticated by the IKEv2 there is 423 no problem that any attackers would modify the actual contents of the 424 packets. The IP addresses in the packets are not authenticated, thus 425 the protocol defined must take care that they are only used as an 426 indication that something might be different, they should not cause 427 any direct actions. 429 One type of attacks which needs to be taken care of the MOBIKE 430 protocol is also various flooding attacks. See 431 [I-D.nikander-mobileip-v6-ro-sec] and [Aur02] for more information 432 about flooding attacks. 434 5. IANA Considerations 436 No IANA assignments are needed. 438 Normative references 440 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 441 August 1980. 443 [I-D.ietf-ipsec-ikev2] 444 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 445 draft-ietf-ipsec-ikev2-12 (work in progress), January 446 2004. 448 [Kiv04] Kivinen, T., "MOBIKE protocol", 449 draft-kivinen-mobike-protocol-00 (work in progress), 450 February 2004. 452 Non-normative references 454 [I-D.nikander-mobileip-v6-ro-sec] 455 Nikander, P., "Mobile IP version 6 Route Optimization 456 Security Design Background", 457 draft-nikander-mobileip-v6-ro-sec-02 (work in progress), 458 December 2003. 460 [I-D.dupont-mipv6-3bombing] 461 Dupont, F., "A note about 3rd party bombing in Mobile 462 IPv6", draft-dupont-mipv6-3bombing-00 (work in progress), 463 February 2004. 465 [Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet 466 Location Management", In Proc. 18th Annual Computer 467 Security Applications Conference, pages 78-87, Las Vegas, 468 NV USA, December 2002. 470 Author's Address 472 Tero Kivinen 473 Safenet, Inc. 474 Fredrikinkatu 47 475 HELSINKI FIN-00100 476 FI 478 EMail: kivinen@safenet-inc.com 480 Intellectual Property Statement 482 The IETF takes no position regarding the validity or scope of any 483 intellectual property or other rights that might be claimed to 484 pertain to the implementation or use of the technology described in 485 this document or the extent to which any license under such rights 486 might or might not be available; neither does it represent that it 487 has made any effort to identify any such rights. Information on the 488 IETF's procedures with respect to rights in standards-track and 489 standards-related documentation can be found in BCP-11. Copies of 490 claims of rights made available for publication and any assurances of 491 licenses to be made available, or the result of an attempt made to 492 obtain a general license or permission for the use of such 493 proprietary rights by implementors or users of this specification can 494 be obtained from the IETF Secretariat. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights which may cover technology that may be required to practice 499 this standard. Please address the information to the IETF Executive 500 Director. 502 Full Copyright Statement 504 Copyright (C) The Internet Society (2004). All Rights Reserved. 506 This document and translations of it may be copied and furnished to 507 others, and derivative works that comment on or otherwise explain it 508 or assist in its implementation may be prepared, copied, published 509 and distributed, in whole or in part, without restriction of any 510 kind, provided that the above copyright notice and this paragraph are 511 included on all such copies and derivative works. However, this 512 document itself may not be modified in any way, such as by removing 513 the copyright notice or references to the Internet Society or other 514 Internet organizations, except as needed for the purpose of 515 developing Internet standards in which case the procedures for 516 copyrights defined in the Internet Standards process must be 517 followed, or as required to translate it into languages other than 518 English. 520 The limited permissions granted above are perpetual and will not be 521 revoked by the Internet Society or its successors or assignees. 523 This document and the information contained herein is provided on an 524 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 525 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 526 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 527 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 528 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Acknowledgment 532 Funding for the RFC Editor function is currently provided by the 533 Internet Society.