idnits 2.17.1 draft-eronen-mobike-mopo-01.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 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 766. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (October 25, 2004) is 7121 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 704, but no explicit reference was found in the text -- 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 (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eronen 3 Internet-Draft Nokia 4 Expires: April 25, 2005 October 25, 2004 6 Mobility Protocol Options for IKEv2 (MOPO-IKE) 7 draft-eronen-mobike-mopo-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 25, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document describes a mobility and multihoming extension to the 43 IKEv2 protocol. The main purpose of this extension is to update the 44 (outer) addresses associated with IKE and IPsec Security 45 Associations. The extension also includes features that assist in 46 selecting which addresses to use, and verify return routability 47 during and after updates. It is also able to work together with NAT 48 Traversal in some scenarios. 50 1. Introduction 52 1.1 Motivation 54 1.1.1 Scenario 1: Mobile client 56 The basic MOBIKE scenario is a mobile device such as a laptop that 57 may have several different network interfaces, and wishes to keep a 58 connection to a VPN gateway working while moving. For instance, a 59 user could start from fixed Ethernet in the office, and then 60 disconnect the laptop and move to office wireless LAN. When leaving 61 the office the laptop could start using GPRS, and switch to a 62 different wireless LAN when the user arrives home. 64 MOBIKE provides a way to notify the VPN gateway of the user's current 65 IP address without requiring a new IKE SA (which may require user 66 interaction for authentication). Since the IP address used inside 67 the tunnel (assigned by the VPN gateway using Configuration Payloads) 68 does not change, transport layer connections are not broken. 70 Mobility detection, policy issues such as which interface should be 71 used, and implementation issues -- such as a possible interface (and 72 division of work) between a "mobility and multihoming control module" 73 and "IKE module" inside a host -- are beyond the scope of MOBIKE. 75 1.1.2 Scenario 2: Mobile client with multihomed gateway 77 The second scenario has again a mobile laptop, but this time the VPN 78 gateway has several network interfaces. 80 MOBIKE provdes a mechanism for the gateway to notify the client of 81 its addresses (obviously, the client needs to know at least one 82 address to contact the VPN gateway in the first place) and changes in 83 their availability. 85 MOBIKE also allows the client to determine which of the gateway's 86 addresses can be used when the client changes its own address. This 87 is required since it cannot be assumed that all of the gateway's 88 interfaces are reachable from all networks the client may connect to. 89 The client may also obtain this information in some other way 90 external to MOBIKE, and policy issues about which address should be 91 actually used are beyond the scope of MOBIKE. 93 1.1.3 Scenario 3: Two multihomed gateways 95 The third scenario has two VPN gateways connecting, for instance, two 96 different sites of a company. Both gateways have several network 97 connections (possible from different ISPs) to provide better 98 availability in case of network failures. 100 Here MOBIKE provides a way to inform the other end of alternative 101 addresses, and switch to some other connection if the currently used 102 path fails. The failures may be detected by either using IKE dead 103 peer detection messages, or some external mechanism beyond the scope 104 of MOBIKE. 106 Note that while it is expected that information about failures may 107 come from various external mechanisms, sending IKE messages is in 108 general the only way to provide a positive confirmation that a path 109 works. 111 1.2 Features 113 This specification includes the following features. Note that some 114 of them may be useful even when the endpoints are not mobile or 115 multi-homed. 117 Continued return routability 119 Before establishing a CHILD_SA, IKEv2 verifies that the peer can 120 receive packets at the address it uses as the source address 121 (except in one corner case involving NAT translation, discussed in 122 Section 4). However, this is done only when the IKE_SA is 123 established, and does not guarantee that the peer stays at that 124 address. In addition, if NAT Traversal is used, the address can 125 be updated due to changes in NAT mappings. 127 This feature adds a payload that can be used in INFORMATIONAL 128 exchanges to verify not only peer liveness ("dead peer 129 detection"), but also the continued ability to receive packets at 130 the given address ("return routability"). 132 Additionally, the "Updating addresses in IKE and IPsec SAs" 133 feature (described below) verifies the return routability of 134 before modifying IPsec SAs. 136 NAT prevention 138 IKEv2/IPsec implementations that do not support NAT Traversal can, 139 in fact, work across some types of one-to-one "basic" NATs (that 140 do not touch transport layer headers) and IPv4/IPv6 translation 141 agents. Some people feel that this is a problem that needs to be 142 fixed, since in some sense any modification of the IP addresses 143 could be considered to be an attack. 145 This feature adds a payload that can be used to verify that the 146 addresses in the IP header have not been modified. 148 UDP encapsulation without NATs 150 There are cases when UDP encapsulation is needed even when no NATs 151 are present. A typical example would be a stateful firewall that 152 performs similar filtering as a NAT, but does not change the IP 153 addresses (and therefore is not detected by NAT_DETECTION 154 payloads). 156 This feature allows using UDP encapsulation without using the 157 other features of NAT Traversal, such as automatic update of peer 158 address. 160 Path testing 162 The path testing features allows parties to find out what action 163 is required when no responses are received; that is, to find a 164 path (combination of addresses) that still works. It also removes 165 the need to configure information about (lack of) routing 166 relationships in the case where not all possible combinations of 167 addresses work. Additionally, the PATH_TEST exchange plays a part 168 in checking return routability before address updates. 170 Updating addresses in IKE and IPsec SAs 172 This feature allows each peer to notify the other peer of the 173 addresses it has, update these in case of change due to e.g. 174 mobility, and update the addresses used in IKE and IPsec SAs. 175 Optionally this also includes updating NAT Traversal related state 176 associated with IPsec SAs (that is, enabling and disabling NAT 177 Traversal as needed). 179 1.3 Features not provided 181 o This extension considers only tunnel mode IPsec Security 182 Associations. It does not modify the traffic selectors in the SPD 183 or inbound IPsec SAs. 185 o This extension does not fully support all possible scenarios 186 involving NATs. Many common cases do work, though. 188 o This extension does not provide any kind of load balancing between 189 different addresses or Security Associations. 191 o This extension does not support the "zero address set" 192 functionality, i.e. temporarily forwarding the traffic of some SA 193 to /dev/null. 195 1.4 Security association viewpoint 197 The main purpose of this extension is to modify state associated with 198 IKE_SA and IPsec SAs that is normally initialized when the SA is 199 created, and not changed afterwards. 201 In particular, this extension considers the following state 202 associated with IKE_SA and outbound IPsec SAs (conceptually speaking; 203 an implementation could store this information in some other way as 204 well): 206 o IKE_SA 208 * local_address (source address for IKE requests) 210 * local_port (source port for IKE requests, either 500 or 4500) 212 * peer_address (destination address for IKE requests) 214 * peer_port (destination port for IKE requests) 216 o outbound IPsec SAs 218 * local_address (tunnel header source address) 220 * peer_address (tunnel header destination address) 222 * peer_port (destination port if UDP encapsulation is used) 224 * udp_encapsulation flag 226 * send_keepalives flag 228 * automatically_update_peer_address flag 230 Note that both IKE_SA and outbound IPsec SAs are considered to have a 231 single pair of (source,destination) addresses at a time. These are 232 the addresses used for IKE requests (including retransmissions of 233 previous requests) and outbound ESP/AH packets. 235 In addition, the IKE_SA contains additional state specific to this 236 extension. This state is used to to store information about 237 addresses that are not currently active (see Section 7 for details). 239 This extension does not modify the SPD or inbound IPsec SAs. 241 1.5 Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [1]. 247 IPsec Security Association (SA) 249 An ESP or AH Security Association. 251 Path 253 A particular combination of source IP address and destination IP 254 address (and possibly ports?). 256 2. Signaling support for this specification 258 Implementations that support this specification MUST include a Vendor 259 ID payload in the IKE_SA_INIT exchange (first two messages). The 260 value for this payload is XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX (TBD). 262 This specification includes several optional features. In 263 particular, implementations are not required to support the following 264 aspects: 266 o Sending NAT_PREVENTION payloads. 268 o NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads. 270 o USE_UDP_ENCAPSULATION payload. 272 3. Continued return routability 274 In IKEv2, an empty INFORMATIONAL exchange does not guarantee return 275 routability, since the peer can generate the response without 276 actually seeing the request. 278 To improve this situation, a sender of an INFORMATIONAL request MUST 279 include a COOKIE2 notification payload in the message. The data 280 associated with this notification MUST be between 8 and 64 octets in 281 length (inclusive), and MUST be chosen in a way that is unpredictable 282 to the recipient. 284 The recipient of an INFORMATIONAL request MUST copy the payload as-is 285 to the response. When processing the response, the original sender 286 MUST verify that the values is the same as sent. If the values do 287 not match, the IKA_SA MUST be closed (TBD details). 289 The Notify Message Type for this message is specified in Section 10. 290 The Protocol ID field is set to one (1), and SPI Size is set to zero. 292 4. NAT prevention 294 IKEv2/IPsec implementations that do not support NAT Traversal can, in 295 fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6 296 translation agents in tunnel mode. Some people feel that this is a 297 problem that needs to be fixed, since in some sense any modification 298 of the IP addresses could be considered to be an attack. 300 This specification addresses the issue as follows. When an IPsec SA 301 is created, the tunnel header IP addresses (and port if doing UDP 302 encapsulation) are taken from the IKE_SA, not the message IP header. 303 NAT_PREVENTION payloads are used to guarantee that NATs have not 304 modified the address used in IKE_SA. However, all response messages 305 are still sent to the address and port the corresponding request came 306 from. 308 The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT 309 request. The data associated with this notification is the SHA-1 310 hash [4] of the following data: the IP address and port from which 311 the packet was sent, and the IP address and port to which the packet 312 was sent. The Notify Message Type for this message is specified in 313 Section 10. The Protocol ID field is set to one (1), and SPI Size is 314 set to zero. 316 The responder MUST compare the NAT_PREVENTION payload with the values 317 from the IP header. If they do not match, the responder replies with 318 "HDR(A,0), N(NAT_PREVENTED)" and does not create any state. 320 If the values do match, the responder initializes (local_address, 321 local_port, peer_address, peer_port) in the to-be-created IKE_SA with 322 values from the IP header. The same applies if neither 323 NAT_PREVENTION nor NAT_DETECTION_* payloads were included, or if the 324 responder does not support NAT Traversal. 326 If the IKE_SA_INIT request included NAT_DETECTION_* payloads but no 327 NAT_PREVENTION payload, the situation is different since the 328 initiator may at this point change from port 500 to 4500. In this 329 case, the responder initializes (local_address, local_port, 330 peer_address, peer_port) from the first IKE_AUTH request, and 331 schedules an INFORMATIONAL exchange to be sent soon after the 332 IKE_AUTH exchanges have been completed. 334 IKEv2 requires that if an IPsec endpoint discovers a NAT between it 335 and its correspondent, it MUST send all subsequent traffic to and 336 from port 4500. To simplify things, implementations that support 337 both this specification and NAT Traversal MUST change to port 4500 if 338 the correspondent also supports both, even if no NAT was detected 339 between them. 341 The initiator initializes its IKE_SA with the values used for sending 342 the first IKE_AUTH request. 344 The use of NAT_PREVENTION payloads with later updates is described in 345 Section 7. 347 5. UDP encapsulation without NATs 349 There are cases when UDP encapsulation is needed even when no NATs 350 are present. A typical example would be a stateful firewall that 351 performs similar filtering as a NAT, but does not change the IP 352 addresses (and therefore is not detected by NAT_DETECTION payloads). 354 This feature allows using UDP encapsulation without using the other 355 features of NAT Traversal, such as automatic update of peer address. 357 To enable this feature, a peer MAY include a USE_UDP_ENCAPSULATION 358 notification payload in a request message that also includes an SA 359 payload requesting a CHILD_SA, or includes a CHANGE_PATH payload. If 360 the recipient supports this feature and its use is allowed by local 361 policy, it includes a USE_UDP_ENCAPSULATION notification payload in 362 the response. 364 The Notify Message Type for this message is specified in Section 10. 365 The Protocol ID field is set to one (1), and SPI Size is set to zero. 366 There is no data associated with this Notify type. 368 6. Path testing 370 Some MOBIKE protocol proposals have (implicitly) assumed that when 371 something occurs, the parties know what is required to correct the 372 situation. This assumption is not necessarily true when the only 373 indication of a problem is a lack of responses to IKE requests. 375 The path testing feature allows parties to find out what action is 376 required when no responses are received; that is, to find a path 377 (combination of addresses) that still works. It also removes the 378 need configure information about (lack of) routing relationships in 379 the case where not all possible combinations of addresses work. 380 Additionally, the PATH_TEST exchange plays a part in checking return 381 routability before address updates. 383 If both parties have several addresses, path testing may require 384 testing all N*M combinations, even when only failures at the "first" 385 hop (local link) are considered. To see why this is the case, 386 consider a case where endpoint A has N links to a global "Internet 387 cloud" and endpoint B has M links. If all but one of A's and B's 388 links are down, finding the one that works requires either local 389 information (something better than lack of responses to IKE 390 requests), or trying N*M combinations. 392 In general, it may also be the case that not addresses have routing 393 between them. For instance, A and B might have IP connections, one 394 from ISP1 (with addresses A1 and B1), and another one from ISP2 (with 395 addresses A2 and B2). In this case, combinations (A1,B2) or (A2,B1) 396 do not necessarily work. Thus, when one of the links goes down, it 397 is necessary that both ends change their addresses simultaneously 398 (changing them one-by-one does not necessarily work). 400 To overcome these limitations, a new IKEv2 exchange type, PATH_TEST, 401 is introduced. This exchange is not part of any IKE_SA, so it cannot 402 be cryptographically protected. It also does not result in the 403 responder keeping any state. 405 Initiator Responder 406 ----------- ----------- 407 HDR(0,0), [NAT_DETECTION_SOURCE_IP, 408 NAT_DETECTION_DESTINATION_IP] --> 410 <-- HDR(0,0), COOKIE, 411 [NAT_DETECTION_SOURCE_IP, 412 NAT_DETECTION_DESTINATION_IP] 414 Performing path testing over several different paths is not required 415 if the node has other information that enables it to select which 416 path should be used. In this case, a single PATH_TEST exchange to 417 retrieve a COOKIE is sufficient. 419 Implementations MAY do path testing even if the currently used path 420 is working to e.g. detect when a better but previously unavailable 421 path becomes available, or to speed up recovery in fault situations. 423 Implementations that perform path testing MUST take steps to avoid 424 causing unnecessary congestion. TBD: add some more details here. 426 7. Updating addresses in IKE and IPsec SAs 428 Finally, we get to the part of this document that actually explains 429 how the IKE and IPsec Security Associations are updated. 431 This extension is based on the idea that same as in ordinary IKEv2, 432 the initiator decides what addresses are used in the IPsec SAs. That 433 is, the responder never updates any IPsec SAs without receiving an 434 explicit CHANGE_PATH request from the initiator. As described below, 435 the responder can however update the IKE_SA in some circumstances. 437 An implementation of this specification maintains some additional 438 information associated with the IKE_SA. This includes the 439 latest_update_received and latest_update_sent counters, a 440 pending_update flag, additional_addresses list, and results of path 441 testing. 443 7.1 In the beginning 445 Both the initiator and responder MAY include one or more 446 ADDITIONAL_ADDRESS notification payloads in the IKE_AUTH exchange (in 447 case of multiple IKE_AUTH exchanges, in the message containing the SA 448 payload). 450 The recipient stores this information, together with 451 peer_address/peer_port from the IKE_SA, to the "additional_addresses" 452 list in the IKE_SA. 454 The Notify Message Type for this message is specified in Section 10. 455 The Protocol ID field is set to one (1), and SPI Size is set to zero. 456 The data associated with this Notify type is either an IPv4 address 457 or an IPv6 address (the type is determined by payload length). 459 7.2 Updates by responder 461 When the responder's set of addresses changes, it proceeds as 462 follows. 464 o If the current path in IKE_SA is no longer valid (e.g. the 465 current local_address is no longer in the set), it uses path 466 testing to select new (local_address, peer_address, peer_port) 467 from (local addresses) X (additional_addresses) 469 o Updates (local_address,peer_address,peer_port) in IKE_SA. 471 o Sets the pending_update to flag. 473 o When window size allows, sends an INFORMATIONAL request containing 474 the following payloads: 476 HDR, SK {N(ADDITIONAL_ADDRESS), [N(ADDITIONAL_ADDRESS), ..., ], 477 N(COOKIE2), [NAT_PREVENTION]} --> 479 and clears the "pending_update" flag. The message includes one 480 ADDITIONAL_ADDRESS for each address the responder has (and is 481 willing to use with this peer), including the one used in IP 482 header. 484 When the initiator receives this, it 486 o If the NAT_PREVENTION payload is present, TBD. 488 o Compares the Message ID with the latest_update_received counter in 489 the IKE_SA. If latest_update_received is greater than this one, a 490 reply is sent but the addresses are not updated. 492 o Updates the latest_update_received counter in the IKE_SA. 494 o Replaces the additional_addresses list in IKE_SA with this list, 495 and if NAT_PREVENTION was not present, also the address from the 496 IP header (TBD). 498 o Replies with "HDR,SK {N(COOKIE2)}". 500 o If current peer_address is NOT contained in additional_addresses, 501 triggers an update to be done (described at the next section). 503 When the responder receives the reply, it 505 o Verifies the COOKIE2 payload as described in Section 3. 507 7.3 Updates by initiator 509 When the initiator wishes to change the path, it does the following: 511 o Uses the PATH_TEST exchange to obtain a COOKIE for the new 512 local_address (if it does not already have one). 514 o Updates IKE_SA with the new (local_address, peer_address, 515 peer_port) information. 517 o Sets pending_update flag. 519 o When the window size allows, sends an INFORMATIONAL request 521 HDR, SK {N(CHANGE_PATH), N(COOKIE), N(COOKIE2), N(ADDITIONAL_ADDRESS),.. 522 [N(NAT_DETECTION_*),] 523 [N(NAT_PREVENTION)]} --> 525 and clears the pending_update flag and sets the latest_update_sent 526 to the Message ID of this message. The message includes one 527 ADDITIONAL_ADDRESS for each address the responder has (and is 528 willing to use with this peer), including the one used in IP 529 header. 531 When the responder receives this message, it 533 o Compares the Message ID with the latest_update_received counter in 534 the IKE_SA. If latest_update_received is greater than this one, 535 replies with "HDR,SK {COOKIE2}", but no other action is taken. 537 o Updates the latest_update_received counter in the IKE_SA. 539 o If the NAT_PREVENTION payload is present, compares it with the 540 information in the IP header. If they do not match, replies with 541 "HDR, SK {COOKIE2,N(NAT_PREVENTED)}". 543 o Compares the COOKIE payload with the source IP address and port in 544 the IP header. If the cookie is not valid, replies with "HDR, SK 545 {COOKIE2, N(NEW_COOKIE_REQUIRED)}". 547 o Checks that using the destination IP address in the IP header is 548 allowed. If this is not the case, replise with "HDR, SK {COOKIE2, 549 N(UNACCEPTABLE_PATH)}". (This case could occur even legally, if 550 the set of addresses has changed but the initiator has not yet 551 received this message. TBD if tere are there other valid causes 552 for this?). 554 o Updates (local_address,peer_address, peer_port) in the IKE_SA and 555 any outbound IPsec SAs with the values from the IP header. 557 o Stores athe additional addresses, together with the 558 peer_address/peer_port from the IKE SA, to the 559 "additional_addresses" list. 561 o If NAT Traversal is supported and NAT detection payloads were 562 included, updates the NAT-related flags in outbound IPsec SAs. 564 o Replies with "HDR,SK {COOKIE2, [NAT_DETECTION_*]}". 566 When the initiator receives the reply, it 568 o Verifies the COOKIE2 payload as described in Section 3. 570 o Compares the Message ID with the latest_update_sent counter in the 571 IKE_SA. If latest_update_sent is greater, stops processing the 572 response. 574 o If the response contains a NAT_PREVENTED payload, TBD (probably we 575 should retry this a couple of times, to make sure that a single 576 packet can't kill us. But if the NAT stays there, and we don't 577 allow it, there's nothing much we can do.) 579 o If the response contains a NEW_COOKIE_REQUIRED payload, removes 580 the cookies for this source address, and starts from the beginning 581 (obtains new cookie with path testing, sets pending_update, and so 582 on). 584 o If the response contains a UNACCEPTABLE_PATH payload, TBD. 586 o Otherwise, updates the outbound IPsec SAs with 587 (local_address,peer_address,peer_port) from the IKE_SA. 589 o If NAT Traversal is supported and NAT detection payloads were 590 included, updates the NAT-related flags in outbound IPsec SAs. 592 The Notify Message Types for CHANGE_PATH, NEW_COOKIE_REQUIRED, and 593 UNACCEPTABLE_PATH are specified in Section 10. The Protocol ID field 594 is set to one (1), and SPI Size is set to zero. There is no data 595 associated with these Notify types. 597 8. Discussion 599 8.1 NAT support 601 This section discusses what cases involving NATs are and are not 602 supported by this specification. The details also depend on exactly 603 what kind of NAT is present; see [9] for discussion about NAT 604 variations. 606 The following cases work: 608 o The responder is single-homed, its address does not change, and it 609 is not behind a NAT. The initiator can be multi-homed, its 610 addresses can change, and it can be behind a NAT (or stateful 611 firewall). 613 o The responder is multi-homed, its addresses do not change, and it 614 is not behind a NAT. The initiator can be multi-homed, its 615 addresses can change, and it can be behind a NAT (or stateful 616 firewall). 618 o The responder is multi-homed, its addresses can change, and it is 619 not behind a NAT. The initiator can be multi-homed, its addresses 620 can change, and it can be behind a "full cone" NAT. 622 The following cases DO NOT work. 624 o The responder's addresses can change, but the initiator is behind 625 a "restricted cone", "port restricted cone", or "symmetric" NAT, 626 or a stateful firewall. (If the responder sends packets from a 627 new address, they will be blocked by the NAT or firewall.) 629 TBD: This section needs more details; in particular, there are 630 probably some tricky details in the second and third cases. 632 8.2 Triggers 634 TBD: describe what kind of situations might lead to a node using the 635 mechanisms specified here. E.g. explicit "use local address X from 636 now on" triggers, and indirect triggers that might lead to e.g. path 637 testing. 639 9. Security considerations 641 The main goal of this specification has been not to reduce any 642 security offered by normal IKEv2. 644 (TO BE WRITTEN: more text is needed here.) 646 If NAT Traversal is not supported, no IPsec (ESP/AH) traffic is sent 647 to an address before it is verified that the peer of the 648 corresponding IKE_SA can actually receive packets at the address. 650 This return routability check is not inherently incompatible with 651 NATs; as explained in Section 4 IKEv2/IPsec can in fact work across 652 some kind of NATs even without NAT Traversal support. In this 653 specification, "NAT prevention", or integrity protection for the 654 addresses in the IP header, is a separate feature. 656 When NAT Traversal is supported, the peer's address may be updated 657 automatically to allow changes in NAT mappings. The "continued 658 return routability" feature, implemented by the COOKIE2 payload, 659 allows verification of the new address after the change. This limits 660 the duration of any "third party bombing" attack by off-path 661 (relative to the victim) attackers. 663 10. IANA considerations 665 This document does not create any new namespaces to be maintained by 666 IANA, but it requires new values in namespaces that have been defined 667 in the IKEv2 base specification [3]. 669 This document defines one new IKEv2 exchange whose value is to be 670 allocated from the "IKEv2 Exchange Types" namespace. 672 Exchange type Value 673 --------------------------- ----- 674 PATH_TEST TBD-BY-IANA (38...239) 676 This document defines eight new IKEv2 notification payloads whose 677 values are to be allocated from the "IKEv2 Notification Payload 678 Types" namespace. 680 Notify message Value 681 --------------------------- ----- 682 ADDITIONAL_ADDRESS TBD-BY-IANA (16396..40959) 683 CHANGE_PATH TBD-BY-IANA (16396..40959) 684 COOKIE2 TBD-BY-IANA (16396..40959) 685 NAT_PREVENTED TBD-BY-IANA (40..8191) 686 NAT_PREVENTION TBD-BY-IANA (16396..40959) 687 NEW_COOKIE_REQUIRED TBD-BY-IANA (40..8191) 688 UNACCEPTABLE_PATH TBD-BY-IANA (40..8191) 689 USE_UDP_ENCAPSULATION TBD-BY-IANA (16396..40959) 691 11. Acknowledgements 693 Everyone in MOBIKE WG, especially Jari Arkko, Francis Dupont, Paul 694 Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also 695 borrows many ideas and even some text from [5], [6], [7], and [8]. 697 12. References 699 12.1 Normative references 701 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 702 Levels", RFC 2119, March 1997. 704 [2] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. 705 Stenberg, "UDP Encapsulation of IPsec Packets", 706 draft-ietf-ipsec-udp-encaps-09 (work in progress), May 2004. 708 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 709 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 711 [4] National Institute of Standards and Technology, "Specifications 712 for the Secure Hash Standard", Federal Information Processing 713 Standard (FIPS) Publication 180-2, August 2002. 715 12.2 Informative references 717 [5] Dupont, F., "Address Management for IKE version 2", 718 draft-dupont-ikev2-addrmgmt-05 (work in progress), June 2004. 720 [6] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming 721 Extensions for IKEv2 (SMOBIKE)", draft-eronen-mobike-simple-00 722 (work in progress), March 2004. 724 [7] Kivinen, T., "MOBIKE protocol", draft-kivinen-mobike-protocol-00 725 (work in progress), February 2004. 727 [8] Kivinen, T., "Design of the MOBIKE protocol", 728 draft-ietf-mobike-design-00 (work in progress), June 2004. 730 [9] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 731 Simple Traversal of User Datagram Protocol (UDP) Through Network 732 Address Translators (NATs)", RFC 3489, March 2003. 734 Author's Address 736 Pasi Eronen 737 Nokia Research Center 738 P.O. Box 407 739 FIN-00045 Nokia Group 740 Finland 742 EMail: pasi.eronen@nokia.com 744 Intellectual Property Statement 746 The IETF takes no position regarding the validity or scope of any 747 Intellectual Property Rights or other rights that might be claimed to 748 pertain to the implementation or use of the technology described in 749 this document or the extent to which any license under such rights 750 might or might not be available; nor does it represent that it has 751 made any independent effort to identify any such rights. Information 752 on the procedures with respect to rights in RFC documents can be 753 found in BCP 78 and BCP 79. 755 Copies of IPR disclosures made to the IETF Secretariat and any 756 assurances of licenses to be made available, or the result of an 757 attempt made to obtain a general license or permission for the use of 758 such proprietary rights by implementers or users of this 759 specification can be obtained from the IETF on-line IPR repository at 760 http://www.ietf.org/ipr. 762 The IETF invites any interested party to bring to its attention any 763 copyrights, patents or patent applications, or other proprietary 764 rights that may cover technology that may be required to implement 765 this standard. Please address the information to the IETF at 766 ietf-ipr@ietf.org. 768 Disclaimer of Validity 770 This document and the information contained herein are provided on an 771 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 772 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 773 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 774 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 775 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 776 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 778 Copyright Statement 780 Copyright (C) The Internet Society (2004). This document is subject 781 to the rights, licenses and restrictions contained in BCP 78, and 782 except as set forth therein, the authors retain all their rights. 784 Acknowledgment 786 Funding for the RFC Editor function is currently provided by the 787 Internet Society.