idnits 2.17.1 draft-ietf-shim6-failure-detection-09.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1538. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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, 2007) is 6134 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) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-05 == Outdated reference: A later version (-04) exists of draft-ietf-shim6-locator-pair-selection-01 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-08 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-02 -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Standards Track I. van Beijnum 5 Expires: January 10, 2008 July 9, 2007 7 Failure Detection and Locator Pair Exploration Protocol for IPv6 8 Multihoming 9 draft-ietf-shim6-failure-detection-09 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 January 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies how the level 3 multihoming shim protocol 43 (SHIM6) detects failures between two communicating hosts. It also 44 specifies an exploration protocol for switching to another pair of 45 interfaces and/or addresses between the same hosts if a failure 46 occurs and an operational pair can be found. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Requirements language . . . . . . . . . . . . . . . . . . . . 5 52 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1. Available Addresses . . . . . . . . . . . . . . . . . . 6 54 3.2. Locally Operational Addresses . . . . . . . . . . . . . 7 55 3.3. Operational Address Pairs . . . . . . . . . . . . . . . 7 56 3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 9 57 3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 9 58 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 59 4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 10 60 4.2. Full Reachability Exploration . . . . . . . . . . . . . 12 61 4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 13 62 5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 15 63 5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 15 64 5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 16 65 5.3. Keepalive Timeout Option Format . . . . . . . . . . . . 21 66 6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 22 67 6.1. Incoming payload packet . . . . . . . . . . . . . . . . 22 68 6.2. Outgoing payload packet . . . . . . . . . . . . . . . . 23 69 6.3. Keepalive timeout . . . . . . . . . . . . . . . . . . . 23 70 6.4. Send timeout . . . . . . . . . . . . . . . . . . . . . . 24 71 6.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 24 72 6.6. Reception of the Keepalive message . . . . . . . . . . . 24 73 6.7. Reception of the Probe message State=Exploring . . . . . 25 74 6.8. Reception of the Probe message State=InboundOk . . . . . 25 75 6.9. Reception of the Probe message State=Operational . . . . 25 76 6.10. Graphical Representation of the State Machine . . . . . 26 77 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 27 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 82 10.2. Informative References . . . . . . . . . . . . . . . . . 31 83 Appendix A. Example Protocol Runs . . . . . . . . . . . . . . . . 33 84 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38 85 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 87 Intellectual Property and Copyright Statements . . . . . . . . . . 41 89 1. Introduction 91 The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support 92 multihoming. It is an IP layer mechanism that hides multihoming from 93 applications. A part of the SHIM6 solution involves detecting when a 94 currently used pair of addresses (or interfaces) between two 95 communication hosts has failed, and picking another pair when this 96 occurs. We call the former failure detection, and the latter locator 97 pair exploration. 99 This document specifies the mechanisms and protocol messages to 100 achieve both failure detection and locator pair exploration. This 101 part of the SHIM6 protocol is called the REAchability Protocol 102 (REAP). 104 The document is structured as follows: Section 3 defines a set of 105 useful terms, Section 4 gives an overview of REAP, and Section 5 106 specifies the message formats and behaviour in detail. Section 8 107 discusses the security considerations of REAP. 109 In this specification, we consider an address to be synonymous with a 110 locator. Other parts of the SHIM6 protocol ensure that the different 111 locators used by a node actually belong together. That is, REAP is 112 not responsible for ensuring that it ends up with a legitimate 113 locator. 115 2. Requirements language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Definitions 123 This section defines terms useful for discussing failure detection 124 and locator pair exploration. 126 3.1. Available Addresses 128 SHIM6 nodes need to be aware of what addresses they themselves have. 129 If a node loses the address it is currently using for communications, 130 another address must replace this address. And if a node loses an 131 address that the node's peer knows about, the peer must be informed. 132 Similarly, when a node acquires a new address it may generally wish 133 the peer to know about it. 135 Definition. Available address. An address is said to be available 136 if the following conditions are fulfilled: 138 o The address has been assigned to an interface of the node. 140 o The address is valid in the sense of RFC 2461 [RFC2461]. 142 o The address is not tentative in the sense of RFC 2462 [RFC2462]. 143 In other words, the address assignment is complete so that 144 communications can be started. 146 Note that this explicitly allows an address to be optimistic in 147 the sense of Optimistic DAD [RFC4429] even though implementations 148 may prefer using other addresses as long as there is an 149 alternative. 151 o The address is a global unicast or unique local address [RFC4193]. 152 That is, it is not an IPv6 site-local or link-local address. 154 With link-local addresses, the nodes would be unable to determine 155 on which link the given address is usable. 157 o The address and interface is acceptable for use according to a 158 local policy. 160 Available addresses are discovered and monitored through mechanisms 161 outside the scope of SHIM6. SHIM6 implementations MUST be able to 162 employ information provided by IPv6 Neighbor Discovery [RFC2461], 163 Address Autoconfiguration [RFC2462], and DHCP [RFC3315] (when DHCP is 164 implemented). This information includes the availability of a new 165 address and status changes of existing addresses (such as when an 166 address becomes invalid). 168 3.2. Locally Operational Addresses 170 Two different granularity levels are needed for failure detection. 171 The coarser granularity is for individual addresses: 173 Definition. Locally Operational Address. An available address is 174 said to be locally operational when its use is known to be possible 175 locally: the interface is up, a default router (if needed) suitable 176 for this address is known to be reachable, and no other local 177 information points to the address being unusable. 179 Locally operational addresses are discovered and monitored through 180 mechanisms outside the SHIM6 protocol. SHIM6 implementations MUST be 181 able to employ information provided from Neighbor Unreachability 182 Detection [RFC2461]. Implementations MAY also employ additional, 183 link layer specific mechanisms. 185 Note 1: A part of the problem in ensuring that an address is 186 operational is making sure that after a change in link layer 187 connectivity we are still connected to the same IP subnet. 188 Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6 189 [I-D.ietf-dna-protocol] can be used to ensure this. 191 Note 2: In theory, it would also be possible for hosts to learn 192 about routing failures for a particular selected source prefix, if 193 only suitable protocols for this purpose existed. Some proposals 194 in this space have been made, see, for instance 195 [I-D.bagnulo-shim6-addr-selection] and 196 [I-D.huitema-multi6-addr-selection], but none have been 197 standardized to date. 199 3.3. Operational Address Pairs 201 The existence of locally operational addresses are not, however, a 202 guarantee that communications can be established with the peer. A 203 failure in the routing infrastructure can prevent packets from 204 reaching their destination. For this reason we need the definition 205 of a second level of granularity, for pairs of addresses: 207 Definition. Bidirectionally operational address pair. A pair of 208 locally operational addresses are said to be an operational address 209 pair when bidirectional connectivity can be shown between the 210 addresses. That is, a packet sent with one of the addresses in the 211 source field and the other in the destination field reaches the 212 destination, and vice versa. 214 Unfortunately, there are scenarios where bidirectionally operational 215 address pairs do not exist. For instance, ingress filtering or 216 network failures may result in one address pair being operational in 217 one direction while another one is operational from the other 218 direction. The following definition captures this general situation: 220 Definition. Unidirectionally operational address pair. A pair of 221 locally operational addresses are said to be an unidirectionally 222 operational address pair when packets sent with the first address as 223 the source and the second address as the destination can be shown to 224 reach the destination. 226 SHIM6 implementations MUST support the discovery of operational 227 address pairs through the use of explicit rechability tests and 228 Forced Bidirectional Communication (FBD), described later in this 229 specification. In addition, implementations MAY employ the following 230 additional mechanisms: 232 o Positive feedback from upper layer protocols. For instance, TCP 233 can indicate to the IP layer that it is making progress. This is 234 similar to how IPv6 Neighbor Unreachability Detection can in some 235 cases be avoided when upper layers provide information about 236 bidirectional connectivity [RFC2461]. 238 In the case of unidirectional connectivity, the upper layer 239 protocol responses come back using another address pair, but show 240 that the messages sent using the first address pair have been 241 received. 243 o Negative feedback from upper layer protocols. It is conceivable 244 that upper layer protocols give an indication of a problem to the 245 multihoming layer. For instance, TCP could indicate that there's 246 either congestion or lack of connectivity in the path because it 247 is not getting ACKs. 249 o ICMP error messages. Given the ease of spoofing ICMP messages, 250 one should be careful to not trust these blindly, however. Our 251 suggestion is to use ICMP error messages only as a hint to perform 252 an explicit reachability test or move an address pair to a lower 253 place in the list of address pairs to be probed, but not as a 254 reason to disrupt ongoing communications without other indications 255 of problems. The situation may be different when certain 256 verifications of the ICMP messages are being performed, as 257 explained by Gont in [I-D.ietf-tcpm-icmp-attacks]. These 258 verifications can ensure that (practically) only on-path attackers 259 can spoof the messages. 261 3.4. Primary Address Pair 263 The primary address pair consists of the addresses that upper layer 264 protocols use in their interaction with the SHIM6 layer. Use of the 265 primary address pair means that the communication is compatible with 266 regular non-SHIM6 communication and no context ID needs to be 267 present. 269 3.5. Current Address Pair 271 SHIM6 needs to avoid sending packets which belong to the same 272 transport connection concurrently over multiple paths. This is 273 because congestion control in commonly used transport protocols is 274 based upon a notion of a single path. While routing can introduce 275 path changes as well and transport protocols have means to deal with 276 this, frequent changes will cause problems. Efficient congestion 277 control over multiple paths is a considered research at the time this 278 specification is written. 280 For these reasons it is necessary to choose a particular pair of 281 addresses as the current address pair which is used until problems 282 occur, at least for the same session. 284 It is theoretically possible to support multiple current address 285 pairs for different transport sessions or SHIM6 contexts. 286 However, this is not supported in this version of the SHIM6 287 protocol. 289 A current address pair need not be operational at all times. If 290 there is no traffic to send, we may not know if the primary address 291 pair is operational. Nevertheless, it makes sense to assume that the 292 address pair that worked in some time ago continues to be operational 293 for new communications as well. 295 4. Protocol Overview 297 This section discusses the design of the reachability detection and 298 full reachability exploration mechanisms, and gives on overview of 299 the REAP protocol. 301 Exploring the full set of communication options between two hosts 302 that both have two or more addresses is an expensive operation as the 303 number of combinations to be explored increases very quickly with the 304 number of addresses. For instance, with two addresses on both sides, 305 there are four possible address pairs. Since we can't assume that 306 reachability in one direction automatically means reachability for 307 the complement pair in the other direction, the total number of two- 308 way combinations is eight. (Combinations = nA * nB * 2.) 310 An important observation in multihoming is that failures are 311 relatively infrequent, so that an operational pair that worked a few 312 seconds ago is very likely to be still operational. So it makes 313 sense to have a light-weight protocol that confirms existing 314 reachability, and only invoke heavier exploration when a there is a 315 suspected failure. 317 4.1. Failure Detection 319 Failure detection consists of three parts: tracking local 320 information, tracking remote peer status, and finally verifying 321 reachability. Tracking local information consists of using, for 322 instance, reachability information about the local router as an 323 input. Nodes SHOULD employ techniques listed in Section 3.1 and 324 Section 3.2 to be track the local situation. It is also necessary to 325 track remote address information from the peer. For instance, if the 326 peer's currently used address is no longer in use, mechanism to relay 327 that information is needed. The Update Request message in the SHIM6 328 protocol is used for this purpose [I-D.ietf-shim6-proto]. Finally, 329 when the local and remote information indicates that communication 330 should be possible and there are upper layer packets to be sent, 331 reachability verification is necessary to ensure that the peers 332 actually have an operational pair. 334 A technique called Forced Bidirectional Detection (FBD, originally 335 defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect]) 336 is employed for the reachability verification. Reachability for the 337 currently used address pair in a SHIM6 context is determined by 338 making sure that whenever there is data traffic in one direction, 339 there is also traffic in the other direction. This can be data 340 traffic as well, but also transport layer acknowledgments or a REAP 341 reachability keepalive if there is no other traffic. This way, it is 342 no longer possible to have traffic in only one direction, so whenever 343 there is data traffic going out, but there are no return packets, 344 there must be a failure, so the full exploration mechanism is 345 started. 347 A more detailed description of the current pair reachability 348 evaluation mechanism: 350 1. To avoid the other side from concluding there is a reachability 351 failure, it's necessary for a host implementing the failure 352 detection mechanism to generate periodic keepalives when there is 353 no other traffic. 355 FBD works by generating REAP keepalives if the node is receiving 356 packets from its peer but not sending any of its own. The 357 keepalives are sent at certain intervals so that the other side 358 knows there is a reachability problem when it doesn't receive any 359 incoming packets for its Send Timeout period. The host 360 communicates its Send Timeout value to the peer as an Keepalive 361 Timeout Option (section 5.3) in the I2, I2bis, R2, or UPDATE 362 messages. The peer then maps this value to its Keepalive Timeout 363 value. 365 The interval after which keepalives are sent is named Keepalive 366 Interval. This document doesn't specify a value for Keepalive 367 Interval, but recognizes that an often used approach is sending 368 keepalives at one-half to one-third of the Keepalive Timeout 369 interval, so that multiple keepalives are generated and have time 370 to reach the correspondent before it times out. An upper bound 371 on this interval would be (Keepalive Timeout - 2) seconds, so 372 that one keepalive has time to reach the other side, assuming a 373 maximum one-way delay of 2 seconds. 375 2. Whenever outgoing data packets are generated, a timer is started 376 to reflect the requirement that the peer should generate return 377 traffic from data packets. The timeout value is set to the value 378 of Send Timeout. 380 For the purposes of this specification, "data packet" refers to 381 any packet that is part of a SHIM6 context, including both upper 382 layer protocol packets and SHIM6 protocol messages except those 383 defined in this specification. 385 3. Whenever incoming data packets are received, the timer associated 386 with the return traffic from the peer is stopped, and another 387 timer is started to reflect the requirement for this node to 388 generate return traffic. This timeout value is set to the value 389 of Keepalive Timeout. 391 These two timers are mutually exclusive. In other words, either 392 the node is expecting to see traffic from the peer based the 393 traffic that the node sent earlier or the node is expecting to 394 respond to the peer based on the traffic that the peer sent 395 earlier (or the node is in an idle state). 397 4. The reception of a REAP keepalive packet leads to stopping the 398 timer associated with the return traffic from the peer. 400 5. Keepalive Interval seconds after the last data packet has been 401 received for a context, and if no other packet has been sent 402 within this context since the data packet has been received, a 403 REAP keepalive packet is generated for the context in question 404 and transmitted to the correspondent. A host may send the 405 keepalive sooner than Keepalive Interval seconds if 406 implementation considerations warrant this, but should take care 407 to to avoid sending keepalives at an excessive rate. REAP 408 keepalive packets SHOULD continue to be sent at the Keepalive 409 Interval until either a data packet in the SHIM6 context has been 410 received from the peer or the Keepalive Timeout expires. 411 Keepalives are not sent at all when a data packet was sent since 412 the last received data packet. 414 6. Send Timeout seconds after the transmission of a data packet with 415 no return traffic on this context, a full reachability 416 exploration is started. 418 Section 7 provides some suggested defaults for these timeout values. 419 Experience from the deployment of the SHIM6 protocol is needed in 420 order to determine what values are most suitable. The setting of 421 these values is also related to various parameters in transport 422 protocols, such as TCP keepalive interval. 424 4.2. Full Reachability Exploration 426 As explained in previous section, the currently used address pair may 427 become invalid either through one of the addresses being becoming 428 unavailable or inoperational, or the pair itself being declared 429 inoperational. An exploration process attempts to find another 430 operational pair so that communications can resume. 432 What makes this process hard is the requirement to support 433 unidirectionally operational address pairs. It is insufficient to 434 probe address pairs by a simple request - response protocol. 435 Instead, the party that first detects the problem starts a process 436 where it tries each of the different address pairs in turn by sending 437 a message to its peer. These messages carry information about the 438 state of connectivity between the peers, such as whether the sender 439 has seen any traffic from the peer recently. When the peer receives 440 a message that indicates a problem, it assists the process by 441 starting its own parallel exploration to the other direction, again 442 sending information about the recently received payload traffic or 443 signaling messages. 445 Specifically, when A decides that it needs to explore for an 446 alternative address pair to B, it will initiate a set of Probe 447 messages, in sequence, until it gets an Probe message from B 448 indicating that (a) B has received one of A's messages and, 449 obviously, (b) that B's Probe message gets back to A. B uses the same 450 algorithm, but starts the process from the reception of the first 451 Probe message from A. 453 Upon changing to a new address pair, the network path traversed most 454 likely has changed, so that the ULP SHOULD be informed. This can be 455 a signal for the ULP to adapt due to the change in path so that, for 456 example, TCP could initiate a slow start procedure, although it's 457 likely that the circumstances that led to the selection of a new path 458 already caused enough packet loss to trigger slow start. 460 Similarly, one can also envision that applications would be able to 461 tell the IP or transport layer that the current connection in 462 unsatisfactory and an exploration for a better one would be 463 desirable. This would require an inter-layer communication mechanism 464 to be developed, however. In any case, this is another issue that we 465 treat as being outside the scope of pure address exploration. 467 REAP is designed to support failure recovery even in the case of 468 having only unidirectionally operational address pairs. However, due 469 to security concerns discussed in Section 8, the exploration process 470 can typically be run only for a session that has already been 471 established. Specifically, while REAP would in theory be capable of 472 exploration even during connection establishment, its use within the 473 SHIM6 protocol does not allow this. 475 4.3. Exploration Order 477 The exploration process assumes an ability to choose address pairs 478 for testing, in some sequence. This process may result in a 479 combinatorial explosion when there are many addresses on both sides, 480 but a back-off procedure is employed to avoid a "signaling storm". 482 Nodes first consult the RFC 3484 default address selection rules 483 [RFC3484] Section 4 rules to determine what combinations of addresses 484 are allowed from a local point of view, as this reduces the search 485 space. RFC 3484 also provides a priority ordering among different 486 address pairs, making the search possibly faster. (Additional 487 mechanisms may be defined in the future for arriving at an initial 488 ordering of address pairs before testing starts 489 [I-D.ietf-shim6-locator-pair-selection].) Nodes may also use local 490 information, such as known quality of service parameters or interface 491 types to determine what addresses are preferred over others, and try 492 pairs containing such addresses first. The SHIM6 protocol also 493 carries preference information in its messages. 495 Discussion note: The preferences may either be learned dynamically 496 or be configured. It is believed, however, that dynamic learning 497 based purely on the multihoming protocol is too hard and not the 498 task this layer should do. Solutions where multiple protocols 499 share their information in a common pool of locators could provide 500 this information from transport protocols, however. 502 Out of the set of possible candidate address pairs, nodes SHOULD 503 attempt to test through all of them until an operational pair is 504 found, and retrying the process as is necessary. However, all nodes 505 MUST perform this process sequentially and with exponential back-off. 506 This sequential process is necessary in order to avoid a "signaling 507 storm" when an outage occurs (particularly for a complete site). 508 However, it also limits the number of addresses that can in practice 509 be used for multihoming, considering that transport and application 510 layer protocols will fail if the switch to a new address pair takes 511 too long. 513 Section 7 suggests default values for the timers associated with the 514 exploration process. The value Initial Probe Timeout (0.5 seconds) 515 specifies the interval between initial attempts to send probes; 516 Number of Initial Probes (4) specifies how many initial probes can be 517 sent before the exponential backoff procedure needs to be employed. 518 This process increases the time between every probe if there is no 519 response. Typically, each increase doubles the time but this 520 specification does not mandate a particular increase. 522 Finally, Max Probe Timeout (60 seconds) specifies a limit beyond 523 which the probe interval may not grow. If the exploration process 524 reaches this interval, it will continue sending at this rate until a 525 suitable response is triggered or the SHIM6 context is garbage 526 collected, because upper layer protocols using the SHIM6 context in 527 question are no longer attempting to send packets. Reaching the Max 528 Probe Timeout may also serve as a hint to the garbage collection 529 process that the context is no longer usable. 531 5. Protocol Definition 533 5.1. Keepalive Message 535 The format of the keepalive message is as follows: 537 0 1 2 3 538 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Next Header | Hdr Ext Len |0| Type = 66 | Reserved1 |0| 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Checksum |R| | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 544 | Receiver Context Tag | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Reserved2 | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 + Options + 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Next Header, Hdr Ext Len, 0, 0, Checksum 555 These are as specified in Section 5.3 of the SHIM6 protocol 556 description [I-D.ietf-shim6-proto]. 558 Type 560 This field identifies the Keepalive message and MUST be set to 66 561 (Keepalive). 563 Reserved1 565 This is a 7-bit field reserved for future use. It is set to zero 566 on transmit, and MUST be ignored on receipt. 568 R 570 This is a 1-bit field reserved for future use. It is set to zero 571 on transmit, and MUST be ignored on receipt. 573 Receiver Context Tag 575 This is a 47-bit field for the Context Tag the receiver has 576 allocated for the context. 578 Reserved2 580 This is a 32-bit field reserved for future use. It is set to zero 581 on transmit, and MUST be ignored on receipt. 583 Options 585 This MAY contain one or more SHIM6 options.The inclusion of the 586 latter options is not necessary, however, as there are currently 587 no defined options that are useful in a Keepalive message. These 588 options are provided only for future extensibility reasons. 590 A valid message conforms to the format above, has a Receiver Context 591 Tag that matches to context known by the receiver, is valid shim 592 control message as defined in Section 12.2 of the SHIM6 protocol 593 description [I-D.ietf-shim6-proto], and its shim context state is 594 ESTABLISHED. The receiver processes a valid message by inspecting 595 its options, and executing any actions specified for such options. 597 Discussion: It may appear prudent to include additional fields 598 that would provide at least a basic level of security, but since 599 data packets also indicate ongoing reachability, just as 600 keepalives, and those packets don't have such fields, there is 601 little or no reason to include them in a keepalive. 603 The processing rules for this message are the given in more detail in 604 Section 6. 606 5.2. Probe Message 608 This message performs REAP exploration. Its format is as follows: 610 0 1 2 3 611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0| 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Checksum |R| | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 617 | Receiver Context Tag | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Precvd| Psent |Sta| Reserved2 | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | | 622 + First probe sent + 623 | | 624 + Source address + 625 | | 626 + + 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | | 630 + First probe sent + 631 | | 632 + Destination address + 633 | | 634 + + 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | First probe nonce | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | First probe data | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 / / 642 / Nth probe sent / 643 | | 644 + Source address + 645 | | 646 + + 647 | | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 + Nth probe sent + 651 | | 652 + Destination address + 653 | | 654 + + 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Nth probe nonce | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Nth probe data | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | | 662 + First probe received + 663 | | 664 + Source address + 665 | | 666 + + 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 + First probe received + 671 | | 672 + Destination address + 673 | | 674 + + 675 | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | First probe nonce | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | First probe data | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 + Nth probe received + 683 | | 684 + Source address + 685 | | 686 + + 687 | | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 + Nth probe received + 691 | | 692 + Destination address + 693 | | 694 + + 695 | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Nth probe nonce | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Nth probe data | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | | 702 + Options + 703 | | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | | 706 + Options + 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Next Header, Hdr Ext Len, 0, 0, Checksum 712 These are as specified in Section 5.3 of the SHIM6 protocol 713 description [I-D.ietf-shim6-proto]. 715 Type 717 This field identifies the Probe message and MUST be set to 67 718 (Probe). 720 Reserved 722 This is a 7-bit field reserved for future use. It is set to zero 723 on transmit, and MUST be ignored on receipt. 725 R 727 This is a 1-bit field reserved for future use. It is set to zero 728 on transmit, and MUST be ignored on receipt. 730 Receiver Context Tag 732 This is a 47-bit field for the Context Tag the receiver has 733 allocated for the context. 735 Psent 737 This is a 4-bit field that indicates the number of sent probes 738 included in this probe message. The first set of probe fields 739 pertains to the current message and MUST be present, so the 740 minimum value for this field is 1. Additional sent probe fields 741 are copies of the same fields sent in (recent) earlier probes and 742 may be included or omitted as per any logic employed by the 743 implementation. 745 Precvd 747 This is a 4-bit field that indicates the number of received probes 748 included in this probe messsage. Received probe fields are copies 749 of the same fields received in (recent) earlier probes and may be 750 included or omitted as per any logic employed by the 751 implementation. 753 The fields probe source, probe destination, probe nonce and probe 754 data may be repeated, depending on the value of Psent and 755 Preceived. 757 Sta (State) 759 This 2-bit State field is used to inform the peer about the state 760 of the sender. It has three legal values: 762 0 (Operational) implies that the sender both (a) believes it has 763 no problem communicating and (b) believes that the recipient also 764 has no problem communicating. 766 1 (Exploring) implies that the sender has a problem communicating 767 with the recipient, e.g., it has not seen any traffic from the 768 recipient even when it expected some. 770 2 (InboundOk) implies that the sender believes it has no problem 771 communicating, i.e., it at least sees packets from the recipient, 772 but that the recipient either has a problem or has not yet 773 confirmed to the sender that the problem has been solved. 775 Reserved2 777 MUST be set to 0 upon transmission and MUST be ignored upon 778 reception. 780 Probe source 782 This 128-bit field contains the source IPv6 address used to send 783 the probe. 785 Probe destination 787 This 128-bit field contains the destination IPv6 address used to 788 send the probe. 790 Probe nonce 792 This is a 32-bit field that is initialized by the sender with a 793 value that allows it to determine which sent probes a received 794 probe correlates with. It is highly recommeded that the nonce 795 field is at least moderately hard to guess so that even on-path 796 attackers can't deduce the next nonce value that will be used. 797 This value SHOULD be generated using a random number generator 798 that is known to have good randomness properties as outlined in 799 RFC 4086 [RFC4086]. 801 Probe data 803 This is a 32-bit field with no fixed meaning. The probe data 804 field is copied back with no changes. Future flags may define a 805 use for this field. 807 Discussion: One potential use of this field relates to 808 communicating delays between reception of a probe and 809 transmission of a reply to it. 811 Options 813 For future extensions. 815 5.3. Keepalive Timeout Option Format 817 Either side of a SHIM6 context can notify the peer of the value that 818 it would prefer the peer to use as its Keepalive Timeout value. If 819 the host is using a non-default Send Timeout value, it SHOULD 820 communicate this value as a Keepalive Timeout value to the peer in 821 the below option. This option MAY be sent in the I2, I2bis, R2, or 822 UPDATE messages. The option SHOULD only need to be sent once in a 823 given shim6 association. If a host receives this option it SHOULD 824 update its Keepalive Timeout value for the correspondent. 826 0 1 2 3 827 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type = 10 |0| Length = 4 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 + Reserved | Keepalive Timeout | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Fields: 836 Type 838 This field identifies the option and MUST be set to 10 (Keepalive 839 Timeout). 841 Length 843 This field MUST be set as specified in Section 5.14 of the SHIM6 844 protocol description [I-D.ietf-shim6-proto]. That is, it is set 845 to 4. 847 Reserved 849 16-bit field reserved for future use. Set to zero upon transmit 850 and MUST be ignored upon receipt. 852 Keepalive Timeout 854 Value in seconds corresponding to suggested Keepalive Timeout 855 value for the peer. 857 6. Behaviour 859 The required behaviour of REAP nodes is specified below in the form 860 of a state machine. The externally observable behaviour of an 861 implementation MUST conform to this state machine, but there is no 862 requirement that the implementation actually employs a state machine. 863 Intermixed with the following description we also provide a state 864 machine description in a tabular form. That form is only 865 informational, however. 867 On a given context with a given peer, the node can be in one of three 868 states: Operational, Exploring, or InboundOK. In the Operational 869 state the underlying address pairs are assumed to be operational. In 870 the Exploring state this node has observed a problem and has 871 currently not seen any traffic from the peer. Finally, in the 872 InboundOK state this node sees traffic from the peer, but peer may 873 not yet see any traffic from this node so that the exploration 874 process needs to continue. 876 The node maintains also the Send timer (Send Timeout seconds) and 877 Keepalive timer (Keepalive Timeout seconds). The Send timer reflects 878 the requirement that when this node sends a payload packet there 879 should be some return traffic (either payload packets or Keepalive 880 messages) within Send Timeout seconds. The Keepalive timer reflects 881 the requirement that when this node receives a payload packet there 882 should a similar response towards the peer. The Keepalive timer is 883 only used within the Operational state, and the Send timer in the 884 Operational and InboundOK states. No timer is running in the 885 Exploring state. As explained in Section 4.1, the two timers are 886 mutually exclusive. That is, either the Keepalive timer is running 887 or the Send timer is running (or no timer is running). 889 Note that Appendix A gives some examples of typical protocol runs to 890 illustrate the behaviour. 892 6.1. Incoming payload packet 894 Upon the reception of a payload packet in the Operational state, the 895 node starts the Keepalive timer if it is not yet running, and stops 896 the Send timer if it was running. 898 If the node is in the Exploring state it transitions to the InboundOK 899 state, sends a Probe message, and starts the Send timer. It fills 900 the Psent and corresponding Probe source address, Probe destination 901 address, Probe nonce, and Probe data fields with information about 902 recent Probe messages that have not yet been reported as seen by the 903 peer. It also fills the Precvd and corresponding Probe source 904 address, Probe destination address, Probe nonce, and Probe data 905 fields with information about recent Probe messages it has seen from 906 the peer. When sending a Probe message, the State field MUST be set 907 to a value that matches the conceptual state of the sender after 908 sending the Probe. In this case the node therefore sets the Sta 909 field to 2 (InboundOk). The IP source and and destination addresses 910 for sending the Probe message are selected as discussed in 911 Section 4.3. 913 In the InboundOK state the node stops the Send timer if it was 914 running, but does not do anything else. 916 The reception of SHIM6 control messages other than the Keepalive and 917 Probe messages are treated similarly with payload packets. 919 While the Keepalive timer is running, the node SHOULD send Keepalive 920 messages to the peer with an interval of Keepalive Interval seconds. 921 Conceptually, a separate timer is used to distinguish between the 922 interval between Keepalive messages and the overall Keepalive Timeout 923 interval. However, this separate timer is not modelled in the 924 tabular or graphical state machines. When sent, the Keepalive 925 message is constructed as described in Section 5.1. It is sent using 926 the current address pair. 928 Operational Exploring InboundOk 929 ------------------------------------------------------------- 930 STOP Send; SEND Probe InboundOk; STOP Send 931 START Keepalive START Send; 932 GOTO InboundOk 934 6.2. Outgoing payload packet 936 Upon sending a payload packet in the Operational state, the node 937 stops the Keepalive timer if it was running and starts the Send timer 938 if it was not running. In the Exploring state there is no effect, 939 and in the InboundOK state the node simply starts the Send timer if 940 it was not yet running. (The sending of SHIM6 control messages is 941 again treated similarly here.) 943 Operational Exploring InboundOk 944 ----------------------------------------------------------- 945 START Send; - START Send 946 STOP Keepalive 948 6.3. Keepalive timeout 950 Upon a timeout on the Keepalive timer, the node sends one last 951 Keepalive message. This can only happen in the Operational state. 953 The Keepalive message is constructed as described in Section 5.1. It 954 is sent using the current address pair. 956 Operational Exploring InboundOk 957 ----------------------------------------------------------- 958 SEND Keepalive - - 960 6.4. Send timeout 962 Upon a timeout on the Send timer, the node enters the Exploring state 963 and sends a Probe message. The Probe message is constructed as 964 explained in Section 6.1, except that the Sta field is set to 1 965 (Exploring). 967 Operational Exploring InboundOk 968 ----------------------------------------------------------- 969 SEND Probe Exploring; - SEND Probe Exploring; 970 GOTO Exploring GOTO Exploring 972 6.5. Retransmission 974 While in the Exploring state the node keeps retransmitting its Probe 975 messages to different (or same) addresses as defined in Section 4.3. 976 A similar process is employed in the InboundOk state, except that 977 upon such retransmission the Send timer is started if it was not 978 running already. 980 The Probe messages are constructed as explained in Section 6.1, 981 except that the Sta field is set to 1 (Exploring) or 2 (InboundOk), 982 depending on which state the sender is in. 984 Operational Exploring InboundOk 985 ---------------------------------------------------------- 986 - SEND Probe Exploring SEND Probe InboundOk 987 START Send 989 6.6. Reception of the Keepalive message 991 Upon the reception of a Keepalive message in the Operational state, 992 the node stops the Send timer, if it was running. If the node is in 993 the Exploring state it transitions to the InboundOK state, sends a 994 Probe message, and starts the Send timer. The Probe message is 995 constructed as explained in Section 6.1. 997 In the InboundOK state the Send timer is stopped, if it was running. 999 Operational Exploring InboundOk 1000 ----------------------------------------------------------- 1001 STOP Send SEND Probe InboundOk; STOP Send 1002 START Send; 1003 GOTO InboundOk 1005 6.7. Reception of the Probe message State=Exploring 1007 Upon receiving a Probe with State set to Exploring, the node enters 1008 the InboundOK state, sends a Probe as described in Section 6.1, stops 1009 the Keepalive timer if it was running, and restarts the Send timer. 1011 Operational Exploring InboundOk 1012 ----------------------------------------------------------- 1013 SEND Probe InboundOk; SEND Probe InboundOk; SEND Probe 1014 STOP Keepalive; START Send; InboundOk; 1015 RESTART Send; GOTO InboundOk RESTART Send 1016 GOTO InboundOk 1018 6.8. Reception of the Probe message State=InboundOk 1020 Upon the reception of a Probe message with State set to InboundOk, 1021 the node sends a Probe message, restarts the Send timer, stops the 1022 Keepalive timer if it was running, and transitions to the Operational 1023 state. New current address pair is chosen for the connection, based 1024 on the reports of received probes in the message that we just 1025 received. If no received probes have been reported, the current 1026 address pair is unchanged. 1028 The Probe message is constructed as explained in Section 6.1, except 1029 that the Sta field is set to 0 (Operational). 1031 Operational Exploring InboundOk 1032 ------------------------------------------------------------- 1033 SEND Probe Operational; SEND Probe Operational; SEND Probe 1034 RESTART Send; RESTART Send; Operational; 1035 STOP Keepalive GOTO Operational RESTART Send; 1036 GOTO Operational 1038 6.9. Reception of the Probe message State=Operational 1040 Upon the reception of a Probe message with State set to Operational, 1041 the node stops the Send timer if it was running, starts the Keepalive 1042 timer if it was not yet running, and transitions to the Operational 1043 state. The Probe message is constructed as explained in Section 6.1, 1044 except that the Sta field is set to 0 (Operational). 1046 Note: This terminates the exploration process when both parties 1047 are happy and know that their peer is happy as well. 1049 Operational Exploring InboundOk 1050 ----------------------------------------------------------- 1051 STOP Send STOP Send; STOP Send; 1052 START Keepalive START Keepalive START Keepalive 1053 GOTO Operational GOTO Operational 1055 The reachability detection and exploration process has no effect on 1056 payload communications until a new operational address pairs have 1057 actually been confirmed. Prior to that the payload packets continue 1058 to be sent to the previously used addresses. 1060 6.10. Graphical Representation of the State Machine 1062 In the PDF version of this specification, an informational drawing 1063 illustrates the state machine. Where the text and the drawing 1064 differ, the text takes precedence. 1066 7. Protocol Constants 1068 The following protocol constants are defined: 1070 Send Timeout 10 seconds 1071 Keepalive Interval Not specified here 1072 Initial Probe Timeout 0.5 seconds 1073 Number of Initial Probes 4 probes 1074 Max Probe Timeout 60 seconds 1076 Alternate values of the Send Timeout may be selected by a host and 1077 communicated to the peer in the Keepalive Timeout Option. 1079 8. Security Considerations 1081 Attackers may spoof various indications from lower layers and the 1082 network in an effort to confuse the peers about which addresses are 1083 or are not operational. For example, attackers may spoof ICMP error 1084 messages in an effort to cause the parties to move their traffic 1085 elsewhere or even to disconnect. Attackers may also spoof 1086 information related to network attachments, router discovery, and 1087 address assignments in an effort to make the parties believe they 1088 have Internet connectivity when in reality they do not. 1090 This may cause use of non-preferred addresses or even denial-of- 1091 service. 1093 This protocol does not provide any protection of its own for 1094 indications from other parts of the protocol stack. Unprotected 1095 indications SHOULD NOT be taken as a proof of connectivity problems. 1096 However, REAP has weak resistance against incorrect information even 1097 from unprotected indications in the sense that it performs its own 1098 tests prior to picking a new address pair. Denial-of- service 1099 vulnerabilities remain, however, as do vulnerabilities against on 1100 path attackers. 1102 Some aspects of these vulnerabilities can be mitigated through the 1103 use of techniques specific to the other parts of the stack, such as 1104 properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link 1105 layer security, or the use of SEND [RFC3971] to protect IPv6 Router 1106 and Neighbor Discovery. 1108 Other parts of the SHIM6 protocol ensure that the set of addresses we 1109 are switching between actually belong together. REAP itself provides 1110 no such assurances. Similarly, REAP provides some protection against 1111 third party flooding attacks [AURA02]; when REAP is run its Probe 1112 nonces can be used as a return routability check that the claimed 1113 address is indeed willing to receive traffic. However, this needs to 1114 be complemented with another mechanism to ensure that the claimed 1115 address is also the correct host. SHIM6 does this by performing 1116 binding of all operations to context tags. 1118 The keepalive mechanism in this specification is vulnerable to 1119 spoofing. On path-attackers that can see a SHIM6 context tag can 1120 send spoofed Keepalive messages once per Send Timeout interval, to 1121 prevent two SHIM6 nodes from sending Keepalives themselves. This 1122 vulnerability is only relevant to nodes involved in a one-way 1123 communication. The result of the attack is that the nodes enter the 1124 exploration phase needlessly, but they should be able to confirm 1125 connectivity unless, of course, the attacker is able to prevent the 1126 exploration phase from completing. Off-path attackers may not be 1127 able to generate spoofed results, given that the context tags are 47- 1128 bit random numbers. 1130 The exploration phase is vulnerable to attackers that are on the 1131 path. Off-path attackers would find it hard to guess either the 1132 context tag or the correct probe identifiers. Given that IPsec 1133 operates above the shim layer, it is not possible to protect the 1134 exploration phase against on-path attackers. This is similar to the 1135 ability to protect other Shim6 control exchanges. There are 1136 mechanisms in place to prevent the redirection of communications to 1137 wrong addresses, but on-path attackers can cause denial-of-service, 1138 move communications to less-preferred address pairs, and so on. 1140 Finally, the exploration itself can cause a number of packets to be 1141 sent. As a result it may be used as a tool for packet amplification 1142 in flooding attacks. In order to prevent this it is required that 1143 the protocol employing REAP has built-in mechanisms to prevent this. 1144 For instance, in SHIM6 contexts are created only after a relatively 1145 large number of packets has been exchanged, a cost which reduces the 1146 attractiveness of using SHIM6 and REAP for amplification attacks. 1147 However, such protections are typically not present at connection 1148 establishment time. When exploration would be needed for connection 1149 establishment to succeed, its usage would result in an amplification 1150 vulnerability. As a result, SHIM6 does not support the use of REAP 1151 in connection establishment stage. 1153 9. IANA Considerations 1155 No IANA actions are required. 1157 10. References 1159 10.1. Normative References 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", BCP 14, RFC 2119, March 1997. 1164 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1165 Discovery for IP Version 6 (IPv6)", RFC 2461, 1166 December 1998. 1168 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1169 Autoconfiguration", RFC 2462, December 1998. 1171 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1172 and M. Carney, "Dynamic Host Configuration Protocol for 1173 IPv6 (DHCPv6)", RFC 3315, July 2003. 1175 [RFC3484] Draves, R., "Default Address Selection for Internet 1176 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1178 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1179 Requirements for Security", BCP 106, RFC 4086, June 2005. 1181 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1182 Addresses", RFC 4193, October 2005. 1184 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1185 for IPv6", RFC 4429, April 2006. 1187 10.2. Informative References 1189 [AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1190 Location Management", In Proceedings of the 18th Annual 1191 Computer Security Applications Conference, Las Vegas, 1192 Nevada, USA., December 2002. 1194 [I-D.bagnulo-shim6-addr-selection] 1195 Bagnulo, M., "Address selection in multihomed 1196 environments", draft-bagnulo-shim6-addr-selection-00 (work 1197 in progress), October 2005. 1199 [I-D.huitema-multi6-addr-selection] 1200 Huitema, C., "Address selection in multihomed 1201 environments", draft-huitema-multi6-addr-selection-00 1202 (work in progress), October 2004. 1204 [I-D.ietf-dna-cpl] 1205 Nordmark, E. and J. Choi, "DNA with unmodified routers: 1206 Prefix list based approach", draft-ietf-dna-cpl-02 (work 1207 in progress), January 2006. 1209 [I-D.ietf-dna-protocol] 1210 Kempf, J., "Detecting Network Attachment in IPv6 Networks 1211 (DNAv6)", draft-ietf-dna-protocol-05 (work in progress), 1212 March 2007. 1214 [I-D.ietf-hip-mm] 1215 Henderson, T., "End-Host Mobility and Multihoming with the 1216 Host Identity Protocol", draft-ietf-hip-mm-05 (work in 1217 progress), March 2007. 1219 [I-D.ietf-shim6-locator-pair-selection] 1220 Bagnulo, M., "Default Locator-pair selection algorithm for 1221 the SHIM6 protocol", 1222 draft-ietf-shim6-locator-pair-selection-01 (work in 1223 progress), October 2006. 1225 [I-D.ietf-shim6-proto] 1226 Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming 1227 Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work 1228 in progress), April 2007. 1230 [I-D.ietf-shim6-reach-detect] 1231 Beijnum, I., "Shim6 Reachability Detection", 1232 draft-ietf-shim6-reach-detect-01 (work in progress), 1233 October 2005. 1235 [I-D.ietf-tcpm-icmp-attacks] 1236 Gont, F., "ICMP attacks against TCP", 1237 draft-ietf-tcpm-icmp-attacks-02 (work in progress), 1238 May 2007. 1240 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1241 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1242 Zhang, L., and V. Paxson, "Stream Control Transmission 1243 Protocol", RFC 2960, October 2000. 1245 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1246 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1248 Appendix A. Example Protocol Runs 1250 This appendix has examples of REAP protocol runs in typical 1251 scenarios. We start with the simplest scenario of two hosts, A and 1252 B, that have a SHIM6 connection with each other but are not currently 1253 sending any data. As neither side sends anything, they also do not 1254 expect anything back, so there are no messages at all: 1256 EXAMPLE 1: No communications 1258 Peer A Peer B 1259 | | 1260 | | 1261 | | 1262 | | 1263 | | 1264 | | 1265 | | 1266 | | 1268 Our second example involves an active connection with bidirectional 1269 payload packet flows. Here the reception of data from the peer is 1270 taken as an indication of reachability, so again there are no extra 1271 packes: 1273 EXAMPLE 2: Bidirectional communications 1275 Peer A Peer B 1276 | | 1277 | payload packet | 1278 |-------------------------------------------->| 1279 | | 1280 | payload packet | 1281 |<--------------------------------------------| 1282 | | 1283 | payload packet | 1284 |-------------------------------------------->| 1285 | | 1286 | | 1288 The third example is the first one that involves an actual REAP 1289 message. Here the hosts communicate in just one direction, so REAP 1290 messages are needed to indicate to the peer that sends payload 1291 packets that its packets are getting through: 1293 EXAMPLE 3: Unidirectional communications 1295 Peer A Peer B 1296 | | 1297 | payload packet | 1298 |-------------------------------------------->| 1299 | | 1300 | payload packet | 1301 |-------------------------------------------->| 1302 | | 1303 | payload packet | 1304 |-------------------------------------------->| 1305 | | 1306 | Keepalive id=p | 1307 |<--------------------------------------------| 1308 | | 1309 | payload packet | 1310 |-------------------------------------------->| 1311 | | 1312 | | 1314 The next example involves a failure scenario. Here A has addresses A 1315 and B has addresses B1 and B2. The currently used address pairs are 1316 (A, B1) and (B1, A). All connections via B1 become broken, which 1317 leads to an exploration process: 1319 EXAMPLE 4: Failure scenario 1321 Peer A Peer B 1322 | | 1323 State: | State: 1324 Operational | Operational 1325 | (A,B1) payload packet | 1326 |-------------------------------------------->| 1327 | | 1328 | (B1,A) payload packet | 1329 |<--------------------------------------------| At time T1 1330 | | path A<->B1 1331 | (A,B1) payload packet | becomes 1332 |----------------------------------------/ | broken 1333 | | 1334 | ( B1,A) payload packet | 1335 | /-----------------------------------------| 1336 | | 1337 | (A,B1) payload packet | 1338 |----------------------------------------/ | 1339 | | 1340 | (B1,A) payload packet | 1341 | /-----------------------------------------| 1342 | | 1343 | (A,B1) payload packet | 1344 |----------------------------------------/ | 1345 | | 1346 | | Send Timeout 1347 | | seconds after 1348 | | T1, B happens to 1349 | | see the problem 1350 | (B1,A) Probe id=p, | first and sends a 1351 | state=exploring | complaint that 1352 | /-----------------------------------------| it is not rec- 1353 | | eiving anything 1354 | | State: 1355 | | Exploring 1356 | | 1357 | (B2,A) Probe id=q, | 1358 | state=exploring | But its lost, 1359 |<--------------------------------------------| retransmission 1360 | | uses another pair 1361 A realizes | 1362 that it needs | 1363 to start the | 1364 exploration. It | 1365 picks B2 as the | 1366 most likely candidate, | 1367 as it appeared in the | 1368 Probe | 1369 State: InboundOk | 1370 | | 1371 | (A, B2) Probe id=r, | 1372 | state=inboundok, | 1373 | received probe q | This one gets 1374 |-------------------------------------------->| through. 1375 | | State: 1376 | | Operational 1377 | | 1378 | | 1379 | (B2,A) Probe id=s, | 1380 | state=operational, | B now knows 1381 | received probe r | that A has no 1382 |<--------------------------------------------| problem to receive 1383 | | its packets 1384 State: Operational | 1385 | | 1386 | (A,B2) payload packet | 1387 |-------------------------------------------->| Payload packets 1388 | | flow again 1389 | (B2,A) payload packet | 1390 |<--------------------------------------------| 1392 The next example shows when the failure for the current locator pair 1393 is in the other direction only. A has addresses A1 and A2, and B has 1394 addresses B1 and B2. The current communication is between A1 and B1, 1395 but A's packets no longer reach B using this pair. 1397 EXAMPLE 5: One-way failure 1399 Peer A Peer B 1400 | | 1401 State: | State: 1402 Operational | Operational 1403 | | 1404 | (A1,B1) payload packet | 1405 |-------------------------------------------->| 1406 | | 1407 | (B1,A1) payload packet | 1408 |<--------------------------------------------| 1409 | | 1410 | (A1,B1) payload packet | At time T1 1411 |----------------------------------------/ | path A1->B1 1412 | | becomes 1413 | | broken 1414 | (B1,A1) payload packet | 1415 |<--------------------------------------------| 1416 | | 1417 | (A1,B1) payload packet | 1418 |----------------------------------------/ | 1419 | | 1420 | (B1,A1) payload packet | 1421 |<--------------------------------------------| 1422 | | 1423 | (A1,B1) payload packet | 1424 |----------------------------------------/ | 1425 | | 1426 | | Send Timeout 1427 | | seconds after 1428 | | T1, B notices 1429 | | the problem and 1430 | (B1,A1) Probe id=p, | sends a com- 1431 | state=exploring | plaint that 1432 |<--------------------------------------------| it is not rec- 1433 | | eiving anything 1434 A responds | State: Exploring 1435 State: InboundOk | 1436 | | 1437 | (A1, B1) Probe id=q, | 1438 | state=inboundok, | 1439 | received probe p | 1440 |----------------------------------------/ | But A's response 1441 | | is lost 1442 | (B2,A2) Probe id=r, | 1443 | state=exploring | Next try different 1444 |<--------------------------------------------| locator pair 1445 | | 1446 | (A2, B2) Probe id=s, | 1447 | state=inboundok, | 1448 | received probes p, r | This one gets 1449 |-------------------------------------------->| through 1450 | | State: Operational 1451 | | 1452 | | B now knows 1453 | | that A has no 1454 | (B2,A2) Probe id=t, | problem to receive 1455 | state=operational, | its packets, and 1456 | received probe s | that A's probe 1457 |<--------------------------------------------| gets to B. It 1458 | | sends a 1459 State: Operational | confirmation to A 1460 | | 1461 | (A2,B2) payload packet | 1462 |-------------------------------------------->| Payload packets 1463 | | flow again 1464 | (B1,A1) payload packet | 1465 |<--------------------------------------------| 1467 Appendix B. Contributors 1469 This draft attempts to summarize the thoughts and unpublished 1470 contributions of many people, including the MULTI6 WG design team 1471 members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis 1472 Lindqvist, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG 1473 contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer 1474 Dawkins, and James Kempf, and HIP WG contributors such as Pekka 1475 Nikander. This draft is also in debt to work done in the context of 1476 SCTP [RFC2960] and HIP multihoming and mobility extension 1477 [I-D.ietf-hip-mm]. 1479 Appendix C. Acknowledgements 1481 The authors would also like to thank Christian Huitema, Pekka Savola, 1482 John Loughney, Sam Xia, Hannes Tschofenig, Sebastian Barre, Thomas 1483 Henderson, Matthijs Mekking, and Deguang Le for interesting 1484 discussions in this problem space, and for review of this 1485 specification. 1487 Authors' Addresses 1489 Jari Arkko 1490 Ericsson 1491 Jorvas 02420 1492 Finland 1494 Email: jari.arkko@ericsson.com 1496 Iljitsch van Beijnum 1498 Email: iljitsch@muada.com 1500 Full Copyright Statement 1502 Copyright (C) The IETF Trust (2007). 1504 This document is subject to the rights, licenses and restrictions 1505 contained in BCP 78, and except as set forth therein, the authors 1506 retain all their rights. 1508 This document and the information contained herein are provided on an 1509 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1510 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1511 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1512 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1513 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1514 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1516 Intellectual Property 1518 The IETF takes no position regarding the validity or scope of any 1519 Intellectual Property Rights or other rights that might be claimed to 1520 pertain to the implementation or use of the technology described in 1521 this document or the extent to which any license under such rights 1522 might or might not be available; nor does it represent that it has 1523 made any independent effort to identify any such rights. Information 1524 on the procedures with respect to rights in RFC documents can be 1525 found in BCP 78 and BCP 79. 1527 Copies of IPR disclosures made to the IETF Secretariat and any 1528 assurances of licenses to be made available, or the result of an 1529 attempt made to obtain a general license or permission for the use of 1530 such proprietary rights by implementers or users of this 1531 specification can be obtained from the IETF on-line IPR repository at 1532 http://www.ietf.org/ipr. 1534 The IETF invites any interested party to bring to its attention any 1535 copyrights, patents or patent applications, or other proprietary 1536 rights that may cover technology that may be required to implement 1537 this standard. Please address the information to the IETF at 1538 ietf-ipr@ietf.org. 1540 Acknowledgment 1542 Funding for the RFC Editor function is provided by the IETF 1543 Administrative Support Activity (IASA).