idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** 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 196: '...address changed, MUST start recovery p...' 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 (June 24, 2004) is 7246 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 696, but no explicit reference was found in the text == Unused Reference: 'I-D.dupont-mipv6-3bombing' is defined on line 708, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-14 -- Possible downref: Normative reference to a draft: ref. 'Kiv04' == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 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 June 24, 2004 4 Expires: December 23, 2004 6 Design of the MOBIKE protocol 7 draft-ietf-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 December 23, 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. It also tries to 39 provide some background information about different choices and tries 40 to record the decisions made by the working group, so that we do not 41 need to repeat discussion later. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Roaming Laptop Scenario . . . . . . . . . . . . . . . . . 3 47 1.2 Multihoming SGW Scenario . . . . . . . . . . . . . . . . . 4 48 2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3. Adopting a new address / multihoming support . . . . . . . . . 6 50 3.1 IP-address list or one IP-address . . . . . . . . . . . . 6 51 3.2 Indirect or direct indication (issue #1) . . . . . . . . . 7 52 3.3 Dead peer detection and IKEv2 (issue #11) . . . . . . . . 7 53 4. Simultaneous Movements (issue #2) . . . . . . . . . . . . . . 9 54 5. Interaction with NAT-T (issue #3) . . . . . . . . . . . . . . 10 55 6. Changing addresses or changing the paths (issue #10, #14) . . 11 56 7. How and When to do Return Routability Checks (issue #6, 57 #12, #15) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 58 8. Scope of SA changes (issue #8) . . . . . . . . . . . . . . . . 14 59 9. Zero Address Set (issue #5) . . . . . . . . . . . . . . . . . 15 60 10. What modes we support (issue #7) . . . . . . . . . . . . . . 16 61 11. Message representation . . . . . . . . . . . . . . . . . . . 17 62 12. Security Considerations . . . . . . . . . . . . . . . . . . 19 63 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 64 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 65 14.1 Normative references . . . . . . . . . . . . . . . . . . . . 21 66 14.2 Non-normative references . . . . . . . . . . . . . . . . . . 21 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 68 Intellectual Property and Copyright Statements . . . . . . . . 22 70 1. Introduction 72 The current IKEv2 and IPsec documents explicitly say that the IPsec 73 and IKE SAs created implicitly between the IP-addresses used in the 74 IKEv2 SA. This means that there is only one IP-address pair attached 75 for the IKEv2 SA, and the only one IP-address pair used as a gateway 76 endpoint address for tunnel mode IPsec SAs. Also after the SA is 77 created there is no way to change those addresses. 79 There are scenarios which require that the IP address might change 80 rapidly. In some cases the problem could be solved by rekeying all 81 the IPsec and IKE SAs after the IP-address has changed. In some 82 scenarios this might be problematic, as the device might be too slow 83 to rekey the SAs that often, and other scenarios the rekeying and 84 required IKEv2 authentication might require user interaction (SecurID 85 cards etc). Due to these reasons, a mechanism to update the 86 IP-addresses tied to the IPsec and IKEv2 SAs is needed. 88 The charter of the MOBIKE working group requires IKEv2, and as IKEv2 89 assumes that the RFC2401bis architecture is used, all protocols 90 developed will use both IKEv2 and RFC2401bis (issue #9). No effort is 91 to be made to make protocols for IKEv1 or old RFC2401 architecture. 93 MOBIKE protocol provides solution to the problem of the updating the 94 IP-addresses. The MOBIKE protocol should take care following: 95 o Notifying the other end of IP-address(es) change 96 o Update the IKE SA endpoint addresses based on the notifications 97 o Switching to use new IP-address if old one does not work anymore 98 o Updating the tunnel mode IPsec SA tunnel endpoint addresses 99 o Ensuring that the given new addresses belong to the peer 101 The MOBIKE protocol can be used in different scenarios. Two such 102 scenarios are discussed below. 104 1.1 Roaming Laptop Scenario 106 In the roaming laptop scenario the device that moves around is 107 laptop, which might have several ways to connect to internet. It 108 might for example have fixed ethernet, WLAN and GPRS access to net, 109 and some of those can be used in different times. It tries to use the 110 most efficient connection it has all the time, but that connection 111 might change. For example user can disconnect himself from the fixed 112 ethernet, and then use the office WLAN, and then later leave the 113 office and start using GPRS during the trip to home. In home he might 114 again use again WLAN (but with different IP-addresses) etc. 116 The device does not use Mobile IP or anything similar, it simply 117 wants to keep the VPN connection to the corporate security gateway 118 (SGW) up and running all the time. Even if the interface or the 119 IP-addresses change, the internal addresses used inside the IPsec 120 tunnel remains same (allocated from the SGW), i.e. the applications 121 might not detect the changes at all. 123 1.2 Multihoming SGW Scenario 125 Another possible scenario which might use MOBIKE is the SGW of the 126 other end of the roaming laptop scenario. The SGW might have multiple 127 interfaces to different ISPs, and wants to provide connection even 128 when some of those connections are broken. One of the interface might 129 also be the WLAN access point in the office. The SGW will know 130 beforehand what set of IP-addresses it will use, but it might need to 131 dynamically send update notifications the clients to tell them which 132 addresses to use. It might also use this to do some sort of load 133 balancing, i.e. giving different clients different preferred address, 134 to utilize all the connections. This kind of load balancing is 135 completely internal to the SGW (i.e. the clients will simply see that 136 the preferred IP-address to be used for tunnel endpoint changes, but 137 they do not know why or how the SGW decided to do that), and the 138 actual algorithms how to do that is outside the scope of MOBIKE 139 protocol (i.e. the whole issues is that MOBIKE does not disallow the 140 SGW to give different sets of IP-addresses in different preference 141 order to different clients). 143 Note, that the load-balancing inside the one IKE SA (i.e. one client) 144 is not handled in the MOBIKE protocol. Each client uses only one of 145 the IP-addresses given by the SGW at one time. 147 2. Issues 149 The base protocol needs to perform the following things: 150 o Ability to inform the peer about the current or changed 151 address(es) of the sender 152 o Ability to inform the peer about the preferred address 153 o Ability to detect an outage situation and fall back to the use of 154 another address 155 o Ability to prevent flooding attacks based on announcing someone 156 else's address 157 o Ability to affect both the IKE and IPsec SAs 159 One of the key issues affecting the MOBIKE protocol is, whether 160 MOBIKE protocol needs to recover from the case where packets simply 161 dont get through. If the node can locally detect some problems with 162 the interfaces (IP-address change, interface disappearing, link going 163 down), it can act based on that and fix the situation. If the packets 164 are simply disappearing somewhere in the net, the detection of the 165 problem requires noticing that we cannot get packets through. If the 166 protocol only need to fix problems appearing in the local interfaces, 167 then the protocol is much simpler. 169 3. Adopting a new address / multihoming support 171 From the MOBIKE's point of view the multihoming support is the set of 172 rules how and when to change to use new IP-address for the other end. 174 3.1 IP-address list or one IP-address 176 One option is that the other end can provide a list of addresses 177 which can be used as destination addresses, and the local end needs 178 to decide which of them to use. The MOBIKE does not include 179 load-balancing, i.e. the local end only uses one IP-address at time, 180 and it only changes to use new IP-address after some kind of 181 indication. 183 Another option is to only communicate one address for each end, and 184 both ends only use that address when communicating. When the 185 something changes, the end whose situation changes, sends update 186 notification to the other end, changing that one address. 188 If the other end provides the full list of possible IP-addresses, 189 then the other end can recover from the movements on its own, meaning 190 that when it detects it cannot get packets through it can try another 191 IP-address. If the other end only provides one IP-address to be used, 192 then the other end has to wait for the new IP-address before the 193 situation is fixed. The good thing about only one IP-address for the 194 remote host is that it makes retransmission easy, and it also makes 195 it clear which end should do the recovery (i.e. the end, whose 196 IP-address changed, MUST start recovery process and send the new 197 IP-address to the other end). 199 The one IP-address approach will not work if both ends happen to 200 loose their IP-address at the same time (routing problems, which 201 causes the one link between the hosts to go down, thus either end 202 cannot get recovery packets through as the link is down). It also may 203 cause the requirement for the IKEv2 window size larger than 1, 204 especially if only direct indications are used. This is because the 205 host needs to be able to send the IP-address change notifications 206 before it can switch to another address, and depending on the return 207 routability checks, retransmissions policies etc, it might be hard to 208 make the protocol such that it works with window size of 1 too (issue 209 #11). Also one IP-address approach does not really benefit much from 210 the indirect indications as the end getting those indirect 211 indications cannot often fix the situation by itself (i.e. even if 212 the host gets ICMP host unreachable for the old IP-address, it cannot 213 try other IP-addresses, as it does not know them). 215 The problems with IP-address list are mostly in its complexity. 216 Notification and recovery processes are more complex, as both end can 217 recover from the IP-address changes. There is also possibilities that 218 both ends tries to recover at the same time and this must be taken 219 care in the protocol. 221 3.2 Indirect or direct indication (issue #1) 223 The indication that the situation regarding the IP-address has 224 changed might be either direct or indirect. The direct indication 225 means that the other end will send specific indication that now 226 something changed. The indirect indication is something which can be 227 observed from infrastructure or lack of packets, not directly from 228 the other end. 230 The direct indication can be for example the other end IKEv2 sending 231 authenticated address update notification, which have different 232 IP-address(es) than used earlier. 234 The indirect indication can be many things. One example might be that 235 the local end notices that suddenly the other ends start using 236 different source address for the packets than what it used before, or 237 ICMP message or routing information change. 239 Another type of indirect information might that there has been no 240 traffic from the other end for some time (i.e. the current connection 241 might be broken). 243 This kind of indirect information should not directly cause any 244 changes to the IP-addresses, but they should be used as indication 245 that there might be need to do dead-peer-detection for the currently 246 used address. I.e. when the local end detects that the other end 247 started to use different source IP-address than which was used 248 before, it should initiate dead-peer-detection for the address 249 currently in use. If that dead-peer-detection tells that the 250 connection is alive, then there is no need to do anything. If local 251 end does not receive any reply to the dead-peer-detection, then it 252 should do dead-peer-detection for the other addresses in the list (if 253 available, in the preferred order). If it can find an address which 254 works, it will switch to that. 256 3.3 Dead peer detection and IKEv2 (issue #11) 258 The IKEv2 dead-peer-detection is done by sending empty informational 259 exchange packet to the other end, in which case the other end will 260 acknowledge that. If no acknowledge is received after certain timeout 261 (and after couple of retransmissions), the local end should try other 262 IP-addresses (if available). The packets to other IP-addresses should 263 use the same message-id as the original dead-peer-detection (i.e. 264 they are simply retransmissions of the dead-peer-detection packet 265 using different destination IP-address). If different message-id is 266 used that violates the IKEv2 constraints on the mandatory ACK for 267 each message-id, causing the IKEv2 SA to be teared down. 269 If the local end does not receive acknowledge message back from any 270 of the IP-addresses, it should mark the IKE SA dead, and delete it 271 (as mandated by the IKEv2 specification). 273 Note, that as IKEv2 implementations might have window size of 1, it 274 means that while we are doing some other exchange, we cannot initiate 275 dead-peer-detection. This means that all other exchanges should also 276 receive identical retransmission policy than what is used for the 277 dead-peer-detection (issue #11). 279 The dead-peer-detection for the other IP-addresses can also be done 280 simultaneously, meaning that after the initial timeout of the 281 preferred address expires, we send packets simultaneously to all 282 other IP-addresses. The problem here is that we need to distinguish 283 from the acknowledge packets which IP-address actually works now 284 (i.e. we will check the acknowledge packets source IP-address, as it 285 should match the destination IP we sent out). 287 Also the other end is most likely going to reply only to the first 288 packet it receives, and that first packet might not be the most 289 preferred IP-address. The reason the other end is only responding to 290 the first packet it receives, is that implementations should not send 291 retransmissions if they have just sent out identical retransmissions. 292 This is to protect the packet multiplication problem, which can 293 happen if some node in the network queues up packets and then send 294 them to the destination. If destination will reply to all of them 295 then the other end will again see multiple packets, and will reply to 296 all of them etc. 298 The protocol should also be nice to the network, meaning, that when 299 some core router link goes down, and all those MOBIKE clients notice 300 that, they should not start sending lots of messages while trying to 301 recover from the problem. This might be especially bad if this 302 happens because packets are dropped because of the congested network. 303 If MOBIKE clients will try simultaneously test all IP-addresses 304 sending lots of packets to the net, because they lost one packet 305 because of the congestion, it simply make problem worse. 307 Also note, that IKE dead-peer-detection is not sufficient for the 308 return routability check. See Section 7 for more information. 310 4. Simultaneous Movements (issue #2) 312 We do not need to solve the simultaneous movement recovery problem, 313 as we are not creating full mobility solution (charter forbids that), 314 but are instead concentrating on the VPN style scenarios. In the 315 scenarios we assume that the one end (SGW) will have fixed set of 316 addresses (from which some subset might be in use), thus it cannot 317 move to the address not known by the other end. This means that the 318 solutions how to recover from cases where both ends move and the 319 movement notifications do not reach other ends, is outside the scope 320 of the MOBIKE WG. 322 Note, that if we use only one address per each end, instead of 323 address list, we might end up in the case where it seems that both 324 ends changed their addresses at the same time. This is something that 325 the protocol must take care of. 327 There is three different cases here: 328 Two mobile nodes getting a new address at the same time, and then 329 being unable to tell each other where they are. This problem is 330 called the rendevouz problem, and is traditionally solved using 331 home agents (Mobile IPv6) or forwarding agents (Host Identity 332 Protocol). Essentially, solving this problem requires the 333 existence of a stable infrastructure node somewhere. Example: 334 roaming laptop to another roaming laptop, no SGW involved. 335 Simultaneous changes to addresses such that at least one of the 336 new addresses was known by both peers before the change occurred. 337 The primary problem in first case was not knowing the new 338 addresses beforehand. Here we know the address so there is no 339 problem. Example 1: two SGWs failover to another path. Example 2: 340 roaming laptop gets a new address at the same time as its SGW's 341 primary interface goes down. 342 No simultaneous changes at all. 344 5. Interaction with NAT-T (issue #3) 346 In some way the MOBIKE and NAT-T are not compatible. The NAT-T tries 347 to work regardless of the IP-addresses, i.e. regardless whether 348 someone modifies its IP-address or not. One of the goals in the 349 MOBIKE is to AUTHENTICATE the change of the IP-address, i.e. when the 350 IP-address changes we want to verify that this change is actually 351 legitimate change done by the other end, not something done by the 352 attacker along the path. 354 There is no way to distinguish the cases where there is NAT along the 355 path which modifies the packets or if it is an attacker doing that. 356 If NAT is detected in the IKE SA creation, that should automatically 357 disable the MOBIKE extensions and use NAT-T. 359 If MOBIKE is enabled for the IKE SA (i.e. no NAT along the path when 360 the IKE SA was created), then if NAT is later added then MOBIKE can 361 detect that, but it cannot securely do anything for the issue. We can 362 disable MOBIKE extensions completely at that time and move to use 363 NAT-T, but as we loose all the security offered by the MOBIKE, it 364 might be better to rekey the IKE SA (if policy allows that) so that 365 we do not use MOBIKE at all and start using normal NAT-T. 367 If we start using NAT-T, then there is no defined way to detect that 368 we moved away from the inside of the NAT. Thus we need to modify 369 NAT-T and add that kind of detection capability there, if we want to 370 start using MOBIKE at that point. 372 As a summary, if the policy accepts the risks caused by enabling 373 NAT-T, then it can switch to NAT-T when it detects we are behind NAT. 374 Easiest way to do it is to create new IKE SA, as NAT-T can only be 375 enabled by the initial IKE SA creation, and it cannot be enabled by 376 rekeys. Moving back from NAT-T to MOBIKE is harder as it requires 377 changes to NAT-T. On the other hand keeping NAT-T enabled simply adds 378 few bytes of extra overhead. 380 If we define some additions and extensions to NAT-T we can probably 381 make it work better with MOBIKE, but there are quite a lot open 382 issues. One way of seeing this is, that we have few other parameters 383 we might want to turn on during the address update, i.e. the NAT-T 384 parameters. Those include turning on or off keepalives, UDP 385 encapsulation, or automatic address updating. 387 6. Changing addresses or changing the paths (issue #10, #14) 389 The question here is, if it is enough for the MOBIKE to detect the 390 dead-address, or do it need to detect also dead-paths. Dead-address 391 detection means that we only detect that we cannot get packets 392 through to that remote address by using the local IP-address given by 393 the local IP-stack (i.e. local address selected normally by the 394 routing information). Dead-path detection means that we need to try 395 all possible local interfaces/IP-addresses for each remote addresses, 396 i.e. find all possible paths between the hosts and try them all to 397 see which of them work (or at least find one working path). 399 Doing the dead-address detection is simpler, and there is less probe 400 packets to be sent, thus it does not cause that much stress to the 401 network. It also is enough for the scenarios where the connection 402 problems are local (i.e. interfaces going down, WLAN access 403 disappearing etc). It does not help if some router somewhere along 404 the path breaks down, in which case rerouting the packets along 405 another path might get around that broken router. The question is, 406 whether rerouting around that problem inside the core network is a 407 problem that MOBIKE needs to solve. 409 7. How and When to do Return Routability Checks (issue #6, #12, #15) 411 One of the decisions that needs to be done is when to do return 412 routability checks. The simple approach is to do it always. Another 413 option is to do it every time new IP-address is taken in to use. The 414 basic format of the return routability check could be similar than 415 dead-peer-detection, but the problem is that if that fails then the 416 IKEv2 specification requires the IKE SA to be deleted. Because of 417 this we might need to do some kind of other exchange. 419 If the other end is SGW with limited set of fixed IP-addresses, then 420 the SGW may have a certificate having all the IP-addresses in the 421 certificate. If the certificate includes all the IP-addresses, it is 422 no point to do weaker return routability check, the data in the 423 certificate is already properly authenticated after the IKE SA is 424 created, so the peer might simply use that and ignore return 425 routability checks for the addresses of the SGW. 427 Another option is to use draft-dupont-mipv6-3bombing 428 [I.D.dupont-mipv6-3bombing] approach: do it only if you had to send 429 the update from some other address than indicated preferred address. 431 Final option would simply not to do return routability checks at all. 432 If we use indirect change notifications then we only move to the new 433 IP address after successful dead-peer-detection on the new address, 434 which is already return routability check. In the direct change 435 notifications the authenticated peer have given out authenticated 436 IP-address, thus we could simply trust the other end. There is no way 437 external attacker can cause any attacks, but we are not protected by 438 the internal attacker, i.e. the authenticated peer forwarding its 439 traffic to the new address. On the other hand we do know the identity 440 of the peer in that case. 442 There are some attacks which can be launched unless the return 443 routability checks include some kind of nonce (issue #15). In this 444 attack the valid end points sends address update notification for the 445 third party, trying to get all the traffic to be sent there, causing 446 denial of service attack. If the return routability checks does not 447 contain any cookies or other random information not known by the 448 other end, then that valid node could reply to the return routability 449 checks even when it cannot see the request. This might cause the 450 other end to turn the traffic to there, even when the real original 451 recipient isn't at that address. 453 The IKEv2 NAT-T does not do any return routability checks. It simply 454 uses the last address used by the other end, as and address where to 455 send return packets back. The attacker can change those IP-addresses, 456 and can cause the return packets to be sent to wrong IP-address. The 457 situation is fixed immediately when the attacker no longer changes 458 the packets, and the first packet with real IP-address reaches the 459 other end. In IKEv2 NAT-T the valid client can cause third party 460 bombing by redirecting all the traffic pointed to him to third party. 461 As the MOBIKE tries to provide better security than IKEv2 NAT-T the 462 MOBIKE protocol should protect against those attacks. 464 There might be also return routability information available from the 465 other parts of the system too (IP-stack, Mobile IP or so), but the 466 checks done might be different (issue #12). There are multiple 467 different levels for the return routability checks: 468 o None, no tests 469 o A party willing to answer is on the path to the claimed address. 470 This is the basic form of return routability test. 471 o There is an answer from the tested address, and that answer was 472 authenticated (including the address) to be from our peer. 473 o There was an authenticated answer from the peer, but it is not 474 guaranteed to be from the tested address or path to it (because 475 the peer can construct a response without seeing the request). 477 The basic return routability checks do not protect against 3rd party 478 bombing, if the attacker is along the path, as the attacker can 479 forward the return routability checks to the real peer (even if those 480 packets are cryptographically authenticated) 482 If the address to be tested is inside the packet too, then attacker 483 cannot forward packets, thus it prevents 3rd party bombings. 485 If the reply packet can be constructed without seeing the request 486 packet (i.e. there is no nonce or similar), then the real peer can 487 cause 3rd party bombing, by replying to those requests without seeing 488 them at all. 490 Other levels might only return information saying that yes, there is 491 someone there in the IP-address which replied to my request. Or say 492 that I sent request to IP-address and got reply back, but I am not 493 sure whether that reply was freshly generated or repeated, or sent 494 from different address. The MOBIKE requirements for the return 495 routability checks could be to verify that there is same 496 (cryptographically) authenticated node in the other end and it can 497 now receive packets from the IP-address it claims to have. 499 MOBIKE might also want to export the information it has done the 500 return routability checks to the other modules, like Mobile IP, so 501 Mobile IP does not need to do return routability checks again, if it 502 is satisfied with the level of checks done by the MOBIKE. 504 8. Scope of SA changes (issue #8) 506 The basic question is that how the IPsec SAs are changed to use new 507 address. One option is that when the IKE SA address is changed then 508 automatically all IPsec SAs associated with it are moved along with 509 it to new address. Another option is to have separate exchange to 510 move the IPsec SAs separately. 512 If we want to update each IPsec SA separately, we probably need more 513 efficient format than notification payload, as it can only store one 514 SPI per payload. I.e. we want separate payload which have list of 515 IPsec SA SPIs and new address set for them. If we have lots of IPsec 516 SAs, those payloads can be quite large unless we support ranges in 517 SPIs or at least have some kind of notation of move those SAs not 518 moved separately (i.e. rest of the SAs indication). The 519 implementations need also keep state of IP-addresses per IPsec SA, 520 not per IKE SA. If we automatically move all IPsec SAs when the IKE 521 SA moves, then we only need to keep track which IKE SA was used to 522 create the IPsec SA, and fetch the IP-addresses from that (Note, that 523 IKEv2 [I-D.ietf-ipsec-ikev2] already requires implementations to keep 524 track which IPsec SAs are created using which IKE SA). 526 If we do allow each IPsec SAs address sets to be updated separately, 527 then we can support scenarios, where the machine have fast and/or 528 cheap connection and slow and/or expensive connection, and it wants 529 to allow moving some of the SAs to the slower and/or more expensive 530 connection, and forbid some SAs to move. I.e. never move the news 531 video stream from the WLAN to the GPRS link. 533 On the other hand, even if we tie the IKE SA update to the IPsec SA 534 update, then we can create separate IKE SAs for this scenario, i.e. 535 we create one IKE SA which have both links as endpoints, and it is 536 used for important traffic, and then we create another IKE SA which 537 have only the fast and/or cheap connection, which is then used for 538 that kind of bulk traffic. 540 9. Zero Address Set (issue #5) 542 One of the features which might be useful would be for the peer to 543 announce the other end that it will now disconnect for some time, 544 i.e. it will not be reachable at all. For instance, a laptop might go 545 to suspend mode. In this case the peer could send address 546 notification with zero new addresses, which means that it will not 547 have any valid addresses anymore. The responder of that kind of 548 notification would then acknowledge that, and could then temporarily 549 disable all SAs. If any of the SAs gets any packets they are simply 550 dropped. This could also include some kind of ACK spoofing to keep 551 the TCP/IP sessions alive (or simply set the TCP/IP keepalives and 552 timeouts large enough not to cause problems), or it could simply be 553 left to the applications, i.e. allow TCP/IP sessions to notice the 554 link is broken. 556 The local policy could then decide how long the peer would allow 557 other peers to be disconnected, i.e. whether this is only allowed for 558 few minutes, or do they allow users to disconnect Friday evening and 559 reconnect Monday morning (consuming resources during weekend too, but 560 on the other hand not more than is normally used during week days, 561 but we do not need lots of extra resources on the Monday morning to 562 support all those people connecting back to network). 564 10. What modes we support (issue #7) 566 The charter mostly talks about VPN style usage, and all scenarios are 567 using tunnel mode, so that is where this document mostly 568 concentrates. For transport mode to be used we first need to define 569 the scenarios where it is needed. XXX someone needs to write more 570 text here. 572 11. Message representation 574 One of the basic design choices that is needed for the MOBIKE is the 575 format of the messages. The IKEv2 offers some formatting alternatives 576 for the protocol. The basic IP-address change notifications can be 577 sent either via informational exchange already specified in the 578 IKEv2, or we could also have our own MOBIKE specific exchange. Using 579 informational exchange has the main advantage that it is already 580 specified in the IKEv2 and the implementations should already have 581 code for those. 583 One advantage of creation of the new exchange would be that we could 584 incorporate the return routability checks to the exchange in this 585 state (i.e. create 3-4 packet exchange). The problem here is that we 586 might need to do the return routability checks for each IP-address 587 separately, thus we might not be able to do it in this phase. 589 Another question is the basic format of the address update 590 notifications. The address update notifications can include multiple 591 addresses, which some can be IPv4 and some IPv6 addresses. The number 592 of addresses is most likely going to be quite small (less than 10). 593 The format might need to give out senders preference of the use of 594 the addresses, i.e. the sender will tell this is the preferred 595 address to be used. The format could either contain the preference 596 number, giving out the relative order of the addresses, or it could 597 simply be ordered list of IP-addresses in the order of the most 598 preferred first. Benefits of the ordered list is, that then we do not 599 need to define what happens if the preference numbers are identical, 600 and we do not need to reserve space for the numbers. Normally we do 601 not need any priority values, we simply need an ordered list. 603 Even when the load-balancing inside the one connection is outside the 604 scope of the MOBIKE, there might be future work to include that. The 605 format selected needs to be flexible enough to allow addition of some 606 kind of extra information for the load-balancing features in the 607 future. This might be something like one reserved field, which can 608 later be used to store that information. As there is other potential 609 information which might have to be tied to the address in the future, 610 a reserved field seems like a prudent design in any case. 612 There are two basic formats for putting IP-address list in to the 613 exchange, we can include each IP-address as separate payload (where 614 the payload order indicates the preference value, or the payload 615 itself might include the preference value), or we can put the 616 IP-address list as one payload to the exchange, and that one payload 617 will then have internal format which includes the list of 618 IP-addresses. 620 Having multiple payloads each having one IP-address makes the 621 protocol probably easier to parse, as we can already use the normal 622 IKEv2 payload parsing procedures to get the list out. It also offers 623 easy way for the extensions, as the payload probably contains only 624 the type of the IP-address (or the type is encoded to the payload 625 type), and the IP-address itself, and as each payload already has 626 length associated to it, we can detect if there is any extra data 627 after the IP-address. Some implementations might have problems 628 parsing too long list of IKEv2 payloads, but if the sender sends them 629 in the most preferred first, the other end can simply only take n 630 first addresses and use them. It might loose connection in some cases 631 if all the n first address are not in use anymore, and the other end 632 hasn't sent new list, but in most cases everything will still work. 634 Having all IP-addresses in one big payload having MOBIKE specified 635 internal format, provides more compact encoding, and keeps the MOBIKE 636 implementation more concentrated to one module. 638 The next choice is which type of payloads to use. IKEv2 already 639 specifies a notify payload, which could be used for that. It includes 640 some extra fields (SPI size, SPI, protocol etc), which gives 4 bytes 641 of the extra overhead, and there is the notify data field, which 642 could include the MOBIKE specific data. 644 Another option would be to have our own payload type, which then 645 include the information needed for the MOBIKE protocol. 647 The basic protocol is most likely going to be something where we send 648 list of all IP-addresses every time the list changes (either 649 addresses are added, removed, or the preferred order changes). 650 Another option is that we send some kind of incremental updates to 651 the IP-address list. Sending incremental updates provides more 652 compact packets (meaning we can support more IP-addresses), but on 653 the other hand have more problems in the synchronization and packet 654 reordering cases i.e. the incremental updates must be processed in 655 order, but for full updates we can simply use the most recent one, 656 and ignore old ones, even if they arrive after the most recent one 657 (IKEv2 packets have message id which is incremented for each packet, 658 thus we know the sending order easily). 660 The address update notification protocol is not restricted to only 661 one way, i.e. both ends might have multiple IP-addresses and both 662 ends might send address updates. Example of that is when the roaming 663 laptop connects to the multihoming SGW. 665 12. Security Considerations 667 As all the messages are already authenticated by the IKEv2 there is 668 no problem that any attackers would modify the actual contents of the 669 packets. The IP addresses in IP header of the packets are not 670 authenticated, thus the protocol defined must take care that they are 671 only used as an indication that something might be different, they 672 should not cause any direct actions. 674 Attacker can also spoof ICMP error messages in an effort to confuse 675 the peers about which addresses are not working. At worst this causes 676 denial-of-service and/or the use of non-preferred addresses, so it is 677 not that serious. 679 One type of attacks which needs to be taken care of the MOBIKE 680 protocol is also various flooding attacks. See 681 [I-D.nikander-mobileip-v6-ro-sec] and [Aur02] for more information 682 about flooding attacks. 684 13. IANA Considerations 686 No IANA assignments are needed. 688 14. References 690 14.1 Normative references 692 [I-D.ietf-ipsec-ikev2] 693 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 694 draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. 696 [Kiv04] Kivinen, T., "MOBIKE protocol", 697 draft-kivinen-mobike-protocol-00 (work in progress), 698 February 2004. 700 14.2 Non-normative references 702 [I-D.nikander-mobileip-v6-ro-sec] 703 Nikander, P., "Mobile IP version 6 Route Optimization 704 Security Design Background", 705 draft-nikander-mobileip-v6-ro-sec-02 (work in progress), 706 December 2003. 708 [I-D.dupont-mipv6-3bombing] 709 Dupont, F., "A note about 3rd party bombing in Mobile 710 IPv6", draft-dupont-mipv6-3bombing-00 (work in progress), 711 February 2004. 713 [Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet 714 Location Management", In Proc. 18th Annual Computer 715 Security Applications Conference, pages 78-87, Las Vegas, 716 NV USA, December 2002. 718 Author's Address 720 Tero Kivinen 721 Safenet, Inc. 722 Fredrikinkatu 47 723 HELSINKI FIN-00100 724 FI 726 EMail: kivinen@safenet-inc.com 728 Intellectual Property Statement 730 The IETF takes no position regarding the validity or scope of any 731 intellectual property or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; neither does it represent that it 735 has made any effort to identify any such rights. Information on the 736 IETF's procedures with respect to rights in standards-track and 737 standards-related documentation can be found in BCP-11. Copies of 738 claims of rights made available for publication and any assurances of 739 licenses to be made available, or the result of an attempt made to 740 obtain a general license or permission for the use of such 741 proprietary rights by implementors or users of this specification can 742 be obtained from the IETF Secretariat. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights which may cover technology that may be required to practice 747 this standard. Please address the information to the IETF Executive 748 Director. 750 Full Copyright Statement 752 Copyright (C) The Internet Society (2004). All Rights Reserved. 754 This document and translations of it may be copied and furnished to 755 others, and derivative works that comment on or otherwise explain it 756 or assist in its implementation may be prepared, copied, published 757 and distributed, in whole or in part, without restriction of any 758 kind, provided that the above copyright notice and this paragraph are 759 included on all such copies and derivative works. However, this 760 document itself may not be modified in any way, such as by removing 761 the copyright notice or references to the Internet Society or other 762 Internet organizations, except as needed for the purpose of 763 developing Internet standards in which case the procedures for 764 copyrights defined in the Internet Standards process must be 765 followed, or as required to translate it into languages other than 766 English. 768 The limited permissions granted above are perpetual and will not be 769 revoked by the Internet Society or its successors or assignees. 771 This document and the information contained herein is provided on an 772 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 773 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 774 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 775 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 776 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 778 Acknowledgment 780 Funding for the RFC Editor function is currently provided by the 781 Internet Society.