idnits 2.17.1 draft-nordmark-multi6-noid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2607. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 15 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 618: '... Receivers MUST silently ignore any ...' RFC 2119 keyword, line 1515: '...ntext. The host MAY perform a reverse...' RFC 2119 keyword, line 1717: '...ble UC messages it is RECOMMENDED that...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Rewritten' is mentioned on line 375, but not defined == Missing Reference: 'IANA' is mentioned on line 595, but not defined == Missing Reference: 'TBD' is mentioned on line 1673, but not defined == Unused Reference: 'ADDR-ARCH' is defined on line 2242, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 2245, but no explicit reference was found in the text == Unused Reference: 'AURA02' is defined on line 2260, but no explicit reference was found in the text == Unused Reference: 'NIKANDER03' is defined on line 2264, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 2280, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 2283, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 2286, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 2298, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-multi6-multihoming-threats-00 ** Downref: Normative reference to an Informational draft: draft-ietf-multi6-multihoming-threats (ref. 'M6THREATS') ** Obsolete normative reference: RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (ref. 'IPv6') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) -- No information found for draft-odell-8 - is the name correct? -- No information found for draft-crocker-mast-protocol - is the name correct? -- Duplicate reference: RFC2461, mentioned in 'DISCOVERY', was also mentioned in 'IPv6'. -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'DISCOVERY') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPv6-SA') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'IPv6-AUTH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'IPv6-ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 13 errors (**), 0 flaws (~~), 16 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 July 7, 2004 Sun Microsystems 5 Multihoming without IP Identifiers 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet Draft expires January 7, 2005. 34 Abstract 36 This document outlines a potential solution to IPv6 multihoming in 37 order to stimulate discussion. 39 This proposed solution relies on verification using the existing DNS 40 to prevent redirection attacks, while allowing locator rewriting by 41 (border) routers, with no per-packet overhead. The solution does not 42 introduce a "stack name" type of identifier, instead it ensures that 43 all upper layer protocols can operate unmodified in a multihomed 44 setting while still seeing a stable IPv6 address. 46 Contents 48 1. INTRODUCTION............................................. 4 49 1.1. Non-Goals........................................... 4 50 1.2. Assumptions......................................... 5 52 2. TERMINOLOGY.............................................. 5 53 2.1. Notational Conventions.............................. 6 55 3. PROTOCOL OVERVIEW........................................ 7 56 3.1. DNS Usage and Dependencies.......................... 11 57 3.2. Host-Pair Context................................... 12 58 3.3. Message Formats..................................... 13 59 3.3.1. Context Initiator (INIT) Message Format........ 14 60 3.3.2. Context Check (CC) Message Format.............. 15 61 3.3.3. Context Check Reply (CCR) Message Format....... 16 62 3.3.4. Context Confirm (CONF) Message Format.......... 16 63 3.3.5. Update Request (UR) Message Format............. 16 64 3.3.6. Update Acknowledgement (UA) Message Format..... 17 65 3.3.7. Unknown Context (UC) Message Format............ 17 67 4. PROTOCOL WALKTHROUGH..................................... 18 68 4.1. Initial Context Establishment....................... 18 69 4.2. Locator Change...................................... 21 70 4.3. Concurrent Context Establishment.................... 22 71 4.3.1. Crossing INIT messages......................... 22 72 4.3.2. Sending INIT after sending CC.................. 23 73 4.4. Handling Locator Failures........................... 23 74 4.5. Locator Set Changes................................. 24 75 4.6. Preventing Premeditated Redirection Attacks......... 26 77 5. HANDLING STATE LOSS...................................... 26 78 5.1. State Loss and Packets from the Peer................ 27 79 5.2. State Loss and Packets from the ULP................. 28 81 6. ENCODING BITS IN THE IPv6 HEADER?........................ 29 83 7. PROTOCOL PROCESSING...................................... 30 84 7.1. State Machine....................................... 30 85 7.2. Sending INIT messages............................... 30 86 7.3. Receiving INIT messages............................. 31 87 7.4. Receiving CC messages............................... 32 88 7.5. Receiving CCR messages.............................. 33 89 7.6. Receiving CONF messages............................. 34 90 7.7. Sending Update Request messages..................... 35 91 7.8. Receiving Update Request messages................... 35 92 7.9. Receiving Update Acknowledgement messages........... 36 93 7.10. Retransmission..................................... 36 94 7.11. Receiving Data Packets............................. 36 95 7.12. Receiving Unknown Context messages................. 37 96 7.13. DNS Verification and Hosts without a FQDN.......... 38 97 7.14. Birthday Counter................................... 40 99 8. COMPATIBILITY WITH STANDARD IPv6......................... 40 101 9. APPLICATION USAGE OF IDENTIFIERS......................... 41 103 10. CHECKSUM ISSUES......................................... 42 105 11. IMPLICATIONS FOR PACKET FILTERING....................... 43 107 12. IPSEC INTERACTIONS...................................... 43 109 13. SECURITY CONSIDERATIONS................................. 44 111 14. PRIVACY CONSIDERATIONS.................................. 45 113 15. DESIGN ALTERNATIVES..................................... 45 114 15.1. Avoid introduction of M6 DNS Resource Record type.. 45 115 15.2. Extension header instead of using flow label....... 46 116 15.3. Explicit close exchange............................ 47 118 16. OPEN ISSUES............................................. 47 119 16.1. Renumbering Considerations......................... 48 120 16.2. Initiator Confusion vs. "Virtual Hosting".......... 48 122 17. ACKNOWLEDGEMENTS........................................ 49 124 18. REFERENCES.............................................. 49 125 18.1. Normative References............................... 49 126 18.2. Informative References............................. 49 128 19. CHANGE LOG.............................................. 51 130 APPENDIX A: CONTEXT CLOSE PROTOCOL........................... 52 132 AUTHORS' ADDRESSES........................................... 56 134 1. INTRODUCTION 136 The goal of the IPv6 multihoming work is to allow a site to take 137 advantage of multiple attachments to the global Internet without 138 having a specific entry for the site visible in the global routing 139 table. Specifically, a solution should allow users to use multiple 140 attachments in parallel, or to switch between these attachment points 141 dynamically in the case of failures, without an impact on the upper 142 layer protocols. 144 This proposed solution uses existing DNS mechanisms to perform enough 145 validation to prevent redirection attacks. 147 The goals for this proposed solution is to: 149 o Have no impact on upper layer protocols in general and on 150 transport protocols in particular. 152 o Address the security threats in [M6THREATS]. 154 o Allow routers rewriting the (source) locators as a means of 155 quickly detecting which locator is likely to work for return 156 traffic. 158 o No per-packet overhead. 160 o No extra roundtrip for setup. 162 o Take advantage of multiple locators/addresses for load spreading. 164 1.1. Non-Goals 166 The assumption is that the problem we are trying to solve is site 167 multihoming, with the ability to have the set of site locator 168 prefixes change over time due to site renumbering. Further, we 169 assume that such changes to the set of locator prefixes can be 170 relatively slow and managed; slow enough to allow updates to the DNS 171 to propagate. This proposal does not attempt to solve, perhaps 172 related, problems such as host multihoming or host mobility. 174 This proposal also does not try to provide an IP identifier. Even 175 though such a concept would be useful to ULPs and applications, 176 especially if the management burden for such a name space was zero 177 and there was an efficient yet secure mechanism to map from 178 identifiers to locators, such a name space isn't necessary (and 179 furthermore doesn't seem to help) when using the DNS to verify the 180 locator relationships. 182 1.2. Assumptions 184 The main technical assumptions this proposal makes is that the DNS 185 infrastructure can be used for verification of the relationship 186 between locators on both the initiator of communication and the 187 responding peer. In particular, it assumes that getting DNS reverse 188 tree (ip6.arpa) populated for the hosts that wish to take advantage 189 of multihoming, will not be a significant problem. 191 This version of the document further relaxes this constraint so that 192 if two communication hosts are in separate multihomed sites, if only 193 one of them has correct information in the forward plus reverse DNS, 194 the communication between them can benefit from the multiple locators 195 of that host. However, without loss of security it isn't possible to 196 benefit from the multiple locators of a host with no DNS information 197 (or incorrect/missing forward and reverse DNS information). 199 2. TERMINOLOGY 201 upper layer protocol (ULP) 202 - a protocol layer immediately above IP. Examples are 203 transport protocols such as TCP and UDP, control 204 protocols such as ICMP, routing protocols such as 205 OSPF, and internet or lower-layer protocols being 206 "tunneled" over (i.e., encapsulated in) IP such as 207 IPX, AppleTalk, or IP itself. 209 interface - a node's attachment to a link. 211 address - an IP layer name that contains both topological 212 significance and acts as a unique identifier for an 213 interface. 128 bits. 215 locator - an IP layer topological name for an interface or a 216 set of interfaces. 128 bits. The locators are 217 carried in the IP address fields as the packets 218 traverse the network. 220 identifier - an IP layer identifier for an IP layer endpoint 221 (stack name in [NSRG]). The transport endpoint is a 222 function of the transport protocol and would 223 typically include the IP identifier plus a port 224 number. NOTE: This proposal does not contain any IP 225 layer identifiers. 227 Application identifier (AID) 228 - an IP locator which has been selected for 229 communication with a peer to be used by the upper 230 layer protocol. 128 bits. This is used for 231 pseudo-header checksum computation and connection 232 identification in the ULP. Different sets of 233 communication to a host (e.g., different 234 connections) might use different AIDs in order to 235 enable load spreading. 237 address field 238 - the source and destination address fields in the 239 IPv6 header. As IPv6 is currently specified this 240 fields carry "addresses". If identifiers and 241 locators are separated these fields will contain 242 locators. 244 FQDN - Fully Qualified Domain Name 246 2.1. Notational Conventions 248 A, B, and C are hosts. X is a potentially malicious host. 250 FQDN(A) is the domain name for A. 252 Lsl(A) is the "local" locator set for A, that is, the set of locators 253 that A itself knows it has. This set expresses which locators should 254 be acceptable to receive packets sent by A. 256 Lsr(A) is the "remote" locator set for A, that is, the set of 257 locators of A that its peer found in the DNS. Normally Lsl(A) and 258 Lsr(A) are the same, but due to DNS updates, DNS load balancing, or 259 misconfiguration they might differ. 261 Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... 262 Ln(A). For robustness Ls(A) is computed as the intersection of 263 Lsl(A) and Lsr(A) by both A and its peer. 265 Lsv(A) is the verified locator set for A. This is the subset of 266 Ls(A) which has been verified with both forward and reverse DNS 267 lookups to be a set corresponding to a single FQDN. This set 268 expresses which locators are safe to use as destinations when sending 269 packets to A. 271 AID(A) is an application ID for A. In this proposal, AID(A) is 272 always one member of A's locator set. 274 3. PROTOCOL OVERVIEW 276 In order to prevent redirection attacks this protocol relies on the 277 DNS (for the hosts which want to take advantage of themselves having 278 multiple locators) being maintained with consistent forward and 279 reverse information. This allows any host, given one locator, to 280 determine the corresponding FQDN and the set of locators for the 281 host. Once those lookups have been performed, and the original 282 locator is indeed part of the set, the host can happily allow any of 283 those locators to be used without being subject to redirection 284 attacks. Keeping the FQDN around allows the solution to handle 285 graceful renumbering by being able to redo the DNS lookups (e.g., 286 based on the TTL on the resource records). 288 DNS is also used to provide an indication of multihoming capability 289 of a host. The details of this is TBD but a simple example would be 290 to introduce a new M6 Resource Record type in the DNS which has no 291 RDATA; thus the mere existence of such a record at a FQDN would imply 292 that the host supports the M6 protocol. See Section 15.1 for an 293 alternative approach that doesn't need a new RR type. 295 ----------------------- 296 | Transport Protocols | 297 ----------------------- 299 ------ ------- -------------- ------------- 300 | AH | | ESP | | Frag/reass | | Dest opts | 301 ------ ------- -------------- ------------- 303 ----------------- 304 | M6 shim layer | 305 ----------------- 307 ------ 308 | IP | 309 ------ 311 Figure 1: Protocol stack 313 The proposal uses an M6 shim layer between IP and the ULPs as shown 314 in figure 1, in order to provide ULP independence. Conceptually the 315 M6 shim layer behaves as if it is associated with an extension 316 header, which would be ordered immediately after any hop-by-hop 317 options in the packet. However, the amount of data that needs to be 318 carried in an actual M6 extension header is close to zero. By using 319 some encoding of the nexthdr value it is possible to carry the common 320 protocols/extension headers without making the packets larger. The 321 nexthdr encodings are discussed later in this document. We refer to 322 packets that use this encoding to indicate to the receiver that M6 323 processing should be applied as "M6 packets" (analogous to "ESP 324 packets" or "TCP packets"). 326 Layering AH and ESP above the M6 shim means that IPsec can be made to 327 be unaware of locator changes the same way that transport protocols 328 can be unaware. Thus the IPsec security associations remain stable 329 even though the locators are changing. Layering the fragmentation 330 header above the M6 shim makes reassembly robust in the case that 331 there is broken multi-path routing which results in using different 332 paths, hence potentially different source locators, for different 333 fragments. Thus, effectively the M6 shim layer is placed between the 334 IP endpoint sublayer, which handles fragmentation, reassembly, and 335 IPsec, and the IP routing sublayer, which on a host selects which 336 default router to use etc. 338 The proposal uses router rewriting of (source) locators as one way to 339 determine which is the preferred (or only working) locator to use for 340 return traffic. But not all packets can have their locators 341 rewritten. In addition to existing IPv6 packets, the packets 342 exchanged before M6 host-pair context state is established at the 343 receiver can not have their locators rewritten. Thus a simple 344 mechanism is needed to indicate to the routers on the path whether or 345 not it is ok to rewrite the locators in the packet. Conceptually 346 this is a single bit in the IPv6 header (we call it the "rewrite ok" 347 bit) but there is no spare bit available. Later in the document we 348 show how we solve this by allocating a range of next header values to 349 denote this semantic bit. 351 Applications and upper layer protocols use AIDs which the M6 layer 352 will map to/from different locators. The M6 layer maintains state, 353 called host-pair context, in order to perform this mapping. The 354 mapping is performed consistently at the sender and the receiver, 355 thus from the perspective of the upper layer protocols, packets 356 appear to be sent using AIDs from end to end, even though the packets 357 travel through the network containing locators in the IP address 358 fields, and even though those locators might be rewritten in flight. 360 ---------------------- ---------------------- 361 | Sender A | | Receiver B | 362 | | | | 363 | ULP | | ULP | 364 | | src AID(A) | | ^ | 365 | | dst AID(B) | | | src AID(A) | 366 | v | | | dst AID(B) | 367 | M6 | | M6 | 368 | | src L1(A) | | ^ | 369 | | dst L1(B) | | | src L2(A) | 370 | v | | | dst L1(B) | 371 | IP | | IP | 372 ---------------------- ---------------------- 373 | ^ 374 -- cloud with some routers ------- 375 src L2(A) [Rewritten] 376 dst L1(B) 377 Figure 2: Mapping with router rewriting of locators. 379 The result of this consistent mapping is that there is no impact on 380 the ULPs. In particular, there is no impact on pseudo-header 381 checksums and connection identification. 383 Conceptually one could view this approach as if both AIDs and 384 locators are being present in every packet, but with a header 385 compression mechanism applied that removes the need for the AIDs once 386 the state has been established. As we will see below the flow label 387 will be used akin to a "compression tag" i.e., to indicate the 388 correct context to use for decompression. 390 The need for some "compression tag" is because the desire to allow 391 load spreading and handle site renumbering. Without those desires it 392 could have been possible to e.g. designate one fixed locator as the 393 AID for a host and storing that in the DNS. But instead different 394 connections between two hosts are allowed to use different AIDs and 395 on reception of a M6 packet the correct AIDs must be inserted into 396 the IP address fields before passing the packet to the ULP. The flow 397 label serves as a convenient "compression tag" without increasing the 398 packet size, and this usage doesn't conflict with other flow label 399 usage. 401 In addition to the zero overhead data messages, there are seven 402 different M6 message types introduced (which are defined as new 403 ICMPv6 messages). Four types are used to perform a 4-way handshake 404 to create state at both endpoints without creating state on the first 405 received packet (which would introduce a memory consumption DoS 406 attack), and two types are used to update the set of locators used 407 for the context, and finally a single message type to signal that 408 state has been lost. The seven message types are called: 410 o Context Initiator message (INIT); first message of the 4-way 411 context establishment. Sent by the initiator when there is a 412 desire to create a host-pair context for future locator agility. 413 Normally sent when a data packet is passed down to IP from the ULP 414 when there is no context state. An ULP packet can be piggybacked 415 on this message. 417 o Context Check message (CC); second message of the 4-way context 418 establishment. Sent in response to a INIT message. An ULP packet 419 can be piggybacked on this message. 421 o Context Check Reply message (CCR); third message of the 4-way 422 context establishment. Sent in response to a CC message. An ULP 423 packet can be piggybacked on this message. 425 o Context Confirm message (CONF); Last message in the context 426 establishment exchange; can be sent in response to a CCR or an 427 INIT message. Carries the responders flow label as well as any 428 initial reductions in the locator set to the initiator. 430 o Update Request message (UR); sent to update the local and remote 431 locator sets. An ULP packet can be piggybacked on this message. 433 o Update Acknowledgement message (UA); sent to acknowledge an Update 434 Request message. An ULP packet can be piggybacked on this 435 message. 437 o Unknown Context message (UC); error which is sent when no state is 438 found. 440 Similar to MAST [MAST] the above exchange can be performed 441 asynchronously with data packets flowing between the two hosts; until 442 context state has been established at both ends the packets would 443 flow without allowing router rewriting of locators and without the 444 ability for the hosts to switch locators. 446 Once the 4-way state creation exchange has completed there is host- 447 pair context state at both hosts, and both ends know a set of 448 locators for the peer that are acceptable as the source in received 449 packets. At that point in time the responder (which didn't use DNS 450 before the setup) can asynchronously start verifying additional 451 locators using the DNS. Once a peer locator has been verified it 452 will be a candidate destination locator including the ability to 453 dynamically switch to using the last received source locator (that is 454 already verified) as the destination locator for return traffic. 456 3.1. DNS Usage and Dependencies 458 For the protocol to be beneficial at least one of the communicating 459 peers need to have a FQDN with consistent information in the forward 460 and reverse trees. The protocol uses the DNS at the end of the 461 communication which normally does the DNS lookup, to not only find 462 all the locators (as AAAA records) but also verify that these 463 locators have reverse tree entries which point back at the FQDN. The 464 locators which do not point back to the FQDN will not be used as part 465 of the locator set. At the end of the communication which isn't 466 required to do a DNS lookup today (the responder or server), this 467 protocol, at some point after the context has been created message is 468 received, will use the AID (normally the source address of the CCR 469 packet) to first find the peer's FQDN, and them perform a forward 470 lookup plus a reverse lookup of all the IPv6 locators, in order to 471 verify that these locators are bound to the same FQDN. As in the 472 initiator case, the locators which do not verify using this method 473 will be excluded from the locator set. If no locators verify, then 474 only the AID will be viewed as part of the locator set i.e., the 475 protocol falls back to not providing any address agility. 477 For the protocol to work well, both ends have to agree on each 478 other's locator sets. There are several reasons why a host's notion 479 of its locators (or IPv4 addresses today) might be different than the 480 set of locators present in the DNS for the host's FQDN 481 (misconfiguration, DNS load balancing, in-progress DNS update, etc.) 482 In order to cope with this, the two communicating hosts exchange each 483 other's notion of each other's locators and form the intersection 484 about what they know (about themselves as well as the peer) and what 485 the peer knows (about themselves as well as the peer). A property of 486 this approach is that the locator set can never be larger than what 487 is contained in the DNS, that is, a host can not use this to fool its 488 peer to include additional locators as destinations, for instance for 489 3rd party DoS attacks [M6THREATS]. This intersection should never be 490 empty; an empty intersection is an indication that only the AID 491 should be used. 493 The hosts' locators might change over time due to renumbering. At 494 some point in time such a change will need to be reflected in the DNS 495 in order for this protocol to be able to take advantage of any added 496 locators. The protocol uses the Update Request from the peer in 497 combination with the DNS TTL as an indication when it makes sense to 498 redo the DNS lookup of the peer's FQDN to detect changes in the 499 locator set. 501 3.2. Host-Pair Context 503 The host-pair context is established on the initiator of 504 communication based on information learned from the DNS (either by 505 starting with a FQDN or with an IP address -> FQDN lookup). The 506 responder will establish some initial state using the context 507 creation 4-way handshake and later verify the peer's locators using 508 the DNS. 510 The context state contains the following information: 512 - the peer locator which the ULP uses as ID; AID(peer) 514 - the local locator which the ULP uses as ID; AID(local) 516 - the set of peer locators determined from the DNS; Lsr(peer) 518 - the set of peer locators communicated from the peer; Lsl(peer) 520 - the set of peer locators; Ls(peer); intersection of the two above 522 - for each peer locator, a bit whether it has been verified with the 523 DNS (by doing reverse + forward lookup). This can be viewed as 524 forming a subset of Ls(peer) which we call Lsv(peer). 526 - the preferred peer locator - used as destination; Lp(peer) 528 - the set of local locators from local information; Lsl(local) 530 - the set of local locators communicated from the peer, that is, 531 which the peer found in the DNS; Lsr(local) 533 - the set of local locators; Ls(local); intersection of the two 534 above 536 - the preferred local locator - used as source; Lp(local) 538 - the flow label allocated by the peer that is used to transmit 539 packets; F(peer) 541 - the flow label allocated by the host to expect in received 542 packets; F(local) 544 - the fully qualified domain name for the peer; FQDN(peer) 546 - State about peer locators that are in the process of being 547 verified in the DNS 549 - Peer's birthday counter (a counter which increments by one each 550 time the host reboots) 552 This state is accessed differently in the transmit and receive paths. 553 In the transmit path when the ULP passes down a packet the key to the 554 context state is the tuple ; this key must 555 identify at most one state record. In the receive path it is the 556 F(local) flow label, which was allocated by the host itself, to 557 uniquely identify a host-pair context. 559 This limits a single host to maintaining about 1 Million host-pair 560 contexts at a time; limited by the 20 bits of flow label. A host 561 that needs to support more than this limit, can do so by acting as 562 multiple hosts from the perspective of this protocol. This would 563 entail having multiple FQDNs and each FQDN being associated with a 564 different set of locators. For instance, these different locators 565 might use different interface identifiers. 567 Note that the flow labels could be selected to be finer grain than 568 above; for instance having a different flow label for each 569 connection. Doing so requires some efficient data structure 570 organization at the receiver to map multiple F(local) to the same 571 context and it might make the host run out of flow labels more 572 easily. However, the use of finer grain flow labels might be 573 necessary when the flow labels are also used for QoS purposes in the 574 routers. [RFC3697]. 576 3.3. Message Formats 578 The set of messages and message sequences are similar to those in 579 [HIP] and [WIMP] but the content is quite different, due to the 580 different approach to security. 582 The base M6 header is an ICMPv6 header as follows: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type | Code | Checksum | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 ICMPv6 Fields: 594 Type 595 TBD [IANA] 597 Code 598 8-bit field. The type of M6 message. The M6 599 header carries seven different types of messages: 601 o Context Initiator message (INIT) 603 o Context Check message (CC) 605 o Context Check Reply message (CCR) 607 o Context Confirm message (CONF) 609 o Update Request message (UR) 611 o Update Acknowledgement message (UA) 613 o Unknown Context message (UC) 615 Checksum The ICMPv6 checksum. 617 Future versions of this protocol may define new message codes. 618 Receivers MUST silently ignore any message code they do not 619 recognize. 621 This drafts doesn't contain actual message layout for the code 622 specific part. However, the content of these messages is specified 623 below. 625 3.3.1. Context Initiator (INIT) Message Format 627 The Context Initiator (INIT) message contains: 629 - Initiator Nonce (used to match the CC message with the INIT 630 message) 632 - Initiator's AID 634 - Responder's AID 636 - Initiator's locally determined locators - Lsl(initiator) 638 - Responder's remotely determined locators - Lsr(responder) 640 - Initiator's flow label (20 bits) 642 - Initiator's birthday counter (a counter which increments by one 643 each time the host reboots) 645 3.3.2. Context Check (CC) Message Format 647 When the responder receives an INIT message it does not allocate any 648 state to prevent a class of DoS attacks. Instead it sends a CC 649 message, which effectively contains the state it would have 650 allocated, and gets that information echoed back from the initiator 651 in a CCR message. 653 This context state consists of: 655 - the two AIDs 657 - the initiator's flow label (The responder's flow label is 658 allocated when the CCR message is received.) 660 - the initiator's locator set from the INIT message; Lsl(initiator) 662 - the responder's locator set from the INIT message; Lsr(responder) 664 - the responder's locator set as know to the responder itself; 665 Lsl(responder). The encoding [TBD] for the responder's locator 666 set can use two bits per locator to indicate whether a locator is 667 in Lsr(responder), Lsl(responder), or both. 669 - The two birthday counters 671 - The "ULP packet discarded" bit indicating that the ULP packet 672 piggybacked on an INIT message was not delivered to the ULP. 674 The Context Check (CC) message contains: 676 - Initiator's Nonce (copied from the INIT message) 678 - Context state as above 680 - A timestamp or nonce (for the benefit of the responder matching 681 the CCR message with the CC, as well as finding the per-host key 682 which was used with the hash below) 684 - A hash over the context state and timestamp/nonce (to prevent 685 modification of the context state between sending it in the CC and 686 receiving it back in the CCR message) 688 3.3.3. Context Check Reply (CCR) Message Format 690 The Context Check Reply (CCR) message contains: 692 - Initiator's nonce (to match the CONF message with the CCR) 694 - The context state, timestamp/nonce, and hash copied from the CC 695 message. 697 3.3.4. Context Confirm (CONF) Message Format 699 In case the responder performs some verification of the peer's 700 locator before it sends the CONF message, it can include the 701 Lsr(initiator) in the CONF message. If this verification is 702 deferred, then a Update Request message will need to be sent later if 703 the DNS verification indicates that some of the peer's locators 704 should not be used because they are not in the DNS. 706 The Context Confirm (CONF) message contains: 708 - Initiator's AID 710 - Responder's AID 712 - Initiator's Nonce (copied from the INIT or CCR message which 713 triggered sending the CONF message) 715 - The responder's flow label 717 - Responder's birthday counter. (Needed when the CONF is in response 718 to an INIT message). 720 - Optionally the initiator's remotely determined locators - 721 Lsr(initiator) 723 - Optionally the responder's locally determined locators - 724 Lsl(responder). (Needed when the CONF is in response to an INIT 725 message). 727 3.3.5. Update Request (UR) Message Format 729 Either end of the communication can send an update request to inform 730 the peer of a change in the locator sets. This change could be any 731 combination of additions to the sender's local locators, deletions to 732 the sender's local locators, or changes to the peers locators that 733 have been determined from the DNS. The Update request message 734 contains: 736 - Request nonce/timestamp (used to match the UA with the UR) 738 - Sender's and receiver's AID 740 - Sender's and receiver's flow label for the context. 742 - Sender's locally determined locators - Lsl(sender) 744 - Receiver's remotely determined locators - Lsr(receiver) 746 3.3.6. Update Acknowledgement (UA) Message Format 748 The Update Acknowledgement message signals the receipt of the Update 749 Request message and contains: 751 - Nonce/timestamp copied from the UR message 753 - Sender's and receiver's AID 755 - Sender's and receiver's flow label for the context. 757 If both ends need to update each other, each end has to send an 758 Update Request message. 760 3.3.7. Unknown Context (UC) Message Format 762 The Unknown Context message contains: 764 - The 20-bit flow label from the triggering packet. 766 - The birthday counter (a counter which increments by one each time 767 the host reboots) 769 - The triggering packet starting with the IPv6 header (as much of 770 the packet as fits in the MTU) 772 4. PROTOCOL WALKTHROUGH 774 4.1. Initial Context Establishment 776 Here is the sequence of events when A starts talking to B: 778 1. A looks up FQDN(B) in the DNS which returns Lsr(B) plus "B is M6 779 capable". One locator is selected to be returned to the 780 application: AID(B) = L1(B). The others are installed in the M6 781 layer on the host with AID(B) being the key to find that state. 783 To make sure that the lookup from AID(B) returns a single state 784 record it appears that one needs to do a reverse lookup of 785 AID(B) to get the FQDN and check that the result is indeed 786 FQDN(B). Whether this check can be deferred until two entities 787 try to use the same AID(B) for a different Ls is for further 788 study. Always doing the reverse lookup would be more 789 predictable in any case. See section 16.2 for some more 790 discussion. 792 2. The ULP creates "connection" state between AID(A)=L1(A) and 793 AID(B) and sends the first packet down to the IP/M6 shim layer 794 on A. L1(A) was picked using regular source address selection 795 mechanisms. 797 3. The M6 layer matches on AID(B) and finds the proto-context state 798 (setup in step #1) with Lsr(B). The existence of that state 799 means that it is possible to establish a host-pair context. 800 Host A can decide when to establish the context; it can defer 801 this and use regular IPv6 with the locators being the AIDs for 802 some time. 804 In this example A decides to immediately establish the host-pair 805 context. Thus it sends an INIT message with the ULP packet as 806 part of the payload (if the MTU allows it to fit). 808 Before sending the INIT message A selects a unique flow label 809 F(local) for the new context and a nonce to match the CC with 810 the INIT. 812 4. The packet (TCP SYN or whatever) is sent to the peer with 813 locators L1(A) to L1(B) i.e., the same as the AIDs, piggybacked 814 on the INIT message. It is possible to set the "rewrite ok" bit 815 in the header for the INIT header, but if the locators are 816 rewritten the piggybacked packet can not be passed to the ULP. 818 5. Host B receives the INIT message and passes the packet to the M6 819 shim layer. The M6 layer can't create state on the first 820 packet, but if the packet was not rewritten in transit (that is, 821 the AIDs are in the IP address fields) it can pass a piggybacked 822 packet to the ULP. The ULP sees a packet identified by AID(A), 823 AID(B). If the source address field is different than AID(A), 824 then it is not safe to pass a piggybacked packet to the ULP 825 since it could have been a case of spoofed AIDs. In this case 826 the CC message would indicate that the ULP packet was dropped so 827 that the initiator can retransmit the ULP packet once the 828 context has been established. 830 The CC message is sent to the source locator of the INIT, even 831 if the peer AID is different. 833 The same technique as in [MIPv6] is used to securely do the 834 CC/CCR exchange without any local state; use a local per-host 835 key which is never shared with anybody and pass the context 836 state, a timestamp, and the keyed hash of the state+timestamp in 837 the CC message. When the state, timestamp, and keyed hash value 838 is returned in the CCR message, the hash is used to verify that 839 the state hasn't been modified by the initiator. 841 The 4-way exchange is done asynchronously with ULP packets, but 842 it is possible (assuming the MTU allows) to piggyback ULP 843 packets on the CC message. 845 Should ULP packets be passed down to the M6 layer on B before 846 the CCR message has been received, there will be no context 847 state and no state installed as a result of a DNS lookup (unlike 848 on A). This will indicate that the ULP message should be passed 849 as-is (not as an M6 message) to the peer. Thus during the 4-way 850 exchange packets can flow in both directions using the original 851 locators=AIDs. 853 6. Host A receives the CC message. It verifies that the message is 854 sent in response to the INIT by comparing the nonce. 856 If a ULP packet was piggybacked A will pass that to the ULP. 857 This can be done even if the locators where rewritten as long as 858 the locators are part of the locator sets known to A. 860 A forms the peer's locator set by taking the intersection of the 861 Lsr it found in the DNS and the Lsl returned in the CC message. 862 If the AID(peer) is not part of the Lsl(peer) it is an error and 863 the AID is added to the locator set. [The fact that the peer 864 forgot to include the AID could be an indication that it is 865 seriously confused. The sender should ensure that the AID is 866 always included in the locator set when sending a locator set to 867 a peer.] 869 Then A sends a CCR message which has the same information as the 870 CC message. The message is sent to the source locator for the 871 CC message. 873 7. Host B receives the CCR message. It verifies that the hash of 874 the state is correct using its per-host key and verifies that 875 the timestamp is recent. At this point in time it knows that A 876 is at least not just blasting out INIT messages as a DoS - A is 877 also responding to CC messages. Thus B goes ahead and allocates 878 state at this point in time using the state that is in the CCR 879 message, and allocates a unique F(local) for this context. 881 At this point in time B has enough information to handle M6 882 packets from A, even though it hasn't yet verified the peer's 883 locators in the DNS. 885 If a ULP packet was piggybacked on the CCR message, B will pass 886 that to the ULP. This is done even if the IP address fields do 887 not contain the AIDs, since having created the context state 888 when the CCR was received, any "response" packets from the ULP 889 will only be sent out to the verified peer locators for the 890 context. Hence there is no risk that this can be used for 891 reflection attacks that bypass any deployed ingress filtering. 893 In response to the CCR message, B sends a CONF message which 894 includes the allocated F(B). Also, if B has performed some DNS 895 verification of the initiator's locators prior to sending the 896 CONF message, and not all locators in Lsl(A) verified, then B 897 includes the Lsr(A) in the CONF message. If B later discovers 898 that not all locators in Lsl(A) verified it will need to send an 899 Update Request message. 901 At this point in time B can start asynchronously and 902 incrementally extracting and verifying Lsr(A) from the DNS. The 903 first lookup consists of finding L1(A)=AID(A) in ip6.arpa to get 904 the FQDN and record it, and lookup the AAAA RR set for that FQDN 905 to get Lsr(A). Based on Lsr(A) and the Lsl(A) received in the 906 CCR, B can form the intersection Ls(A). If this intersection 907 does not contain AID(A) it is an error and the AID is added to 908 the locator set. 910 Once Ls(A) is known, B can verify (also incrementally) that each 911 member of Ls(A) is indeed assigned to A by doing a reverse 912 lookup of each one (except L1(A) which was already looked up 913 above). Only when the reverse lookup of a given peer locator 914 has completed is that locator marked as verified. This reverse 915 lookup of each locator prevents 3rd party DoS attacks as 916 described in [M6THREATS]. 918 At this point in time B knows that A has context state and it 919 knows the flow label to use, thus it can start sending packets 920 using the context. 922 8. Host A receives the CONF message, records F(peer) from the 923 packet, and if present, extracts the Lsr(A) and forms the 924 intersection Lsl(A) and Lsr(A) and uses this to update Ls(A). 925 If the resulting Ls(A) does not contain AID(A) this is an error 926 and the AID is added to the locator set. 928 If a ULP packet was piggybacked on the CONF message, A will pass 929 that to the ULP as long as the source locator of the CONF 930 message was one of as part of the verified Ls(peer) locators. 932 At this point in time A knows that B has context state and it 933 knows the flow label to use, thus it can start sending packets 934 using the context. 936 4.2. Locator Change 938 This is the sequence of events when B receives a packet with a 939 previously unused source locator for A, for instance L2(A). 941 Host B receives M6 packet with source L2(A) and destination L1(B). 942 Looks up context state using the flow label. If this lookup succeeds 943 and the source address field contains a locator which is in Lsl(B), 944 then the locator is acceptable for incoming packets (even though it 945 might not have been verified for use as return traffic) and the 946 packet is rewritten to contain the AIDs from the context state and 947 passed to the ULP. 949 If L2(A) has not been verified then it would make sense for B to put 950 that locator first in the list of asynchronous DNS verifications that 951 are needed. If/once L2(A) has been verified B can make it the 952 preferred peer locator to use when sending packets to AID(A). 954 The verification needs to complete before using the locator as a 955 destination in order to prevent 3rd party DoS attacks [M6THREATS]. 957 If a host receives a packet with a known flow label but where the 958 locators (source and/or destination) are not part of the locator 959 sets, the packet is silently dropped as specified in more detail in 960 Section 7.11. 962 4.3. Concurrent Context Establishment 964 Should both A and B attempt to contact each other at about the same 965 time using the same AIDs for each other, the message flow is 966 different than above. However, if different AIDs are used this would 967 result in two completely independent contexts between the two hosts 968 following the basic content establishment above. 970 If B tries to contact A after B has received the CCR message, then B 971 will discover the context state for AID(A) and not trigger creating a 972 new context. But since B does not create any state when receiving 973 the INIT, it is possible for B to send a INIT after it has received 974 an INIT (and sent a CC), as well as the case of two crossing INIT 975 messages. 977 4.3.1. Crossing INIT messages 979 Here is the sequence of events when A starts talking to B at the same 980 time as B starts talking to A: 982 1. A sends an INIT message to B. As part of this A creates proto- 983 state for the context and allocates its flow label. It has 984 Lsr(B) from the DNS lookup. 986 2. B sends an INIT message to A. As part of this B creates proto- 987 state for the context and allocates its flow label. It has 988 Lsr(A) from the DNS lookup. 990 3. B receives the INIT message from A. It discovers the context it 991 created in step 2 since it matches the AIDs. Thus it can 992 immediately send a CONF message containing its flow label and 993 Lsr(A). 995 4. A receives the INIT message from B. It discovers the context it 996 created in step 1 since it matches the AIDs. Thus it can 997 immediately send a CONF message containing its flow label and 998 Lsr(B). 1000 5. A receives the CONF message from B and can complete the context 1001 state creation. 1003 6. B receives the CONF message from A and can complete the context 1004 state creation. 1006 4.3.2. Sending INIT after sending CC 1008 Here is the sequence of events when A starts talking to B, and after 1009 B has received the INIT but before B has received the CCR, B starts 1010 establishing a context with A: 1012 1. A sends an INIT message to B. As part of this A creates proto- 1013 state for the context and allocates its flow label. It has 1014 Lsr(B) from the DNS lookup. 1016 2. B receives the INIT message from A. It finds no matching 1017 context thus it proceeds in the normal context establishment and 1018 sends a CC message to A. 1020 3. A ULP on B wants to send a packet to AID(A) which triggers B to 1021 send an INIT message to A. As part of this B creates proto- 1022 state for the context and allocates its flow label. B has 1023 Lsr(A) from the DNS lookup. 1025 4. A receives the CC message from B and responds with a CCR message 1026 as in the normal context establishment. 1028 5. A receives the INIT message from B. It discovers the context it 1029 created in step 1 since it matches the AIDs. Since A has sent 1030 the CCR it knows that the B will soon complete the context 1031 establishment and respond with a CONF message. Thus the INIT 1032 can be silently ignored. 1034 6. B receives the CCR message from A. At this point in time it 1035 discovers that it is a bidirectional setup because it has 1036 context state indicating that it has sent an INIT message. B 1037 needs to inform A of the flow label it selected in step 3, which 1038 is does in the CONF message. 1040 4.4. Handling Locator Failures 1042 Should not all locators be working when the communication is 1043 initiated some extra complexity arises, because the ULP has already 1044 been told which AIDs to use. If the locators that where selected to 1045 be AIDs are not working it isn't possible to defer the context 1046 establishment, but instead it needs to be performed before ULP 1047 packets can be successfully exchanged. If the destination locator 1048 isn't reachable, the M6 layer needs to retry the INIT message with 1049 different destination locators until a working one is found. If the 1050 source locator isn't reachable for return traffic, routers which 1051 rewrite the source locator at site exit can be helpful to convey to 1052 the peer which locator to use. When the initiator's AID is not 1053 working as a locator, it isn't possible to piggyback ULP packets on 1054 the INIT message, to prevent using packets with a source locator 1055 different than the source AID being used for reflection attacks that 1056 would bypass any deployed ingress filtering. 1058 After context setup the sender can use retransmit hints from the ULP 1059 to get the M6 layer to try a different verified locator. This is the 1060 only possibility when only one end is (re)transmitting ULP packets 1061 and the destination locator is no longer working. Some heuristics 1062 are needed in the M6 layer to determine which alternative destination 1063 locator to try, and how often to try a different one when there are 1064 persistent failures. 1066 If one outbound path from the site fails and the border routers 1067 rewrite source locators then the peer will see packets with the 1068 working source locators. Once that locator has been verified by the 1069 peer, the return path will switch to use the working locator. As 1070 long as both ends are transmitting packets this will relatively 1071 quickly switch to working locators except when both hosts experience 1072 a failing locator at the same time. 1074 Without locator rewriting, it would be beneficial to add some 1075 notification e.g., by defining a new bit in the router advertisement 1076 prefixes to indicate that the prefix is problematic to use for due to 1077 failures at the site border (IMHO this is semantically different than 1078 the preferred vs. deprecated semantics), but we would also need some 1079 mechanism to carry this information from the border routers to the 1080 routers on each subnet. Perhaps the router renumbering protocol 1081 [RFC2894] could be extended to carry this information. 1083 4.5. Locator Set Changes 1085 Due to events like site renumbering, the set of locators assigned to 1086 a host might change at a slow rate. Since this proposal uses the 1087 locators in the DNS as the credible source for which locators are 1088 assigned, there is some coordination necessary to ensure that before 1089 a host, or the border routers for a site doing rewriting, start using 1090 a new source locator, the peer has been informed about the new 1091 locator. The Update Request message is sufficient to inform the peer 1092 that a new locator should be acceptable as the source of packets from 1093 the host, while DNS verification needs to be involved to make that 1094 locator usable as a destination. 1096 Due to concerns about having packets with unknown, hence potentially 1097 bogus, source locators triggering DNS lookups this proposal instead 1098 uses the DNS TTL in combination with the locator sets in the Update 1099 Request message, as an indication that the set of locators need to be 1100 refreshed. 1102 Each host determines when its own notion of its locators change, and 1103 uses the Update Request message to inform the peer of these changes. 1104 If a locator is removed from the set this will make the peer 1105 immediately stop considering that locator as part of the locator set. 1106 However, if an additional local locator is communicated to the peer 1107 in an Update Request, it can not be added to the verified locator set 1108 at the peer until it has also been seen in the DNS. Thus, when a 1109 host observes that it has a new locator, the host might want to 1110 verify that this locator has been added to the DNS for itself, before 1111 announcing it to the peer in an Update Request message. 1113 When a host receives an Update Request with an additional locator for 1114 the peer and the DNS TTL for the FQDN->Ls lookup has expired, the 1115 peer will redo this DNS lookup to find the, perhaps updated, set of 1116 locators in the DNS. (Presumably failures to redo the lookup 1117 shouldn't have a negative effect.) 1119 TBD: Even if there is no Update Request, should the DNS verification 1120 be redone periodically based on the DNS TTL? If so, what should the 1121 minimum time be to avoid DNS storms for FQDNs which have a very low 1122 TTL? 1124 When the DNS lookup for the peer's FQDN returns a different locator 1125 set than previously, the host will inform the peer of the new Lsr 1126 locator set in an Update Request. However, since this change to 1127 Lsv(peer) doesn't effect which source locators are acceptable in 1128 received packets, it is not time critical to send the Update Request 1129 message. 1131 If a host wants to modify the set of locators from which the peer 1132 accepts packets for the context, the host can send an Update Request 1133 message with a different Lsl(sender). 1135 When a host sees (based on router advertisements [DISCOVERY]) that 1136 one of its locators has become deprecated and it has additional 1137 locators that are still preferred, it is recommended that the host 1138 stop using the deprecated locator(s) as the source locator with the 1139 contexts that have already been established. This ensures that, 1140 should the deprecated locator become invalid, the peers have already 1141 verified other locator(s) for the host. 1143 TBD: Is there is a need to explicitly signal to the peer "this 1144 locator is deprecated - please verify another locator and use that as 1145 Lp(peer)" 1147 4.6. Preventing Premeditated Redirection Attacks 1149 The threats document [M6THREATS] talks of premeditated redirection 1150 attacks, that is, where an attacker claims to be a host before the 1151 real host appears. The absence of an actual IP layer identifier in 1152 this proposal makes that a non-issue; the attacker could only claim 1153 to be host A if the attacker is reachable at one of A's locators. 1154 Thus by definition the attacker would have to be on the path between 1155 the communicating peers and such attackers can already perform 1156 redirection attacks in today's Internet. 1158 5. HANDLING STATE LOSS 1160 The protocol needs to handle two forms of state loss: 1162 - a host loosing the M6 layer state followed by packets arriving 1163 from a peer which hasn't lost the state. This could be due to the 1164 host crashing and rebooting, or due to the M6 layer discarding the 1165 state too early. 1167 - the M6 layer garbage collecting state too early due to not being 1168 aware of what all ULPs do, resulting in the ULP passing down 1169 packets when there is no context state any more. 1171 Part of the first case is the already existing case of a host 1172 crashing and "rebooting" and as a result loosing transport and 1173 application state. In this case there are some added complications 1174 from the M6 layer since a peer will continue to send packets assuming 1175 the context still exists and due to the loss of state on the receiver 1176 it isn't even able to pass the correct packet up to the ULP (e.g., to 1177 be able to get TCP to generate a reset packet) since it doesn't know 1178 what AIDs to use when replacing the locators. 1180 The second case is a bit more subtle and has two facets. Ideally an 1181 implementation shouldn't discard the context state when there is some 1182 ULP that still depends on this state. While this might be possible 1183 for some implementations with a fixed set of applications, it doesn't 1184 appear to be possible for implementations which provide the socket 1185 API; there can be things like user-level "connections" on top of UDP 1186 as well as application layer "session" above TCP which retain the 1187 identifiers from some previous communication and expect to use those 1188 identifiers at a later date. But the M6 layer has no ability to be 1189 aware of this. 1191 Thus an implementation shouldn't discard context state when it knows 1192 it has ULP connection state (which can be checked in e.g., Unix for 1193 TCP), or when there is active communication (UDP packets being sent 1194 to AID(A) recently), but when there is an infrequently communicating 1195 user-level "connection" over UDP or "session" over TCP the context 1196 state might be garbage collected even though it shouldn't. 1198 Knowing whether the ULP depends on the M6 layer state is not 1199 sufficient; even if the ULP doesn't, the peer host might still keep 1200 the context state. Thus the peer might send a packet using the 1201 context at some future time. To the host this looks similar to the 1202 reboot state loss, in the sense that it receives packets from the 1203 peer and has no matching context. The host doesn't know whether this 1204 is due to a legitimate peer which has retained the context state, or 1205 whether it is a DoS attack using random flow labels. However, if the 1206 ULP on the host passes down a packet to transmit it would turn into 1207 the second case. 1209 5.1. State Loss and Packets from the Peer 1211 If B crashes and reboots and A retransmits a packet with flow label, 1212 L3(B), L2(A) then what is needed on B is a packet to L1(B) from L1(A) 1213 passed to the ULP so that the ULP can send an error (such as a TCP 1214 reset). But B has no matching state thus it needs to send an Unknown 1215 Context error back to try to help A discover the state loss. 1217 Another case is when B decides that the context has not been used for 1218 a long time and as a result discards the context state, and then a 1219 packet (perhaps a TCP SYN for a new connection) arrives from the peer 1220 using the context i.e., an M6 packet with a flow label. In this 1221 case, B has no choice but send an Unknown Context error back to A. 1222 (But see Appendix A for a method to remove the need for this error 1223 ever arising.) 1225 However, if A blindly trusts the Unknown Context message and uses it 1226 to restart a context establishment, that is, discarding its current 1227 context state and sending a INIT, then this could be used by 1228 attackers to force extra work, but also it would allow an attacker 1229 that arrives on the path after a context has been established to 1230 destroy the existing context and insert itself as a Man-in-The-Middle 1231 for the new context establishment. 1233 Given that the locators might be rewritten by routers, the main thing 1234 A has to identify the context is the flow label in the packet that 1235 caused the Unknown Context error at B. While this uniquely 1236 identifies the context on host B, it does not do so on A. Thus if A 1237 maintains some number of contexts with different peers, it might not 1238 be able to uniquely tell to which context the Unknown Context error 1239 should be applied. The use of the source address field in the 1240 Unknown Context message should help disambiguate things, but it isn't 1241 clear to what extent this helps. This ambiguity is an opportunity 1242 that an attacker can take advantage of. The introduction of the 1243 birthday counter (an idea from [HIP]), with a relatively small window 1244 (e.g., 900) of acceptable birthday counter values can substantially 1245 reduce the probability of off-path attackers being able to use the 1246 Unknown Context error to kill a context by sending bogus Unknown 1247 Context errors. 1249 If we in addition introduce the close exchange, as suggested in 1250 Appendix A, we also remove most of the ability of an attacker to 1251 cause extra work by having a host respond to packets with random flow 1252 labels with Unknown Context errors. This combination of the birthday 1253 counter and the CLOSE/CLOSEACK messages, means that the Unknown 1254 Context error only needs to be when packets with an unknown flow 1255 label are received during the first X minutes after the reboot. 1257 5.2. State Loss and Packets from the ULP 1259 If host B only lost (for instance, by garbage collecting too early) 1260 the M6 context state, things are a bit more complicated for packets 1261 passed down from the ULP. Without any context state the M6 layer on 1262 B can not determine whether packets to AID(A) coming from the ULP are 1263 destinated to a standard IPv6 host, or to a host which supports 1264 multihoming. At a minimum the host needs to try to determine this, 1265 and if it somehow determines that the peer supports multihoming, then 1266 it should try to determine the peer's locators and reestablish a 1267 host-pair context. 1269 B can determine whether A is M6 capable by doing a reverse lookup of 1270 AID(A)->FQDN(A) followed by a FQDN(A) lookup to see of there is an M6 1271 record (and get the locator set of A as well). Or, if DNS reverse 1272 lookups are undesirable or do not work, perhaps a packet could be 1273 exchanged with A to ask it whether it supports multihoming. Simply 1274 sending an INIT message to the AID(A) will not only tell it whether A 1275 supports multihoming, but also let B know the flow label and Lsl(A) 1276 locators to use. But as this protocol is currently specified, using 1277 a new ICMP type, an INIT message sent to a host which doesn't support 1278 multihoming will be silently dropped. TBD: Would it make sense to 1279 instead use a new payload type for the M6 messages to at least 1280 receive an ICMP payload type unknow error from hosts which do not 1281 support multihoming? 1283 If B is communicating with both standard IPv6 hosts and hosts which 1284 support multihoming, then for performance reasons it should avoid 1285 doing these DNS lookups or peer queries for every packet sent to a 1286 standard IPv6 host. Implementation tricks (such as "has this socket 1287 ever used M6" flag at the socket layer, "negative caching" of peers 1288 that do not support M6) can be useful to avoid performance overhead, 1289 and caching of the peers that do support M6 can all be used to 1290 address this performance concern. 1292 If, as part of this, B determines that A is M6 capable, it has the 1293 same information as the initiator during the initial context 1294 establishment thus it can follow that procedure starting by sending 1295 an INIT message. If A didn't garbage collect its end of the state 1296 this will result in receiving a CONF message from A which includes 1297 the flow label etc. 1299 6. ENCODING BITS IN THE IPv6 HEADER? 1301 The idea is to pick extra IP protocol values for common combinations, 1302 and have a designated protocol value to capture the uncommon IP 1303 protocols which might use M6. The uncommon IP protocol values would 1304 require an additional extension header when used over M6. 1306 We pick two unused ranges of IP protocol values with 8 numbers each 1307 (assuming we will not need more than 7 common transport protocols). 1308 The ranges start at P1 and P2, respectively: 1309 P1 TCP over M6 - rewrite ok 1310 P1+1 UDP over M6 - rewrite ok 1311 P1+2 SCTP over M6 - rewrite ok 1312 P1+3 RDDP over M6 - rewrite ok 1313 P1+4 ESP over M6 - rewrite ok 1314 (...) 1315 P1+7 escape - any protocol over M6 - rewrite ok 1316 In this case we spend another 8 bytes (minimum IPv6 1317 extension header size due to alignment rule) to carry the 1318 actual IP protocol. This causes some mtu concerns for those 1319 protocols, but they aren't very likely to be used with M6? 1321 P2 TCP over M6 - no rewrite 1322 P2+1 UDP over M6 - no rewrite 1323 P2+2 SCTP over M6 - no rewrite 1324 P2+3 RDDP over M6 - no rewrite 1325 P2+4 ESP over M6 - no rewrite 1326 (...) 1327 P2+7 escape - any protocol over M6 - no rewrite 1328 In this case we spend another 8 bytes (minimum IPv6 1329 extension header size due to alignment rule) to carry the 1330 actual IP protocol. This causes some mtu concerns for those 1331 protocols, but they aren't very likely to be used with M6? 1333 Thus a router would check if the protocol is in the P1 range and if 1334 so, it can rewrite the locator(s). A host would check a received 1335 packet against both P1 and P2 ranges and if so pass it to the M6 shim 1336 layer. 1338 Some possible alternatives to the above encoding: 1340 - use some combination of the universal/local and group bit in the 1341 interface id of the source address field to indicate "rewrite ok". 1343 - always have a M6 shim header - adds 8 bytes overhead per packet. 1345 7. PROTOCOL PROCESSING 1347 A more detail description of the protocol is presented in this 1348 section. 1350 7.1. State Machine 1352 The protocol can be described using the following states: 1354 o IDLE: no state for the context at all. 1356 o INIT-SENT: an INIT message has been sent. 1358 o CCR-SENT: a CCR message has been sent. 1360 o ESTABLISHED: a CCR or CONF message has been received thus the 1361 context is fully established with data packets being carried using 1362 the flow labels and Section 6 encoding. 1364 o UR-SENT: Established but awaiting an Update Acknowledgement. 1366 7.2. Sending INIT messages 1368 When a host needs a host-pair context it first checks if there 1369 already is a context which matches the pair of AIDs. If not, it will 1370 establish such a context by sending an INIT message. The sender of 1371 the INIT message is a called the "initiator" and the peer is called 1372 the "responder" even if this terminology is inexact when both ends 1373 send INIT messages at about the same time. 1375 The initiator must verify that the AIDs are part of the locator sets; 1376 if this is not the case it is most likely due to some local confusion 1377 on the initiator since the AIDs were selected (see Section 4.1) from 1378 the locator sets. 1380 If the initiator knows that it doesn't have a FQDN or that a 1381 verification using forward and reverse lookups would fail, for 1382 instance due to the reverse tree not being populated, it might as 1383 well only include the AID in Lsl(initiator) since this saves the 1384 responder the effort to try to verify things in the DNS. 1386 The initiator creates a proto-context state and allocates a unique 1387 flow label; F(local). 1389 Then it picks a random [RANDOM] nonce to include in the INIT message, 1390 sends the INIT message, and sets the state to INIT-SENT. 1392 The first INIT message is sent to the destination locator which is 1393 the AID. Should the INIT message be retransmitted, a different 1394 destination locator should be used. The INIT messages, as all other 1395 M6 control messages, can be sent with the "rewrite ok" bit set. If 1396 the routers do not rewrite the source locators it might be necessary 1397 for the initiator to try different source locators as well as 1398 destination locators as it is retransmitting the INIT message. 1400 7.3. Receiving INIT messages 1402 When a host receives an INIT message it first checks whether it has 1403 an existing context for the AID pair. 1405 If such a context is found, the following additional checks are 1406 applied: 1408 o The state is INIT-SENT or ESTABLISHED 1410 o The IP source address field in the INIT contains a locator which 1411 is part of Lsl(peer) 1413 o The IP destination address field in the INIT contains a locator 1414 which is part of Lsl(host) 1416 If any of the above checks fail the INIT message is silently dropped. 1417 If all the checks succeed, the host can update the existing context 1418 from the INIT message (the peer's birthday counter, locator set, and 1419 flow label) and respond with a CONF message. The CONF message should 1420 include the nonce from the INIT message, the local flow label, the 1421 local birthday counter, Lsr(peer) and Lsl(responder) from the 1422 existing context. If the INIT message matching an existing context 1423 has piggybacked a ULP packet, this packet is passed to the ULP. 1425 In there is no state matching the AID pair, the host verifies that 1426 the AID(responder) is in fact one of its locators. Should this fail 1427 the INIT message is silently dropped. 1429 Then the responder forms a CC message using a per-host key and a 1430 timestamp or serial number to produce a keyed hash to protect the 1431 state information carried in the CC message and returned in the CCR 1432 message. 1434 If the responder knows that it doesn't have a FQDN or that a 1435 verification using forward and reverse lookups would fail, for 1436 instance due to the reverse tree not being populated, it might as 1437 well only include the AID in Lsl(responder) in the CC message since 1438 this might save the initiator the effort to try to verify things in 1439 the DNS. 1441 If the INIT packet has a piggybacked ULP packet, that is, the nexthdr 1442 value is something different than NONXTHDR, this packet can 1443 potentially be passed to the ULP. It is safe to pass it to the ULP 1444 when the source and destination address fields in the INIT packet are 1445 the AIDs, and it is also safe to accept such packets when the 1446 destination address field contain a locator different than the AID. 1447 But if either the INIT packet was sent with a different source 1448 locator or the source locator was rewritten in transit, it is not 1449 safe to pass the piggybacked packet to the ULP. (This is because 1450 until the context state is created, any "response" packet from the 1451 ULP would be sent as a regular IPv6 packet to the peer AID. The need 1452 to prevent reflection attacks which can bypass any deployed ingress 1453 filtering means that we need to avoid this when the INIT packet was 1454 not sourced by the AID.) In this case the responder sets the "ULP 1455 packet discarded" bit in the CC message. 1457 7.4. Receiving CC messages 1459 The host looks for a matching context based on the AID pair. If no 1460 context is found, or if the context is not in state INIT-SENT, or if 1461 the nonce doesn't match what was sent in the INIT, the CC message is 1462 silently dropped. 1464 Otherwise the host records the Lsl(peer) from the CC message, changes 1465 the state to CCR-SENT, and sends a CCR message. The CCR message can 1466 either reuse the nonce used with the INIT message, or a new random 1467 nonce can be selected. 1469 The host forms Ls(peer) as the intersection between Lsr(peer) and 1470 Lsl(peer). If this intersection does not contain AID(peer) it is an 1471 error and the AID is added to the set. 1473 If the CC packet has a piggybacked ULP packet, this packet can 1474 potentially be passed to the ULP. It is clearly safe to pass it to 1475 the ULP when the source and destination address fields in the CC 1476 packet are the AIDs. But it seems to also be safe when the address 1477 field contents fall in the locators sets as known to the initiator. 1478 If this is not the case, then the piggybacked ULP packet is silently 1479 ignored. 1481 7.5. Receiving CCR messages 1483 The timestamp/serial is verified to be recent, and then the 1484 timestamp/serial is used to determine which per-host key was used for 1485 the keyed hash in the CC message. Using this key, the keyed hash is 1486 verified. If it does not verify, or if the timestamp/serial is too 1487 old, the CCR message is silently dropped. 1489 Then the host looks for a matching context based on the AID pair. If 1490 a context is found this could be the second form of concurrent 1491 context establishment. The host performs the following checks: 1493 o The state is INIT-SENT 1495 o The IP source address field in the CCR contains a locator which is 1496 part of Lsl(peer) 1498 o The IP destination address field in the CCR contains a locator 1499 which is part of Lsl(host) 1501 If any of the above checks fail the CCR message is silently dropped. 1503 If the checks all succeed, the host can update the existing context 1504 from the CCR message (the peer's birthday counter, locator set, and 1505 flow label) and respond with a CONF message. If this update results 1506 in Ls(local) or Ls(peer) not including the corresponding AID, this is 1507 an error and the AID is added to the set. 1509 The CONF message should include the nonce from the CCR message, the 1510 local flow label, the local birthday counter, the Lsr(peer), and 1511 Lsl(responder) from the existing context. 1513 If a context is not found, then one is created based on the 1514 information in the CCR message. The host allocates a flow label for 1515 the context. The host MAY perform a reverse plus forward DNS lookup 1516 starting with AID(peer), and if so it includes the resulting 1517 Lsr(initiator) in the CONF message. Otherwise, the CONF message only 1518 contains the nonce, flow label and birthday counter. 1520 If the CCR packet has a piggybacked ULP packet, it will be passed to 1521 the ULP independently of the IP address fields in the CCR message. 1522 This is possible because even if the CCR contains spoofed locators 1523 and/or AIDs, any "response" packet from the ULP will only be sent to 1524 the verified peer locators now that the context state has been 1525 created. 1527 7.6. Receiving CONF messages 1529 The host looks for a matching context based on the AID pair. 1531 If no matching context is found the CONF message is silently 1532 discarded. 1534 If the state is INIT-SENT and the nonce does not match the nonce sent 1535 in the INIT, the CONF message is silently discarded. If the state is 1536 CCR-SENT and the nonce does not match the nonce sent in the CCR, the 1537 CONF message is silently discarded. 1539 In any other state the CONF message is silently discarded. 1541 Then the CONF message is used to record the peer's flow label. If 1542 the CONF message contains the Lsr(initiator) this is used to update 1543 the context. As part of this Ls(initiator) is updated to be the 1544 intersection of Lsr(initiator) and Lsl(initiator). If this 1545 intersection does not contain AID(initiator) this is an error and the 1546 AID is added to the set. 1548 If the CONF message contains the Lsl(responder), which is the case 1549 during bidirectional establishment i.e., the CONF was sent in 1550 response to an INIT message, then this is used to update the context 1551 and Ls(responder) is updated to be the intersection of Lsr(responder) 1552 and the received Lsl(responder). If this intersection does not 1553 contain AID(responder) this is an error and the AID is added to the 1554 set. 1556 Finally the state is changed to be ESTABLISHED. 1558 If the CONF packet has a piggybacked ULP packet, this packet can 1559 potentially be passed to the ULP. It is clearly safe to pass it to 1560 the ULP when the source and destination address fields in the CONF 1561 packet are the AIDs. But it seems to also be safe when the address 1562 field contents fall in the locators sets as known to the initiator. 1563 [Given that the CONF is know to be the result of a INIT/CCR packet, 1564 it can be assumed that the locators fall in the sets?] 1566 If this is not the case, then the piggybacked ULP packet is silently 1567 ignored. 1569 7.7. Sending Update Request messages 1571 When a hosts sees that either its own locator set has changed, or 1572 that the DNS verification (initial, or redone after DNS TTL expiry) 1573 of the peers locators show a reduction in the locator set, the host 1574 should send an Update Request. 1576 The sender of the Update Request should verify that the AIDs are part 1577 of the locator sets as part of sending the Update Request. 1579 The sender picks a random nonce to include in the message, sends the 1580 message to Lp(peer), and sets the state to UR-SENT. 1582 7.8. Receiving Update Request messages 1584 The host looks for a matching context based on the AID pair and the 1585 flow label pair in the Update Request message. 1587 If no context is found, the Update Request is silently dropped. 1589 If a context is found, it is verified that the locators that are in 1590 the IP address fields are part of the Lsl locator sets. If not, the 1591 update request is silently dropped. Then the locators in the Update 1592 Request are used to update the context state. As part of this the 1593 intersections of the local and remote locator sets are maintained. 1594 Should either of the intersections not include the corresponding AID 1595 this is an error and the AID in question is added to the set. 1597 The receipt of a reduced Lsl(sender) should result in immediately no 1598 longer using the removed locators as destination locators for 1599 transmitted packets. The receipt of an increased Lsl(sender) should, 1600 if the remaining DNS TTL for the FQDN has reached zero, trigger a a 1601 DNS verification (forward and reverse lookup) of the new locators. 1602 Should this verification complete successfully, the locator(s) will 1603 be added to the verified set of peer locators hence be valid for 1604 transmitting packets. 1606 The receipt of changes to Lsr(receiver) is less critical since the 1607 peer will accept as source locators any of the locators that are part 1608 of the Lsl(receiver) that was communicated to the peer during context 1609 establishment or in the most recent Update Request. 1611 The host responds to the Update Request by sending an Update 1612 Acknowledgement back to the sender of the request copying the 1613 nonce/timestamp, AIDs and flow labels from the request. 1615 7.9. Receiving Update Acknowledgement messages 1617 The host looks for a matching context based on the AID pair and the 1618 flow label pair in the Update Acknowledgement message. 1620 If no context is found, the Update Acknowledgement is silently 1621 dropped. 1623 If a context is found, it is verified that the context state is in 1624 UR-SENT and that the nonce in the acknowledgement matches the nonce 1625 that was sent in the request. If either of those checks fail, the 1626 message is silently dropped. 1628 Otherwise, the state for the context is changed back to ESTABLISHED. 1630 7.10. Retransmission 1632 The INIT messages are retransmitted by the initiator until a CC or a 1633 CONF message with a matching nonce is received. 1635 The CC messages are not retransmitted; if they are lost the initiator 1636 will retransmit the INIT message. 1638 The CCR messages are retransmitted by the initiator until a CONF 1639 message with a matching nonce is received. 1641 The Update Request messages are retransmitted until an Update 1642 Acknowledgement with a matching nonce is received. 1644 These retransmissions continue with binary exponential backoff until 1645 CONTEXT_IDLE_TIME (suggested 5 or 15 minutes) have passed. The 1646 initial retransmit timer is 4 seconds. It is suggested that some 1647 randomness be applied to the retransmit timer to avoid 1648 synchronization should lots of hosts in a site follow the same 1649 pattern of retransmissions. 1651 7.11. Receiving Data Packets 1653 Received M6 control packets (INIT) etc are dispatched based on the 1654 ICMP code and processed as indicated in the sections above. 1656 Received M6 data packets (as indicated by the payload types in 1657 section 6) are processed as follows: 1659 1. Lookup the context based on the flow label 1661 1a. If no context found, drop the packet and send a Unknown 1662 Context message to the sender. 1664 2. Compare the destination address field with Lsl(local) 1666 2a. If destination is not in Lsl(local), silently drop the 1667 packet. 1669 2b. If destination is Lp(local), no action is needed. 1671 2c. If destination is not Lp(local), should we change 1672 Lp(local) so that the source locator for transmitted 1673 packets is changed? [TBD] 1675 3. Compare the source address field with Lsl(peer), Lsv(peer) 1677 3a. If source is not in Lsl(peer), silently drop the packet. 1679 3b. If source is in Lsl(peer) but not in Lsv(peer), trigger 1680 verifying that locator (and accept the packet). 1682 3b. If source is Lp(peer), no action is needed. 1684 3c. If source is not Lp(peer) and is in Lsv(peer), change 1685 Lp(peer) so that the destination locator for transmitted 1686 packets is changed. 1688 In the cases where the packet wasn't dropped above, the packet is 1689 rewritten to contain the AIDs from the context state and passed to 1690 the ULP. 1692 7.12. Receiving Unknown Context messages 1694 Look for matching contexts (there might be multiple) that have the 1695 same peer flow label as the one in the UC message, and where 1696 Lsl(peer) in the context includes the source address field of the UC 1697 message. 1699 If no such context is found, silently discard the UC message. 1701 If the birthday counter in the UC message is the same as the recorded 1702 birthday counter for the peer, the UC message was due to the context 1703 state being garbage collected without the peer rebooting. 1705 If the birthday counter in the UC message is greater than (using 1706 serial number arithmetic) the recorded birthday counter, but is not 1707 more than MAX_BIRTHDAY_INCR than this number, then the UC message is 1708 assumed to be due to a reboot of the peer. 1710 In both of the above cases the context can be discarded and a new 1711 context be initiated by sending an INIT message. [TBD: discard vs. 1712 update the existing context based on the CC and CONF messages?] 1714 If the birthday counter doesn't match either criteria, then UC 1715 message is silently dropped. 1717 In both above cases of acceptable UC messages it is RECOMMENDED that 1718 the host also verify whether the included packet is consistent with a 1719 packet that the host might have sent recently; for instance that in 1720 the case of UDP, TCP, or SCTP, the port numbers match port numbers 1721 that are currently in use and that the TCP and SCTP sequence numbers 1722 are reasonable for the matched connections. [The utility of these 1723 checks is limited, because for some ULPs such as ICMP echo messages, 1724 the host might not have any way to check things hence it is required 1725 to accept the UC message.] 1727 7.13. DNS Verification and Hosts without a FQDN 1729 A host without a FQDN, or a host which knows that the forward and 1730 reverse DNS information for it is missing or inconsistent, can remove 1731 the need for the peer to detect this by passing a Lsl in INIT and CC 1732 messages which consists of only the AID for the context. When doing 1733 so, the "rewrite ok" bit should not be set for those messages. 1735 This approach is possible even if the host has multiple locators; it 1736 implies that such a host can take advantage of any multihoming of the 1737 peer even though it can't take full advantage of itself being 1738 multihomed. Thus the peer's locators can change for the context, but 1739 the host itself can only use its AID for the context. 1741 When a host verifies the locator relationship it treats the peer's 1742 AID as being implicitly verified by the context establishment 1743 handshake as long as the AID was used as the locator for this 1744 exchange. This is basically relying on the return routability 1745 property for the AID being a locator. Thus is Lsl(peer) contains the 1746 AID as a single member, and that AID is used as the locator during 1747 the context establishment, there is no need to perform any DNS 1748 verification. 1750 Since the host might not itself know that it doesn't have a FQDN or 1751 that the reverse plus forward lookups would fail to verify, the peer 1752 also needs to take this into account in the verification. When an 1753 initiator verifies things using the reverse lookup and it discovers 1754 that the lookup for one or more of the peer's locators fail with a 1755 permanent DNS error, it should exclude those locator(s) from the set. 1756 And if all of them fail, it should still include the peer's AID as 1757 the only member in the peer's locator set. 1759 When a responder tries to verify the peer by performing DNS lookups 1760 (reverse and forward), if it fails to perform a reverse lookup on the 1761 peer AID due to a permanent DNS error, which is needed to find the 1762 FQDN, then it will assume that the peer has no FQDN. In this case 1763 the Lsr(peer) will contain only the AID(peer) i.e., the peer's 1764 locator can not change. However, it will still accept data packets 1765 with any of the Lsl(peer) locators in the source address fields; it 1766 will not send packets to any locator but the AID. 1768 If the reverse lookup of the peer's AID fails with a transient DNS 1769 error, it is recommended that the DNS lookup is redone (using binary 1770 exponential backoff until it either succeeds or fails with a 1771 permanent error). 1773 If the DNS lookups fail with a permanent error it is recommended that 1774 the locator set with the failed locators removed is signaled to be 1775 the peer as Lsr(peer) in an Update Request message. 1777 This will make the peer stop using those locators as source locators 1778 even though the host sending the Update Request will continue to 1779 accept packets from any of the locators in Lsl(peer). 1781 The initiator starts off with Lsr(responder) being based on what the 1782 forward DNS lookup returned. As successful reverse lookups, that is 1783 reverse lookups that point at the same FQDN, are completed on these 1784 locators, the locators are added to Lsv(responder) i.e. become 1785 candidate destination locators. The initial Lsv(responder) is the 1786 AID even without a reverse lookup. But should the INIT message be 1787 (re)transmitted to different destination locators, the AID will not 1788 be considered verified unless there has been a successful reverse 1789 lookup. 1791 The responder starts off with Lsv(initiator) containing only the AID, 1792 if and only if the AID was used as a locator during the context 1793 establishment. If the AID was not used as a locator during the 1794 establishment, the Lsv(initiator) will initially be empty. This 1795 implies that data packets can not be sent until at least one locator 1796 has been verified using the DNS. [TBD: Is this too strict? Can we 1797 allow the locator that was used during establishment to be in Lsv 1798 even though it is not the AID?] 1799 When the host receives messages (CC, CONF, Update Request) which 1800 shrinks Lsl(peer), it will remove the deleted locators from Ls(peer) 1801 and as a result from Lsv(peer) as well. 1803 TBD: Need to know whether there is a strict definition of temporary 1804 vs. permanent DNS errors. Things like NXDOMAIN should be a permanent 1805 error. 1807 7.14. Birthday Counter 1809 Each host needs to maintain a birthday counter in stable storage to 1810 help with safe resynchronization when one of the ends have lost its 1811 state. 1813 When a host is first initialized it allocates a random initial value 1814 for the birthday counter [RANDOM]. Each time the host looses all 1815 state, that is, crashes or powers off and reboots, it increments the 1816 birthday counter by one and saves the result in stable storage. 1818 The protocol needs a constant, MAX_BIRTHDAY_INCR, which should be 1819 chosen so that during the lifetime of a context after the peer has 1820 stopped sending (Appendix A uses X minutes for this), no host should 1821 reboot and increment its birthday counter more than this number of 1822 times. 1824 It might be reasonable to assume that no host can reboot more 1825 frequently than once a second. This implies that if the context is 1826 discarded 15 minutes after the last packet was received, the peer 1827 could have rebooted at most 900 times after it sent the last packet 1828 using the context. As a result the probability of an off-path 1829 attacker hitting this window of 900 in a 32-bit birthday counter is 1830 about 1 in a million. A 64-bit birthday counter might be overkill. 1832 8. COMPATIBILITY WITH STANDARD IPv6 1834 A host can easily implement M6 in a way that interoperates with 1835 current IPv6 as follows. 1837 When the DNS lookup routines do not find an M6 record for the peer 1838 they will return the AAAA resource record set to the application; 1839 those would be the IPv6 addresses. When the ULP passes down these 1840 addresses, the M6 layer will not have any state generated by the DNS 1841 lookup code, thus no M6 processing will take place on the sender. 1842 (Note that this relates to the M6 layer state recovery in section 1843 5.2) 1844 The receive side handles both standard IPv6 and M6 since it 1845 demultiplexes on whether a packet is an M6 packet, that is, based on 1846 the payload types in Section 6. 1848 9. APPLICATION USAGE OF IDENTIFIERS 1850 The upper level protocols will operate on AIDs which are mere 1851 locators. Thus as long as a site hasn't renumbered, the AID can be 1852 used to either send packets to the host, or (e.g. if that locator 1853 isn't working) it is possible for an application to do a reverse 1854 lookup plus forward lookup of the AID to get the set of locators for 1855 the peer. 1857 Once a site has been renumbered, the AIDs which contain the old 1858 prefix will no longer be useful. Hence applications must try to 1859 honor the DNS TTL somehow. But this is a renumbering issue and not 1860 an effect of the multihoming support. 1862 Applications, which map the peer's IP address to a domain name, today 1863 perform a reverse lookup in the DNS (e.g., using the getnameinfo() 1864 API). This proposal doesn't add or subtract to the benefits of 1865 performing such reverse lookups. 1867 Applications which today either retain a peer's IPv6 address for 1868 future use, such as connecting back to that peer ("callbacks"), or 1869 pass a peer's IPv6 address to a third party ("referrals") will not 1870 break with this multihoming support; they will end up retaining 1871 and/or passing the AID instead of an IPv6 address. Since the AID is 1872 a locator things will still work as long as that locator is 1873 reachable. 1875 However, the AID doesn't contain information whether the host is M6 1876 capable, thus the callbacks and referrals would use IPv6 without 1877 multihoming support unless something special is done. To be able to 1878 take advantage of the multihoming support the application or host 1879 would need to detect whether the AID is M6 capable, for instance, by 1880 doing a reverse lookup on the AID to get the FQDN and the a forward 1881 lookup on the FQDN to look for the "M6 capable" DNS RR. An 1882 alternative would be to use the suggestion in Section 5.2 to send an 1883 INIT message to the peer to discover if it is M6 capable. 1885 Also, should the locator which is the AID not be reachable, the 1886 application/host will fail to communicate with the peer. A reverse 1887 plus forward lookup of the AID, or the INIT suggestion, can be 1888 performed to discover all the locators. 1890 Whether these lookups can be hidden from the application, or whether 1891 the applications need to be modified to make the callbacks and 1892 referrals take full advantage of the multihoming is for further 1893 study. 1895 10. CHECKSUM ISSUES 1897 The IPv6 header does not have a checksum field; the IPv6 address 1898 fields are assumed to be protected by the ULP pseudo-header checksum. 1899 The general approach of an M6 shim which replaces locators with 1900 identifiers (where only the identifiers are covered by the ULP 1901 checksum) raises the potential issue of robustly handling bit errors 1902 in the address fields. 1904 With the definition of the M6 shim there can be undetectable bit 1905 errors in the flow label field or the nexthdr field which might 1906 adversely affect the operation of the protocol. And since the AIDs 1907 are what's covered by the ULP's pseudo-header checksum the locators 1908 in the address fields are without checksum protection. An undetected 1909 bit error in the source locator would look like an unverified source 1910 locator to the receiver. In this proposal such packets are silently 1911 ignored. 1913 Except for the obscure case when Ls(A) contains multiple locators, 1914 one or more of those are not working, and the bit error causes L1(A) 1915 to be replaced by L2(A). That would make the return traffic go to 1916 L2(A), but that might be a non-functioning locator. In this case the 1917 mistake will be corrected when a subsequent packet is received from 1918 A. 1920 An undetected bit error in the destination address field is also 1921 harmless; it might cause misdelivery of the packet to a host which 1922 has no context but when the peer receives any resulting Unknown 1923 Context error message, it will not contain a source locator which is 1924 in the peer's locator set, hence it will be silently ignored. 1926 An undetected bit error in the IPv6 next header field can potentially 1927 make a M6 packet appear as a non-M6 packet and vice versa. This 1928 isn't any different than undetected bit errors in IPv6 next header 1929 field without multihoming support. 1931 An undetected bit error in the flow label in a data message could 1932 have two possible effects: not finding any context state, or finding 1933 the incorrect context state. In the first case any Unknown Context 1934 error message would be dropped by the peer since the flow label 1935 included in the error message doesn't match the flow label that was 1936 originally sent. In the second case this will result in a packet 1937 with incorrect identifiers being delivered to the ULP which most like 1938 will drop it due to ULP checksums not matching. 1940 11. IMPLICATIONS FOR PACKET FILTERING 1942 Ingress filtering should be replaced by locator rewriting when the 1943 "rewrite ok" bit is set. 1945 Locator rewriting (when the bit is set) can be applied at places 1946 where ingress filtering isn't currently performed (e.g., due to 1947 multihoming issues). 1949 Firewall filtering potentially require modifications to be aware of 1950 M6. All the packets contain locators thus a stateful firewall would 1951 need to be aware of the context state to let the correct packets 1952 through as locators might change during some 1953 communication/connections. Such firewalls could optionally perform 1954 their own verification by issuing DNS lookups the same way as the 1955 endpoint. However, the firewalls probably has to be more careful not 1956 exposing themselves to DoS attacks by doing too much DNS lookups. 1958 12. IPSEC INTERACTIONS 1960 As specified, all of ESP, AH, and key management is layered above the 1961 M6 layer. Thus they benefit from the stable AIDs provided above the 1962 M6 layer. This means the IPsec security associations are unaffected 1963 by switching locators. 1965 The alternative would be to layer M6 above IPsec, but that doesn't 1966 seem to provide any benefits. Since we want to allow routers 1967 performing locator rewriting it wouldn't be possible to take 1968 advantage of for instance AH to protect the integrity of the IP 1969 headers. 1971 A result of layering M6 above IPsec is that the M6 protocol can 1972 potentially be used to redirect IPsec protected traffic as a 1973 selective DoS mechanism. If we somehow could require IPsec for the 1974 M6 protocol packets when the ULP packets between the same hosts use 1975 IPsec, then we could prevent such attacks. 1977 However, due to the richness in IPsec policy, this would be a bit 1978 tricky. If only some protocols or port numbers/selectors are to be 1979 protected by IPsec per a host's IPsec policy, then how would one 1980 determine whether M6 traffic needs to be protected? Should one take 1981 the conservative approach that if any packets between the hosts/AIDs 1982 need to be protected, then the M6 traffic should also be protected? 1984 For this to be useful both communicating hosts would need to make the 1985 same policy decisions, so if we are to take this path there would 1986 need to some standardization in this area. 1988 13. SECURITY CONSIDERATIONS 1990 This analysis is far from complete. Early analysis indicates this 1991 addresses the issues in [M6THREATS]. 1993 Just as in today's Internet hosts on the path can inject bogus 1994 packets; in this proposal they need to extract the flow labels from 1995 the packets in order to do this which wouldn't be hard. Packet 1996 injection from off-path places becomes harder since it requires 1997 guessing the 20 bit flow label together with locators that are in the 1998 locator sets. If ingress filtering is deployed the attacker might 1999 not be able to freely choose the source locator, thus just as in 2000 today's Internet ingress filtering further limits attackers ability 2001 to inject packets with spoofed source addresses. 2003 An attacker can inject bogus Update Request messages by picking 2004 random flow labels and locators, in an attempt to make the 2005 communication break or make it use less locators. Worst case this 2006 can cause the communication to drop down to only using the AIDs and 2007 no other locators. Such an attacker needs to know the AID pair and 2008 guess the flow label pair for the attack to be successful. Guessing 2009 a total of 40 bits of flow labels would be hard for an off-path 2010 attacker. One could make this even harder by, in addition to the 2011 flow labels, have the context establishment exchange some larger 2012 random numbers between the peers, and using those numbers to compute 2013 a HMAC on the Update Request. This would still be subject to Man- 2014 in-The-Middle attacks for on-path attackers, but it would make it a 2015 lot harder for off-path attackers to hit something with random 2016 packets. 2018 An attacker can inject bogus Unknown Context messages. The 2019 protection against this is a locator and flow label match as well as 2020 hitting the relatively small window of acceptable Birthday Counters. 2021 In addition, the receiver will reject Unknown Context messages if the 2022 included payload packet was not a packet that it might have recently 2023 sent. 2025 DNS verification implications TBD. 2027 14. PRIVACY CONSIDERATIONS 2029 The existence of mappings in the DNS from any locator to a FQDN and 2030 from the FQDN to all the locators of a host can potentially make it 2031 harder than in today's Internet for a host that is part of a 2032 multihomed site to be anonymous. 2034 This is especially true if the host wants to take advantage of RFC 2035 3401 temporary addresses, or if the host is moving between different 2036 subnets since the forward and reverse information would need to be 2037 updated. 2039 Thus a host which is in a multihomed site which desires to have 2040 multiple pseudonyms and use the M6 protocol would need to, not only 2041 have multiple locators per prefix (as in RFC 3041), but also have 2042 multiple FQDNs each FQDN corresponding to a separate set of locators. 2044 Note that hosts that communicate with peers that are multihomed are 2045 not required to have a FQDN to take advantage of the multiple 2046 locators of the peer, hence they can retain the same amount of 2047 pseudonyms as with RFC 3041. 2049 15. DESIGN ALTERNATIVES 2051 Several aspects of the protocol can be tweaked while following the 2052 original idea of using a set of locators as an equivalence set and 2053 using the DNS to verify the set membership. 2055 A few to consider are listed in this section. 2057 15.1. Avoid introduction of M6 DNS Resource Record type 2059 It is possible to avoid introducing a new resource record type to 2060 indicate whether a peer is M6 capable. 2062 Instead one of the M6 packets can be used. For instance, a host can 2063 send an INIT message to the peer and if the host receives a response 2064 it knows the peer is M6 capable. 2066 This potentially has some performance implications, hence it would be 2067 desirable to structure the use of the protocol slightly differently. 2068 For instance, if the peer is not M6 capable it is useful if the INIT 2069 message would result in an ICMP error being returned. As currently 2070 specified, with the M6 messages being an informational ICMP type, no 2071 such error message will be returned. Thus it would be better if the 2072 M6 messages were instead defined to be a separate new payload type so 2073 that hosts which do not implement the protocol respond with an ICMPv6 2074 "payload type unknown" error. 2076 If the initiator doesn't know whether the peer supports M6 or not, it 2077 would seem better to not piggyback a ULP packet on the INIT message 2078 but instead send any ULP packet separately. Since this might be 2079 suboptimal when the peer does support M6, it would be useful for the 2080 host to cache which AIDs/FQDNs support M6 so it can use piggybacking 2081 in that case. 2083 And since sending the INIT message over and over to a host which 2084 doesn't support M6, it would also be useful for the host to cache 2085 which AIDs/FQDNs do not support M6 so that it can skip trying an INIT 2086 message when it has already tried once. 2088 15.2. Extension header instead of using flow label 2090 Use an actual extension header for M6 and use a context tag in that 2091 header instead of using the flow label. This would make the packets 2092 8 bytes larger since the minimum extension header size is 8 bytes due 2093 to the alignment rules for extension headers in IPv6. 2095 With an 8 byte extension header one could fit 2097 - 8 bits of next header value 2099 - 16 bits of checksum (over the extension header only) [TBD: is this 2100 useful?] 2102 - 1 bit to indicate that it is a M6 data packets (other M6 packets 2103 would have e.g. a 8 bit message type instead) 2105 - 39 bits of context tag 2107 As a result one would only need to allocate 2 protocol values instead 2108 of the 16 suggested in Section 6: One protocol value for "M6 - 2109 rewrite ok" and one value for "M6 - no rewrite". 2111 The data messages could look like this: 2113 0 1 2 3 2114 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 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Checksum | Nexthdr |0| Context Tag | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Context Tag (continued) | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 M6 control messages could look like: 2123 0 1 2 3 2124 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 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | Checksum | Nexthdr |1| Message Type| 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 15.3. Explicit close exchange 2133 Instead of relying on the Unknown Context error to try to synchronize 2134 when one has garbage collected the context state and the other end 2135 has not, we could define an explicit close exchange. An early 2136 attempt at this is specified in Appendix A. This approach would 2137 remove any DoS concerns related to responding to Unknown Context 2138 errors. 2140 16. OPEN ISSUES 2142 Either we need to specify an upper lifetime of a context after no 2143 packets have been received on the context, or we need to adopt a 2144 close handshake akin to the example in Appendix A. This need arises 2145 because the logic for the birthday counter needs to know how many 2146 times a peer can reboot while the host maintains an old context with 2147 that peer; this number determines the window of allowed birthday 2148 counter values for the Unknown Context error. 2150 Which DNS errors should be treated as temporary vs. permanent? 2152 Does it make sense to establish a larger context tag for each 2153 direction in addition to the flow label, so that Update Request 2154 messages and Close messages can be less subject to random packet 2155 injection? 2157 Is it possible to facilitate transition to M6 using some "M6 proxy" 2158 at site boundaries until all important hosts in a site have been 2159 upgraded to support M6? Would would be the properties of such a 2160 proxy? Would it place any additional requirements on the protocol 2161 itself? 2163 Would destination locator rewriting be a useful way for the routing 2164 system to pass some information to the host? Or is source locator 2165 rewriting sufficient? 2166 Understanding the performance of DNS verification with and without 2167 DNSsec. With DNSsec how many public key signature verifications are 2168 likely to be needed for the reverse lookup of each locator? 2170 How does the use of the last verified source locator as a destination 2171 locator for subsequent return traffic interact with ingress 2172 filtering? It would be nice if the protocol could operate with 2173 uncoordinated ingress filtering between the different exits/ISPs, but 2174 it is unclear whether this is feasible. 2176 16.1. Renumbering Considerations 2178 Need to write down any special coordination needed when a locator is 2179 added to a locator set or when one is removed; this can happen when a 2180 site is renumbered. 2182 16.2. Initiator Confusion vs. "Virtual Hosting" 2184 When A wants to communicate with host B and host X at the same time 2185 there can be some confusion since the DNS could return partially 2186 overlapping locator sets for the two remote hosts. For example, 2188 The lookup of FQDN(B) returns Ls(B) which contains L1(B), L2(B), ... 2189 Ln(B). 2191 The lookup of FQDN(X) returns L1(B), L1(X) 2193 The result is that connections that could be intended to go to B and 2194 to X could both end up with an AID=L1(B), but the multihoming shim 2195 layer would have two separate locator sets associated with L1(B). 2196 Thus at a minimum when the second of the two communications starts 2197 there has to be some way to resolve this conflict. 2199 In Section 4.1 this is resolved by the initiator performing a reverse 2200 lookup on the AID. Thus looking up L1(B) in the ip6.arpa tree in the 2201 above example. That works because it would return FQDN(B) thus X 2202 could be safely declared as being bogus. As a result communication 2203 with X would not be possible. 2205 However, in many (IPv4) hosting setups today multiple domain names 2206 (www.foo.com, www.bar.com) are served by a single IP address. In 2207 this case the reverse lookup can't point back at both names unless 2208 the PTR resource record contains multiple records with different 2209 names. Per [RFC2181] section 10.2 this is allowed but it doesn't 2210 appear to be commonly used. 2212 Can we depend on this little used feature of the PTR usage? If not 2213 it would seems to mean that each locator can only be used with one 2214 FQDN which would be more restrictive than we have with IPv4 today. 2216 17. ACKNOWLEDGEMENTS 2218 The first version of this document was the result of discussions in a 2219 MULTI6 design team but is not the "product" of that design team. The 2220 scribe wishes to acknowledge the contributions of (in alphabetical 2221 order): Iljitsch van Beijnum, Brian Carpenter, Tony Li, Mike O'Dell, 2222 and Pekka Savola. 2224 The idea to allow locator rewriting by routers was first presented by 2225 Mike O'Dell [ODELL96]. The techniques for avoiding state DoS attacks 2226 on the first packet are patterned after [MIPv6]. The idea to use a 2227 set of locators and not inventing a new identifier name space, as 2228 well as using the DNS for verification of the locators, was first 2229 brought up by Tony Li. 2231 Later versions of the document have benefited from the comments of 2232 many participants in the Multi6 WG. 2234 18. REFERENCES 2236 18.1. Normative References 2238 [M6THREATS] Nordmark, E., and T. Li, "Threats relating to IPv6 2239 multihoming solutions", draft-ietf-multi6-multihoming- 2240 threats-00.txt, July 2004. 2242 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 2243 Addressing Architecture", RFC 3513, April 2003. 2245 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 2246 6 (IPv6) Specification", RFC 2461. 2248 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 2249 Recommendations for Security", RFC 1750, December 1994. 2251 18.2. Informative References 2253 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 2254 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 2255 March 2003. 2257 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in 2258 IPv6", RFC 3775, June 2004. 2260 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 2261 draft-aura-mipv6-bu-attacks-01 (work in progress), March 2262 2002. 2264 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. 2265 Nordmark, "Mobile IP version 6 Route Optimization Security 2266 Design Background", draft-nikander-mobileip-v6-ro-sec-02 2267 (work in progress), June 2003. 2269 [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture 2270 for IPv6", draft-odell-8+8-00.txt, October 1996, 2272 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): 2273 AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, 2274 October, 2003. 2276 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 2277 Discovery for IP Version 6 (IPv6)", RFC 2461, December 2278 1998. 2280 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 2281 Protocol". RFC 2401, November 1998. 2283 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 2284 November 1998. 2286 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 2287 RFC 2406, November 1998. 2289 [RFC2181] R. Elz, and R. Bush, "Clarifications to the DNS 2290 Specification", RFC 2181, July 1997. 2292 [RFC3697] J. Rajahalme, A. Conta, B. Carpenter, S. Deering, "IPv6 2293 Flow Label Specification", RFC 3697, March 2004. 2295 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 2296 August 2000. 2298 [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless 2299 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 2301 [HIP] Robert Moskowitz, "Host Identity Protocol", 11-Jun-04, 2302 2304 [WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol 2305 (WIMP)", July 2004, 2307 19. CHANGE LOG 2309 Changes since version -01: 2311 o Made the protocol allow for locator rewriting of all the M6 control 2312 messages. 2314 o Allow for hosts without a FQDN or without a correct forward+reverse 2315 relationship benefit from the peer being multihomed. 2317 o Handle inconsistencies between the DNS and host configuration, e.g. 2318 due to two-faced DNS or DNS-based load balancing, by having the host 2319 tell its peer what it received from the DNS and use the intersection 2320 of the DNS info and the info known by the host itself. 2322 o Removed the probability of DNS inconsistencies resulting in packets 2323 being dropped due to having an unknown source locator; a host informs 2324 its peer which locators should be acceptable as source addresses 2325 while the destination locators continue to be verified in the DNS. 2327 o Changed the context establishment to start with an INIT message from 2328 the Initiator instead of having the establishment be driven by a 2329 message with an unknown flow label arriving at a host. This allows 2330 the Initiator to decide when to establish the context; before the 2331 context is established "regular" packets can be exchanged as long as 2332 the locators used are the AIDs. 2334 o Renamed the messages to have the same names as in WIMP; 2335 INIT/CC/CCR/CONF 2337 o Simplified the uniqueness requirements for the flow label to be 2338 "unique per receiving host" in order to handle dynamic changes 2339 (driven from the DNS) of the set of locators assigned to a host. 2340 Without this change it was impossible to make the flow label plus 2341 locators uniquely identify a context at the receiver when the set of 2342 locators changes over time (e.g., due to renumbering). This limits 2343 each (virtual) host to about 1 Million contexts at any given time. 2344 Removing this limitation would imply carrying a larger context tag in 2345 an extension header, which is a possible tweak to this protocol. 2347 o The simplified uniqueness requirement resulted in needing receiver 2348 instead of sender allocation of the flow label, which in turn 2349 resulted in the initiator sending the first message (the INIT) in the 2350 context establishment exchange. 2352 o Made it possible to allow locator rewriting on the context 2353 establishment messages, while allowing piggybacking of ULP packets. 2355 However, in some cases when locators are being rewritten, ULP packets 2356 can not be piggybacked until the context is established, to avoid 2357 security exposure. 2359 o Added details of how the host-pair context is established when both 2360 ends initiate the setup at the same time. 2362 o Worked out the details for how messages are retransmitted. As a 2363 result, the 4th message in the establishment exchange needs to be 2364 mandatory to ensure that the initiator always knows the correct flow 2365 label to use in transmitted packets. Thus the 3-way context 2366 establishment exchange becomes a 4-way exchange as in [HIP] and 2367 [WIMP], with the ability to piggyback ULP packets on all those 2368 messages. 2370 o As a result of needing a 4-way exchange there is no longer any 2371 benefit in attempting a provisional allocation of a flow label when 2372 receiving the INIT. Hence the responders flow label allocation is 2373 now done when receiving the CCR message. 2375 o Added details about how the host-pair context state could be removed 2376 in a coordinated fashion in Appendix A. 2378 o Added details on state recovery when one end has lost the peer's 2379 host-pair context state, using a birthday counter as in [HIP] 2381 o Added a suggestion on how one can avoid introducing a new M6 DNS 2382 Resource Record type. 2384 o Renamed "flowid" to correctly be "flow label" 2386 APPENDIX A: CONTEXT CLOSE PROTOCOL 2388 This scheme is robust against arbitrary network partitioning and 2389 loss, whether in both directions or in one direction, through the use 2390 of timers plus new CLOSE and CLOSEACK messages. It introduces one 2391 additional state in the state machine: 2393 o CLOSING: about to go away but the state is retained to be able to 2394 reliably inform the peer that the state is being removed. No data 2395 packets can be sent using the context when in closing state, but 2396 otherwise it is the same as ESTABLISHED state. 2398 The underlying observation is that the network doesn't spontaneously 2399 generate packets, thus for a packet to be received it must have been 2400 sent by the peer, and if the host does not send a packet no packet 2401 will be received by the peer. (But packets might be sent and never 2402 received.) 2404 In the basic analysis we assume that the network delay (propagation 2405 and queuing) is zero, that is, a packet is received by the peer 2406 either immediately when sent, or never (in the case of loss). 2408 The mechanism uses a time constant: X minutes. 2410 The mechanism works as follows: 2412 1. When no packet has been received on the context for X minutes 2413 the context transitions to CLOSING state. A CLOSE message is 2414 transmitted to the peer. 2416 When in CLOSING state the host must not send any data packets 2417 using the context. If there is a need to send a data packet a 2418 new context must be created by starting by sending an INIT. 2420 2. When the host receives a CLOSE message it discards the context 2421 state and responds with a CLOSEACK message. (The authenticity 2422 of the CLOSE message can be verified the same way data messages 2423 are verified, that is, the flow label needs to match and the 2424 locators be in the locator sets.) This processing applies 2425 whether or not the state is CLOSING in order to handle CLOSE 2426 messages from both ends crossing in flight. 2428 Once the context state has been discarded any need to send data 2429 packets will trigger establishing a new context, starting with 2430 sending an INIT. 2432 3. A CLOSE message which is received when there is no context state 2433 can not be verified but will result in a CLOSEACK response to 2434 speed up the peer discarding the state in the presence of packet 2435 loss. 2437 4. The CLOSE message is retransmitted until either a CLOSEACK 2438 message is received, or it has been retransmitted for a total of 2439 X minutes. When either occurs the context state is discarded. 2441 5. When a host receives a CLOSEACK message it verifies that it is 2442 in CLOSING state and that the CLOSEACK was in response to the 2443 CLOSE (using e.g., a nonce in the CLOSE message). 2445 It is possible to use stronger verification of the CLOSEACK 2446 based on secrets tied to the context state, but only for the 2447 first CLOSE message since the state is discarded on its 2448 reception. Thus if the CLOSEACK response to the first CLOSE is 2449 lost, the host would need to wait for the full X minutes until 2450 discarding its state. 2452 Due to packet loss the two sides can have different views of when the 2453 last packet might have been sent, but because no received packets in 2454 X minutes causes a state transition, this difference can not be 2455 larger than X. Since the CLOSE messages are retransmitted for X 2456 minutes (during which the peer can not possibly receive any data 2457 packets) the peer will transition to CLOSING and stop sending data 2458 packets before the host will discard its state. Example 2 shows a 2459 case when this happens. 2461 Example 1: working communication in both directions 2463 Time T: A sends a packet to B. While A doesn't know it yet, this is 2464 the last packet A will send using the context. B continues to send 2465 packets to A. 2467 Time T+X: B has not received any packets from A for X seconds. B 2468 marks the context as CLOSING, that is, it will not use the state to 2469 transmit any more. B sends a CLOSE message to A. 2471 Time T+X: A receives a CLOSE message from A. Discards the context 2472 state and responds with a CLOSEACK message. 2474 Time T+X: B receives the CLOSEACK message and discards the context 2475 state. 2477 Example 2: Unidirectional failure; A->B packets are all dropped. 2479 Time T: A sends a packet to B. While A doesn't know it, this is the 2480 last packet B will receive from A. 2482 Time T+1 etc: A sends a packet to B which is lost. 2484 Time T+X: B has not received any packets from A for X seconds. B 2485 marks the context as CLOSING, that is, it will not use the state to 2486 transmit any more. B sends a CLOSE message to A. 2488 Time T+X: A receives a CLOSE message from A. Discards the context 2489 state and responds with a CLOSEACK message. The CLOSEACK message is 2490 lost. 2492 Time T+X+1 etc: B retransmits the CLOSE message. 2494 Time T+X+1 etc: A receives the CLOSE message, has no context state, 2495 and responds with a CLOSEACK message. The CLOSEACK message is lost. 2497 Time T+2X: B stops retransmitting the CLOSE message and discards the 2498 session state. 2500 Example 3: Bidirectional failure; all packets are dropped. 2502 Time T1: A sends a packet to B. While A doesn't know it, this is the 2503 last packet B will receive from A. 2505 Time T2: B sends a packet to A. While B doesn't know it, this is the 2506 last packet A will receive from B. 2508 Time T1+1 etc: A sends a packet to B which is lost. Time T2+1 etc: B 2509 sends a packet to A which is lost. 2511 Time T1+X: B has not received any packets from A for X seconds. B 2512 marks the association as CLOSING, that is, it will not use the state 2513 to transmit any more. B sends a CLOSE message to A. The CLOSE 2514 message is lost. 2516 Time T2+X: A has not received any packets from B for X seconds. A 2517 marks the association as CLOSING, that is, it will not use the state 2518 to transmit any more. A sends a CLOSE message to B. The CLOSE 2519 message is lost. 2521 Time T1+X+1 etc: B retransmits the CLOSE message, which is lost. 2522 Time T2+X+1 etc: A retransmits the CLOSE message, which is lost. 2524 Time T1+2X: B stops retransmitting the CLOSE message and discards the 2525 session state. 2527 Time T2+2X: A stops retransmitting the CLOSE message and discards the 2528 session state. 2530 Since the difference between T1 and T2 can't be more than X, we know 2531 that the session state can not be discarded before the other end has 2532 transitioned to CLOSING. 2534 The above examples generalize to arbitrary packet loss; in no case 2535 will a data packet be received when there is no association state. 2536 Hence data packet that are received and have no matching session 2537 state can be silently dropped; no need to send an Unknown Context 2538 error or an INIT message. 2540 Intuitively it seems like network delays can be handled to make the 2541 period for the retransmission of the CLOSE message be X+MSL (Maximum 2542 segment lifetime) instead of X, but this needs to be verified. 2544 The introduction of the close mechanism adds some considerations to 2545 the state machine. For instance, if an INIT arrives when in CLOSING 2546 state, the INIT would need to create a separate, new context, which 2547 has different flow labels at both ends. That way the context in 2548 CLOSING state is allowed to expire based on timeout or receiving a 2549 Close Acknowledgement message, in parallel with the new context being 2550 created. 2552 This means that there might be more than one context for the same AID 2553 pair. This has the following implications: 2555 o When handling packets passed down from the ULP, the M6 layer 2556 should not match any contexts in CLOSING state, but instead behave 2557 as if there was no context even when there is a context in CLOSING 2558 state. [TBD: It might be useful to copy certain information from 2559 the context in CLOSING state to the new context.] 2561 o The context establishment packets (INIT, CC, CCR, and CONF) should 2562 also ignore any context in CLOSING state. 2564 o Data packets received from the wire identify which context to use 2565 with the flow label field. 2567 o M6 control packets that are sent after the context is established 2568 needs to be able to indicate which of possibly multiple contexts 2569 are intended. As a result, the Update Request, Update 2570 Acknowledgement, Close and Close Acknowledgement messages carry 2571 both flow labels which are used to identify the state. 2573 AUTHORS' ADDRESSES 2575 Erik Nordmark 2576 Sun Microsystems, Inc. 2577 17 Network Circle 2578 Mountain View, CA 2579 USA 2581 phone: +1 650 786 2921 2582 fax: +1 650 786 5896 2583 email: erik.nordmark@sun.com 2585 Intellectual Property Statement 2587 The IETF takes no position regarding the validity or scope of any 2588 Intellectual Property Rights or other rights that might be claimed to 2589 pertain to the implementation or use of the technology described in 2590 this document or the extent to which any license under such rights 2591 might or might not be available; nor does it represent that it has 2592 made any independent effort to identify any such rights. Information 2593 on the procedures with respect to rights in RFC documents can be 2594 found in BCP 78 and BCP 79. 2596 Copies of IPR disclosures made to the IETF Secretariat and any 2597 assurances of licenses to be made available, or the result of an 2598 attempt made to obtain a general license or permission for the use of 2599 such proprietary rights by implementors or users of this 2600 specification can be obtained from the IETF on-line IPR repository at 2601 http://www.ietf.org/ipr. 2603 The IETF invites any interested party to bring to its attention any 2604 copyrights, patents or patent applications, or other proprietary 2605 rights that may cover technology that may be required to implement 2606 this standard. Please address the information to the IETF at 2607 ietf-ipr@ietf.org. 2609 Disclaimer of Validity 2611 This document and the information contained herein are provided on an 2612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2614 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2615 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2616 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2619 Copyright Statement 2621 Copyright (C) The Internet Society (2004). This document is subject 2622 to the rights, licenses and restrictions contained in BCP 78, and 2623 except as set forth therein, the authors retain all their rights. 2625 Acknowledgment 2627 Funding for the RFC Editor function is currently provided by the 2628 Internet Society.