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