idnits 2.17.1 draft-eronen-mobike-mopo-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 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 706. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 722), 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 4) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. 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 9, 2004) is 7229 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: '2' is defined on line 644, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 667, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-14 -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-08) exists of draft-dupont-ikev2-addrmgmt-05 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-00 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '9') (Obsoleted by RFC 5389) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Eronen 2 Internet-Draft Nokia 3 Expires: January 7, 2005 July 9, 2004 5 Mobility Protocol Options for IKEv2 (MOPO-IKE) 6 draft-eronen-mobike-mopo-00.txt 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 any 22 time. 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 January 7, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes a mobility and multihoming extension to the 40 IKEv2 protocol. The main purpose of this extension is to update the 41 (outer) addresses associated with IKE and IPsec Security 42 Associations. The extension also includes features that assist in 43 selecting which addresses to use, and verify return routability 44 during and after updates. It is also able to work together with NAT 45 Traversal in some scenarios. 47 1. Introduction 49 1.1 Features 51 This specification includes the following features. Note that some 52 of them may be useful even when the endpoints are not mobile or 53 multi-homed. 55 Continued return routability 57 Before establishing a CHILD_SA, IKEv2 verifies that the peer can 58 receive packets at the address it uses as the source address 59 (except in one corner case involving NAT translation, discussed in 60 Section 4). However, this is done only when the IKE_SA is 61 established, and does not guarantee that the peer stays at that 62 address. In addition, if NAT Traversal is used, the address can 63 be updated due to changes in NAT mappings. 65 This feature adds a payload that can be used in INFORMATIONAL 66 exchanges to verify not only peer liveness ("dead peer 67 detection"), but also the continued ability to receive packets at 68 the given address ("return routability"). 70 Additionally, the "Updating addresses in IKE and IPsec SAs" 71 feature (described below) verifies the return routability of 72 before modifying IPsec SAs. 74 NAT prevention 76 IKEv2/IPsec implementations that do not support NAT Traversal can, 77 in fact, work across some types of one-to-one "basic" NATs and 78 IPv4/IPv6 translation agents in tunnel mode. Some people feel 79 that this is a problem that needs to be fixed, since in some sense 80 any modification of the IP addresses could be considered to be an 81 attack. 83 This feature adds a payload that can be used to verify that the 84 addresses in the IP header have not been modified. 86 UDP encapsulation without NATs 88 There are cases when UDP encapsulation is needed even when no NATs 89 are present. A typical example would be a stateful firewall that 90 performs similar filtering as a NAT, but does not change the IP 91 addresses (and therefore is not detected by NAT_DETECTION 92 payloads). 94 This feature allows using UDP encapsulation without using the 95 other features of NAT Traversal, such as automatic update of peer 96 address. 98 Path testing 100 Some MOBIKE protocol proposals have (implicitly) assumed that when 101 something occurs, the parties know what is required to correct the 102 situation. This assumption is not necessarily true when the only 103 indication of a problem is a lack of responses to IKE requests. 105 The path testing features allows parties to find out what action 106 is required when no responses are received; that is, to find a 107 path (combination of addresses) that still works. It also removes 108 the need to configure information about (lack of) routing 109 relationships in the case where not all possible combinations of 110 addresses work. Additionally, the PATH_TEST exchange plays a part 111 in checking return routability before address updates. 113 Updating addresses in IKE and IPsec SAs 115 This feature allows each peer to notify the other peer of the 116 addresses it has, update these in case of change due to e.g. 117 mobility, and update the addresses used in IKE and IPsec SAs. 118 Optionally this also includes updating NAT Traversal related state 119 associated with IPsec SAs (that is, enabling and disabling NAT 120 Traversal as needed). 122 1.2 Features not provided 124 o This extension considers only tunnel mode IPsec Security 125 Associations. It does not modify the traffic selectors in the SPD 126 or inbound IPsec SAs. 128 o This extension does not fully support all possible scenarios 129 involving NATs. Many common cases do work, though. 131 o This extension does not provide any kind of load balancing between 132 different addresses or Security Associations. 134 o This extension does not support the "zero address set" 135 functionality, i.e. temporarily forwarding the traffic of some SA 136 to /dev/null. 138 1.3 Security association viewpoint 140 The main purpose of this extension is to modify state associated with 141 IKE_SA and IPsec SAs that is normally initialized when the SA is 142 created, and not changed afterwards. 144 In particular, this extension considers the following state 145 associated with IKE_SA and outbound IPsec SAs (conceptually speaking; 146 an implementation could store this information in some other way as 147 well): 149 o IKE_SA 151 * local_address (source address for IKE requests) 153 * local_port (source port for IKE requests, either 500 or 4500) 155 * peer_address (destination address for IKE requests) 157 * peer_port (destination port for IKE requests) 159 o outbound IPsec SAs 161 * local_address (tunnel header source address) 163 * peer_address (tunnel header destination address) 165 * peer_port (destination port if UDP encapsulation is used) 167 * udp_encapsulation flag 169 * send_keepalives flag 171 * automatically_update_peer_address flag 173 Note that both IKE_SA and outbound IPsec SAs are considered to have a 174 single pair of (source,destination) addresses at a time. These are 175 the addresses used for IKE requests (including retransmissions of 176 previous requests) and outbound ESP/AH packets. 178 In addition, the IKE_SA contains additional state specific to this 179 extension. This state is used to to store information about 180 addresses that are not currently active (see Section 7 for details). 182 This extension does not modify the SPD or inbound IPsec SAs. 184 1.4 Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [1]. 190 IPsec Security Association (SA) 192 An ESP or AH Security Association. 194 Path 196 A particular combination of source IP address and destination IP 197 address (and possibly ports?). 199 2. Signaling support for this specification 201 Implementations that support this specification MUST include a Vendor 202 ID payload in the IKE_SA_INIT exchange (first two messages). The 203 value for this payload is XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX (TBD). 205 This specification includes several optional features. In 206 particular, implementations are not required to support the following 207 aspects: 209 o Sending NAT_PREVENTION payloads. 211 o NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads. 213 o USE_UDP_ENCAPSULATION payload. 215 3. Continued return routability 217 In IKEv2, an empty INFORMATIONAL exchange does not guarantee return 218 routability, since the peer can generate the response without 219 actually seeing the request. 221 To improve this situation, a sender of an INFORMATIONAL request MUST 222 include a COOKIE2 notification payload in the message. The data 223 associated with this notification MUST be between 8 and 64 octets in 224 length (inclusive), and MUST be chosen in a way that is unpredictable 225 to the recipient. 227 The recipient of an INFORMATIONAL request MUST copy the payload as-is 228 to the response. When processing the response, the original sender 229 MUST verify that the values is the same as sent. If the values do 230 not match, the IKA_SA MUST be closed (TBD details). 232 The Notify Message Type for this message is specified in Section 10. 233 The Protocol ID field is set to one (1), and SPI Size is set to zero. 235 4. NAT prevention 237 IKEv2/IPsec implementations that do not support NAT Traversal can, in 238 fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6 239 translation agents in tunnel mode. Some people feel that this is a 240 problem that needs to be fixed, since in some sense any modification 241 of the IP addresses could be considered to be an attack. 243 This specification addresses the issue as follows. When an IPsec SA 244 is created, the tunnel header IP addresses (and port if doing UDP 245 encapsulation) are taken from the IKE_SA, not the message IP header. 246 NAT_PREVENTION payloads are used to guarantee that NATs have not 247 modified the address used in IKE_SA. However, all response messages 248 are still sent to the address and port the corresponding request came 249 from. 251 The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT 252 request. The data associated with this notification is the SHA-1 253 hash [4] of the following data: the IP address and port from which 254 the packet was sent, and the IP address and port to which the packet 255 was sent. The Notify Message Type for this message is specified in 256 Section 10. The Protocol ID field is set to one (1), and SPI Size is 257 set to zero. 259 The responder MUST compare the NAT_PREVENTION payload with the values 260 from the IP header. If they do not match, the responder replies with 261 "HDR(A,0), N(NAT_PREVENTED)" and does not create any state. 263 If the values do match, the responder initializes (local_address, 264 local_port, peer_address, peer_port) in the to-be-created IKE_SA with 265 values from the IP header. The same applies if neither 266 NAT_PREVENTION nor NAT_DETECTION_* payloads were included, or if the 267 responder does not support NAT Traversal. 269 If the IKE_SA_INIT request included NAT_DETECTION_* payloads but no 270 NAT_PREVENTION payload, the situation is different since the 271 initiator may at this point change from port 500 to 4500. In this 272 case, the responder initializes (local_address, local_port, 273 peer_address, peer_port) from the first IKE_AUTH request, and 274 schedules an INFORMATIONAL exchange to be sent soon after the 275 IKE_AUTH exchanges have been completed. 277 IKEv2 requires that if an IPsec endpoint discovers a NAT between it 278 and its correspondent, it MUST send all subsequent traffic to and 279 from port 4500. To simplify things, implementations that support 280 both this specification and NAT Traversal MUST change to port 4500 if 281 the correspondent also supports both, even if no NAT was detected 282 between them. 284 The initiator initializes its IKE_SA with the values used for sending 285 the first IKE_AUTH request. 287 The use of NAT_PREVENTION payloads with later updates is described in 288 Section 7. 290 5. UDP encapsulation without NATs 292 There are cases when UDP encapsulation is needed even when no NATs 293 are present. A typical example would be a stateful firewall that 294 performs similar filtering as a NAT, but does not change the IP 295 addresses (and therefore is not detected by NAT_DETECTION payloads). 297 This feature allows using UDP encapsulation without using the other 298 features of NAT Traversal, such as automatic update of peer address. 300 To enable this feature, a peer MAY include a USE_UDP_ENCAPSULATION 301 notification payload in a request message that also includes an SA 302 payload requesting a CHILD_SA, or includes a CHANGE_PATH payload. If 303 the recipient supports this feature and its use is allowed by local 304 policy, it includes a USE_UDP_ENCAPSULATION notification payload in 305 the response. 307 The Notify Message Type for this message is specified in Section 10. 308 The Protocol ID field is set to one (1), and SPI Size is set to zero. 309 There is no data associated with this Notify type. 311 6. Path testing 313 Some MOBIKE protocol proposals have (implicitly) assumed that when 314 something occurs, the parties know what is required to correct the 315 situation. This assumption is not necessarily true when the only 316 indication of a problem is a lack of responses to IKE requests. 318 The path testing feature allows parties to find out what action is 319 required when no responses are received; that is, to find a path 320 (combination of addresses) that still works. It also removes the 321 need configure information about (lack of) routing relationships in 322 the case where not all possible combinations of addresses work. 323 Additionally, the PATH_TEST exchange plays a part in checking return 324 routability before address updates. 326 If both parties have several addresses, path testing may require 327 testing all N*M combinations, even when only failures at the "first" 328 hop (local link) are considered. To see why this is the case, 329 consider a case where endpoint A has N links to a global "Internet 330 cloud" and endpoint B has M links. If all but one of A's and B's 331 links are down, finding the one that works requires either local 332 information (something better than lack of responses to IKE 333 requests), or trying N*M combinations. 335 In general, it may also be the case that not addresses have routing 336 between them. For instance, A and B might have IP connections, one 337 from ISP1 (with addresses A1 and B1), and another one from ISP2 (with 338 addresses A2 and B2). In this case, combinations (A1,B2) or (A2,B1) 339 do not necessarily work. Thus, when one of the links goes down, it 340 is necessary that both ends change their addresses simultaneously 341 (changing them one-by-one does not necessarily work). 343 To overcome these limitations, a new IKEv2 exchange type, PATH_TEST, 344 is introduced. This exchange is not part of any IKE_SA, so it cannot 345 be cryptographically protected. It also does not result in the 346 responder keeping any state. 348 Initiator Responder 349 ----------- ----------- 350 HDR(0,0), [NAT_DETECTION_SOURCE_IP, 351 NAT_DETECTION_DESTINATION_IP] --> 353 <-- HDR(0,0), COOKIE, 354 [NAT_DETECTION_SOURCE_IP, 355 NAT_DETECTION_DESTINATION_IP] 357 Performing path testing over several different paths is not required 358 if the node has other information that enables it to select which 359 path should be used. In this case, a single PATH_TEST exchange to 360 retrieve a COOKIE is sufficient. 362 Implementations MAY do path testing even if the currently used path 363 is working to e.g. detect when a better but previously unavailable 364 path becomes available, or to speed up recovery in fault situations. 366 Implementations that perform path testing MUST take steps to avoid 367 causing unnecessary congestion. TBD: add some more details here. 369 7. Updating addresses in IKE and IPsec SAs 371 Finally, we get to the part of this document that actually explains 372 how the IKE and IPsec Security Associations are updated. 374 This extension is based on the idea that same as in ordinary IKEv2, 375 the initiator decides what addresses are used in the IPsec SAs. That 376 is, the responder never updates any IPsec SAs without receiving an 377 explicit CHANGE_PATH request from the initiator. As described below, 378 the responder can however update the IKE_SA in some circumstances. 380 An implementation of this specification maintains some additional 381 information associated with the IKE_SA. This includes the 382 latest_update_received and latest_update_sent counters, a 383 pending_update flag, additional_addresses list, and results of path 384 testing. 386 7.1 In the beginning 388 Both the initiator and responder MAY include one or more 389 ADDITIONAL_ADDRESS notification payloads in the IKE_AUTH exchange (in 390 case of multiple IKE_AUTH exchanges, in the message containing the SA 391 payload). 393 The recipient stores this information, together with peer_address/ 394 peer_port from the IKE_SA, to the "additional_addresses" list in the 395 IKE_SA. 397 The Notify Message Type for this message is specified in Section 10. 398 The Protocol ID field is set to one (1), and SPI Size is set to zero. 399 The data associated with this Notify type is either an IPv4 address 400 or an IPv6 address (the type is determined by payload length). 402 7.2 Updates by responder 404 When the responder's set of addresses changes, it proceeds as 405 follows. 407 o If the current path in IKE_SA is no longer valid (e.g. the 408 current local_address is no longer in the set), it uses path 409 testing to select new (local_address, peer_address, peer_port) 410 from (local addresses) X (additional_addresses) 412 o Updates (local_address,peer_address,peer_port) in IKE_SA. 414 o Sets the pending_update to flag. 416 o When window size allows, sends an INFORMATIONAL request containing 417 the following payloads: 419 HDR, SK {N(ADDITIONAL_ADDRESS), [N(ADDITIONAL_ADDRESS), ..., ], 420 N(COOKIE2), [NAT_PREVENTION]} --> 422 and clears the "pending_update" flag. The message includes one 423 ADDITIONAL_ADDRESS for each address the responder has (and is 424 willing to use with this peer), including the one used in IP 425 header. 427 When the initiator receives this, it 428 o If the NAT_PREVENTION payload is present, TBD. 430 o Compares the Message ID with the latest_update_received counter in 431 the IKE_SA. If latest_update_received is greater than this one, a 432 reply is sent but the addresses are not updated. 434 o Updates the latest_update_received counter in the IKE_SA. 436 o Replaces the additional_addresses list in IKE_SA with this list, 437 and if NAT_PREVENTION was not present, also the address from the 438 IP header (TBD). 440 o Replies with "HDR,SK {N(COOKIE2)}". 442 o If current peer_address is NOT contained in additional_addresses, 443 triggers an update to be done (described at the next section). 445 When the responder receives the reply, it 447 o Verifies the COOKIE2 payload as described in Section 3. 449 7.3 Updates by initiator 451 When the initiator wishes to change the path, it does the following: 453 o Uses the PATH_TEST exchange to obtain a COOKIE for the new 454 local_address (if it does not already have one). 456 o Updates IKE_SA with the new (local_address, peer_address, 457 peer_port) information. 459 o Sets pending_update flag. 461 o When the window size allows, sends an INFORMATIONAL request 463 HDR, SK {N(CHANGE_PATH), N(COOKIE), N(COOKIE2), N(ADDITIONAL_ADDRESS),.. 464 [N(NAT_DETECTION_*),] 465 [N(NAT_PREVENTION)]} --> 467 and clears the pending_update flag and sets the latest_update_sent 468 to the Message ID of this message. The message includes one 469 ADDITIONAL_ADDRESS for each address the responder has (and is 470 willing to use with this peer), including the one used in IP 471 header. 473 When the responder receives this message, it 474 o Compares the Message ID with the latest_update_received counter in 475 the IKE_SA. If latest_update_received is greater than this one, 476 replies with "HDR,SK {COOKIE2}", but no other action is taken. 478 o Updates the latest_update_received counter in the IKE_SA. 480 o If the NAT_PREVENTION payload is present, compares it with the 481 information in the IP header. If they do not match, replies with 482 "HDR, SK {COOKIE2,N(NAT_PREVENTED)}". 484 o Compares the COOKIE payload with the source IP address and port in 485 the IP header. If the cookie is not valid, replies with "HDR, SK 486 {COOKIE2, N(NEW_COOKIE_REQUIRED)}". 488 o Checks that using the destination IP address in the IP header is 489 allowed. If this is not the case, replise with "HDR, SK {COOKIE2, 490 N(UNACCEPTABLE_PATH)}". (This case could occur even legally, if 491 the set of addresses has changed but the initiator has not yet 492 received this message. TBD if tere are there other valid causes 493 for this?). 495 o Updates (local_address,peer_address, peer_port) in the IKE_SA and 496 any outbound IPsec SAs with the values from the IP header. 498 o Stores athe additional addresses, together with the peer_address/ 499 peer_port from the IKE SA, to the "additional_addresses" list. 501 o If NAT Traversal is supported and NAT detection payloads were 502 included, updates the NAT-related flags in outbound IPsec SAs. 504 o Replies with "HDR,SK {COOKIE2, [NAT_DETECTION_*]}". 506 When the initiator receives the reply, it 508 o Verifies the COOKIE2 payload as described in Section 3. 510 o Compares the Message ID with the latest_update_sent counter in the 511 IKE_SA. If latest_update_sent is greater, stops processing the 512 response. 514 o If the response contains a NAT_PREVENTED payload, TBD (probably we 515 should retry this a couple of times, to make sure that a single 516 packet can't kill us. But if the NAT stays there, and we don't 517 allow it, there's nothing much we can do.) 519 o If the response contains a NEW_COOKIE_REQUIRED payload, removes 520 the cookies for this source address, and starts from the beginning 521 (obtains new cookie with path testing, sets pending_update, and so 522 on). 524 o If the response contains a UNACCEPTABLE_PATH payload, TBD. 526 o Otherwise, updates the outbound IPsec SAs with 527 (local_address,peer_address,peer_port) from the IKE_SA. 529 o If NAT Traversal is supported and NAT detection payloads were 530 included, updates the NAT-related flags in outbound IPsec SAs. 532 The Notify Message Types for CHANGE_PATH, NEW_COOKIE_REQUIRED, and 533 UNACCEPTABLE_PATH are specified in Section 10. The Protocol ID field 534 is set to one (1), and SPI Size is set to zero. There is no data 535 associated with these Notify types. 537 8. Discussion 539 8.1 NAT support 541 This section discusses what cases involving NATs are and are not 542 supported by this specification. The details also depend on exactly 543 what kind of NAT is present; see [9] for discussion about NAT 544 variations. 546 The following cases work: 548 o The responder is single-homed, its address does not change, and it 549 is not behind a NAT. The initiator can be multi-homed, its 550 addresses can change, and it can be behind a NAT (or stateful 551 firewall). 553 o The responder is multi-homed, its addresses do not change, and it 554 is not behind a NAT. The initiator can be multi-homed, its 555 addresses can change, and it can be behind a NAT (or stateful 556 firewall). 558 o The responder is multi-homed, its addresses can change, and it is 559 not behind a NAT. The initiator can be multi-homed, its addresses 560 can change, and it can be behind a "full cone" NAT. 562 The following cases DO NOT work. 564 o The responder's addresses can change, but the initiator is behind 565 a "restricted cone", "port restricted cone", or "symmetric" NAT, 566 or a stateful firewall. (If the responder sends packets from a 567 new address, they will be blocked by the NAT or firewall.) 569 TBD: This section needs more details; in particular, there are 570 probably some tricky details in the second and third cases. 572 8.2 Triggers 574 TBD: describe what kind of situations might lead to a node using the 575 mechanisms specified here. E.g. explicit "use local address X from 576 now on" triggers, and indirect triggers that might lead to e.g. path 577 testing. 579 9. Security considerations 581 The main goal of this specification has been not to reduce any 582 security offered by normal IKEv2. 584 (TO BE WRITTEN: more text is needed here.) 586 If NAT Traversal is not supported, no IPsec (ESP/AH) traffic is sent 587 to an address before it is verified that the peer of the 588 corresponding IKE_SA can actually receive packets at the address. 590 This return routability check is not inherently incompatible with 591 NATs; as explained in Section 4 IKEv2/IPsec can in fact work across 592 some kind of NATs even without NAT Traversal support. In this 593 specification, "NAT prevention", or integrity protection for the 594 addresses in the IP header, is a separate feature. 596 When NAT Traversal is supported, the peer's address may be updated 597 automatically to allow changes in NAT mappings. The "continued 598 return routability" feature, implemented by the COOKIE2 payload, 599 allows verification of the new address after the change. This limits 600 the duration of any "third party bombing" attack by off-path 601 (relative to the victim) attackers. 603 10. IANA considerations 605 This document does not create any new namespaces to be maintained by 606 IANA, but it requires new values in namespaces that have been defined 607 in the IKEv2 base specification [3]. 609 This document defines one new IKEv2 exchange whose value is to be 610 allocated from the "IKEv2 Exchange Types" namespace. 612 Exchange type Value 613 --------------------------- ----- 614 PATH_TEST TBD-BY-IANA (38...239) 616 This document defines eight new IKEv2 notification payloads whose 617 values are to be allocated from the "IKEv2 Notification Payload 618 Types" namespace. 620 Notify message Value 621 --------------------------- ----- 622 ADDITIONAL_ADDRESS TBD-BY-IANA (16396..40959) 623 CHANGE_PATH TBD-BY-IANA (16396..40959) 624 COOKIE2 TBD-BY-IANA (16396..40959) 625 NAT_PREVENTED TBD-BY-IANA (40..8191) 626 NAT_PREVENTION TBD-BY-IANA (16396..40959) 627 NEW_COOKIE_REQUIRED TBD-BY-IANA (40..8191) 628 UNACCEPTABLE_PATH TBD-BY-IANA (40..8191) 629 USE_UDP_ENCAPSULATION TBD-BY-IANA (16396..40959) 631 11. Acknowledgements 633 Everyone in MOBIKE WG, especially Jari Arkko, Francis Dupont, Paul 634 Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also 635 borrows many ideas and even some text from [5], [6] and [7]. 637 12. References 639 12.1 Normative references 641 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 642 Levels", RFC 2119, March 1997. 644 [2] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. 645 Stenberg, "UDP Encapsulation of IPsec Packets", 646 draft-ietf-ipsec-udp-encaps-09 (work in progress), May 2004. 648 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 649 draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. 651 [4] National Institute of Standards and Technology, "Specifications 652 for the Secure Hash Standard", Federal Information Processing 653 Standard (FIPS) Publication 180-2, August 2002. 655 12.2 Informative references 657 [5] Dupont, F., "Address Management for IKE version 2", 658 draft-dupont-ikev2-addrmgmt-05 (work in progress), June 2004. 660 [6] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming 661 Extensions for IKEv2 (SMOBIKE)", draft-eronen-mobike-simple-00 662 (work in progress), March 2004. 664 [7] Kivinen, T., "MOBIKE protocol", draft-kivinen-mobike-protocol-00 665 (work in progress), February 2004. 667 [8] Kivinen, T., "Design of the MOBIKE protocol", 668 draft-ietf-mobike-design-00 (work in progress), June 2004. 670 [9] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 671 Simple Traversal of User Datagram Protocol (UDP) Through Network 672 Address Translators (NATs)", RFC 3489, March 2003. 674 Author's Address 676 Pasi Eronen 677 Nokia Research Center 678 P.O. Box 407 679 FIN-00045 Nokia Group 680 Finland 682 EMail: pasi.eronen@nokia.com 684 Intellectual Property Statement 686 The IETF takes no position regarding the validity or scope of any 687 Intellectual Property Rights or other rights that might be claimed to 688 pertain to the implementation or use of the technology described in 689 this document or the extent to which any license under such rights 690 might or might not be available; nor does it represent that it has 691 made any independent effort to identify any such rights. Information 692 on the procedures with respect to rights in RFC documents can be 693 found in BCP 78 and BCP 79. 695 Copies of IPR disclosures made to the IETF Secretariat and any 696 assurances of licenses to be made available, or the result of an 697 attempt made to obtain a general license or permission for the use of 698 such proprietary rights by implementers or users of this 699 specification can be obtained from the IETF on-line IPR repository at 700 http://www.ietf.org/ipr. 702 The IETF invites any interested party to bring to its attention any 703 copyrights, patents or patent applications, or other proprietary 704 rights that may cover technology that may be required to implement 705 this standard. Please address the information to the IETF at 706 ietf-ipr@ietf.org. 708 Disclaimer of Validity 710 This document and the information contained herein are provided on an 711 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 712 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 713 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 714 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 715 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 718 Copyright Statement 720 Copyright (C) The Internet Society (2004). This document is subject 721 to the rights, licenses and restrictions contained in BCP 78, and 722 except as set forth therein, the authors retain all their rights. 724 Acknowledgment 726 Funding for the RFC Editor function is currently provided by the 727 Internet Society.