idnits 2.17.1 draft-nordmark-multi6-cb64-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 3 characters in excess of 72. == There are 2 instances 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 503: '... Receivers MUST silently ignore? Reject? [TBD] any message code...' 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 332, but not defined == Missing Reference: 'IANA' is mentioned on line 473, but not defined == Missing Reference: 'TBD' is mentioned on line 503, but not defined == Unused Reference: 'ADDR-ARCH' is defined on line 1297, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1300, but no explicit reference was found in the text == Unused Reference: 'AURA02' is defined on line 1313, but no explicit reference was found in the text == Unused Reference: 'NIKANDER03' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 1343, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 1346, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 1349, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-threats-00 ** Downref: Normative reference to an Informational draft: draft-nordmark-multi6-threats (ref. 'M6SEC') -- Possible downref: Non-RFC (?) normative reference: ref. 'CBID' ** Obsolete normative reference: RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (ref. 'IPv6') (Obsoleted by RFC 4861) == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 -- No information found for draft-nikander-mobileip-v6-ro-sec - is the name correct? -- No information found for draft-odell-8 - is the name correct? -- No information found for draft-crocker-mast-protocol - is the name correct? -- No information found for draft-van-beijnum-multi6-cryptoid - is the name correct? == Outdated reference: A later version (-01) exists of draft-nordmark-multi6-sim-00 == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-noid-00 -- 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) Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 Oct 27, 2003 Sun Microsystems 5 Multihoming using 64-bit Crypto-based IDs 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as `"work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet Draft expires April 27, 2004. 32 Abstract 34 This document outlines a potential solution to IPv6 multihoming in 35 order to stimulate discussion. This proposal is a middle ground 36 between the NOID and CB128 proposals. 38 This proposed solution relies on verification the crypto-based 39 identifier properties (using public-key crypto during uncommon 40 operations), while allowing locator rewriting by (border) routers, 41 with no per-packet overhead. The solution does have something which 42 could be viewed as a "stack name" type of identifier, but this isn't 43 exposed to upper layer protocols. Instead it ensures that all upper 44 layer protocols can operate unmodified in a multihomed setting while 45 still seeing a stable IPv6 address, even though the address 46 internally consists of 64-bits worth of subnet locator plus 64-bits 47 of crypto-based identifier. 49 This solution (and this draft) is remarkably similar to draft- 50 nordmark-multi6-noid-00.txt; only issues related to prevention of 51 redirection attacks differ. 53 DISCLAIMER: This work has been discussed in a design team. The 54 design team is still exploring multiple approaches and this is an 55 attempt to capture one such approach on paper. Because of this and 56 due to lack of time to review the document one can not say that this 57 is a product of the DT; errors and confusions should be attributed to 58 the scribe and not to the DT. 60 Contents 62 1. INTRODUCTION............................................. 4 63 1.1. Non-Goals........................................... 4 64 1.2. Assumptions......................................... 5 66 2. TERMINOLOGY.............................................. 5 67 2.1. Notational Conventions.............................. 6 69 3. PROTOCOL OVERVIEW........................................ 7 70 3.1. Host-Pair Context................................... 10 71 3.2. Message Formats..................................... 12 73 4. PROTOCOL WALKTHROUGH..................................... 14 74 4.1. Initial Context Establishment....................... 14 75 4.2. Locator Change...................................... 17 76 4.3. Handling Locator Failures........................... 18 77 4.4. Locator Set Changes................................. 18 78 4.5. Preventing Premeditated Redirection Attacks......... 19 80 5. HANDLING STATE LOSS...................................... 20 82 6. ENCODING BITS IN THE IPv6 HEADER?........................ 22 84 7. COMPATIBILITY WITH STANDARD IPv6......................... 23 86 8. APPLICATION USAGE OF IDENTIFIERS......................... 24 88 9. CHECKSUM ISSUES.......................................... 24 90 10. IMPLICATIONS FOR PACKET FILTERING....................... 25 92 11. IPSEC INTERACTIONS...................................... 26 94 12. SECURITY CONSIDERATIONS................................. 26 96 13. DESIGN ALTERNATIVES..................................... 27 98 14. OPEN ISSUES............................................. 28 99 14.1. Initiator Confusion vs. "Virtual Hosting".......... 28 100 14.2. Using larger context tags.......................... 29 102 15. COMPARISON WITH NOID AND CB128.......................... 30 104 16. ACKNOWLEDGEMENTS........................................ 30 106 17. IPR CONSIDERATIONS...................................... 31 107 18. REFERENCES.............................................. 31 108 18.1. Normative References............................... 31 109 18.2. Informative References............................. 31 111 1. INTRODUCTION 113 The goal of the IPv6 multihoming work is to allow a site to take 114 advantage of multiple attachments to the global Internet without 115 having a specific entry for the site visible in the global routing 116 table. Specifically, a solution should allow users to use multiple 117 attachments in parallel, or to switch between these attachment points 118 dynamically in the case of failures, without an impact on the upper 119 layer protocols. 121 This proposed solution uses crypto-based identifiers [CBID] 122 properties to perform enough validation to prevent redirection 123 attacks. 125 The goals for this proposed solution is to: 127 o Have no impact on upper layer protocols in general and on 128 transport protocols in particular. 130 o Address the security threats in [M6SEC]. 132 o Allow routers rewriting the (source) locators as a means of 133 quickly detecting which locator is likely to work for return 134 traffic. 136 o No per-packet overhead. 138 o No extra roundtrip for setup. 140 o Take advantage of multiple locators/addresses for load spreading. 142 1.1. Non-Goals 144 The assumption is that the problem we are trying to solve is site 145 multihoming, with the ability to have the set of site locator 146 prefixes change over time due to site renumbering. Further, we 147 assume that such changes to the set of locator prefixes can be 148 relatively slow and managed; slow enough to allow updates to the DNS 149 to propagate. This proposal does not attempt to solve, perhaps 150 related, problems such as host multihoming or host mobility. 152 This proposal also does not try to provide an IP identifier to the 153 upper layer protocols - even though it uses a 64-bit CBID internally 154 to prevent redirection attacks. An IP identifier name space would be 155 useful to ULPs and applications, especially if the management burden 156 for such a name space was zero and there was an efficient yet secure 157 mechanism to map from identifiers to locators, but exposing such a 158 name space isn't necessary to solve the problem at hand. 160 1.2. Assumptions 162 The main technical assumptions this proposal makes is that using 163 public key signatures during the more uncommon operations would 164 provide acceptable performance. The proposal doesn't require such 165 operations during normal communication; only when a locator changes 166 for a host will it need to be verified before return traffic will be 167 sent to that locator, or when two hosts claim to use the same 168 identifier. 170 Another assumption is that where DNS is already used (normally at the 171 initiating end of communication) it is acceptable to lookup a 172 multihoming capability "flag" in the DNS in addition to the current 173 AAAA lookup (of the addresses/locators). 175 2. TERMINOLOGY 177 upper layer protocol (ULP) 178 - a protocol layer immediately above IP. Examples are 179 transport protocols such as TCP and UDP, control 180 protocols such as ICMP, routing protocols such as 181 OSPF, and internet or lower-layer protocols being 182 "tunneled" over (i.e., encapsulated in) IP such as 183 IPX, AppleTalk, or IP itself. 185 interface - a node's attachment to a link. 187 address - an IP layer name that contains both topological 188 significance and acts as a unique identifier for an 189 interface. 128 bits. 191 locator - an IP layer topological name for an interface or a 192 set of interfaces. 128 bits. The locators are 193 carried in the IP address fields as the packets 194 traverse the network. 196 identifier - an IP layer identifier for an IP layer endpoint 197 (stack name in [NSRG]). In this proposal a 64-bit 198 CBID i.e. a hash of a public key. 200 Application identifier (AID) 201 - an IP locator which has been selected for 202 communication with a peer to be used by the upper 203 layer protocol. 128 bits. This is used for 204 pseudo-header checksum computation and connection 205 identification in the ULP. Different sets of 206 communication to a host (e.g., different 207 connections) might use different AIDs in order to 208 enable load spreading. The AIDs contain a 64-bit 209 CBID in the low-order bits. 211 address field 212 - the source and destination address fields in the 213 IPv6 header. As IPv6 is currently specified this 214 fields carry "addresses". If identifiers and 215 locators are separated these fields will contain 216 locators. 218 FQDN - Fully Qualified Domain Name 220 2.1. Notational Conventions 222 A, B, and C are hosts. X is a potentially malicious host. 224 FQDN(A) is the domain name for A. 226 ID(A) is the 64 bit CBID for A. 228 Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... 229 Ln(A). Each Lk(A) contains ID(A) in the low-order bits. The high- 230 order 64 bits of a locator are sometimes referred to as the "subnet 231 locator". (The protocol doesn't prevent a single host having 232 multiple identities, but that can be viewed multiple entities A, B, 233 etc existing on the same host.) 235 AID(A) is an application ID for A. In this proposal, AID(A) is 236 always one member of Ls(A). 238 3. PROTOCOL OVERVIEW 240 In order to prevent redirection attacks this protocol relies on the 241 ability to verify (using public key crypto as in [CBID]) that the 242 entity requesting redirection indeed holds the private key where the 243 hash of the corresponding public key hashes to the ID itself. 245 DNS is used to lookup an indication of the multihoming capability of 246 a host, in addition to being used to lookup the AAAA records 247 containing the locators. The details of this is TBD but a simple 248 example would be to introduce a new M6 RR type in the DNS which has 249 no RDATA; thus the mere existence of such a record at a FQDN would 250 imply that the host supports the M6 protocol. 252 In essence this proposal is the same as [NOID] except that the CBID 253 property is used instead of DNS for verification. 255 ----------------------- 256 | Transport Protocols | 257 ----------------------- 259 ------ ------- -------------- ------------- 260 | AH | | ESP | | Frag/reass | | Dest opts | 261 ------ ------- -------------- ------------- 263 ----------------- 264 | M6 shim layer | 265 ----------------- 267 ------ 268 | IP | 269 ------ 271 Figure 1: Protocol stack 273 The proposal uses an M6 shim layer between IP and the ULPs as shown 274 in figure 1, in order to provide ULP independence. Conceptually the 275 M6 shim layer behaves as if it is an extension header, which would be 276 ordered immediately after any hop-by-hop options in the packet. 277 However, the amount of data that needs to be carried in an actual M6 278 extension header is close to zero. By using some encoding of the 279 nexthdr value it is possible to carry the common protocols/extension 280 headers without making the packets larger. The nexthdr encodings are 281 discussed later in this document. We refer to packets that use this 282 encoding to indicate to the receiver that M6 processing should be 283 applied as "M6 packets" (analogous to "ESP packets" or "TCP 284 packets"). 286 Layering AH and ESP above the M6 shim means that IPsec can be made to 287 be unaware of locator changes the same way that transport protocols 288 can be unaware. Thus the IPsec security associations remain stable 289 even though the locators are changing. Layering the fragmentation 290 header above the M6 shim makes reassembly robust in the case that 291 there is broken multi-path routing which results in using different 292 paths, hence potentially different source locators, for different 293 fragments. 295 The proposal uses router rewriting of (source) locators as one way to 296 determine which is the preferred (or only working) locator to use for 297 return traffic. But not all packets can have their locators 298 rewritten. In addition to existing IPv6 packets, the packets 299 exchanged before M6 host-pair context state is established at the 300 receiver can not have their locators rewritten. Thus a simple 301 mechanism is needed to indicate to the routers on the path whether or 302 not it is ok to rewrite the locators in the packet. Conceptually 303 this is a single bit in the IPv6 header (we call it the "rewrite ok" 304 bit) but there is no spare bit available. Later in the document we 305 show how we solve this by allocating a range of next header values to 306 denote this semantic bit. 308 Applications and upper layer protocols use AIDs which the M6 layer 309 will map to/from different locators. The M6 layer maintains state, 310 called host-pair context, in order to perform this mapping. The 311 mapping is performed consistently at the sender and the receiver, 312 thus from the perspective of the upper layer protocols packets appear 313 to be sent using AIDs from end to end, even though the packets travel 314 through the network containing locators in the IP address fields, and 315 even though those locators might be rewritten in flight. 317 ---------------------- ---------------------- 318 | Sender A | | Receiver B | 319 | | | | 320 | ULP | | ULP | 321 | | src AID(A) | | ^ | 322 | | dst AID(B) | | | src AID(A) | 323 | v | | | dst AID(B) | 324 | M6 | | M6 | 325 | | src L1(A) | | ^ | 326 | | dst L1(B) | | | src L2(A) | 327 | v | | | dst L1(B) | 328 | IP | | IP | 329 ---------------------- ---------------------- 330 | ^ 331 -- cloud with some routers ------- 332 src L2(A) [Rewritten] 333 dst L1(B) 334 Figure 2: Mapping with router rewriting of locators. 336 The result of this consistent mapping is that there is no impact on 337 the ULPs. In particular, there is no impact on pseudo-header 338 checksums and connection identification. 340 Conceptually one could view this approach as if both AIDs and 341 locators being present in every packet, but with a header compression 342 mechanism applied that removes the need for the AIDs once the state 343 has been established. As we will see below the flowid will be used 344 akin to a "compression tag" i.e., to indicate the correct context to 345 use for decompression. 347 The need for some "compression tag" is because the desire to allow 348 load spreading and handle site renumbering. Without those desires it 349 could have been possible to e.g. designate one fixed locator as the 350 AID for a host and storing that in the DNS. But instead different 351 connections between two hosts are allowed to use different AIDs and 352 on reception of a M6 packet the correct AIDs must be inserted into 353 the IP address fields before passing the packet to the ULP. The 354 flowid serves as a convenient "compression tag" without increasing 355 the packet size, and this usage doesn't conflict with other flowid 356 usage. 358 In addition to the zero overhead data messages, there are six 359 different M6 message types introduced (which could be defined as new 360 ICMPv6 messages). Three types are used to perform a 3-way handshake 361 to create state at both endpoints without creating state on the first 362 received packet (which would introduce a memory consumption DoS 363 attack), 2 are used to do a challenge request/response exchange when 364 a new locator is introduced, and finally a single message type to 365 signal that state has been lost. The six message types are called: 367 o Context request message; first message of the 3-way context 368 establishment. Sent by the responder when a data packet arrives 369 with no context state. An ULP packet can be piggybacked on this 370 message. 372 o Context response message; second message of the 3-way context 373 establishment. Sent in response to a context request. An ULP 374 packet can be piggybacked on this message. 376 o Context confirm message; third message of the 3-way context 377 establishment. Sent in response to a context response. An ULP 378 packet can be piggybacked on this message. 380 o Challenge request message; first message of the 2-way challenge. 382 o Challenge response message; second message of the 2-way challenge. 384 o Unknown context message; error which is sent when no state is 385 found. 387 Similar to MAST [MAST] the 3-way state creation exchange can be 388 performed asynchronously with data packets flowing between the two 389 hosts; until context state has been established at both ends the 390 packets would flow without allowing router rewriting of locators and 391 without the ability for the hosts to switch locators. 393 Once the 3-way state creation exchange has completed there is host- 394 pair context state at both hosts. At that point in time the hosts 395 will use the challenge/response mechanism each time a new and 396 unverified peer locator appears. 398 3.1. Host-Pair Context 400 The host-pair context is established on the initiator of 401 communication based on information learned from the DNS (either by 402 starting with a FQDN or with an IP address -> FQDN lookup). The 403 responder will establish some initial state using the context 404 creation 3-way handshake. Both hosts later update the peer locators 405 based on the source locator in received packets after having verified 406 the new locator using a challenge exchange. 408 The context state contains the following information: 410 - the peer locator which the ULP uses as ID; AID(peer) 411 - the local locator which the ULP uses as ID; AID(local) 413 - the set of peer locators; Ls(peer). Each locator contains the 414 same 64-bit ID. 416 - for each peer locator, a bit whether it has been verified (by 417 performing a challenge/response. TBD: do this even for the 418 original locators that where learned from the DNS?) 420 - the preferred peer locator - used as destination; Lp(peer) 422 - the set of local locators; Ls(local). Each locator contains the 423 same 64-bit ID. 425 - the preferred local locator - used as source; Lp(local) 427 - the flowid used to transmit packets; F(local) 429 - the flowid to expect in receive packets; F(peer) 431 - State about peer locators that are in the process of being 432 verified. 434 This state is accessed differently in the transmit and receive paths. 435 In the transmit path when the ULP passes down a packet the key to the 436 context state is the tuple ; this key must 437 identify at most one state record. In the receive path it is the 438 F(peer) plus the 64-bit peer and local IDs that are used to identify 439 at most one state record. Thus the sender allocated flowid is part 440 of the key for looking up the context state at the receiver. 442 These uniqueness requirements imposed by those lookup keys uniquely 443 identifying one state record means that one can not create multiple 444 records (e.g. with different locator sets) that have the same AID 445 pair, and the peer must pick a flowid so that host-pair contexts 446 which have the same 64-bit ID pair but a different AID pair gets a 447 different F(local). 449 Note that the flowids could be selected to be finer grain than above; 450 for instance having a different flowid for each connection. Doing so 451 requires some efficient data structure organization at the receiver 452 to map multiple F(peer) to the same context. 454 3.2. Message Formats 456 These message formats are largely the same as in [CB128] but the 457 context request, response, and confirm are sent in the opposite 458 direction. 460 The base M6 header is an ICMPv6 header as follows: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type | Code | Checksum | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 ICMPv6 Fields: 472 Type 473 TBD [IANA] 475 Code 476 8-bit field. The type of M6 message. The M6 477 header carries 6 different types of messages: 479 o Context request message; first message of the 480 3-way context establishment. An ULP packet can 481 be piggybacked on this message. 483 o Context response message; second message of the 484 3-way context establishment. An ULP packet can 485 be piggybacked on this message. 487 o Context confirm message; third message of the 488 3-way context establishment. An ULP packet can 489 be piggybacked on this message. 491 o Challenge request message; first message of the 492 2-way challenge. 494 o Challenge response message; second message of 495 the 2-way challenge. 497 o Unknown context message; error which is sent 498 when no context state found. 500 Checksum The ICMPv6 checksum. 502 Future versions of this protocol may define message codes. 503 Receivers MUST silently ignore? Reject? [TBD] any message code 504 they do not recognize. 506 This drafts doesn't contain actual message layout for code 507 specific part. However, the content of these messages is 508 specified below. 510 The Context request message contains: 512 - Sender Nonce 514 - Sender AID 516 - Receiver AID 518 - Sender flowid (20 bits) 520 The Context response message contains: 522 - Receiver Nonce (copied from Sender Nonce in request) 524 - Context state consisting of: the two AIDs, the two flowids, and 525 the initial locators 527 - A timestamp or nonce (for sender's benefit) 529 - A hash over the context state and timestamp (to prevent 530 modification) 532 The Context confirm message contains: 534 - The context state, timestamp/nonce, and hash copied from the 535 context response. 537 The Challenge request message contains: 539 - Sender generated nonce/timestamp 541 - The two AIDs 543 - The 20-bit flowid from the received data message 545 - The source locator from the received data message 547 The Challenge response message contains: 549 - The nonce/timestamp from the challenge request 550 - The 20-bit flowid (from the challenge request) 552 - The above locator 554 - A hash value (H2) which proves that the sender knows the both 555 flowids. This allows the receiver of the response to avoid 556 verifying the PK signature generated by a host which can't be 557 the original peer. 559 - The public key of the sender. 561 - The public key signature of all of the above fields. 563 The Unknown context message contains: 565 - The 20-bit flowid from the triggering packet. 567 4. PROTOCOL WALKTHROUGH 569 4.1. Initial Context Establishment 571 Here is the sequence of events when A starts talking to B: 573 1. A looks up FQDN(B) in the DNS which returns Ls(B) plus "B is 574 M6 capable". The host verifies that all the locators contain 575 the same 64-bit ID. One locator is selected to be returned 576 to the application: AID(B) = L1(B). The others are installed 577 in the M6 layer on the host with AID(B) being the key to find 578 that state. To make sure that the lookup from AID(B) returns 579 a single state record one has to catch the case when an 580 attempt is to create different context state for the same 581 AID; different locators sets. 583 To make sure that the lookup from AID(B) returns a single 584 state record in the M6 layer there has to be a check if there 585 is already a record for that 64-bit ID with a different Ls. 586 One could envision sending a PK challenge to the locators to 587 resolve such a conflict, or doing a reverse lookup of AID(B) 588 to get and verify the FQDN. See section 14.1 for more 589 discussion. 591 2. The ULP creates "connection" state between AID(A)=L1(A) and 592 AID(B) and sends the first packet. L1(A) was picked using 593 regular source address selection mechanisms. 595 3. The M6 layer matches on AID(B) and finds the proto-context 596 state (setup in step #1) with Ls(B). The existence of that 597 state will make the M6 layer send a M6 packet. The M6 layer 598 selects a flowid F(A) consistent with the uniqueness 599 requirements in section 3.1 (which ensure that the receiver 600 will map to the correct AID pair). 602 4. The packet (TCP SYN or whatever) is sent to peer with 603 locators L1(A) to L1(B) i.e., the same as the AIDs. Since B 604 doesn't have any context state yet, A will not set the 605 "rewrite ok" bit in the header. 607 5. Host B receives packet and sees it is a "M6 packet". Passes 608 the packet to the M6 shim layer. The M6 layer tries to match 609 a context state using the flowid and the bottom 64 bits of 610 the address fields. Since this is the first packet in the 611 communication between A and B no such state is found. The M6 612 layer can't create state on the first packet, but since the 613 rewrite bit is not set in the packet it can pass the packet 614 unmodified to the ULP. The ULP sees a packet identified by 615 AID(A), AID(B). 617 The M6 layer initiates a state creation 3-way exchange by 618 forming a context request message. The same technique as in 619 [MIPv6] can be used to securely do this exchange without any 620 local state; use a local key which is never shared with 621 anybody and pass the context state, a timestamp, and the 622 keyed hash of the state+timestamp in the context request 623 packet. When the state, timestamp, and keyed hash value is 624 returned in the context response message, the hash is used to 625 verify that the state hasn't been modified. 627 The 3-way exchange is done asynchronously with ULP packets, 628 but it is possible (assuming the MTU allows) to piggyback ULP 629 packets on this exchange. 631 Should ULP packets be passed down to the M6 layer on B before 632 the context response message has been received there will be 633 no context state and no state installed as a result of a DNS 634 lookup (unlike on A). This will indicate that the ULP 635 message should be passed as-is (not as an M6 message) to the 636 peer. Thus during the 3-way exchange packets can flow in 637 both directions using the original locators=AIDs. (However, 638 this has some interactions with the suggestions in section 639 5.) 641 6. Host A receives the context request message. It verifies 642 that the message is related to something it sent by looking 643 at the locators (should match the AIDs) and the flowid it 644 sent (which is in the state in the context request message). 646 If a ULP packet was piggybacked A will pass that to the ULP. 648 Then A sends a content response which has the same 649 information as the context request plus a nonce/timestamp 650 that A selected. 652 7. Host B receives the context response message. It verifies 653 that the hash of the state is correct using its per-host key. 654 At this point in time it knows that A is at least not just 655 blasting out packets as a DoS - A is also responding to 656 context request messages. Thus B goes ahead and allocates 657 state at this point in time using the state that is in the 658 context response message. 660 The M6 layer selects a flowid F(B) consistent with the 661 uniqueness requirements in section 3.1 (which ensure that the 662 receiver will map to the correct AID pair). At this point in 663 time B has enough information to handle M6 packets from A. 664 It has also the state (F(B) mainly) necessary send data 665 packets to A with "rewrite ok" set. Thus B sends a context 666 confirm message to A which contains A's nonce/timestamp from 667 the context response and F(B). 669 If a ULP packet was piggybacked on the context response B 670 will pass that to the ULP. 672 Note that B doesn't perform a public key challenge/response 673 for the original AIDs since ULPs and applications don't seem 674 assume that level of strength in the peer address/identity. 675 If there will be such applications the applications could 676 perhaps trigger such additional verification. 678 8. Host A receives the context confirm message, verifies the 679 nonce/timestamp, and records F(peer) from the packet. 681 If a ULP packet was piggybacked on the context confirm A will 682 pass that to the ULP. 684 At this point in time A knows that B has context state, thus 685 it can start sending packets with "rewrite ok" set. 687 4.2. Locator Change 689 This is the sequence of events when B receives a packet with a 690 previously unused source locator for A, for instance L2(A). 692 1. Host B receives M6 packet with source L2(A) and destination 693 L1(B). Looks up context state using the flowid and the 694 bottom 64-bits of the locators. If this lookup succeeds then 695 the locator is acceptable for incoming packets (even though 696 it might not have been verified for use as return traffic) 697 and the packet is rewritten to contain the AIDs from the 698 context state and passed to the ULP. 700 If the source locator is in Ls(peer) and already verified 701 then the preferred return locator (Lp(peer)) is updated to 702 use it for return packets. 704 If the source locator is previously unknown then it is added 705 to the context state as a Ls(peer) awaiting verification and 706 a Challenge Request packet is generated. The challenge 707 request includes a nonce generated by B, F(A) (that was 708 received in the packet from the unknown locator), the 709 identifiers and the previously unknown peer locator. 711 The challenge response needs to complete before using the 712 locator as a destination in order to prevent redirection 713 attacks and 3rd party DoS attacks. 715 2. Host A receives the challenge request packet. Verifies that 716 it has state for those AIDs with the F(A) it received on the 717 request. It computes the hash H2 to show to B that it knows 718 the flowids for both directions by computing 719 H2 = SHA1(nonce from request, F(A), F(B), AID(A), AID(B)) 721 It includes its public key (the one whose hash is ID(A)) and 722 signs the whole challenge response using its private key. 724 3. Host B receives the challenge response packet. It finds the 725 context state using F(A). It verifies the nonce against what 726 it used for sending the challenge request. It verifies H2. 727 (Only devices on the path between A and B during the context 728 establishment knows both F(A) and F(B), thus this check 729 limits DoS attacks based on forcing PK signature verification 730 to attackers on the path.) Then it verifies that the hash of 731 the public key equals ID(A), and finally the public key 732 signature using that public key. 734 4.3. Handling Locator Failures 736 Should not all locators be working when the communication is 737 initiated some extra complexity arises, because the ULP has 738 already been told which AIDs to use. If the locators that where 739 selected to be AIDs are not working it isn't possible to send a 740 zero-overhead initial packet from A to B. Instead both the AIDs 741 and the working locators need to be conveyed. This could be done 742 by either reusing IP-in-IP encapsulating or defining another M6 743 message type which carries both. Details TBD. 745 After context setup the sender can use retransmit hints from the 746 ULP to get the M6 layer to try a different verified locator. 748 If one outbound path from the site fails and the border routers 749 rewrite source locators then the peer in another site will see 750 packets with the working source locators. Once that has locator 751 been verified, the return path will switch to use the working 752 locator. As long as both ends are transmitting packets this will 753 relatively quickly switch to working locators except when both 754 hosts experience a failing locator at the same time. 756 Without locator rewriting one would need to add some notification 757 e.g., by defining a new bit in the router advertisement prefixes 758 (IMHO this is semantically different than the preferred vs. 759 deprecated stuff), but we also need some mechanism to carry this 760 info from the border routers to the routers on each subnet. 762 4.4. Locator Set Changes 764 Should the set of locators change after the context has been 765 established the ability to learn and verify new peer locators will 766 handle this fine. 768 The DNS only needs to be updated with new locators in order to 769 allow new communication to be established. 771 When a host sees (based on router advertisements [DISCOVERY]) that 772 one of its locators has become deprecated and it has additional 773 locators that are still preferred, it is recommended that the host 774 start using the preferred locator(s) with the contexts that have 775 already been established. This ensures that should the deprecated 776 locator become invalid the peers have already verified other 777 locator(s) for the host. 779 4.5. Preventing Premeditated Redirection Attacks 781 The threats document [M6SEC] talks of premeditated redirection 782 attacks that is where an attacker claims to be a host before the 783 real host appears. While an attacker can only use a given AID if 784 it is on the path (so that return packets arrive at the attacker), 785 an attacker can use a 64-bit ID combined with any 64-bit subnet 786 locator. This is of concern since on the receive side the context 787 state is identified by the 64-bit ID pair. 789 Thus this proposal is potentially subject to this threat because 790 for performance reasons there is no public-key challenge when the 791 context state is initially established. 793 The following sequence shows how such a redirection attack is 794 detected when X pretends to be ID(A): 796 1. Host X with creates locator L1(X) using its "own" subnet 797 locator and ID(A) as the bottom 64 bits. X selects F(X) to 798 communicate with B and sends a M6 data message to B. 800 2. The context request, response and confirm messages are 801 exchanged between B and X resulting on B selecting F(B) for 802 communicating with X (which B believes has identifier ID(A)). 804 3. X and B happily communicate without B performing any higher- 805 level, such as IKE/IPsec, identity check on its peer. 807 4. Host A tries to communicate with B. It sends an M6 packet 808 with ID(A) and F(A) to B. 810 5. Host B receives this M6 packet and discovers it already has 811 context state for ID(A). B doesn't do anything different 812 than if there was no context state - the difference in 813 processing happens when the context confirm is received - 814 except that any piggybacked ULP packet is not passed to the 815 ULP. Thus, as in section 4.1, a flowid is selected and the 816 context request is sent, which makes A send back a context 817 response. 819 6. Host B receives the context response and verifies it the same 820 way as in section 4.1. Then it looks if there is already a 821 context for ID(A) and finds the context which contains F(X) 822 and L1(X). 824 The existence of this "old" context could be due to multiple 825 reasons: 827 - The peer lost state while B retained the context state. 828 In this case one would expect that the old context has not 829 been used to receive packets for some time. (Having a 830 protocol constant denoting the minimum time after sending 831 a packet that state can be lost and later recreated would 832 be helpful here.) In this case it would also be common 833 that the source address of the packet would fall in the 834 locator set for the old context. But it isn't impossible 835 that a peer state loss and using a different locator 836 happens at the same time. 838 - The old host was performing a premediated redirection 839 attack. 841 - The new host is attempting a redirection attack. 843 In all cases the approach consists of finishing the state 844 setup by sending a context confirm message to A, and then 845 sending a challenge to both the "new" A and the "old" A. But 846 depending on the time since packets where last received from 847 the "old" A the order can be different. The first peer 848 locator which responds with a valid challenge response will 849 "win" and the other context state will be deleted. 851 TBD: The above has DoS concerns in terms of verifying the 852 challenge response. Having both ends remove the context state at 853 about the same time would be beneficial since it would reduce the 854 frequency of this happening in the absence of attacks, thus it 855 would be more realistic to apply resource limits for this type of 856 challenges. 858 5. HANDLING STATE LOSS 860 The protocol needs to handle two forms of state loss: 862 - a peer loosing all state, 864 - the M6 layer garbage collecting state too early due to not 865 being aware of what all ULPs do. 867 The first case is the already existing case of a host crashing and 868 "rebooting" and as a result loosing transport and application 869 state. In this case there are some added complications from the 870 M6 layer since a peer will continue to send packets assuming the 871 context still exists and due to the loss of state on the receiver 872 it isn't even able to pass the correct packet up to the ULP (e.g., 873 to be able to get TCP to generate a reset packet) since it doesn't 874 know what AIDs to use when replacing the locators. 876 The second case is a bit more subtle. Ideally an implementation 877 shouldn't discard the context state when there is some ULP that 878 still depends on this state. While this might be possible for 879 some implementations with a fixed set of applications, it doesn't 880 appear to be possible for implementations which provide the socket 881 API; there can be things like user-level "connections" on top of 882 UDP as well as application layer "session" above TCP which retain 883 the identifiers from some previous communication and expect to use 884 those identifiers at a later date. But the M6 layer has no 885 ability to be aware of this. 887 Thus an implementation shouldn't discard context state when it 888 knows it has ULP connection state (which can be checked in e.g., 889 Unix for TCP), or when there is active communication (UDP packets 890 being sent to AID(A) recently), but when there is an infrequently 891 communicating user-level "connection" over UDP or "session" over 892 TCP the context state might be garbage collected even though it 893 shouldn't. 895 For instance, if B crashes and rebooted and A retransmits a packet 896 with flowid, L3(B), L2(A) then what is needed is a packet to L1(B) 897 from L1(A) passed to the ULP so that the ULP can send an error 898 (such as a TCP reset). But B has no matching state thus it needs 899 to send an Unknown context error back. (Should the packet not 900 have "rewrite ok" set host B can pass it to the ULP since it knows 901 that such packets contain locators that are AIDs. But once the 902 context has been established the peer is likely to send all 903 packets with "rewrite ok" set.) 905 If host B instead only lost (garbage collected too early) the M6 906 context state things are a bit more complicated for packets passed 907 down from the ULP. Without without any context state the M6 layer 908 on B can not determine whether packets to AID(A) coming from the 909 ULP are destinated to a standard IPv6 host or a host which 910 supports multihoming. B can determine this by performing some 911 packet exchange with A to ask it whether it supports multihoming. 913 If B is communicating with both standard IPv6 hosts and hosts 914 which support multihoming then it has to avoid doing these peer 915 queries for every packet sent to a standard IPv6 host. 916 Implementation tricks (such as "has this socket ever used M6" flag 917 at the socket layer, and "negative caching" of peers that do not 918 support M6) can be useful to avoid performance overhead. 920 Potentially this state recovery can result in A having two 921 contexts for B; one with the old flowid and one with a new flowid. 922 This must be avoided so that packets to B only use the flowid that 923 is known to B. Specifying this is for further study. 925 6. ENCODING BITS IN THE IPv6 HEADER? 927 The idea is to pick extra IP protocol values for common 928 combinations, and have a designated protocol value to capture the 929 uncommon IP protocols which might use M6. The uncommon IP 930 protocol values would require an additional extension header when 931 used over M6. 933 We pick two unused ranges of IP protocol values with 8 numbers 934 each (assuming we will not need more than 7 common transport 935 protocols). The ranges start at P1 and P2, respectively: 936 P1 TCP over M6 - rewrite ok 937 P1+1 UDP over M6 - rewrite ok 938 P1+2 SCTP over M6 - rewrite ok 939 P1+3 RDDP over M6 - rewrite ok 940 P1+4 ESP over M6 - rewrite ok 941 (...) 942 P1+7 escape - any protocol over M6 - rewrite ok 943 In this case we spend another 8 bytes (minimum IPv6 944 extension header size due to alignment rule) to carry the 945 actual IP protocol. This causes some mtu concerns for those 946 protocols, but they aren't very likely to be used with M6? 948 P2 TCP over M6 - no rewrite 949 P2+1 UDP over M6 - no rewrite 950 P2+2 SCTP over M6 - no rewrite 951 P2+3 RDDP over M6 - no rewrite 952 P2+4 ESP over M6 - no rewrite 953 (...) 954 P2+7 escape - any protocol over M6 - no rewrite 955 In this case we spend another 8 bytes (minimum IPv6 956 extension header size due to alignment rule) to carry the 957 actual IP protocol. This causes some mtu concerns for those 958 protocols, but they aren't very likely to be used with M6? 960 Thus a router would check if the protocol is in the P1 range and 961 if so, it can rewrite the locator(s). A host would check a 962 received packet against both P1 and P2 ranges and if so pass it to 963 the M6 shim layer. 965 Some possible alternatives to the above encoding is to: 967 - use some combination of the universal/local and group bit in 968 the interface id of the source address to indicate "rewrite 969 ok". 971 - steal the ECN bits from the traffic class before ECN becomes a 972 proposed standard? Don't think this will be popular! 974 - always have a shim header - adds 8 bytes overhead per packet. 976 7. COMPATIBILITY WITH STANDARD IPv6 978 A host can easily implement M6 in a way that interoperates with 979 current IPv6 as follows. 981 When the DNS lookup routines do not find an M6 record for the peer 982 they will return the AAAA resource record set to the application; 983 those would be the IPv6 addresses. When the ULP passes down these 984 addresses the M6 layer will not have any state generated by the 985 DNS lookup code, thus no M6 processing will take place on the 986 sender. (Note that this relates to the M6 layer state recovery in 987 section 5.) 989 The receive side handles both standard IPv6 and M6 since it 990 demultiplexing on whether a packet is an M6 packet. 992 8. APPLICATION USAGE OF IDENTIFIERS 994 The upper level protocols will operate on AIDs which are mere 995 locators. Thus as long as a site hasn't renumbered the AID can be 996 used to either send packets to the host, or (e.g. if that locator 997 isn't working), it is possible for an application to do a reverse 998 lookup plus forward lookup of the AID to get the set of locators 999 for the peer. 1001 Once a site has been renumbered the AIDs which contain the old 1002 prefix will no longer be useful. Hence applications must try to 1003 honor the DNS TTL somehow. 1005 Applications which use to map the peer's IP address to a domain 1006 name today perform a reverse lookup in the DNS (e.g., using the 1007 getnameinfo() API). This proposal doesn't add or subtract to the 1008 benefits of performing such reverse lookups. 1010 9. CHECKSUM ISSUES 1012 The IPv6 header does not have a checksum field; the IPv6 address 1013 fields are assumed to be protected by the ULP pseudo-header 1014 checksum. The general approach of an M6 shim which replaces 1015 locators with identifiers (where only the identifiers are covered 1016 by the ULP checksum) raises the potential issue of robustly 1017 handling bit errors in the address fields. 1019 With the definition of the M6 shim there can be undetectable bit 1020 errors in the flowid field or the nexthdr field which might 1021 adversely affect the operation of the protocol. And since the 1022 AIDs are what's covered by the ULP's pseudo-header checksum the 1023 locators in the address fields are without checksum protection. 1024 An undetected bit error in the source locator would look like an 1025 unverified source locator to the receiver. Thus the packet would 1026 (after replacing locators with identifiers based on the context) 1027 be passed to the ULP and a challenge response exchange be 1028 triggered. In the case of a bit error in the locator this 1029 challenge isn't likely to receive a response; and if there is a 1030 response by someone it wouldn't be from the actual peer thus the 1031 verification would fail. Thus such an undetected bit error is 1032 harmless. 1034 Except for the obscure case when Ls(A) contains multiple verified 1035 locators, one or more of those are not working, and the bit error 1036 causes L1(A) to be replaced by L2(A). That would make the return 1037 traffic go to L2(A), but that might be a non-functioning locator. 1038 In this case the mistake will be corrected when a subsequent 1039 packet is received from A. 1041 An undetected bit error in the destination address field is also 1042 harmless; it might cause misdelivery of the packet to a host which 1043 has no context but the reception of the resulting Unknown context 1044 error message will show that it arrives from the incorrect locator 1045 thus it will be ignored. 1047 An undetected bit error in the IPv6 next header field can 1048 potentially make a M6 packet appear as a non-M6 packet and vice 1049 versa. This isn't any different than undetected bit errors in 1050 IPv6 next header field without multihoming support. 1052 An undetected bit error in the flowid in a data message could have 1053 two possible effects: not finding any context state, or finding 1054 the incorrect context state. In the first case the Unknown 1055 context error message would be dropped by the peer since the 1056 flowid included in the error message doesn't match the flowid that 1057 was originally sent. In the second case this will result in a 1058 packet with incorrect identifiers being delivered to the ULP which 1059 most like will drop it due to ULP checksums not matching. 1061 10. IMPLICATIONS FOR PACKET FILTERING 1063 Ingress filtering should be replaced by locator rewrite when the 1064 "rewrite ok" bit is set. 1066 Locator rewriting (when the bit is set) can be applied at places 1067 where ingress filtering isn't currently performed (e.g., due to 1068 multihoming issues). 1070 Firewall filtering potentially require modifications to be aware 1071 of M6. All the packets contain locator thus a firewall would need 1072 to be aware of the context state to let the correct packets 1073 through. Such firewalls could optionally perform their own 1074 verification by issuing challenge request messages (the protocol 1075 doesn't explicitly allow for this; they would have to pretend 1076 being the actual endpoint sending the challenge). 1078 11. IPSEC INTERACTIONS 1080 As specified all of ESP, AH, and key management is layered above 1081 the M6 layer. Thus they benefit from the stable identifiers 1082 provided above the M6 layer. This means the IPsec security 1083 associations are unaffected by switching locators. 1085 The alternative would be to layer M6 above IPsec, but that doesn't 1086 seem to provide any benefits. Since we want to allow routers 1087 performing locator rewriting it wouldn't be possible to take 1088 advantage of for instance AH to protect the integrity of the IP 1089 headers. 1091 12. SECURITY CONSIDERATIONS 1093 This analysis is far from complete. Early analysis indicates this 1094 addresses the issues in [M6SEC]. 1096 Just as in today's Internet hosts on the path can inject bogus 1097 packets; in this proposal they need to extract the flowids from 1098 the packets in order to do this which wouldn't be hard. Packet 1099 injection from off-path places becomes harder since it requires 1100 guessing the 20 bit flowid together with the 64-bit ID pair. 1102 Hosts on the path can also launch PK signature verification DoS 1103 attacks against either end since they can observe the flowids from 1104 the establishment and therefor compute the H2 hash in the 1105 challenge response packet. This would force the endpoint to run 1106 the signature verification algorithm which is expensive. If we 1107 don't expect the locator sets to be very dynamic one could 1108 restrict the rate at which such verification takes place, at least 1109 after the first few locators have been verified for a peer. 1111 The initial setup of a host-pair context does not perform any 1112 verification using public key crypto, but this does not seem to 1113 make the result less secure than today's Internet. Applications 1114 which do not perform access control based on it's notion of the 1115 peer wouldn't care about the strength of the peer's identifier. 1116 And applications which perform strict access control hopefully do 1117 this using strong crypto (IPsec, TLS, etc) today and would 1118 continue to do so. That leaves applications which perform the 1119 questionable practise of merely verifying the forward plus reverse 1120 lookups in the DNS and then using the IP address (or resulting 1121 FQDN) for access control discussions. As discussed in section 6 1122 the application's lookup of locator->FQDN->ID and verifying that 1123 the identifier matches provides about the same strength. [TBD are 1124 we really sure?] 1126 The CBIDs are only statistically unique. But 64 bit identifiers 1127 seems large enough to make collisions unlikely enough to keep the 1128 protocol simple. (If not one could envision complications like 1129 making the protocol capable of detecting collisions by storing the 1130 public key in the context state and seeing if a host claims to use 1131 the same ID but has a different public key.) While at about 4 1132 Billion hosts in the Internet there is approximately a 50% 1133 probability that there exists 2 hosts with the same 64-bit 1134 identifier this has no effect on the protocol per see. It is not 1135 until a single host has that order of magnitude of context state 1136 records that it could get confused due to collisions. 1138 13. DESIGN ALTERNATIVES 1140 Use an actual extension header for M6 and use a context tag in 1141 that header instead of using the flowid. This would make the 1142 packets 8 bytes larger since the minimum extension header size is 1143 8 bytes due to the alignment rules for extension headers in IPv6. 1145 Make the flowid allocation be done by the receiver of the flowid 1146 (as is done for the context tags in [CB128]) instead of by the 1147 sender as in this proposal. 1149 It is possible to use these mechanisms together with the 1150 structured 64/80 bit identifiers suggested in [CRYPTOID]. 1152 14. OPEN ISSUES 1154 Some protocol complexity is added by not performing a mutual 1155 public-key challenge immediately when a context is created. At 1156 the expensive of a performance hit one could simplify the protocol 1157 to always to these challenges. 1159 Is it possible to facilitate transition to M6 using some "M6 1160 proxy" at site boundaries until all important hosts in a site have 1161 been upgraded to support M6? Would would be the properties of 1162 such a proxy? Would it place any additional requirements on the 1163 protocol itself? 1165 One of the issues with FQDNs mapping to AAAA records is that in 1166 some cases multiple AAAA records mean a multihomed host and in 1167 other cases it means multiple hosts providing the same service. 1168 If we need to introduce a new RR type for M6, would it be useful 1169 to try to make this host/service distinction more clear at the 1170 same time? An example solution would be that the M6 record would 1171 by its existence indicate the M6 capability, and its RDATA would 1172 contain a list of host names which would be used to resolve the 1173 AAAA records for each host implementing the service. Another 1174 possibility related to this proposal would be to use the fact that 1175 a given host would have the same 64-bit ID in its locators, thus 1176 after retrieving the locators for a FQDN it is possible to group 1177 those into "host sets" by comparing the bottom 64-bits (assuming 1178 the node is M6 capable). This grouping could be performed in 1179 routines like getaddrinfo() transparent to the applications. 1181 Would destination locator rewriting be a useful way for the 1182 routing system to pass some information to the host? Or is source 1183 locator rewriting sufficient? 1185 The mechanisms allow adding locators to a locator set but there is 1186 currently no mechanism for removing a locator (e.g., when a host 1187 renumbers). Does it make sense to add such a mechanism? 1189 The responder only discovers the peer's locators once they are 1190 used as sources in packets. Would it make sense to allow the 1191 initiator to pass a list of its locators to the responder? (They 1192 would still need to be verified before use to prevent 3rd party 1193 DoS attacks [M6SEC]). 1195 14.1. Initiator Confusion vs. "Virtual Hosting" 1197 When A wants to communicate with host B and host X at the same 1198 time there can be some confusion since the DNS could return the 1199 same identifier for B and X while returning different locator 1200 sets. For example, 1202 The lookup of FQDN(B) returns Ls(B) where each locator has a 64- 1203 bit ID(B) 1205 The lookup of FQDN(X) returns Ls(X) where each locator has a 64- 1206 bit ID(B) 1208 The result is that connections that could be intended to go to B 1209 and to X would both end up with different AIDs ID at the ULP, but 1210 the multihoming shim layer would have two separate locator sets 1211 associated with ID(B). Thus at a minimum when the second of the 1212 two communications starts there has to be some way to resolve this 1213 conflict. 1215 If multiple FQDNs map to the same host, which is common in virtual 1216 hosting using IPv4 today, and the locator set is being modified 1217 for that host then this could be quite normal; looking up 1218 www.foo.com would provide the ID of the peer and a perhaps staler 1219 set of locators for the ID than looking up www.bar.com. 1221 Is it reasonable to assume when there is some overlap between 1222 Ls(B) and Ls(X) above that this is a normal condition? Should one 1223 form the intersection of Ls(B) and Ls(X) and use that for the 1224 existing context state? Or at least purge unverified peer 1225 locators, those from which the host hasn't seen a challenge 1226 response, that are not in the intersection from the locator set 1228 Section 4.1 suggests using a challenge request/response exchange 1229 when the second lookup takes place. Should the challenge be 1230 performed with the newer or older locator sets? What are the DoS 1231 issues in performing such a challenge? 1233 14.2. Using larger context tags 1235 The 128-bit identifier proposal [CB128] uses a larger context tag 1236 as part of the context setup than is used in the data packets to 1237 identify the context. This larger context tag is useful to 1238 prevent off-path attackers from launching "verify signature" DoS 1239 attacks; a more inexpensive check can be performed to verify that 1240 the peer knows the full context tag. 1242 That approach could easily be adopted to this proposal as well 1243 with the flowid carrying the low-order 20 bits of e.g. a 64 bit 1244 context tag. Would this be beneficial? 1246 15. COMPARISON WITH NOID AND CB128 1248 This approach represents at some level a middle ground between 1249 [NOID] and [CB128] in that: 1251 - Not using DNS for verification as in [NOID] but using the CBID 1252 property plus public key crypto as in [CB128]. Once DNSsec is 1253 used there are less public key operations to verify using CBID 1254 than for all the delegations in the ip6.arpa tree for a 1255 previously unknown peer locator. 1257 - Like [NOID] there are no extra bytes added to the packets. 1259 - Like [NOID] the AIDs are useful in referrals. 1261 - Uses similar messages as in [CB128] but the context 1262 request/response/confirm is sent in the reverse direction with 1263 the context request being sent by the responder (in [CB128] the 1264 context request is sent by the initiator). 1266 16. ACKNOWLEDGEMENTS 1268 This document is the result of discussions in a MULTI6 design team 1269 but is not the "product" of that design team. The scribe wishes 1270 to acknowledge the contributions of (in alphabetical order): 1271 Iljitsch van Beijnum, Brian Carpenter, Tony Li, Mike O'Dell, and 1272 Pekka Savola. 1274 The idea to allow locator rewriting by routers was first presented 1275 by Mike O'Dell [ODELL96]. The techniques for avoiding state DoS 1276 attacks on the first packet are patterned after [MIPv6]. 1278 17. IPR CONSIDERATIONS 1280 When IP addresses that have a hash of a public key in the low 1281 order 64 bits were discussed in the Mobile IP WG and in the SEND 1282 WG two vendors asserted IPR. It is not known to the author 1283 whether such IPR claims would apply to this specification as well. 1285 18. REFERENCES 1287 18.1. Normative References 1289 [M6SEC] Nordmark, E., and T. Li, "Threats relating to IPv6 1290 multihoming solutions", draft-nordmark-multi6-threats- 1291 00.txt, October 2003. 1293 [CBID] G. Montenegro and C. Castelluccia, "Statistically Unique 1294 and Cryptographically Verifiable Identifiers and 1295 Addresses", ISOC NDSS02, San Diego, February 2002. 1297 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 1298 Addressing Architecture", RFC 3513, April 2003. 1300 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, 1301 Version 6 (IPv6) Specification", RFC 2461. 1303 18.2. Informative References 1305 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from 1306 the NSRG", draft-irtf-nsrg-report-09.txt (work in 1307 progress), March 2003. 1309 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support 1310 in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in 1311 progress), June 2003. 1313 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 1314 draft-aura-mipv6-bu-attacks-01 (work in progress), March 1315 2002. 1317 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and 1318 E. Nordmark, "Mobile IP version 6 Route Optimization 1319 Security Design Background", draft-nikander-mobileip- 1320 v6-ro-sec-01 (work in progress), June 2003. 1322 [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture 1323 for IPv6", draft-odell-8+8-00.txt, October 1996, 1325 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT 1326 (MAST): AN EXTENDED PROPOSAL", draft-crocker-mast- 1327 protocol-01.txt, October, 2003. 1329 [CRYPTOID] I. van Beijnum, "CRYPTO-BASED HOST IDENTIFIERS", 1330 draft-van-beijnum-multi6-cryptoid-00.txt, (unpublished) 1332 [CB128] E. Nordmark, "Strong Identity Multihoming using 128 bit 1333 Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim- 1334 00.txt, October 2003. 1336 [NOID] E. Nordmark, "Multihoming without IP Identifiers", 1337 draft-nordmark-multi6-noid-00.txt, October 2003. 1339 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 1340 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1341 1998. 1343 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 1344 Protocol". RFC 2401, November 1998. 1346 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 1347 November 1998. 1349 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload 1350 (ESP)", RFC 2406, November 1998. 1352 AUTHORS' ADDRESSES 1354 Erik Nordmark 1355 Sun Microsystems, Inc. 1356 17 Network Circle 1357 Mountain View, CA 1358 USA 1360 phone: +1 650 786 2921 1361 fax: +1 650 786 5896 1362 email: erik.nordmark@sun.com 1364 Full Copyright Statement 1366 Copyright (C) The Internet Society (2003). All Rights Reserved. 1368 This document and translations of it may be copied and furnished to 1369 others, and derivative works that comment on or otherwise explain it 1370 or assist in its implementation may be prepared, copied, published 1371 and distributed, in whole or in part, without restriction of any 1372 kind, provided that the above copyright notice and this paragraph are 1373 included on all such copies and derivative works. However, this 1374 document itself may not be modified in any way, such as by removing 1375 the copyright notice or references to the Internet Society or other 1376 Internet organizations, except as needed for the purpose of 1377 developing Internet standards in which case the procedures for 1378 copyrights defined in the Internet Standards process must be 1379 followed, or as required to translate it into languages other than 1380 English. 1382 The limited permissions granted above are perpetual and will not be 1383 revoked by the Internet Society or its successors or assignees. 1385 This document and the information contained herein is provided on an 1386 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1387 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1388 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1389 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1390 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1392 Acknowledgement 1394 Funding for the RFC Editor function is currently provided by the 1395 Internet Society.