idnits 2.17.00 (12 Aug 2021) /tmp/idnits35868/draft-ylitalo-multi6-wimp-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 28, 2004) is 6687 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 1693, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (ref. '2') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '4') == Outdated reference: draft-ietf-ipsec-esp-v3 has been published as RFC 4303 == 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. '6') == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 ** Downref: Normative reference to an Informational draft: draft-irtf-nsrg-report (ref. '7') Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 J. Ylitalo 2 Internet-Draft V. Torvinen 3 Expires: July 28, 2004 Ericsson Research Nomadiclab 4 E. Nordmark 5 Sun Microsystems, Inc. 6 January 28, 2004 8 Weak Identifier Multihoming Protocol (WIMP) 9 draft-ylitalo-multi6-wimp-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 28, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This draft defines a Weak Identifier Multihoming Protocol (WIMP) for 40 IPv6 hosts. WIMP uses a new logical layer between networking and 41 transport layers that separates the end-point identifier and locator 42 roles from each other. The identifiers are used to name the 43 end-points, while IPv6 addresses are used for routing purposes. WIMP 44 is based on opportunistic security principles, and it does not 45 require any pre-configured security infrastructure. The protocol 46 consists of context establishment and re-addressing exchanges. The 47 context establishment exchange creates a state for both hosts. The 48 re-addressing exchange is used to update locator information at the 49 peer host. Used cryptographic operations are light and efficient. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1 Requirements language . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1 Cryptographic techniques . . . . . . . . . . . . . . . . . . 5 57 2.1.1 Reverse hash chain . . . . . . . . . . . . . . . . . . . . . 5 58 2.1.2 Reverse hash chain and message authentication . . . . . . . 6 59 2.1.3 Chained bootstrapping . . . . . . . . . . . . . . . . . . . 7 60 2.1.4 Secret splitting . . . . . . . . . . . . . . . . . . . . . . 7 61 2.2 Notational Conventions . . . . . . . . . . . . . . . . . . . 8 62 3. Protocol overview . . . . . . . . . . . . . . . . . . . . . 10 63 3.1 WIMP layer . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.2 Host-Pair Context . . . . . . . . . . . . . . . . . . . . . 11 65 3.3 Generating reverse hash chains . . . . . . . . . . . . . . . 12 66 3.4 Context establishment exchange . . . . . . . . . . . . . . . 13 67 3.5 Re-addressing exchange . . . . . . . . . . . . . . . . . . . 14 68 4. Packet processing . . . . . . . . . . . . . . . . . . . . . 17 69 4.1 Processing outgoing application data . . . . . . . . . . . . 17 70 4.2 Processing incoming application data . . . . . . . . . . . . 18 71 5. Packets . . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 5.1 INIT - the context initiator packet . . . . . . . . . . . . 19 73 5.2 CC - the context check packet . . . . . . . . . . . . . . . 20 74 5.3 CCR - the context check reply packet . . . . . . . . . . . . 20 75 5.4 CONF - the context confirm packet . . . . . . . . . . . . . 21 76 5.5 RESYNCH - the re-synchronization packet . . . . . . . . . . 21 77 5.6 REA - The re-addressing packet . . . . . . . . . . . . . . . 22 78 5.7 AC - The address check packet . . . . . . . . . . . . . . . 22 79 5.8 ACR - The address check reply packet . . . . . . . . . . . . 23 80 6. Message formats . . . . . . . . . . . . . . . . . . . . . . 24 81 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . . 24 82 6.1.1 WIMP Controls . . . . . . . . . . . . . . . . . . . . . . . 25 83 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 6.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 6.3 HASH-INIT . . . . . . . . . . . . . . . . . . . . . . . . . 28 87 6.4 HASH-CC . . . . . . . . . . . . . . . . . . . . . . . . . . 29 88 6.5 HASH-REA . . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 6.6 ANCHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 6.7 HASHVAL . . . . . . . . . . . . . . . . . . . . . . . . . . 31 91 6.8 HASHKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 31 92 6.9 FLOWID . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 6.10 CHALLENGE . . . . . . . . . . . . . . . . . . . . . . . . . 32 94 6.11 LSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 95 6.12 KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 7. State Machine . . . . . . . . . . . . . . . . . . . . . . . 36 97 7.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 7.2 State Processes . . . . . . . . . . . . . . . . . . . . . . 36 99 7.3 State Loss . . . . . . . . . . . . . . . . . . . . . . . . . 38 100 8. Security Considerations . . . . . . . . . . . . . . . . . . 40 101 8.1 Context establishment exchange . . . . . . . . . . . . . . . 40 102 8.1.1 Man-in-the-Middle attacks . . . . . . . . . . . . . . . . . 40 103 8.1.2 Denial-of-Service attacks . . . . . . . . . . . . . . . . . 40 104 8.2 Re-addressing exchange . . . . . . . . . . . . . . . . . . . 41 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 43 107 Normative references . . . . . . . . . . . . . . . . . . . . 44 108 Informative references . . . . . . . . . . . . . . . . . . . 45 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 110 A. Example of secure reverse hash chain generation . . . . . . 46 111 B. Goals for IPv6 Site-Multihoming Architectures . . . . . . . 47 112 B.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 47 113 B.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . 47 114 B.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . 47 115 B.4 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 116 B.5 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 48 117 B.6 Transport-Layer Survivability . . . . . . . . . . . . . . . 48 118 B.7 Impact on DNS . . . . . . . . . . . . . . . . . . . . . . . 48 119 B.8 Packet Filtering . . . . . . . . . . . . . . . . . . . . . . 48 120 B.9 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 48 121 B.10 Impact on Routers . . . . . . . . . . . . . . . . . . . . . 48 122 B.11 Impact on Hosts . . . . . . . . . . . . . . . . . . . . . . 48 123 B.12 Interaction between Hosts and the Routing System . . . . . . 48 124 B.13 Operations and Management . . . . . . . . . . . . . . . . . 49 125 B.14 Cooperation between Transit Providers . . . . . . . . . . . 49 126 B.15 Security compared to IPv4 multihoming . . . . . . . . . . . 49 127 C. Things MULTI6 Developers should think about . . . . . . . . 50 128 C.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 50 129 C.2 Identifiers and locators . . . . . . . . . . . . . . . . . . 50 130 C.3 On The Wire . . . . . . . . . . . . . . . . . . . . . . . . 50 131 C.4 Names, Hosts, Endpoints, or none of the above? . . . . . . . 51 132 Intellectual Property and Copyright Statements . . . . . . . 53 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 without an impact on the upper layer protocols. 143 This draft defines a Weak Identifier Multihoming Protocol (WIMP) for 144 IPv6 hosts. WIMP uses reverse hash chains and secret splitting to 145 perform enough validation to prevent redirection attacks. 147 The goals for WIMP are: 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 [6]. 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 Minimal per-packet overhead. 160 o No extra round trip for setup through optional piggy-backing. 162 o Take advantage of multiple locators for load spreading. 164 1.1 Requirements language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC2119 [1]. 170 2. Terminology 172 Upper Layer Protocol (ULP) 174 A protocol layer immediately above IP. Examples are transport 175 protocols such as TCP and UDP, control protocols such as ICMP, 176 routing protocols such as OSPF, and internet or lower-layer 177 protocols being "tunneled" over (i.e., encapsulated in) IP such as 178 IPX, AppleTalk, or IP itself. 180 Interface 182 A node's attachment to a link. 184 Locator 186 An IP layer topological name for an interface. The 128 bit 187 locators are carried in the IP address fields as the packets 188 traverse the network. 190 Identifier 192 An IP layer identifier for an IP layer endpoint (stack name in 193 [7]). The transport endpoint is a function of the transport 194 protocol and would typically include the IP identifier plus a port 195 number. 197 Address field 199 The source and destination address fields in the IPv6 header. 200 This draft separates identifiers from locators, and therefore 201 these fields contain locators. 203 FQDN 205 Fully Qualified Domain Name 207 2.1 Cryptographic techniques 209 2.1.1 Reverse hash chain 211 Reverse hash chain is cryptographically generated list of data 212 entities with some interesting characteristics. It is practically 213 impossible to calculate or otherwise figure out the next value in the 214 chain even when you know the previous value. However, it is very 215 easy to verify whether some given value is the next value or not. 217 The chain is created by recursively computing a hash function over a 218 result of the same function. The initial argument for the first hash 219 value computation is typically a large random number. The last 220 generated value of the chain is called as the "anchor" or "root" 221 value. The hash values are revealed in the reverse order starting 222 from the anchor value. 224 Hn = Hash(challenge) 225 Hn-1 = Hash(Hn) 226 ... 227 H0 = anchor = Hash(H1) 229 CHAIN: H0,..,Hn 231 This technique is usually applied based on an assumption that only an 232 authentic end-point knows the correct successor values of the chain. 233 In the bootstrapping process, the end-point computes a new hash chain 234 and reveals the anchor value of the chain to its peer. 236 Each hash chain can be used only once. 238 2.1.2 Reverse hash chain and message authentication 240 Hashed message authentication codes (HMAC; RFC2104) are typically 241 used to authenticate messages with a symmetric key. This requires, 242 naturally, that all communicating peers share a secret. 244 Example: HMAC(key, Message). 246 Reverse hash chain values can be used as keys in the message 247 authentication. This is different from the shared secret scheme 248 because anybody who is able to receive the subsequent messages is 249 able to verify that the messages belong together. The reverse hash 250 chain value (key) used in message authentication is not revealed 251 before the next message. In other words, the peer is able verify the 252 message only after it has received the next message. This procedure 253 can be used to verify that all subsequent messages come from the same 254 entity than the first message. In other words, the hash chain binds 255 the messages together. 257 A Man-in-the-Middle (MitM) attacker is not able to (unnoticeably) 258 modify the messages after the first message in the exchange. However, 259 an attacker may spoof the first message and use own hash chain. The 260 protocol is based on opportunistic principle where the first message 261 must be sent by an authentic node. The last message should contain 262 only the last hash value, Hn. 264 Message_1: Message, HMAC(H1, Message) 265 Message_2: Message, H1, HMAC(H2, Message) 266 Message_3: Message, H2, HMAC(H3, Message) 267 ... 268 Message_n: Message, Hn-1, HMAC(Hn, Message) 269 Message_n+1: Hn 271 2.1.3 Chained bootstrapping 273 In the basic model, each reverse hash chain is an independent entity. 274 This is not a problem if the anchor of the chain can be 275 authenticated, and if the hash chain is known to be long enough to 276 have values to every message in the communication session. However, 277 it is possible to use short hash chains to avoid extra computation. 279 Basically, the bootstrapping message can be authenticated using 280 public keys. In the opportunistic mode, the peers do not authenticate 281 the bootstrapping message with signatures, but rely that all 282 subsequent messages are coming from the same peer. Two independently 283 created reverse hash chains can be linked together with a Hash 284 computation. The last value of the first reverse hash chain is used 285 to authenticate the first value of the second chain: 287 ... 288 Message_n: Message, H1_new, Hn-1, HMAC(Hn, Message) 289 Message_n+1: Message, Hn, HMAC(H2_new, Message) 290 Message_n+2: Message, H2_new, HMAC(H3_new, Message) 291 ... 293 2.1.4 Secret splitting 295 In secret splitting, the secret is divided into several pieces. Any 296 piece alone does not give enough information for an attacker to 297 create the original secret. The only way to create the secret is to 298 posses all the pieces of the key. 300 The simplest scheme splits a secret into two pieces. The splitting is 301 done by generating a random-bit string, the same length as the 302 secret, that will represent one piece of the split. The secret is 303 then XORed with the random string to generate the other piece. 304 Essentially, the secret is encrypted with a one-time pad. The pieces 305 are the encrypted message, and the pad. 307 Example: 309 secret XOR random_string = encrypted_message 311 secret_piece_1 = random_string 312 secret_piece_2 = encrypted_message 314 The original secret can be reconstructed by XORing the pieces 315 together. However, each piece alone can not be used to reconstruct 316 the secret, not even with the highest possible computing power. One 317 secret can very easily be divided into more than two pieces. What is 318 needed is just more random-bit strings that are XORed into the 319 secret. 321 Secret splitting is useful technique for storing secrets in two 322 physical places, or for sending a secret to the other end-point using 323 two or more parallel communication paths. 325 2.2 Notational Conventions 327 - I is an initiating host, i.e. an initiator. 329 - R is a responding host, i.e. a responder. 331 - ID(I) is an identifier for I. 333 - ID(R) is an identifier for R. 335 - FQDN(R) is the domain name for R. 337 - Ls(I) is the locator set for I, which consists of L1(I), L2(I), 338 ... Ln(I). 340 - Ls(R) is the locator set for R. 342 - F(I) is a flowid assigned by the initiator and used by the 343 responder. The responder uses F(I) in packets going to the 344 initiator. F(I) is a tag for the host-pair context at the 345 initiator. 347 - F(R) is a flowid assigned by the responder and used by the 348 initiator. 350 - Hk(I) is k:th hash value in a initiator's reverse hash chain. 351 The 'H0(I)' is the first revealed value, i.e. the "anchor" of the 352 reverse hash chain. Note that the parameter k defines the 353 revealing order, not the computation order. 355 - Hk(R) is k:th hash value in a responder's reverse hash chain. 357 3. Protocol overview 359 In order to prevent redirection attacks WIMP relies on the ability to 360 verify that the entity requesting redirection indeed holds the 361 successor values of a hash chain and is able to combine a divided 362 secret that is sent via parallel paths. WIMP can be divided into two 363 exchanges: context establishment and re-addressing exchange. The 364 former exchange establishes a state for both communication 365 end-points. The re-addressing exchange is used to update the 366 locators belonging to the communicating parties. WIMP layer hides 367 multiple addresses from the upper layer protocols. 369 3.1 WIMP layer 371 WIMP layer is located between IP and the ULPs, as shown in figure 1, 372 in order to provide ULP independence. Conceptually the WIMP layer 373 behaves as if it is an extension header, which would be ordered 374 immediately after any hop-by-hop options in the packet. 376 +-----------------------------------+ 377 | Transport Protocols | 378 +-----------------------------------+ 379 | AH | ESP | Frag/reass | Dest opts | 380 +-----------------------------------+ 381 | WIMP layer | 382 +-----------------------------------+ 383 | IP | 384 ------------------------------------+ 386 Figure 1: Protocol stack 388 All protocols above WIMP layer use 128 bit identifiers (IDs). The 389 IDs are non-routable by their nature and never used in the IPv6 390 header in the network. An ID consists of an initial 2 bit prefix of 391 01, followed by 126 bits suffix that is a hash. The suffix in the 392 initiator's identifier, ID(I), is a hash of a nonce. The suffix in 393 the responder's identifier, ID(R), is constructed taking a hash of 394 the responder's FQDN(R). 396 Applications and upper layer protocols use IDs which the WIMP layer 397 will map to/from locators (see figure 2). The WIMP layer maintains 398 state, called host-pair context, in order to perform this mapping. 399 The mapping is performed consistently at the initiator and the 400 responder, thus from the perspective of the upper layer protocols 401 packets appear to be sent using IDs from end to end, even though the 402 packets travel through the network containing locators in the IP 403 address fields, and even though those locators might be rewritten in 404 flight. The result of this consistent mapping is that there is no 405 impact on the ULPs. In particular, there is no impact on 406 pseudo-header checksums and connection identification. 408 ---------------------- ---------------------- 409 | Initiator | | Responder | 410 | | | | 411 | ULP | | ULP | 412 | | src ID(I) | | ^ | 413 | | dst ID(R) | | | src ID(I) | 414 | v | | | dst ID(R) | 415 | WIMP | | WIMP | 416 | | src L1(I) | | ^ | 417 | | dst L1(R) | | | src L1(I) | 418 | v | | | dst L1(R) | 419 | IP | | IP | 420 ---------------------- ---------------------- 421 | ^ 422 -- cloud with some routers ------- 424 Figure 2: Mapping identifiers to locators. 426 Layering AH and ESP above the WIMP means that IPsec can be made to be 427 unaware of locator changes the same way that transport protocols can 428 be unaware. Thus the IPsec security associations remain stable even 429 though the locators are changing. Layering the fragmentation header 430 above the WIMP makes reassembly robust in the case that there is 431 broken multi-path routing which results in using different paths, 432 hence potentially different source locators, for different fragments. 434 3.2 Host-Pair Context 436 The initiator creates a host-pair context based on IDs and the 437 locator set learned from the DNS. The responder establishes a state 438 after receiving the second message from the initiator. 440 The context state contains the following information: 442 - Context identifiers (e.g. identities and flow id's) 444 - Locator and locator status (e.g. if locator has been verified, 445 and which locators are preferred for communication) 447 - Hash chain information (e.g. parameters needed in the 448 construction of hash chains, last used local chains values, and 449 last known peer chain values) 451 Every IP packet must contain information about the related host-pair 452 context. Basically, every packet could contain an extra extension 453 header including the IDs. However, that would add extra overhead to 454 the packets. Instead, we use flowid field in the IPv6 header to 455 represent the host-pair context. Conceptually one could view the 456 approach as if both IDs being present in every packet, but with a 457 header compression mechanism applied that removes the need for the 458 IDs once the state has been established. The flowid serves as a 459 convenient "compression tag" without increasing the packet size. 461 Flowids are used in regular IPv6 packets to find the right context 462 for received packets. Each host selects for itself the flowid it 463 wants to see in packets received from its peer. This allows it to 464 select different flowids for different peers. 466 The problem related to flowid selection is identical with the IPSEC 467 SPI selection. A host cannot select a flowid for IP packets going to 468 its peer. Otherwise, two different hosts might select the same flowid 469 and the peer could not uniquely identify the correct host-pair 470 context using the received flowid. 472 Selected flowid is communicated to the peer in the third (CCR) and 473 fourth (CONF) packets of the context creation exchange. 475 3.3 Generating reverse hash chains 477 In general, the way by which the reverse hash chains are generated is 478 a local matter. The hash chains are needed by the initiator and the 479 responder during the context establishment exchange. Also, the 480 initiator of the re-addressing exchange needs to construct a new hash 481 chain. 483 This document sets the following requirements for the hash chains 484 generation: 486 - Each reverse hash chain MUST be unique for each host-pair 487 context establishment and re-addressing exchange. 489 - The responder MUST be able to reconstruct the same reverse hash 490 chain based on the parameters that are present in the context 491 check reply message (CCR) in order to be stateless at the 492 beginning of context establishment exchange. 494 - The responder MUST be able to reconstruct the same reverse hash 495 chain based on the parameters that are present in the context 496 check reply message (CCR) even if the system boots. 498 - The initial argument of the hash chain is never revealed to 499 other parties. 501 - The length of the hash chain is implementation specific but must 502 be the same every time a chain is constructed. 504 Theoretically speaking, the minimum length of the hash chain is three 505 (3) hash values. This will last for one context establishment 506 exchange, and one re-addressing exchange for both direction (note 507 that re-addressing exchange includes a bootstrapping procedure where 508 a new hash chain is created for the initiator). However, each 509 unsuccessful re-addressing exchange attempt will require one more 510 hash chain value. Failures in re-addressing exchange may be due to 511 connection loss in some of the locators, or an active attack. 513 Appendix A gives one example of secure hash chain generation. 515 3.4 Context establishment exchange 517 The context establishment exchange serves to manage the establishment 518 of state between an initiator and a responder. The procedure uses 519 delayed authentication principle where initial message exchange are 520 verified with the parameters included in the latter messages. The 521 procedure is designed to be stateless for the responder side. At the 522 end of the exchange both parties have a uniquely identifiable 523 host-pair context containing the peer's anchor value. 525 Initiator Responder 527 compute hash chain 528 generate random ID(I) 529 select flowid F(I) 531 INIT: IDs, challenge_I, 532 HMAC_INIT{H0(I), (IDs|challenge_I|F(I))} 533 --------------------------> 534 compute temporary hash chain 536 CC: IDs, HMAC_INIT, HMAC_CC{H0_R, (IDs|HMAC_INIT)} 537 <------------------------- 538 remain stateless 540 CCR: IDs, H0(I), challenge_I, F(I), HMAC_INIT, HMAC_CC 541 --------------------------> 542 recompute the hash chain 543 verify HMAC_INIT and HMAC_CC 544 select flowid F(R) 545 CONF: IDs, H0(R), F(R) 546 <-------------------------- 547 verify HMAC_CC 549 The initiator first sends a context initiator message, INIT, to the 550 responder. The INIT message contains the IDs, a challenge and a keyed 551 hash. The hash, having the anchor value as a key, is computed over 552 the IDs, challenge and flowid. The flowid is sent later in the 553 context check reply message (CCR). 555 Once the responder receives the INIT message, it must check that it 556 does not already have a host-pair context with the ID pair. If the 557 context is not found, the responder continues with the negotiation. 558 However, it does not want to establish a state because it is not able 559 to verify the origin of the message. In order to remain stateless, 560 the responder computes a temporary hash chain using the initiator's 561 challenge in the INIT packet, and sends a context check message (CC) 562 to the initiator. The CC message is protected with the anchor value 563 of responder hash chain. 565 The initiator replies to the CC message with a context check reply 566 message (CCR) and proves that it was reachable at the specific 567 location by disclosing the anchor value. The CCR message includes the 568 flowid that uniquely identifies the host pair context to the 569 initiator. 571 Again, the responder does not accept CCR packets with an ID pair that 572 already has a host pair-context. If the context is not found, the 573 responder recomputes its own hash chain and verifies the keyed hashes 574 (HMAC_INIT and HMAC_CC). The anchor value of the initiator hash chain 575 binds the INIT and CCR messages together, and in this way the 576 responder is able to verify that messages are coming from the same 577 host. If the keyed hashes were valid, the responder names the host 578 pair context by generating a flowid for it, and replies with a 579 context confirmation message (CONF) revealing its anchor value. 581 The initiator verifies the keyed hash in the CC message with the 582 anchor value received in the CONF message, and finalizes its state. 584 The context establishment exchange has been designed in the way that 585 it can be reused for secure resynchronisation. If the initiator 586 receives a RESYNC message, it SHOULD start a new handshake with the 587 INIT message by including the latest disclosed responder's hash chain 588 value. In this way, the initiator can be sure that the RESYNC message 589 really originated from the responder, and not from an attacker. In 590 this case, the responder discloses the successor hash chain value in 591 the CONF message, instead of the anchor value. 593 3.5 Re-addressing exchange 595 Once the state has been completed, both hosts have a host-pair 596 context. At this point, the initiator has received the responder's 597 locator set from the DNS. However, it is possible that the responder 598 has published only one IP address in the DNS, but it is still able to 599 multihome, and has several IP addresses. Basically, both hosts may 600 send to their peers the locator sets. A host may verify the peer's 601 addresses on demand basis or all at once. 603 Initiator Responder 605 compute new hash chain 607 REA: IDs, Ls(I), H1(I), H0_new(I), challenge, 608 HMAC_REA{H2(I), (IDs|Ls(I)|H1(I)|H0_new(I)|challenge} 609 --------------------------> 610 verify H1(I) 611 generate a divided secret using H1(R) 612 send AC per new locator 614 AC1: IDs, Key_count, Key_mask, key_piece, challenge 615 ... <------------------------- 616 ACn <------------------------- 618 combine the key pieces 619 verify the combined key 621 ACR: IDs, Key_combined, Key_mask, H2(I) 622 --------------------------> 623 verify the combined key H1(R) 624 verify HMAC_REA 626 The re-addressing exchange is a three way handshake. The 627 re-addressing message (REA) has two purposes. First, it contains the 628 initiator's locator set. Second, it bootstraps a new hash chain. 630 Once the responder receives a REA message, it verifies that the hash 631 chain value H1(I) belongs to the initiator (this example assumes that 632 the previously revealed hash chain value was the anchor, H0). In 633 addition, the responder stores the initiator's new anchor value 634 H0_new(I) and the new challenge value into the host-pair context. 636 The responder divides its own next unused hash chain value into 637 pieces using the secret splitting technique. The hash chain value is 638 divided into as many parts as there were locators in the received 639 locator set. The responder defines a key mask for each of the key 640 pieces (see Section 6.12). The key mask will later allow the 641 responder to check if all pieces found their way to the initiator. It 642 is possible that the initiator is not reachable via all of the 643 locators in the locator set. 645 The responder sends one address check message (AC) per locator in the 646 received locator set. Each AC message contains one piece of the hash 647 chain value. The initiator must have a local policy on how long it 648 waits for the upcoming AC messages. 650 If the initiator receives all pieces of the hash chain value, it 651 verifies that it is a successor value of the responder's hash chain. 652 Otherwise, the initiator MAY stop the re-addressing exchange 653 procedure. The initiator makes an OR operation with all of the 654 received key masks and includes the result of the operation with the 655 combined key to the address check reply message (ACR). 657 The responder verifies the combined key using the key mask that 658 indicates the key pieces that the initiator was able to receive. In 659 addition, the responder uses the received initiator's hash chain 660 value to authenticate the earlier received REA message. Finally, the 661 responder marks the corresponding locators in the initiator's locator 662 set as verified. 664 4. Packet processing 666 Each host is assumed to have a separate WIMP implementation that 667 manages the host's host-pair context and handles requests for new 668 ones. Each host-pair context is governed by a state machine, with 669 states defined in Section 7. WIMP implementation can simultaneously 670 maintain host-pair contexts with more than one host. Furthermore, 671 WIMP implementation may have more than one active host-pair context 672 with another host; in this case, host-pair contexts are distinguished 673 by their respective IDs and flowids. It is not possible to have more 674 than one host-pair contexts between any given pair of IDs. 675 Consequently, the only way for two hosts to have more than one 676 parallel associations is to use different IDs, at least in one end. 678 The processing of packets depends on the state of the host-pair 679 context(s) with respect to the originator of the packet. A WIMP 680 implementation determines whether it has an active association with 681 the originator of the packet based on the IDs or the flowid of the 682 packet. 684 4.1 Processing outgoing application data 686 In an WIMP host, an application can send application level data using 687 IDs as source and destination identifiers. The IDs can be specified 688 via a backwards compatible API. However, whenever there is such 689 outgoing data, the stack has to send the resulting datagram using 690 appropriate source and destination IP addresses. 692 The following steps define the conceptual processing rules for 693 outgoing datagrams destinated to a ID(R). 695 1. If the datagram has a specified source address, it MAY be a 696 ID(I). If it is not, the implementation MAY replace the source 697 address with a ID(I). Otherwise it MUST send the packet using 698 the given IP addresses and bypass the WIMP layer. 700 2. If the datagram has an unspecified source address, the 701 implementation MUST choose a suitable source ID(I) for the 702 datagram. In selecting a proper ID(I), the implementation MUST 703 consult the table of currently active WIMP sessions, and 704 preferably select a ID(I) that already has an active session with 705 the target ID(R). 707 3. If there is no active WIMP session with the ID(R), one must be 708 created by running the context establishment exchange. The 709 implementation MAY piggy-pack ULP payload to the exchange 710 packets. 712 4. Once there is an active WIMP session for the given ID(R), the 713 outgoing datagram does not contain WIMP headers. Instead, the 714 IDs are represented by flowids in the IP headers. 716 5. The IDs in the datagram are replaced with suitable IP addresses. 717 The rules defined in [2] MAY be followed. 719 4.2 Processing incoming application data 721 Incoming WIMP datagrams arrive as normal IP packets containing WIMP 722 flowids. In the usual case the receiving host has a corresponding 723 host-pair context, identified by the flowid in the packet. However, 724 if the host has crashed or otherwise lost its WIMP state, it may not 725 have such a host-pair context. 727 The following steps define the conceptual processing rules for 728 incoming datagrams targeted to a WIMP host-pair context. 730 1. Detect the proper host-pair context, using the flowid. If there 731 are no host-pair context identified with the flowid, the host MAY 732 reply with a RESYNC packet. Sending such RESYNCs MUST be rate 733 limited. However, if the receiver has an open socket 734 corresponding the IP addresses in the IP header it MUST process 735 the packet as standard IP datagram. 737 2. If a proper host-pair context is found, the packet is processed 738 by WIMP. The IP addresses in the datagram are replaced with the 739 IDs associated with the host-pair context. 741 3. The datagram is delivered to the upper layer. Demultiplexing the 742 datagram the right upper layer socket is based on the IDs. 744 5. Packets 746 There are eight basic WIMP packets. Four are for the context 747 establishment exchange, three are for re-addressing, and one is for 748 state loss. 750 Packets consist of the fixed header as described in Section 6.1, 751 followed by the parameters. The parameter part, in turn, consists of 752 zero or more TLV coded parameters. 754 Packet representation uses the following operations: 756 () parameter 757 [] optional parameter 759 An upper layer payload MAY follow the WIMP header. The payload proto 760 field in the header indicates if there is additional data following 761 the WIMP header. The WIMP packet, however, MUST NOT be fragmented. 762 This limits the size of the possible additional data in the packet. 764 5.1 INIT - the context initiator packet 766 The WIMP header values for the INIT packet: 768 Header: 769 Packet Type = 1 770 SRC ID = Initiator's ID 771 DST ID = Responder's ID 773 IP( WIMP ( CHALLENGE, HASH-INIT )) 775 Valid control bits: P 777 The INIT packet contains the fixed WIMP header, initiator's 778 challenge, and HASH-INIT TLV (Section 6.3). 780 If the INIT message is a response to a RESYNC packet the initiator 781 SHOULD replace the challenge with the responder's old challenge. In 782 this way, the initiator is able to verify later that the responder 783 has really lost its state. 785 The Initiator generates the Responder's identifier, ID(R), using the 786 the Responder's FQDN. If the Initiator does not know the Responder's 787 FQDN, it MUST use IP addresses for the application identifiers in the 788 socket API and by pass the WIMP protocol. 790 5.2 CC - the context check packet 792 The WIMP header values for the CC packet: 794 Header: 795 Packet Type = 2 796 SRC ID = Responder's ID 797 DST ID = Initiator's ID 799 IP ( WIMP ( HASH-INIT, HASH-CC )) 801 Valid control bits: P 803 The IDs MUST be the same received in INIT. (If the Responder has 804 multiple IDs, the responder ID used MUST match Initiator's request.) 806 The Responder copies the HASH-INIT TLV from INIT message to the CC 807 message 809 The Responder computes a temporary hash chain using the received 810 initiator's challenge and IDs (see Section 3.3). The responder uses 811 the generated anchor value of the temporary hash chain as a key for 812 the HASH-CC computation Section 6.4). (Note: The responder does not 813 store the temporary hash chain values.) 815 5.3 CCR - the context check reply packet 817 The WIMP header values for the CCR packet: 819 Header: 820 Type = 3 821 SRC ID = Initiator's ID 822 DST ID = Responder's ID 824 IP ( WIMP ( ANCHOR, FLOWID, CHALLENGE, [HASHVAL,] HASH-INIT, HASH-CC ) 826 Valid control bits: P 828 The IDs used MUST match the ones used in the previous messages. 830 If the initiator already has a host-pair context for the responder, 831 but responder has lost its state, the initiator SHOULD sent the 832 latest known responder's hash value, HASHVAL, and the old challenge, 833 to the responder. 835 The Initiator reveals the anchor value that was used in HASHKEY TLV 836 in the HASH-INIT computation in the INIT message. 838 Initiator copies the HASH-INIT, and HASH-CC TLVs from the CC message 839 to the CCR message. In addition, CCR message includes the anchor, 840 flowid, challenge, and responder's latest hash value. .The Initiator 841 selects a flowid that the responder uses to send packets to the 842 Initiator (Section 3.2) 844 5.4 CONF - the context confirm packet 846 The WIMP header values for the CONF packet: 848 Header: 849 Packet Type = 4 850 SRC ID = Responder's ID 851 DST ID = Initiator's ID 853 IP ( WIMP ( ANCHOR, FLOWID )) 855 Valid control bits: P 857 The Responder reveals the anchor value that was used in HASHKEY TLV 858 in the HASH-CC computation in the CC message. 860 The Responder selects a flowid that the initiator uses to send 861 packets to the Responder. 863 5.5 RESYNCH - the re-synchronization packet 865 The WIMP header values for the RESYNC packet: 867 Header: 868 Packet Type = 5 869 SRC ID = Responder's ID 870 DST ID = (zero) 872 IP ( WIMP ( FLOWID )) 874 Valid control bits: - 876 Once a responder receives an IP packet with an unknown flowid it 877 replies with RESYNC packet and copies the received flowid into the 878 message. However, if the responder has an open socket corresponding 879 the IP addresses in the IP header it MUST process the packet as a 880 standard IP datagram. 882 5.6 REA - The re-addressing packet 884 The WIMP header values for the REA packet: 886 Header: 887 Packet Type = 10 888 SRC ID = Initiator's ID 889 DST ID = Responder's ID 891 IP ( WIMP ( LSET, HASHVAL, ANCHOR, CHALLENGE, HASH-REA )) 893 Valid control bits: P 895 The REA message contains initiator's locator set. The node that was 896 the responder during the context establishment exchange is the 897 initiator when it initiates a re-addressing exchange. The initiating 898 party of re-addressing exchange is called the initiator in the REA 899 context. 901 The Initiator revels a successor hash value (HASHVAL TLV) of its 902 current hash chain. In addition, it bootstraps a new hash chain by 903 revealing a new anchor value (ANCHOR TLV). The challenge used to 904 generate a new hash chain is included into the message. Hash chain 905 generation for the initiator is discussed in Section Section 3.3. 907 Section 6.5 describes how the HASH-REA is computed. 909 5.7 AC - The address check packet 911 The WIMP header values for the AC packet: 913 Header: 914 Packet Type = 11 915 SRC ID = Responder's ID 916 DST ID = Initiator's ID 918 IP ( WIMP ( KEY, CHALLENGE )) 920 Valid control bits: P 922 The responder divided a secret into as many pieces as there were 923 addresses in locator set in the received REA message. The key count 924 contains the total number of the key pieces. The key mask is an 925 identifier for a key piece in the KEY TLV. The challenge TLV includes 926 the challenge received in the REA message. The initiator is able to 927 bind the received AC to the correct exchange using the challenge. The 928 responder sends one AC packet per locator in the received locator 929 set. (Note: Each AC contains one key piece.) 931 5.8 ACR - The address check reply packet 933 The WIMP header values for the AC packet: 935 Header: 936 Packet Type = 12 937 SRC ID = Initiator's ID 938 DST ID = Responder's ID 940 IP ( WIMP ( KEY, HASHVAL )) 942 Valid control bits: P 944 The KEY TLV is constructed of the received key pieces and their key 945 masks. The HASHVAL TLV contains the hash value that was used as a key 946 in the REA packet in HASH-REA TLV. 948 6. Message formats 950 6.1 Payload format 952 All WIMP packets start with a fixed header. 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Next Header | Payload Len | Type | VER. | RES. | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Controls | Checksum | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Sender's Identifier (ID) | 962 | | 963 | | 964 | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Receiver's Identifier (ID) | 967 | | 968 | | 969 | | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | | 972 / WIMP Parameters / 973 / / 974 | | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 The WIMP header is logically an IPv6 extension header followed by a 978 next header that is defined in Next Header field. If no next headers 979 follow, the decimal 59, IPPROTO_NONE, the IPV6 no next header value, 980 is used. 982 The Header Length field contains the length of the WIMP header and 983 the length of parameters in 8 bytes units, excluding the first 8 984 bytes. Since all WIMP headers MUST contain the sender's and 985 receiver's ID fields, the minimum value for this field is 4, and 986 conversely, the maximum length of the WIMP Parameters field is 987 (255*8)-32 = 2008 bytes. 989 The Packet Type indicates the WIMP packet type. The individual 990 packet types are defined in the relevant sections. If a WIMP host 991 receives a packet that contains an unknown packet type, it MUST drop 992 the packet. 994 The Version is four bits. The current version is 1. The version 995 number is expected to be incremented only if there are incompatible 996 changes to the protocol. Most extensions can be handled by defining 997 new packet types, new parameter types, or new controls. 999 The following four bits are reserved for future use. They MUST be 1000 zero when sent, and they SHOULD be ignored when handling a received 1001 packet. 1003 The ID fields are always 128 bits (16 bytes) long. 1005 6.1.1 WIMP Controls 1007 The WIMP control section transfers information about the structure of 1008 the packet and capabilities of the host. 1010 The following fields have been defined: 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | | | | | | | | | | | | |P| | | | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 P - Piggy backing The sending host is capable of sending and 1017 receiving additional data (e.g. ESP) in WIMP packets. 1019 The rest of the fields are reserved for future use and MUST be set to 1020 zero on sent packets and ignored on received packets. 1022 6.1.2 Checksum 1024 The checksum field is located at the same location within the header 1025 as the checksum field in UDP packets, enabling hardware assisted 1026 checksum generation and verification. Note that since the checksum 1027 covers the source and destination addresses in the IP header, it must 1028 be recomputed on WIMP based middle-boxes. 1030 The pseudo-header [3] contains the source and destination IPv6 1031 addresses, WIMP packet length in the pseudo-header length field, a 1032 zero field, and the WIMP protocol number (TBD) in the Next Header 1033 field. The length field is in bytes and can be calculated from the 1034 WIMP header length field: (WIMP Header Length + 1) * 8. 1036 6.2 Parameters 1038 The parameters are used to carry the hash chain values associated 1039 with the sender's ID, together with other related security 1040 information. The parameters consists of ordered parameters, encoded 1041 in TLV format. 1043 The following parameter types are currently defined. 1045 TLV Type Length Data 1047 (TBD) 1049 6.2.1 TLV format 1051 The TLV encoded parameters are described in the following 1052 subsections. The type-field value also describes the order of these 1053 fields in the packet. The parameters MUST be included into the 1054 packet so that the types form an increasing order. If the order does 1055 not follow this rule, the packet is considered to be malformed and it 1056 MUST be discarded. 1058 All the TLV parameters have a length which is a multiple of 8 bytes. 1059 When needed, padding MUST be added to the end of the parameter so 1060 that the total length becomes a multiple of 8 bytes. This rule 1061 ensures proper alignment of data. If padding is added, the Length 1062 field MUST NOT include the padding. Any added padding bytes MUST be 1063 set zero by the sender, but their content SHOULD NOT be checked on 1064 the receiving end. 1066 Consequently, the Length field indicates the length of the Contents 1067 field (in bytes). The total length of the TLV parameter (including 1068 Type, Length, Contents, and Padding) is related to the Length field 1069 according to the following formula: 1071 Total Length = 11 + Length - (Length + 3) % 8; 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Type |C| Length | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | | 1078 / Contents / 1079 / +-+-+-+-+-+-+-+-+ 1080 | | Padding | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 Type Type code for the parameter 1084 C Critical. One if this parameter is critical, and 1085 MUST be recognized by the recipient, zero otherwise. 1086 The C bit is considered to be a part of the Type field. 1087 Consequently, critical parameters are always odd 1088 and non-critical ones have an even value. 1089 Length Length of the parameter, in bytes. 1090 Contents Parameter specific, defined by Type 1091 Padding Padding, 0-7 bytes, added if needed 1093 Critical parameters MUST be recognized by the recipient. If a 1094 recipient encounters a critical parameter that it does not recognize, 1095 it MUST NOT process the packet any further. 1097 Non-critical parameters MAY be safely ignored. If a recipient 1098 encounters a non-critical parameter that it does not recognize, it 1099 SHOULD proceed as if the parameter was not present in the received 1100 packet. 1102 6.3 HASH-INIT 1104 0 1 2 3 1105 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 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Type | Length | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | | 1110 | HASH | 1111 | | 1112 | | 1113 | | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Type 65500 1117 Length 20 1118 HASH 1120 160 bit SHA1 is computed over: 1121 - WIMP common header. 1122 - HASHKEY TLV, Initiator's second hash value, H1(I) 1123 - FLOWID TLV, initiator. 1124 - CHALLENGE TLV, 128 challenge generated by the initiator. 1125 excluding the HASH-INIT parameter. The checksum field MUST 1126 be set to zero and the WIMP header length in the WIMP common 1127 header MUST be calculated to cover all the included 1128 parameters when the SHA1 is calculated. 1130 HASH-INIT calculation and verification process: 1132 INIT message sender: 1134 1. Create the INIT message, containing HASHKEY, FLOWID, and 1135 CHALLENGE TLVs, without the HASH-INIT TLV. 1137 2. Calculate the length field in the WIMP header. 1139 3. Compute the SHA1. 1141 4. remove the HASHKEY, and FLOWID TLVs. 1143 5. Add the HASH-INIT TLV to the packet. 1145 6. Recalculate the length field in the WIMP header. 1147 CCR message receiver: 1149 1. reconstruct the INIT message, containing HASHKEY, FLOWID, and 1150 CHALLENGE TLVs, without the HASH-INIT TLV. 1152 2. Calculate the WIMP packet length in the WIMP header and clear the 1153 checksum field (set it to all zeros). 1155 3. Compute the HASH-INIT and verify it against the received 1156 HASH-INIT. 1158 6.4 HASH-CC 1160 The TLV structure is the same as in Section 6.3. The fields are: 1162 Type 65502 1163 Length 20 1164 HASH 160 bit SHA1 is computed over: 1165 - WIMP common header. 1166 - HASHKEY TLV, the responder's hash chain value. 1167 - HASH-INIT TLV, received in the INIT message, 1168 excluding the HASH-CC parameter. The checksum field MUST 1169 be set to zero and the WIMP header length in the WIMP common 1170 header MUST be calculated to cover all the included 1171 parameters when the SHA1 is calculated. 1173 HASH-CC calculation and verification process: 1175 CC message sender: 1177 1. Create the CC message, containing HASHKEY, and HASH-INIT TLVs, 1178 without HASH-CC TLV. 1180 2. Calculate the length field in the WIMP header. 1182 3. Compute the SHA1. 1184 4. remove the HASHKEY TLV. 1186 5. Add the HASH-CC TLV to the packet. 1188 6. Recalculate the length field in the WIMP header. 1190 CCR and CONF message receiver: 1192 1. reconstruct the CC message, containing HASHKEY, and HASH-INIT 1193 TLVs, without the HASH-CC TLV. 1195 2. Calculate the WIMP packet length in the WIMP header and clear the 1196 checksum field (set it to all zeros). 1198 3. Compute the HASH-CC and verify it against the received HASH-CC. 1200 6.5 HASH-REA 1202 The TLV structure is the same as in Section 6.3. The fields are: 1204 Type 65504 1205 Length 20 1206 HASH 160 bit SHA1 is computed over: 1207 - WIMP common header, 1208 - LSET TLV, Initiator's locator set. 1209 - HASHVAL TLV, a hash value, Hk, of the initiator's 1210 hash chain 1211 - HASHKEY TLV, a successor hash value, Hk+1, of the 1212 initiator's hash chain 1213 - ANCHOR TLV, the anchor value, H0, of the initiator's 1214 new hash chain 1215 - CHALLENGE TLV, the challenge used in the new hash chain 1216 generation. 1217 excluding the HASH-REA parameter. The checksum field MUST 1218 be set to zero and the WIMP header length in the WIMP common 1219 header MUST be calculated to cover all the included 1220 parameters when the SHA1 is calculated. 1222 HASH-REA calculation and verification process. 1224 REA message sender: 1226 1. Create the REA message, containing LSET, HASHVAL, ANCHOR, HASHKEY 1227 and CHALLENGE TLVs, without HASH-REA TLV. 1229 2. Calculate the length field in the WIMP header. 1231 3. Compute the SHA1. 1233 4. remove the HASHKEY TLV. 1235 5. Add the HASH-CC TLV to the packet. 1237 6. Recalculate the length field in the WIMP header. 1239 REA message receiver: 1241 1. Add HASHKEY TLV 1242 2. Remove and store HASH-REA TLV. 1244 3. Calculate the WIMP packet length in the WIMP header and clear the 1245 checksum field (set it to all zeros). 1247 4. Compute the HASH-REA and verify it against the received HASH-REA. 1249 6.6 ANCHOR 1251 The TLV structure is the same as in Section 6.3. The fields are: 1253 Type 10 1254 Length 20 1255 HASH 160 bit SHA1. An anchor value of a hash chain. 1257 6.7 HASHVAL 1259 The TLV structure is the same as in Section 6.3. The fields are: 1261 Type 12 1262 Length 20 1263 HASH 160 bit SHA1 hash value. It is generated by computing 1264 a hash over a successor hash chain value. 1266 6.8 HASHKEY 1268 The TLV structure is the same as in Section 6.3. The fields are: 1270 Type 14 1271 Length 20 1272 HASH 160 bit SHA1 hash value that is used as a key in 1273 HASH-INIT, HASH-CC and HASH-REA TLV computation. 1274 The key value is never revealed in the 1275 same message as the corresponding authentication hash. 1277 6.9 FLOWID 1279 The FLOWID parameter contains the flowid that the receiving host must 1280 use when sending data to the sending host. 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Type | Length | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Flowid | Reserved | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 Type 16 1291 Length 4 1292 Reserved Zero when sent, ignored when received 1293 Flowid 20 bit flowid 1295 6.10 CHALLENGE 1297 0 1 2 3 1298 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 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Type | Length | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Reserved | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | challenge | 1305 | | 1306 | | 1307 | | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 Type 20 1311 Length 20 1312 Reserved Zero when sent, ignored when received 1313 challenge 128 bit random number 1315 6.11 LSET 1317 0 1 2 3 1318 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 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Type | Length | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Reserved | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Address #1 | 1325 / / 1326 | | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 / ... / 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Address #n | 1331 / / 1332 | | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 Type 22 1336 Length variable 1337 Reserved Zero when sent, ignored when received 1338 Address IPv6 address 1340 6.12 KEY 1342 0 1 2 3 1343 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 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Type | Length | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | AC ID | Hash ID | Key Count | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Key mask | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Key piece 160 bit (AC message) / | 1352 / Combined key 160 bit (ACR message) / 1353 | | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Type 26 1357 Length variable 1358 AC ID An increasing counter that identifies the exchange for 1359 the responder. 1360 Hash ID The order number of a hash chain value in the responder's 1361 hash chain. The hash chain value that is divided into key 1362 pieces. 1363 Key count The total number of key pieces sent/received 1364 Key Mask 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 The responder defines a bit in the mask for a key piece. 1370 Key piece A hash chain value is divided into (160 bit) key pieces 1371 by the responder. 1372 Combined key The initiator constructs a combined key using the key 1373 pieces. 1375 The AC ID is related to a divided secret, i.e. a hash chain value. 1376 Every key piece related to that value must have the same AC ID. 1378 Responder sending AC message: 1380 The key count field value in the AC packet is the total number of key 1381 pieces sent by the responder. I.e. the total number of sent AC 1382 packets. Each KEY-MASK TLV in one AC packet contains a key piece and 1383 corresponding bit on in the key mask field 1385 (Note: The responder is able to make a return routability test 1386 maximum for 32 addresses per divided key.) 1387 Initiator sending ACR message: 1389 The initiator makes an OR operation for all received key masks in the 1390 AC packets. The result of the operation is included in the KEY-MASK 1391 TLV in ACR message.The key count field in KEY-MASK TLV in the ACR 1392 message indicates the number of key pieces the initiator received 1393 from the responder. The combined key is included into the KEY-MASK 1394 TLV. 1396 7. State Machine 1398 The initiator of the context establishment exchange is called the 1399 initiator. Once the host-pair contexts are established, this initial 1400 distinction is lost. The sender of the REA message is called the 1401 initiator of the re-addressing exchange. In a case of state loss, the 1402 sender of the RESYNCH message becomes a responder. . 1404 The state machine is presented in a single system view, representing 1405 either an Initiator or a Responder. There is not a complete overlap 1406 of processing logic here and in the packet definitions. Both are 1407 needed to completely implement WIMP. 1409 Implementors must understand that the state machine, as described 1410 here, is informational. Specific implementations are free to 1411 implement the actual functions differently. 1413 7.1 States 1415 START , state machine start 1417 INIT-sent , INIT sent by initiator 1419 CCR-sent , CCR sent by initiator 1421 ESTABLISHED , host-pair context established 1423 ESTABLISHED-REA-sent , REA sent 1425 FAILED , host-pair context establishment failed 1427 7.2 State Processes 1429 +---------+ 1430 | START | 1431 +---------+ 1433 Datagram to send, send INIT and go to INIT-send 1434 Receive INIT, send CC and stay at START 1435 Receive CCR, process 1436 if successful, send CONF and go to ESTABLISHED 1437 if fail, stay at START 1438 Receive IP packet with unknown flowid, send RESYNC and stay at START 1439 Receive ANYOTHER, drop and stay at START 1441 +-----------+ 1442 | INIT-sent | 1443 +-----------+ 1445 Receive INIT, send CC and stay at INIT-sent 1446 Receive CCR, process 1447 if successful, send CONF and go to ESTABLISHED 1448 if fail, stay at INIT-sent 1449 Receive CC, process 1450 if successful, send CCR and go to CCR-sent 1451 if fail, stay at INIT-sent 1452 Receive ANYOTHER, drop and stay at INIT-sent 1453 Timeout, increment timeout counter 1454 If counter is less than INIT_RETRIES_MAX, send INIT and stay at INIT-sent 1455 If counter is greater than INIT_RETRIES_MAX, go to FAILED 1457 +----------+ 1458 | CCR-sent | 1459 +----------+ 1461 Receive INIT, send CC and stay at CCR-sent 1462 Receive CCR, process 1463 if successful, send CONF and go to ESTABLISHED 1464 if fail, stay at CCR-SENT 1465 Receive CONF, process 1466 if successful, go to ESTABLISHED 1467 if fail, stay at CCR-SENT 1468 Receive ANYOTHER, drop and stay at CCR-sent 1469 Timeout, increment timeout counter 1470 If counter is less than CCR_RETRIES_MAX, send CCR and stay at CCR-sent 1471 If counter is greater than CCR_RETRIES_MAX, go to FAILED 1473 +-------------+ 1474 | ESTABLISHED | 1475 +-------------+ 1477 REA to send, go to ESTABLISHED-REA-sent 1478 Receive RESYNC, send INIT and cycle at ESTABLISHED 1479 Receive CC, process 1480 if successful, send CCR and stay at ESTABLISHED 1481 if fail, drop, and stay at ESTABLISHED 1482 Receive CONF, process 1483 if successful, update host-pair context and cycle at ESTABLISHED 1484 if fail, drop, and stay at ESTABLISHED 1485 Receive REA, process 1486 if successful, update host-pair context, send ACs, 1487 and cycle at ESTABLISHED 1488 if fail, drop, and stay at ESTABLISHED 1489 Receive ACR, process 1490 if successful, update host-pair context, and cycle at ESTABLISHED 1491 if fail, drop, and stay at ESTABLISHED 1492 Receive IP packet for host-pair context, process and stay at ESTABLISHED 1493 Receive ANYOTHER, drop and stay at ESTABLISHED 1495 +-----------------------+ 1496 | ESTABLISHED-REA-sent | 1497 +-----------------------+ 1499 Receive RESYNC, send INIT and go to ESTABLISHED 1500 Receive REA, process 1501 if successful, update host-pair context, send ACs, 1502 and cycle at ESTABLISHED-REA-sent 1503 if fail, drop, and cycle at ESTABLISHED-REA-sent 1504 Receive AC, process 1505 if successful, send ACR, and go to ESTABLISHED 1506 if fail, sent REA, and cycle at ESTABLISHED-REA-sent 1507 Receive ACR, process 1508 if successful, update host-pair context, 1509 and cycle at ESTABLISHED-REA-sent 1510 if fail, drop, cycle at ESTABLISHED-REA-sent 1511 Receive IP packet for host-pair context, process, 1512 and stay at ESTABLISHED-AC-sent 1513 Receive ANYOTHER, drop and stay at ESTABLISHED-AC-sent 1514 Timeout, increment timeout counter 1515 If counter is less than REA_RETRIES_MAX, send REA, 1516 and stay at ESTABLISHED-REA-sent 1517 If counter is greater than REA_RETRIES_MAX, go to FAILED 1519 7.3 State Loss 1521 WIMP protocol and state machine is designed to recover from one of 1522 the parties crashing and losing its state. The following scenarios 1523 describe the main use cases covered by the design. 1525 No prior state between the two systems. 1527 The system with data to send is the Initiator. The process 1528 follows standard 4 packet context establishment exchange, 1529 establishing the host-pair context. 1531 The initiator has no state with the responder, but the responder 1532 has an earlier host-pair context. 1534 Initiator acts as in no prior state, sending INIT. The 1535 Initiator selects a new random ID(I) and the responder finally 1536 establishes a new host-pair context with the initiator. The old 1537 context will expire due to timers (TBD). 1539 The initiator has a host-pair context, but the responder does not. 1541 The responder 'detects' the situation when it receives a packet 1542 that contains an unknown flowid. The responder sends a RESYNC 1543 with received flowid and a NULL (zero) initiator ID. The 1544 initiator gets the RESYNC and initiates a new context 1545 establishment exchange to re-establish the host-pair context 1546 with the existing IDs. The initiator generates a new hash 1547 chain but sends the old challenge, to the responder. 1549 If a host reboots or times out, it has lost its host-pair context. 1550 If the system that lost state has a datagram to deliver to its peer, 1551 it simply restarts the context establishment exchange with INIT 1552 message containing a new ID(I). The responder replies with CC packet. 1554 If a system receives an IP packet for an unknown flowid, the 1555 assumption is that it has lost the state and its peer did not. In 1556 this case, the system replies with a RESYNCH packet. The ID(I) is 1557 typically NULL in the RESYNCH, since the system usually does not know 1558 the peer's ID any more. 1560 The system receiving the RESYNCH packet first checks to see if it has 1561 an established and recently used host-pair context with the party 1562 sending the RESYNCH. If such a context exists, the initiator 1563 initiates a new context establishment exhange by sending INIT 1564 message. Note that the process will result in a new host-pair 1565 context at the responder site, while the initiator is able to use the 1566 existing host-pair context. 1568 8. Security Considerations 1570 The initial design choice was to use reverse hash chains instead of 1571 public key technology. The reason for this was that there exists 1572 already a group of authenticated Diffie-Hellman key exhange 1573 protocols. However, protocols using public key technology are 1574 vulnerable for different kind of CPU related denial-of-service 1575 attacks. The trade-off between hash chain based message 1576 authentication and signatures is that hash chains are vulnerable for 1577 a class of man-in-the-middle attacks. However, if we accept that the 1578 first round-trip of the context establishment exchange is open for 1579 such attacks we obtain several advantages. The hash chain computation 1580 is a lightweight operation compared to signature verification. 1582 8.1 Context establishment exchange 1584 8.1.1 Man-in-the-Middle attacks 1586 The context establishment exchange is based on opportunistic 1587 authentication. In other words, both hosts, the initiator and 1588 responder, have to trust the first message comes from the authentic 1589 peer. The responder trusts that the INIT message comes from an 1590 authentic initiator. In a similar way, the initiator trusts that the 1591 CC message comes from an authentic responder. Therefore, the first 1592 round-trip is vulnerable for the MitM attacks. 1594 The second round-trip of the exchange bootstraps the hash chains and 1595 bounds the messages together. The anchor values revealed during the 1596 second round-trip are used to authenticate the first round-trip 1597 messages. A MitM attacker cannot change any values in the CCR 1598 message, because the message is authenticated with the responder's 1599 HMAC. The responder's HMAC, in turn, is computed over the initiator's 1600 HMAC. In this way, the responder does not need to establish a state 1601 once it receives INIT message. In addition, a MitM attacker cannot 1602 reserve a host-pair context by sending CCR message with initiator's 1603 ID because the messages are bound together. Finally, the hash chains 1604 have two main purposes. They bind messages together, and they are 1605 used to authenticate the messages. The hash chain properties were 1606 discussed in more detail in Section 2.1. 1608 8.1.2 Denial-of-Service attacks 1610 The initiator may use any identifier, ID(I), it wants with the 1611 responder. This property protects the initiator from a specific form 1612 of DoS attack. That is, the attacker is not able to establish a 1613 context with the responder using the initiator's identifier if the 1614 initiator chooses its identifier randomly. 1616 On the other hand, the beginning of the context establishment 1617 exchange is stateless for the responder in order to avoid attacks 1618 where the attacker is trying to create inconsistent states in the 1619 responder. The responder does a kind of return-routability test 1620 before establishing a state. The initiator has to prove that is 1621 reachable in the location where it sent the initial packet. The 1622 responder may optionally restrict establishing a host-pair context 1623 for an initiator if the responder already has several host-pair 1624 contexts related to same IP addresses. 1626 Basically, the context establishment protocol is vulnerable for a 1627 flowid related attack. The only value that is not protected with HMAC 1628 is the responder's flowid in the last message. The reason for this is 1629 that the responder cannot reserve any values before it creates a 1630 state. The state is created after receiving the CCR message. As a 1631 consequence, the responder cannot include the flowid into its HMAC in 1632 the CC message. a MitM attacker may change the responder's flowid on 1633 the fly in the last message and course a denial-of-service situation. 1634 In other words, the initiator will send IP packets with wrong flowid 1635 to the responder. However, the main objective of the protocol was to 1636 protect the hosts from the re-direction attacks and the presented 1637 attack does not open new vulnerabilities for that part. 1639 8.2 Re-addressing exchange 1641 When a site renumbers, a host inside the site must inform its peers 1642 about the new IP address(es). The sender of the new locator set is 1643 called an initiator. Once the responder receives REA message it 1644 cannot trust that the initiator is reachable at the new locations. To 1645 avoid different kind of DoS and redirection attacks the responder 1646 must verify that the initiator indeed is reachable at the claimed 1647 locations. 1649 the proposed protocol takes advantage of parallel paths between the 1650 hosts. The responder splits its hash chain value into pieces and 1651 protects each challenge (AC) message with one piece. Each of 1652 challenge messages is sent to different location. As a consequence, 1653 an attacker has to locate at different topological locations, at the 1654 same time, to be able to answer to the challenge. The initiator, in 1655 turn, is able to verify that all of the pieces came from the 1656 authentic responder. The secret splitting works only if there are 1657 more than one AC messages to be sent and the messages are routed via 1658 different paths to the initiator. (Note: To increase the security of 1659 the challenge message, the responder could protect the AC message 1660 with HMAC. The key in each message would then be a divided secret, 1661 i.e. a hash value.) 1663 9. IANA Considerations 1665 IANA has assigned IP Protocol number TBD to WIMP. 1667 10. Acknowledgments 1669 This draft is a result of the discussion between the authors, Pekka 1670 Nikander and Jari Arkko at the 58th IETF. The idea was to write a 1671 Multi6 draft using reverse hash chains and secret splitting. The main 1672 objective in this draft has been on identifying the hosts to their 1673 peers with reverse hash chains. Instead of inventing the wheel once 1674 again, we took several ideas from the existing protocol proposals. 1675 Therefore, there are certain similarities with SIM and HIP design 1676 factors. We would like to thank all contributers in those drafts that 1677 have affect the work. 1679 Normative references 1681 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1682 Levels", BCP 14, RFC 2119, March 1997. 1684 [2] Draves, R., "Default Address Selection for Internet Protocol 1685 version 6 (IPv6)", RFC 3484, February 2003. 1687 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1688 Specification", RFC 2460, December 1998. 1690 [4] Abley, J., Black, B. and V. Gill, "Goals for IPv6 1691 Site-Multihoming Architectures", RFC 3582, August 2003. 1693 [5] Kent, S., "IP Encapsulating Security Payload (ESP)", 1694 draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003. 1696 [6] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming 1697 solutions", draft-nordmark-multi6-threats-00.txt (work in 1698 progress), October 2003. 1700 [7] Lear, E. and R. Droms, "What's In A Name: Thoughts from the 1701 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), March 1702 2003. 1704 Informative references 1706 Authors' Addresses 1708 Jukka Ylitalo 1709 Ericsson Research Nomadiclab 1711 Jorvas FIN-02420 1712 FINLAND 1714 Phone: +358 9 299 1 1715 EMail: jukka.ylitalo@ericsson.com 1717 Vesa Torvinen 1718 Ericsson Research Nomadiclab 1720 Turku FIN-20520 1721 FINLAND 1723 Phone: +358 9 299 1 1724 EMail: vesa.torvinen@ericsson.com 1726 Erik Nordmark 1727 Sun Microsystems, Inc. 1728 17 Network Circle 1729 Mountain View, CA 1730 USA 1732 Phone: +1 650 786 2921 1733 EMail: erik.nordmark@sun.com 1735 Appendix A. Example of secure reverse hash chain generation 1737 This Appendix gives an example for secure hash chain generation. 1739 Initiator (context establishment and re-addressing exchanges): 1741 Hn(I) = SHA1(secret(I)|ID(I)|ID(R)|challenge(I)) 1742 ... 1743 H1(I) = SHA1(H2(I)) 1744 H0(I) = SHA1(H1(I)) 1746 Responder (context establishment exchange): 1748 Hn(R) = SHA1(secret(R)|ID(R)|ID(I)|challenge(I)) 1749 Note: challenge(I) is generated by the initiator 1750 ... 1751 H1(R) = SHA1(H2(R)) 1752 H0(R) = SHA1(H1(R)) 1754 The default length of both of the hash chains is n=10. 1756 secret(I) = 256 bit secret random number generated by the initiator 1757 secret(R) = 256 bit secret random number generated by the responder 1758 challenge(I) = 128 bit public random number generated by the initiator 1759 Hk(I/R) = initiator's/responder's 160 bit hash chain value 1760 ID(I/R) = initiator's/responder's 128 bit identifier 1762 The secret(I/R) is not revealed to the peers. The long term 1763 secret(R) MUST survive when the system boots. The responder SHOULD 1764 use the same secret(R) for different hash chains generated during the 1765 lifetime of the secret(R). 1767 Appendix B. Goals for IPv6 Site-Multihoming Architectures 1769 This section compares the proposed solution with the goals of IPv6 1770 site multihoming architecture [4]. 1772 B.1 Redundancy 1774 The proposed end-to-end protocol allows applications to use multiple 1775 IPv6 addresses. Furthermore, the WIMP layer is able to receive events 1776 from different sources: from upper and lower layers. L2 may inform 1777 WIMP, e.g, if the local link is down. L4, in turn, may launch a 1778 trigger due to TCP time-outs. Finally, the redundancy is a question 1779 of local triggers, implementation and address selection policy. (The 1780 address selection policy should be separated from the core protocol 1781 draft) 1783 B.2 Load Sharing 1785 The identifier and locator-set separation makes it possible to 1786 implement dynamic load sharing. The sender is able to select source 1787 and destination IP addresses on packet basis. The sender and receiver 1788 may have several parallel paths between then; both of the hosts being 1789 multi-homed at the same time. (Note: However, sending TPC packets via 1790 alternative paths may lead to poor performance.) 1792 B.3 Performance 1794 The protocol defined in this draft does not directly interoperate 1795 with Internet routing protocols. However, the implementation should 1796 follow source address routing principles. In other words, the next 1797 hop router, and its prefix, defines the used source address. However, 1798 a host with one interface typically receives multiple prefixes from 1799 one access router. Congestion related to a path should be identified 1800 using RTT and bandwidth values as triggers for hand-offs between 1801 addresses. 1803 B.4 Policy 1805 The proposed solution does not take a stand on the reason why 1806 multihoming is used. The solution provides support for 1807 site-multihoming for external policy reasons. If the responder has 1808 stored several IP addresses to the DNS, the initiator may assume that 1809 the responder supports multihoming. (Note: there are several other 1810 ways using DNS to inform the initiator that the peer supports 1811 multihoming.) 1813 B.5 Simplicity 1815 Proposed solution is straightforward to deploy and maintain. It is 1816 not more complex to deploy and operate than current IPv4 multihoming 1817 practices. The protocol supports legacy IPv6 socket API. 1819 B.6 Transport-Layer Survivability 1821 The proposed solution provides re-homing transparency for 1822 transport-layer sessions. The existing transport-layer sessions are 1823 able to use the new path because the upper layer identities are 1824 separated from the network topology. 1826 B.7 Impact on DNS 1828 No impacts on DNS RR records. 1830 B.8 Packet Filtering 1832 The solution does not preclude filtering. 1834 B.9 Scalability 1836 The proposed protocol is responsible for changing the default path, 1837 source and destination IP addresses, to another if the peer is not 1838 reachable via some route. The routing desicion is made at the 1839 end-host. 1841 B.10 Impact on Routers 1843 The proposed solution does not require changes to IPv6 router 1844 implementations. 1846 B.11 Impact on Hosts 1848 A host that has not implemented the proposed solution can still work 1849 in a multihomed site. The solution requires changes to the end-host 1850 stack, however, these changes are logically separate functions that 1851 can be added to existing functions. The solution does not require 1852 changes to the socket API or the transport layer. 1854 B.12 Interaction between Hosts and the Routing System 1856 The solution does not require interaction between a site's hosts and 1857 its routing system. 1859 B.13 Operations and Management 1861 The staff responsible for the operation of a site is able to 1862 advertise any prefixes it wants for the hosts. The site multihoming 1863 system can be configured advertising different set of prefixes. 1865 B.14 Cooperation between Transit Providers 1867 The solution does not require cooperation between transit providers. 1869 B.15 Security compared to IPv4 multihoming 1871 The proposed solution is vulnerable for man-in-the-middle attack in 1872 the first message exchange because it relies on opportunistic 1873 security principles. The security properties are analyzed in Section 1874 8. 1876 Appendix C. Things MULTI6 Developers should think about 1878 This section answers to the questions presented in the 1879 draft-lear-multi6-things-to-think-about-00. 1881 C.1 Routing 1883 "How will your solution solve the multihoming problem?" 1885 By definining a new logical layer between networking (L3) and 1886 transport (L4) layers. The logical layer separates identifiers from 1887 locators. The dynamic one-to-many binding between an identifier and 1888 IP addresses makes multihoming possible. The identifiers are used by 1889 upper layers, while the IP addresses are used on the wire. 1891 "Does your solution address mobility?" 1893 The proposal does not define any rendevouz server, but allows dynamic 1894 address updates between hosts. 1896 C.2 Identifiers and locators 1898 "Does your solution provide for a split between identifiers and 1899 locators?" 1901 Yes. The responder's identifier is a 128-bit hash of FQDN. The 1902 initiator's identifier, in turn, is a hash of a nonce for security 1903 reasons. 1905 "What is the lifetime of a binding from an identifier to a locator?" 1907 The lifetime of a binding is the lifetime of open sockets. As long as 1908 there are open connections between end-points, the corresponding 1909 host-pair context should not be deleted. However, the binding can be 1910 dynamically updated. 1912 "How is the binding updated?" 1914 By re-addressing exchange. 1916 "Will transport connections remain up?" 1918 Yes. 1920 C.3 On The Wire 1922 "At what layer is your solution applied, and how?" 1923 At logical layer between networking (L3) and tranport (L4) layers. 1925 "Is it applied in every packet? If so, what fields are used?" 1927 It is applied in every packet by using flowid field in the IPv6 1928 header 1930 "Why is the layer you chose the correct one?" 1932 The implementation does not affect the upper layers nor applications. 1934 "Does your solution expand the size of an IP packet?" 1936 Only during the context establishment and re-addressing exchanges. 1937 The IP payload packets use flowid field to identify packets. 1939 "Do you change the way fragmenting is handled?" 1941 Not in the normal IPv6 packets. The packets carrying context 1942 establishment or re-addressing exchange messages must not be 1943 fragmented. 1945 "Are there any changes to ICMP error semantics?" 1947 No. However, the presented packet formats can be implemented as ICMP 1948 extension fields. 1950 C.4 Names, Hosts, Endpoints, or none of the above? 1952 "Please explain the relationship of your solution to DNS" 1954 The proposal assumes that a host is multi-homed if it has several 1955 AAAA RR entries in the DNS. 1957 "Please explain interactions with "2-faced" DNS" 1959 No effect 1961 "Does your solution require centralized registration?" 1963 Every server (responder) must have a basic DNS entry, containing FQDN 1964 and locator set, as nowadays 1966 "Have you checked for DNS circular dependencies?" 1968 The solution is dependent of FDQN and locator set mapping 1970 "What if a DNS server itself is multihomed?" 1971 No effect. 1973 "What application/API changes are needed?" 1975 None. 1977 "Is this solution backward compatible with "old" IP version 6?" 1979 Yes. The new identifiers are identified with two highest bits in the 1980 128-bit identifier, like in the HIP. 1982 "Is your solution backward compatible with IPv4?" 1984 The 6to4 gateway must work as an authentication proxy. TBD. 1986 "How will your solution interact with other middle-boxes?" 1988 TBD. 1990 "Are there any implications for scoped addressing?" 1992 TBD. 1994 "Are there any layer 2 implications to your proposal?" 1996 None. 1998 "How will your solution handle referrals, such as those within FTP?" 2000 TBD. 2002 "Are you introducing a namespace that might involve mnemonics?" 2004 No. 2006 Intellectual Property Statement 2008 The IETF takes no position regarding the validity or scope of any 2009 intellectual property or other rights that might be claimed to 2010 pertain to the implementation or use of the technology described in 2011 this document or the extent to which any license under such rights 2012 might or might not be available; neither does it represent that it 2013 has made any effort to identify any such rights. Information on the 2014 IETF's procedures with respect to rights in standards-track and 2015 standards-related documentation can be found in BCP-11. Copies of 2016 claims of rights made available for publication and any assurances of 2017 licenses to be made available, or the result of an attempt made to 2018 obtain a general license or permission for the use of such 2019 proprietary rights by implementors or users of this specification can 2020 be obtained from the IETF Secretariat. 2022 The IETF invites any interested party to bring to its attention any 2023 copyrights, patents or patent applications, or other proprietary 2024 rights which may cover technology that may be required to practice 2025 this standard. Please address the information to the IETF Executive 2026 Director. 2028 Full Copyright Statement 2030 Copyright (C) The Internet Society (2004). All Rights Reserved. 2032 This document and translations of it may be copied and furnished to 2033 others, and derivative works that comment on or otherwise explain it 2034 or assist in its implementation may be prepared, copied, published 2035 and distributed, in whole or in part, without restriction of any 2036 kind, provided that the above copyright notice and this paragraph are 2037 included on all such copies and derivative works. However, this 2038 document itself may not be modified in any way, such as by removing 2039 the copyright notice or references to the Internet Society or other 2040 Internet organizations, except as needed for the purpose of 2041 developing Internet standards in which case the procedures for 2042 copyrights defined in the Internet Standards process must be 2043 followed, or as required to translate it into languages other than 2044 English. 2046 The limited permissions granted above are perpetual and will not be 2047 revoked by the Internet Society or its successors or assignees. 2049 This document and the information contained herein is provided on an 2050 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2051 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2052 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2053 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2054 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2056 Acknowledgment 2058 Funding for the RFC Editor function is currently provided by the 2059 Internet Society.