idnits 2.17.00 (12 Aug 2021) /tmp/idnits58383/draft-nagarajan-multi6-comparison-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1250. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1266), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 8 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 (October 18, 2004) is 6417 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: '9' is defined on line 1194, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1206, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-noid-01 == Outdated reference: A later version (-01) exists of draft-ylitalo-multi6-wimp-00 == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-threats-01 == Outdated reference: A later version (-01) exists of draft-huston-multi6-architectures-00 -- No information found for draft-crocker-multiaddr-analysis - is the name correct? == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 == Outdated reference: A later version (-01) exists of draft-eggert-hip-rendezvous-00 == Outdated reference: A later version (-02) exists of draft-nikander-hip-mm-01 Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Multi6 A. Nagarajan 2 Internet-Draft H. Tschofenig 3 Expires: April 18, 2005 Siemens 4 October 18, 2004 6 Comparative Analysis of Multi6 Proposals using a Locator/Identifier 7 Split 8 draft-nagarajan-multi6-comparison-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 18, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 An IP address serves as a locator and an identifier in the classical 42 Internet environment. This dual role of the IP address makes 43 mobility and multihoming a challenging task. There have been various 44 proposals to overcome this limitation, particularly from the Multi6 45 working group. 47 This memo makes a comparative analysis of these proposals that 48 support a locator/identifier split for multihoming in IPv6 from the 49 security point of view. The purpose is also to provide a common 50 framework under which future proposals can be compared and chosen for 51 various security requirements. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Strong Identity Multihoming . . . . . . . . . . . . . . . . . 4 57 2.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4 58 2.2 SIM Protocol Overview . . . . . . . . . . . . . . . . . . 4 59 2.3 SIM Security Considerations . . . . . . . . . . . . . . . 5 60 3. Multihoming without Identifiers . . . . . . . . . . . . . . . 9 61 3.1 Notational Conventions . . . . . . . . . . . . . . . . . . 9 62 3.2 NOID Protocol Overview . . . . . . . . . . . . . . . . . . 9 63 3.3 NOID Security Considerations . . . . . . . . . . . . . . . 10 64 4. Multihoming using 64-bit Crypto-Based IDs . . . . . . . . . . 12 65 4.1 Notational Conventions . . . . . . . . . . . . . . . . . . 12 66 4.2 CB64 Protocol Overview . . . . . . . . . . . . . . . . . . 13 67 4.3 CB64 Security Considerations . . . . . . . . . . . . . . . 14 68 5. Weak Identifier Multihoming Protocol . . . . . . . . . . . . . 15 69 5.1 Notational Conventions . . . . . . . . . . . . . . . . . . 15 70 5.2 WIMP Protocol Overview . . . . . . . . . . . . . . . . . . 16 71 5.3 WIMP Security Considerations . . . . . . . . . . . . . . . 17 72 6. Location Independent Network . . . . . . . . . . . . . . . . . 19 73 6.1 Notational Conventions . . . . . . . . . . . . . . . . . . 19 74 6.2 LIN6 Protocol Overview . . . . . . . . . . . . . . . . . . 20 75 6.3 LIN6 Security Considerations . . . . . . . . . . . . . . . 21 76 7. Host Identity Protocol . . . . . . . . . . . . . . . . . . . . 24 77 7.1 Notational Conventions . . . . . . . . . . . . . . . . . . 24 78 7.2 HIP Protocol Overview . . . . . . . . . . . . . . . . . . 24 79 7.3 HIP Security Considerations . . . . . . . . . . . . . . . 25 80 8. Other Security Considerations . . . . . . . . . . . . . . . . 28 81 9. Comparison of Multi6 Proposals . . . . . . . . . . . . . . . . 29 82 10. Security Considerations . . . . . . . . . . . . . . . . . . 30 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 85 11.2 Informative References . . . . . . . . . . . . . . . . . . . 31 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 87 Intellectual Property and Copyright Statements . . . . . . . . 33 89 1. Introduction 91 The Multi6 group aims at providing potential solutions for 92 multihoming support in IPv6. Most of these proposals try to define a 93 new convergence layer operating between the classic internet and the 94 transport layers [8]. This eventually splits the dual role of the IP 95 from being both locators and identifiers to only locators. For 96 naming the end hosts, new identifiers are thought of. Such locator/ 97 identifier split multihoming solutions bring in new security 98 considerations. 100 The IETF draft [6] discusses some common threats relating to IPv6 101 multihoming solutions. In this memo we look into the security issues 102 of some Multi6 proposals that deal with the locator/identifier split 103 and try to compare them on the basis of the threats draft. We look 104 at the proposals from the following point of view: There is a 105 protocol which establishes state at two endpoints. For future state 106 updates (in case of multihoming and mobility) an authorization 107 problem exists as to who is allowed to modify the pre-established 108 state and how. We analyse the properties of the proposed protocols. 110 2. Strong Identity Multihoming 112 The SIM proposal [1] assumes that the problem to be solved is site 113 multihoming, with the ability to have the set of site locator 114 prefixes change over time due to site renumbering. It also assumes 115 that public key signatures are not required for normal communication. 116 They are used for verification only at the time of locator prefix 117 changes for a host or when two hosts claim to use the same 118 identifier. 120 This proposal aims to achieve site multihoming by introducing an M6 121 shim layer between the classic IP and the transport layer. All the 122 applications and the upper layer protocols use identifiers to name 123 the hosts. These identifiers are hashes of the public key of the 124 hosts. The network layer uses IPv6 to locate the hosts on the 125 internet. The M6 layer is an extension header between the IP and the 126 transport layer that maps the identifiers to the locators and vice 127 versa. From the perspective of the upper layers, the packets seem to 128 travel end to end using identifiers, although they are rewritten with 129 locators on flight. 131 2.1 Notational Conventions 133 A is the initiating host and B is the responding host. X is a 134 potentially malicious host. 136 FQDN (A) is the domain name for A. 138 Ls(A) is the locator set for A, which consists of L1 (A), L2 (A) 139 until Ln (A). 141 ID(A) is an application ID for A.ID(A) is a 128 bit number 142 consisting of two fixed bits (e.g., 10) followed by 126 bits of a 143 truncated SHA1 hash of a public key that the host has generated. 145 CT(A) is a 64 bit "context tag" allocated by A and used when B 146 sends packets to A. The packets contain the low-order 32 bits of 147 the tag, named CT32 (A). The full tag is used for DoS-attack 148 prevention during the PK challenge/response. 150 2.2 SIM Protocol Overview 152 The SIM proposal is composed of two parts. The protocol starts with 153 a 3-way hand shake between the communicating parties where a context 154 state is established in the M6 layer. The context state includes 155 information on the peer and local identities, the locator set of the 156 peer and the local host, the verification status of each locator of 157 the peer and the context tags of the initiator and the receiver. The 158 context establishment as illustrated in Figure 1is composed of the 159 Context Request, Context Response and the Context Confirm messages. 160 The details of this message exchange can be looked into the IETF 161 draft [1]. 163 I with ID(I) at L1(I) 164 R with ID(R) at L1(R) 166 I-->R, CReq :Nonce(I),ID(I),ID(R),CT(I) 168 R-->I, CRes :Nonce(I),Context[ID(I),ID(R),CT(I),CT(R), 169 L1(I),L1(R)],TimeStamp,Hash(Context,TimeStamp) 171 I-->R, CCon :Context[ID(I),ID(R),CT(I),CT(R),L1(I),L1(R)], 172 Hash(Context,TimeStamp) 174 Figure 1: SIM protocol Context Establishment 176 The second part of the SIM proposal is the challenge request-response 177 protocol shown in Figure 2 that is used when one of the hosts changes 178 its locator. The protocol relies on the fact that the mobile node 179 can prove the knowledge of the 64 bit context tags of both the 180 initiator and the receiver that was used only at the time of state 181 establishment. 183 I with ID(I) at L2(I) 184 R with ID(R) at L1(R) 186 I-->R, Data packet from unknown locator L2(I) 188 R-->I, ChaReq:Nonce(R),ID(I),ID(R),CT32(R),L2(I) 190 I-->R, ChaRes:[Nonce(R),CT32(R),L2(I), 191 Hash(Nonce(R),ID(I),ID(R),CT(I),CT(R)),PK(R)]Sign(R) 193 Figure 2: SIM protocol Readdressing 195 2.3 SIM Security Considerations 197 The initiator of the communication first tries to establish a 198 host-pair context with the peer based on information it learns from 199 the DNS.The responder later establishes some initial state with the 200 initiator using the context creation 3-way handshake. Locator 201 updates are later possible using signature verifications. However, 202 it is very crucial that these locator changes be authenticated to 203 avoid man in the middle attacks. 205 In order to prevent such attacks during locator updates, the SIM 206 protocol relies on the ability to verify that the entity requesting 207 redirection indeed holds the private key where the hash of the 208 corresponding public key hashes to the ID itself. 210 1. PREMEDIATED REDIRECTION 212 From our analysis of this proposal, it is evident that a 213 premediated redirection attack[6] on host B is possible due to 214 the absence of an initiator authentication. When host A 215 initiates a communication with B based on a DNS look up for B, 216 B initiates a 3-way exchange in order to establish a context 217 among themselves. However, B does not make any attempt to 218 reverse look up A in order to verify that A is who he claims 219 to be. They eventually establish a context pair and start 220 exchanging data packets. A malicious host X could easily 221 claim to be A and encourage B to exchange data with it 222 attempting a premediated redirection attack. A reverse lookup 223 with the L(X)->FQDN and then forward lookup for FQDN->ID(X) 224 would prove if X is who he claims to be. SIM fails to do this 225 and remains unknown about the redirection until A genuinely 226 initiates a communication with B. 228 2. REDIRECTING PACKETS TO ATTACKER 230 Any protocol that does not know how to authenticate locator 231 changes for a mobile host is open to redirection attacks. The 232 SIM protocol however uses public key signature verifications 233 to verify locator updates and is not susceptible to such 234 attacks. If Host X claims to be A that has just moved and 235 encourages B to send data packets to it, it (and A) will 236 receive a challenge request from B. B waits until it receives 237 the first correct response signed with the private key that 238 corresponds to the public key of A. It would be impossible 239 for anybody other than A (even X) to sign using A's private 240 key. However, host X could attempt to increase the cost of 241 computation on B's side by compelling it to verify more and 242 more signatures. This by itself could be a denial of service 243 attack. 245 3. REDIRECTING PACKETS TO A BLACK HOLE 247 This variant of the classic redirection attacks [6] is 248 different because this forces a host to send packets to a 249 nonexistent locator and eventually dropping them off. 251 Assuming that A and B are already communicating and X sends a 252 locator update to B claiming that it is A and has moved (to a 253 black hole), both A and the black hole locator receive 254 challenge requests from B. It is evident that only A sends an 255 acceptable response forcing B to ignore the locator update 256 from X. 258 4. REDIRECTING PACKETS TO A THIRD PARTY 260 Mechanisms that prevent the previous redirection attacks can 261 prevent this one too. Assuming that A and B are already 262 communicating, the SIM proposal makes sure that no other host 263 other than A itself would be able to authenticate to B on the 264 basis of a challenge response that is signed with A's private 265 key. 267 5. PACKET INJECTION 269 The SIM protocol introduces a M6 shim layer between the IP and 270 the transport layers. This M6 layer is just an extension 271 header for the data packets as shown below. It would be 272 suffice for an attacker X to learn just the 32 bit context tag 273 to inject false packets in a sequence. Though it would be 274 difficult for nodes out of path between A and B to guess the 275 context tag, it would be sufficiently easy for those between 276 the communicating nodes to learn their context tags, create 277 new forged packets and inject them. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Next Header | Type=0 (data) | Checksum | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Context Tag | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: M6 packet header 289 This situation is no different from other IP packets of today 290 which do not experience any IPsec protection. As a proposed 291 solution, IPsec could be used along with the SIM proposal. 293 6. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS 294 During the initial phase of the context establishment, the 295 proposal avoids using heavy computations in order to remain 296 stateless. It does not introduce PK signature verifications 297 until there is a locator change and necessitates one. 298 However, this could in turn present a resource exhaustion 299 denial of service attack. The attacker could spoof one or 300 many challenge response packets to the receiver and force it 301 to do heavy PK signature verifications. This would exhaust 302 the responser's resources posing a denial of service to the 303 original initiator. 305 3. Multihoming without Identifiers 307 The NOID proposal [2] assumes that the problem to be solved is site 308 multihoming, with the ability to have the set of site locator 309 prefixes change over time due to site renumbering. It also assumes 310 that the DNS infrastructure can be used for verification of the 311 relationship between locators on both the initiator of communication 312 and the responding peer. Further, doing a reverse look up for each 313 locator in the locator set to its FQDN is assumed not to create 314 significant problem. 316 NOID proposes an approach for endpoint identifier and locator 317 separation where the endpoint identifier space is drawn from the 318 locator space. Instead of creating a new namespace for endpoint 319 identifiers, the endpoint identifier may be chosen from the set of 320 locators itself. This initial locator could be used for 321 communication among hosts until one of them necessitate a locator 322 update. 324 3.1 Notational Conventions 326 A is the initiating host and B is the responding host. X is a 327 potentially malicious host. 329 FQDN (A) is the domain name for A. 331 Ls(A) is the locator set for A, which consists of L1 (A), L2 (A) 332 until Ln (A). 334 AID (A) is an application ID for A. In this proposal, AID (A) is 335 always one member of Ls (A). 337 3.2 NOID Protocol Overview 339 The NOID proposal is composed of two parts. The protocol starts with 340 a 3-way hand shake between the communicating parties where a context 341 state is established in the M6 layer. The context state includes 342 information on peer locator which the upper layer protocol uses as 343 the AID, the local locator which the application uses as the AID, the 344 locator set of the peer and the local host, the verification status 345 of each locator of the peer and the FlowIDs of the initiator and the 346 receiver. The second part of the NOID proposal is the locator 347 updates. Assuming that the initiator is mobile and sends a packet to 348 the receiver from a new locator L2(I), the receiver would now have to 349 perform some return routability test to make sure that the L2(I) 350 indeed belongs to the initiator. For this, NOID relies on DNS 351 verifications. The receiver performs a reverse look up for L2(I) to 352 see if L2 belongs to the locator set of I. This way, it confirms 353 that I is reachable at L2 and makes L2 as the preferred locator. 355 I with AID(I) at L1(I) 356 R with AID(R) at L1(R) 358 I-->R, CReq :Nonce(I),AID(I),AID(R),FlowID(I) 360 R-->I, CRes :Nonce(I),Context[AID(I),AID(R),FlowID(I),FlowID(R), 361 L1(I),L1(R)],TimeStamp,Hash(Context,TimeStamp) 363 I-->R, CCon :Context[AID(I),AID(R),FlowID(I),FlowID(R),L1(I),L1(R), 364 TimeStamp,Hash(Context,TimeStamp) 366 Figure 4: NOID protocol Context Establishment 368 3.3 NOID Security Considerations 370 Conceptually, the NOID proposal is similar to that of the SIM. It 371 adds a layer to the middle of IP above most IP processing, but below 372 IPsec, fragmentation and reassembly functions [7]. It assigns one of 373 the locators in the locator set of a host as the host identifier and 374 uses global DNS as a mapping system between IDs and Locators. 376 Since the NOID proposal does not make use of cryptographic 377 identifiers, it does not perform PK signature verifications like the 378 SIM. As an alternative to prevent redirection attacks, it relies on 379 the DNS (for the hosts which support this protocol) being maintained 380 with consistent forward and reverse maps. 382 1. PREMEDIATED REDIRECTION 384 We understand that the NOID proposal is quite secure from the 385 premediation attacks [6] due to timely reverse DNS lookups. 386 When an attacker X using L(X) spoofs like host A and sends a 387 M6 data packet to B to start a communication, B does not 388 authenticate X at this point. It sends the context request 389 message to initiate the 3 way exchange and waits for the 390 context response message from the initiator. However, after B 391 sends the context confirm message to the initiator, it starts 392 asynchronously and incrementally extracting and verifying the 393 locator set of the initiator from the DNS. This verification 394 would fail as L(X) would not look up to FQDN(A).NOID suggests 395 such packets be dropped and an unknown context error be sent. 397 2. REDIRECTING THE PACKETS 399 In NOID, redirection attacks on the pretext of locator changes 400 are not possible by an attacker. This is because as soon as a 401 host receives packets from a new locator, it first looks up 402 the context states (already has a list of verified locators) 403 using the flow ID and the locators. If this look up succeeds 404 then the locator is acceptable for incoming packets. However, 405 if the locator has not been verified then it puts the new 406 locator on the top in the list of asynchronous DNS 407 verifications that are needed to be made. Assuming that A and 408 B are already communicating and X (using L(X) and FQDN(A)) is 409 attempting a redirection attack on B, X will never be 410 successful as its L(X) will not be looked up to FQDN (A) in 411 the DNS records. 413 The strength of the NOID proposal relies on the DNS look up 414 and it is important that any genuine host has authentic DNS 415 records. It is out of the scope of this draft to look at such 416 security threats. The DNS reverse look up method prevents all 417 kinds of redirection attacks including those to the attacker, 418 a third party or a black hole. 420 3. PACKET INJECTION 422 The current draft of the NOID proposal does not talk in detail 423 about the format of the data packets. It is however clear 424 that any node in the path between the hosts can look at the 425 source and destination locators and the flow IDs of the 426 packets being exchanged. Therefore, it should not be 427 difficult to inject false packets or manipulate the flow IDs 428 to affect the original data stream. 430 4. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS 432 The NOID proposal uses DNS look up to authenticate the peer 433 host and for locator changes verifications. Since DNS look up 434 are so important in NOID, it is also important that the DNS 435 that is looked up into also has only authentic DNS records. 436 Hence, a host could use a signed DNS zone or some secure 437 mechanism for forward or reverse look ups. For instance, when 438 an attacker X pretending to be host A, spoofs one or many 439 packets to host B, host B would put the locators of X on the 440 top of the list for DNS verifications. If it is a signed DNS 441 zone or a secure look up mechanism, it would end up consuming 442 a lot of resources of B. 444 4. Multihoming using 64-bit Crypto-Based IDs 446 The CB64 proposal [3] is remarkably similar to the NOID and the SIM 447 proposals. It assumes that the problem to be solved is site 448 multihoming, with the ability to have the set of site locator 449 prefixes change over time due to site renumbering. It also assumes 450 that public key signatures are not required for normal communication. 451 They are used for verification only at the time of locator prefix 452 changes for a host or when two hosts claim to use the same 453 identifier. 455 According to the NOID proposal, hosts that interact with each other 456 are identified using the AIDs or application IDs. AIDs are also a 457 part of Ls and are of 128 bits. NOID makes use of flow IDs so that 458 mapping to the correct AID at the receiving end can be accomplished. 460 According to the SIM proposal, hosts that interact with each other 461 use 128 bit cryptographic identifiers that consist of a truncated 462 SHA1 hash of a public key that the host has generated. SIM also 463 makes use of context tags that allow the receiver to find the correct 464 context without relying on the locators in the packet. 466 CB64 tries to keep the AID and the Flow ID of NOID. However, AIDs in 467 CB64 are a combination of locators and cryptographic identifiers. 468 ID(A) which is a 64 bit hash of the public key is embedded in the 469 lower order bits of AID(A) [which is a part of the Ls (A)]. The 470 upper 64 bits is the subnet locator. 472 4.1 Notational Conventions 474 A is the initiating host and B is the responding host. X is a 475 potentially malicious host. 477 FQDN (A) is the domain name for A. 479 ID(A) is the 64 bit CBID for A 481 Ls(A) is the locator set for A, which consists of L1(A), L2(A), 482 until Ln(A). Each Lk(A) contains ID(A) in the low-order bits. 483 The high-order 64 bits of a locator are sometimes referred to as 484 the "subnet locator".(The protocol does not prevent a single host 485 having multiple identities, but that can be viewed multiple 486 entities A, B etc existing on the same host). 488 AID (A) is an application ID for A. In this proposal, AID (A) is 489 always one member of Ls (A). 491 4.2 CB64 Protocol Overview 493 The CB64 proposal is made of two parts. The protocol starts with a 494 3-way hand shake between the communicating parties where a context 495 state is established in the M6 layer. The context state includes 496 information on peer locator which the upper layer protocol uses as 497 the AID, the local locator which the application uses as the AID, the 498 locator set of the peer with each containing the same 64 bit ID in 499 the lower bits, the locator set of the local host with each locator 500 containing the same 64 bit ID in the lower bits, the verification 501 status of each locator of the peer and the FlowIDs of the initiator 502 and the receiver. 504 I with AID(I) at L1(I) 505 R with AID(R) at L1(R) 507 I-->R, CReq :Nonce(I),AID(I),AID(R),FlowID(I) 509 R-->I, CRes :Nonce(I),Context[AID(I),AID(R),FlowID(I),FlowID(R), 510 L1(I),L1(R)],TimeStamp,Hash(Context,TimeStamp) 512 I-->R, CCon :Context[AID(I),AID(R),FlowID(I),FlowID(R),L1(I),L1(R), 513 TimeStamp,Hash(Context,TimeStamp) 515 Figure 5: CB64 protocol Context Establishment 517 The second part of the CB64 proposal is the challenge 518 request-response protocol that is used when one of the hosts changes 519 its locator. The protocol relies on the fact that the mobile node 520 can prove the knowledge of the FlowIDs of both the initiator and the 521 receiver that was used only at the time of state establishment. 523 I with AID(I) at L2(I) 524 R with AID(R) at L1(R) 526 I-->R, Data packet from unknown locator L2(I) 528 R-->I, ChaReq:Nonce(R),AID(I),AID(R),FlowID(R),L2(I) 530 I-->R, ChaRes:[Nonce(R),FlowID(R),L2(I), 531 Hash(Nonce(R),AID(I),AID(R),FlowID(I),FlowID(R))PK(R)]Sign(R) 533 Figure 6: CB64 protocol Readdressing 535 4.3 CB64 Security Considerations 537 CB64 uses 128 bit locators that are embedded with the cryptographic 538 identifiers to locate a host on the internet. Similar to the NOID 539 proposal, it does not use separate identifiers (like the SIM 540 proposal) but assigns one of these locators as the application 541 identifier for a host. However, since application identifiers hold 542 cryptographic identifiers, CB64 performs PK signature verifications 543 similar to SIM for locator updates verifications. 545 In order to prevent redirection attacks during locator updates, the 546 CB64 protocol relies on the ability to verify that the entity 547 requesting redirection indeed holds the private key where the hash of 548 the corresponding public key hashes to the ID itself. 550 1. PREMEDIATED REDIRECTION 552 From our analysis of this proposal, it is evident that a 553 premediated redirection attack [6] on host B is possible due 554 to the absence of an initiator authentication. This scenario 555 is quite similar to that of the SIM proposal 557 2. Other security issues 559 All the security issues of CB64 are exactly similar to that of 560 the SIM. This is because both the SIM and the CB64 rely on 561 similar PK signature verification mechanism for locator 562 changes authentication. Therefore, it is strongly recommended 563 that security considerations of the SIM proposal be referred. 565 5. Weak Identifier Multihoming Protocol 567 The WIMP proposal [5] uses a new logical layer between networking and 568 transport layers that separates the end-point identifier and locator 569 roles from each other. The identifiers are used to name the 570 end-points, while IPv6 addresses are used for routing purposes. 571 Identifiers in WIMP are 128-bit non-routable IDs that are never used 572 in packets on the network. These IDs are locally generated for both 573 local and remote nodes by hashing a nonce (for the initiator's 574 endpoint identity) and the FQDN (for the responder's endpoint 575 identity). The WIMP layer manages the mapping between IDs and 576 locators based on internal state. 578 Communication between two end-points requires establishment of a WIMP 579 session. Once the session is established, it can be used for 580 multiple simultaneous or sequential connections to the same 581 end-point. During WIMP session establishment, WIMP introduces a 582 separate header into the data packets, between the IP and TCP/UDP 583 headers that contains information about the WIMP session. WIMP does 584 not introduce a separate header into all IPv6 (data) packets. 585 Instead, once a WIMP session is established, the IPv6 FlowID is used 586 to hold an identifier for the WIMP host-pair context associated with 587 a given packet. The FlowIDs serve as a convenient "compression tag" 588 without increasing the packet size. 590 5.1 Notational Conventions 592 A is the initiating host and B is the responding host. X is a 593 potentially malicious host. 595 ID(I) is an identifier for I and ID(R) is an identifier for R. 597 FQDN(R) is the domain name for R. 599 Ls(I) is the locator set for I, which consists of L1(I), L2(I) 600 until Ln(I). 602 Ls(R) is the locator set for R. 604 F(I) is a FlowID assigned by the initiator and used by the 605 responder. The responder uses F(I) in packets going to the 606 initiator. 608 F(R) is a FlowID assigned by the responder and used by the 609 initiator. 611 Hk(I) is k-th hash value in the initiator's reverse hash chain. 612 The H0(I) is the first revealed value, i.e. the "anchor" of the 613 reverse hash chain. Note that the parameter k defines the 614 revealing order, not the computation order. 616 Hk(R) is k-th hash value in a responder's reverse hash chain. 618 5.2 WIMP Protocol Overview 620 CONTEXT ESTABLISHMENT 621 Initiator Responder 623 compute hash chain 624 generate random ID(I) 625 select flowid F(I) 627 INIT: IDs, challenge_I, 628 HMAC_INIT{H0(I), (IDs|challenge_I|F(I))} 629 --------------------------> 630 compute temporary hash chain 632 CC: IDs, HMAC_INIT, HMAC_CC{H0_R, (IDs|HMAC_INIT)} 633 <------------------------- 634 remain stateless 636 CCR: IDs, H0(I), challenge_I, F(I), HMAC_INIT, HMAC_CC 637 --------------------------> 638 recompute the hash chain 639 verify HMAC_INIT and HMAC_CC 640 select flowid F(R) 641 CONF: IDs, H0(R), F(R) 642 <-------------------------- 643 verify HMAC_CC 645 READDRESSING EXCHANGE 647 Initiator Responder 649 compute new hash chain 651 REA: IDs, Ls(I), H1(I), H0_new(I), challenge, 652 HMAC_REA{H2(I), (IDs|Ls(I)|H1(I)|H0_new(I)|challenge} 653 --------------------------> 654 verify H1(I) 655 generate a divided secret using H1(R 656 send AC per new locator 658 AC1: IDs, Key_count, Key_mask, key_piece, challenge 659 ... <------------------------- 660 ACn <------------------------- 662 combine the key pieces 663 verify the combined key 665 ACR: IDs, Key_combined, Key_mask, H2(I) 666 --------------------------> 667 verify the combined key 668 H1(R) 669 verify HMAC_REA 671 Figure 7: WIMP protocol(context establishment and locator change 672 verification) 674 5.3 WIMP Security Considerations 676 In order to prevent redirection attacks WIMP relies on the ability to 677 verify that the entity requesting redirection indeed holds the 678 successor values of a hash chain and is able to combine a divided 679 secret that is sent via parallel paths. 681 WIMP uses reverse hash chains and context establishment is based on 682 opportunistic authentication. In other words, both the initiator and 683 the responder have to trust each other that the first message comes 684 from an authentic peer. Once the initial messages have been sent out 685 safely, the following messages are secure. It would be impossible 686 for an attacker who had not eaves dropped the initial messages spoof 687 the following messages and data exchange. 689 1. PREMEDIATED REDIRECTION 691 Premediated redirection [6] is possible in WIMP because there 692 is no authentication of the initial messages. The receiving 693 host is forced to trust its peer as whom it claims to be. 694 After the first message, all the other messages are 695 authenticated. A malicious host X could easily spoof as A to 696 initiate a communication with B. Since B needs to trust the 697 first message from the peer, B is fooled to trust X as A. 698 Then X can happily communicate with B pretending to be A. 699 As an alternative to avoid this, IPsec could be used for the 700 initial messages. However, this could have yet another set of 701 protocol overload problems like key exchanges and security 702 association establishments. 704 2. REDIRECTING THE PACKETS 705 The WIMP protocol is sufficiently secure against redirection 706 attacks because it verifies that the entity requesting 707 redirection indeed holds the successor values of a hash chain. 708 Assuming that A and B are already communicating and X spoofs 709 as A to pose a redirection attack to B, X sends a readdressing 710 or REA message to B. To avoid a possible redirection attack, 711 B must verify that the initiator indeed is who he claims to be 712 (by verifying if the hash value sent in the REA message is a 713 successor of the previous value) and is reachable at the 714 claimed locations (by sending a challenge message to all the 715 locators). In order to authenticate himself X must be able to 716 guess the successor hash value and to locate at different 717 topological locations, at the same time, to be able to answer 718 to the challenges. Since both of these are far from possible, 719 X would fail to make a successful redirection attack. 721 3. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS 723 WIMP uses hash chains as compared to the PK signatures for 724 host authentication and locator change verifications. The 725 trade-off between hash chain based message authentication and 726 signatures is that hash chains are vulnerable for a class of 727 man-in-the-middle attacks ONLY in the initial couple of 728 messages. However, if we accept that the first round-trip of 729 the context establishment exchange is open for such attacks 730 hash chains have other advantages. The hash chain computation 731 is a lightweight operation compared to signature verification 732 and consumes fewer resources at the time of resource 733 exhaustion attacks [5]. It could also be possible that 734 signature verifications be used only for the vulnerable 735 initial messages. 737 6. Location Independent Network 739 LIN6 [4] is a protocol supporting multihoming and mobility in IPv6. 740 LIN6 introduces the node id, not the interface id, for each node. 741 Each node can be identified by its node id no matter where the node 742 is connected and no matter how many interfaces the node has. In the 743 IPv6 layer, 64-bit node id called LIN6 ID is used while 128-bit 744 node-id called LIN6 generalized ID is used above the Transport layer. 745 TCP connections and security associations can be preserved even if 746 the node moves to another subnet or the node changes the using 747 interface in a multihoming environment without modifying TCP or IPsec 749 LIN6 attempts to make transport connections at the TCP layer using 750 some form of a standard ID and then passed on the network layer. 751 When this reaches the network layer, the IPv6 layer overwrites the 752 standard ID with the network ID and then passes it on further. 754 6.1 Notational Conventions 756 A is the initiating host and B is the responding host. X is a 757 potentially malicious host. 759 MA-A is the Mobile Agent of A and MA-B is the Mobile Agent of B. 761 NS is the name server with AAAA records( network prefix of MA and 762 LIN6 ID of a node). 764 The LIN6 ID is the ID for a node in the network. This is the EUI 765 64 standard identifier. The EUI 64 has 64 bits, the upper 24 bits 766 is organizations unique ID (OUI) and is allocated by the IEEE to 767 the organization. The rest of the 40 bits is assigned randomly. 768 Here the organizations ID is the ID of the authors University and 769 is 0x00-0c-21. 771 <--24--> <---- 40 bits -----> 772 +-------+-------------------+ 773 | OUI | Random assignment | 774 +-------+-------------------+ 776 Figure 8 778 The LIN6 prefix is a predefined constant value that is attached to 779 the head of the LIN6 ID to form the LIN6 generalized ID. 781 The LIN6 generalized ID is used to identify the hosts ONLY in the 782 transport layer. This ID is NOT used in the IP layer. These 783 LING6 generated ID are used to make SA among the hosts and for 784 IPsec. Therefore from the ULP and the transport layer point of 785 view, all data exchange are identified using the LIN6 generated 786 IDs. 788 <-------- 64 bits --------> <-------- 64 bits -------> 789 LIN6 +---------------------------+--------------------------+ 790 generalized | LIN6 prefix (constant) | LIN6-ID | 791 ID +---------------------------+--------------------------+ 793 Figure 9 795 The LIN6 address is used in the network layer and contains the 796 network prefix. The network identifies the network (locator). 797 The LIN6 address is formed by combining the network prefix and the 798 LIN6 ID. 800 +---------------------------+--------------------------+ 801 | network prefix | LIN6-ID | 802 +---------------------------+--------------------------+ 804 Figure 10 806 6.2 LIN6 Protocol Overview 807 +------------------+ 808 | Mobile Agent (A) | 809 | |<---------------+ 810 +------------------+ | 811 ^ | 812 |4.Get N/W prefix(B) | 813 | from MA(B),create | 814 | IP(B) |1.Network prefix 815 | | Registration 816 | | 817 | | 818 |3.Create LIN6(B), | 819 | IP of MA(B) | 820 2.N/W prefix | | 821 of MA(B), | | 6.N/W prefix 822 +--------+ LIN6 ID(B) v 5.send pkt | of MA(A) +---------+ 823 |Name | +------+ -----------> +------+ |Name | 824 |server |<---------->|Node A| <---------- |Node B| <-------> |server | 825 +--------+ +------+ 8.send pkt +------+ +---------+ 826 | | 827 | | 828 | | 829 | | 830 | | 7.Get N/W prefix(A) 831 |1.Network prefix | from MA(A) 832 | Registration | 833 | | 834 | v 835 | +------------------+ 836 | | Mobile Agent (B) | 837 +-------------->| | 838 +------------------+ 840 Figure 11 842 6.3 LIN6 Security Considerations 844 The security issues of the LIN6 proposal are very similar to that of 845 the Mobile IPv6. This is because LIN6 also makes use of mobile 846 agents and requires binding updates. Assuming that there exists 847 proper authorization of the Binding Updates used by mobile agents 848 (which is still an open issue in the LIN6 proposal), we look at the 849 other security issues. 851 1. PREMEDIATED REDIRECTION 853 When node A wishes to communicate with node B, it sends a 854 packet to B (after looking up the AAAA records and the MA-B 855 for B's network prefix). For B to send a packet back to A, I 856 has to obtain the network prefix of host A from MA-A. Host B 857 first obtains the FQDN of host A from the name server by 858 indicating the LIN6 ID of Node-A, and then obtains the MA-A:s 859 network prefix from the name server by indicating the FQDN of 860 Node-A. Finally, it obtains the network prefix of A from the 861 MA-A. Assuming that the DNS records are authentic, it would 862 not be possible of a malicious host X to spoof as A and 863 initiate a communication with B. AAAA records will indeed 864 show up that X is not A. 866 2. REDIRECTING THE PACKETS 868 LIN6 proposes three different solutions to support 869 multihoming. Two of these solutions make use of authenticated 870 header mechanism for registering the new IP with the mobile 871 agent. The third proposal makes use of cookies in addition to 872 the authentication headers. All of the proposals make sure 873 that redirection of packets to a third party locator is not 874 possible as long as the mobile agents can be trusted. 875 Assuming that the binding updates are secure and redirection 876 is not possible at the time of locator updates, there are 877 still possibilities for redirection at the time of DNS look 878 ups. The interface between the correspondent node and the DNS 879 server is very important because security of LIN6 is dependent 880 on the DNS request and response messages. The initial DNS 881 request by a correspondent node returns the address of the 882 Mapping Agent of the initiator. If this message is modified, 883 the correspondent node can be forced to learn the wrong 884 address of the Mapping Agent. A malicious node could easily 885 take advantage of this to perform a redirection a redirection 886 attack. It is also crucial in LIN6 that the DNS holds only 887 authentic AAAA records and are in the secure zone. 889 3. PACKET INJECTION 891 Packet injection is possible at the time of data exchange and 892 location updates. The binding update security is still TBD in 893 the LIN6 proposal. Assuming that binding updates always take 894 place using security associations (in the case of the first 895 proposal for mobility in LIN6), packet injection would be 896 difficult. 897 LIN6 also supports IPsec for data exchange. If IPsec is used 898 in connection establishment and payload protection, then it 899 would not be possible to inject packets or disrupt the flow of 900 the data stream. However, this could have extra overheads of 901 the IPsec like key generation and exchange. 902 It should also be noted that packet injection is possible at 903 the time of DNS request and reply. Since this problem is 904 generic to all redirection attacks, it is not a special 905 concern for packet injection problem. 907 4. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS 909 Any protocol that uses signature verifications could be 910 subjected to resource exhaustion attacks as these 911 verifications are often expensive for a host. When one of the 912 nodes in a LIN6 protocol is mobile, it has to inform the 913 mobile agent (MA) and/or the corresponding node (CN) about its 914 new location. The corresponding node can start using the new 915 locator ONLY after the new network prefix has been verified 916 for impersonation. Attackers can take advantage of such a 917 situation to send forged location updates to the corresponding 918 node. Its should be noted that LIN6 also makes proposals that 919 are based on SA between the Mobile Node and the Correspondent 920 Node for authenticating binding updates. 922 7. Host Identity Protocol 924 The HIP proposal [9]is an ID/Locator separation mechanism intended to 925 solve a much wider problem space than site multi-homing. HIP uses 926 cryptographic identifiers termed Host Identity Tags (HITs) at the 927 application layer, which are mapped to locators (IP Addresses) by a 928 HIP protocol stack layer that interfaces between the transport layer 929 and network layer. The essential characteristic of HIP is it use of 930 opportunistic identity generation, as it uses a cryptographic host 931 identifier as the basis of the persistent identity. The transport 932 session can be agile across locators, or even across IP protocol 933 versions, as the HIT is used to determine session integrity allowing 934 the hosts to determine what packets legitimately form part of the 935 session. 937 HIP is proposed as a new protocol element, located at layer 3.5 (i.e. 938 above the internetwork IP layer and below the transport layer). The 939 presentation to the transport layer uses 128 bit hash values (the 940 HIT) in place of IP addresses, while the presentation to the internet 941 layer uses conventional IP addresses. 943 7.1 Notational Conventions 945 I is the initiating host and R is the responding host. X is a 946 potentially malicious host. 948 FQDN (R) is a fully qualified domain name of R and this is used to 949 uniquely identify R. 951 HI (R) is the Host Identifier of R. A host identifier is 952 cryptographic in nature and is the public key of an asymmetric 953 key-pair. Correspondingly, the host itself is the entity that 954 holds the private key of the key pair. 956 The Host Identity Tag or HIT is a 128 bit hash value of the Host 957 Identifier. Its fixed length makes for easier protocol coding and 958 presents and consistent format. 960 D-H key is the Diffie-Hellmann key used by a host to create a 961 session key (SK). The resultant session key is used to generate 962 the keying material or the KEYMAT to derive all the other keys for 963 integrity checks and encryption. 965 7.2 HIP Protocol Overview 966 Initiator Responder 968 I1: trigger exchange 969 --------------------------> 970 select pre-computed R1 971 R1: puzzle, D-H, key, sig 972 <------------------------- 973 check sig remain stateless 974 solve puzzle 975 I2: solution, D-H, {key}, sig 976 --------------------------> 977 compute D-H check cookie 978 check puzzle 979 check sig 980 R2: sig 981 <-------------------------- 982 check sig compute D-H 984 Figure 12: HIP protocol(context establishment) 986 7.3 HIP Security Considerations 988 HIP is designed to provide secure authentication of hosts and to 989 provide a fast key exchange for IPsec ESP. HIP also attempts to 990 limit the exposure of the host to various denial-of-service and 991 man-in-the-middle attacks. This is achieved through security 992 associations and PK signature verifications. 994 In order to prevent redirection attacks during locator updates, the 995 CB64 protocol relies on the ability to verify that the entity 996 requesting redirection indeed holds the private key where the hash of 997 the corresponding public key hashes to the ID itself. 999 1. PREMEDIATED REDIRECTION 1001 Premediated redirection is not possible in HIP because, HIP 1002 tries to authenticate the initiator using PK signatures at the 1003 time of base exchange itself. When an attacker X pretending 1004 to be an initiator I, sends a spoofed trigger exchange message 1005 to the host R, R creates a puzzle and generates a 1006 Diffie-Hellmann key for the session and sends it back to the 1007 attacker. The attacker needs to solve the puzzle, encrypt his 1008 host identity (which is the public authentication key of A) 1009 and then sign it (with the private key of X). The responder 1010 decrypts the encrypted host identity and uses it to verify the 1011 signature. The private key of the attacker and the public key 1012 of A would not make a key pair for signature verification. 1013 Authentication fails and the receiver stops the 3-way base 1014 exchange. Since the Host Identity of a host is the public 1015 authentication key, it is important that these are retrieved 1016 from a signed DNS zone, a certificate or some secure methods. 1018 2. REDIRECTING THE PACKETS 1020 HIP proposes some ways to handle locator changes. One of them 1021 is to use the readdressing parameter REA and the other is to 1022 have Rendezvous Servers for efficient multihoming and 1023 mobility. 1024 The former method tries to make a new security association 1025 with the hosts every time a mobile node changes its location 1026 on the network. Since no other host, even those in the path 1027 between the initiator and the receiver cannot know the session 1028 keys (exchanged using Diffie-Hellmann key exchange protocol) 1029 for the new security associations, it is impossible for a 1030 middle man to issue false locator updates to one of the host 1031 and redirect the packets. 1032 The later method uses rendezvous servers which maintain a 1033 mapping between the Host Identities of HIP nodes for which 1034 they provide service and the node's current IP addresses. HIP 1035 nodes must notify their Rendezvous Servers about any changes 1036 in their IP addresses. It is important that the HIP mobile 1037 nodes be authenticated before they update their new IP in 1038 their respective Rendezvous Servers. Assuming so, it would be 1039 difficult for a malicious host to make false location updates 1040 on Rendezvous Servers that do not belong to it. Therefore 1041 false location updates are difficult, making all kinds of 1042 redirection attacks also difficult. 1044 3. PACKET INJECTION 1046 Since HIP makes use of IPsec ESP in order to secure all the 1047 packets, packets that are injected would either be unencrypted 1048 or would belong to irrelevant security associations. Such 1049 packets could be ignored and this would not affect the regular 1050 stream of data flow in HIP. 1052 4. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS 1054 Denial-of-service attacks take advantage of the cost of start 1055 of state for a protocol on the Responder compared to the 1056 cheapness on the Initiator. HIP makes no attempt to increase 1057 the cost of the start of state on the Initiator, but makes an 1058 effort to reduce the cost to the Responder. This is done by 1059 having the Responder start the 3-way cookie exchange instead 1060 of the initiator by sending a puzzle. 1061 This shifting of the start of state cost to the Initiator in 1062 creating the I2 HIP packet, presents yet another DoS attack. 1063 The attacker spoofs the I1 HIP packet and sends out the R1 HIP 1064 packet. This could tie up the initiator with evaluating the 1065 R1 HIP packet and creating the I2 HIP packet. The defense 1066 against this attack is to simply ignore any R1 packet where a 1067 corresponding I1 or ESP data was not sent. 1068 Message R2 also includes signature verification. However, the 1069 responder verifies the signature ONLY if it receives the 1070 correct solution for the puzzle it sent out. For an attacker 1071 to force the receiver with signature verifications with I2 1072 message, it needs to find the correct solution of the puzzle 1073 that was sent out. This would be the price that he would pay 1074 for one signature verification attack on the receiver. 1075 Denial of service attack with R2 message is avoided by 1076 including a HMAC value in the R2 message. The initiator would 1077 verify the signature ONLY if the HMAC value of the message is 1078 first verified. It would be impossible for an attacker to 1079 compute the correct HMAC as this requires the integrity key 1080 that the communicating hosts generated with the session key. 1081 For rendezvous mechanisms for mobility management, the 1082 security considerations are yet to be determined. It is 1083 assumed that all requests and replies to and from the DNS are 1084 secure and that DNS holds only authentic records in a secure 1085 zone. 1087 8. Other Security Considerations 1089 Replay attacks - The SIM, NOID and the CB64 proposals make use of 1090 nonce and timestamp in the context establishment messages and 1091 readdressing messages. This makes replay attacks difficult. This 1092 is especially significant for SIM and CB64 proposals that involve 1093 PK signature verifications for authentication. In the other 1094 proposals like Lin6 and WIMP, replay attacks do not gain anything 1095 significant for the attacker. In the HIP proposal, however, 1096 replay attacks are avoided by using the cookie mechanism to 1097 generate the puzzle. This mechanism makes use of a nonce to 1098 calculate the index for the puzzle. 1099 Protecting the context establishment itself - One big draw back of 1100 all the proposals except the HIP is that they do not make any 1101 attempt to protect the initial context establishment mechanism. 1102 For instance, the WIMP proposal assumes that the initial two 1103 messages need to be exchanged between authentic nodes. If the 1104 initial messages itself are protected, nodes in the path will not 1105 be able to create the same hash chain and use them for man in the 1106 middle attacks. In the other proposals like SIM, NOID and CB64 1107 protecting the context establishment could protect the Context Tag 1108 or Flow ID as they are important for rewriting the locator values 1109 back to the identifier values. Otherwise, the CTs and FlowIDs are 1110 open to attacks. 1112 9. Comparison of Multi6 Proposals 1114 The following table shows various attacks and relates them to the 1115 individual proposals. The symbol 'x' indicates that the attack is 1116 applicable to the respective protocol proposal. 1118 +---------------+-------+-------+-------+-------+-------+-------+ 1119 | | SIM | NOID | CB64 | WIMP | LIN6 | HIP | 1120 +---------------+-------+-------+-------+-------+-------+-------+ 1121 |Premediated | | | | | | | 1122 |redirection | x | | x | x | | | 1123 |attacks | | | | | | | 1124 +---------------+-------+-------+-------+-------+-------+-------+ 1125 |Redirecting | | | | | | | 1126 |packets to the | | | | | x | | 1127 |attacker | | | | | | | 1128 +---------------+-------+-------+-------+-------+-------+-------+ 1129 |Redirecting | | | | | | | 1130 |packets to a | | | | | x | | 1131 |third party | | | | | | | 1132 +---------------+-------+-------+-------+-------+-------+-------+ 1133 |Redirecting | | | | | | | 1134 |packets to a | | | | | x | | 1135 |black hole | | | | | | | 1136 +---------------+-------+-------+-------+-------+-------+-------+ 1137 |Packet | | | | | | 1138 |injection | x | x | x | x | | | 1139 | | | | | | | | 1140 +---------------+-------+-------+-------+-------+-------+-------+ 1141 |Resource | | | | | | | 1142 |exhaustion DoS | x | x | x | | x | | 1143 |attacks | | | | | | | 1144 +---------------+-------+-------+-------+-------+-------+-------+ 1146 Figure 13 1148 10. Security Considerations 1150 This document discusses security issues of Multi6 locator/identifier 1151 split protocol proposals. As such, it contains a number of security 1152 issues. 1154 11. References 1156 11.1 Normative References 1158 11.2 Informative References 1160 [1] Nordmark, E., "Strong Identity Multihoming using 128 bit 1161 Identifiers (SIM/CBID128) for use in RFCs to Indicate 1162 Requirement Levels", draft-nordmark-multi6-sim-01.txt (work in 1163 progress), October 2003. 1165 [2] Nordmark, E., "Multihoming without IP Identifiers", 1166 draft-nordmark-multi6-noid-01.txt (work in progress), October 1167 2003. 1169 [3] Nordmark, E., "Multihoming using 64-bit Crypto-based IDs", 1170 draft-nordmark-multi6-cb64-00.txt (work in progress), October 1171 2003. 1173 [4] Teraoka, F., Ishiyama, M. and M. Kunishi, "LIN6: A Solution to 1174 Multihoming and Mobility in IPv6", 1175 draft-teraoka-multi6-lin6-00.txt (work in progress), December 1176 2003. 1178 [5] Ylitalo, J., Torvinen, V. and E. Nordmark, "Weak Identifier 1179 Multihoming Protocol (WIMP)", draft-ylitalo-multi6-wimp-00 1180 (work in progress), January 2004. 1182 [6] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming 1183 solutions", draft-nordmark-multi6-threats-01.txt (work in 1184 progress), June 2004. 1186 [7] Huston, G., "Architectural Approaches to Multi-Homing for 1187 IPv6", draft-huston-multi6-architectures-00.txt (work in 1188 progress), May 2004. 1190 [8] Crocker, D., "Choices for Multiaddressing", 1191 draft-crocker-multiaddr-analysis-01.txt (work in progress), 1192 October 2003. 1194 [9] Moskowitz, R., Nikander, P., Jokela, P. and T. Henderson, "Host 1195 Identity Protocol", draft-moskowitz-hip-09.txt (work in 1196 progress), February 2004. 1198 [10] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1199 Architecture", draft-moskowitz-hip-arch-05 (work in progress), 1200 September 2003. 1202 [11] Eggert, L., "Host Identity Protocol (HIP) Rendezvous 1203 Mechanisms", draft-eggert-hip-rendezvous-00.txt (work in 1204 progress), February 2004. 1206 [12] Nikander, P. and J. Arkko, "End-Host Mobility and Multi-Homing 1207 with Host Identity Protocol", draft-nikander-hip-mm-01.txt 1208 (work in progress), December 2003. 1210 Authors' Addresses 1212 Aarthi Nagarajan 1213 Siemens 1214 Otto-Hahn-Ring 6 1215 Munich, Bayern 81739 1216 Germany 1218 EMail: aarthi.nagarajan@tuhh.de 1220 Hannes Tschofenig 1221 Siemens 1222 Otto-Hahn-Ring 6 1223 Munich, Bayern 81739 1224 Germany 1226 EMail: Hannes.Tschofenig@siemens.com 1228 Intellectual Property Statement 1230 The IETF takes no position regarding the validity or scope of any 1231 Intellectual Property Rights or other rights that might be claimed to 1232 pertain to the implementation or use of the technology described in 1233 this document or the extent to which any license under such rights 1234 might or might not be available; nor does it represent that it has 1235 made any independent effort to identify any such rights. Information 1236 on the procedures with respect to rights in RFC documents can be 1237 found in BCP 78 and BCP 79. 1239 Copies of IPR disclosures made to the IETF Secretariat and any 1240 assurances of licenses to be made available, or the result of an 1241 attempt made to obtain a general license or permission for the use of 1242 such proprietary rights by implementers or users of this 1243 specification can be obtained from the IETF on-line IPR repository at 1244 http://www.ietf.org/ipr. 1246 The IETF invites any interested party to bring to its attention any 1247 copyrights, patents or patent applications, or other proprietary 1248 rights that may cover technology that may be required to implement 1249 this standard. Please address the information to the IETF at 1250 ietf-ipr@ietf.org. 1252 Disclaimer of Validity 1254 This document and the information contained herein are provided on an 1255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1257 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1258 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1259 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1262 Copyright Statement 1264 Copyright (C) The Internet Society (2004). This document is subject 1265 to the rights, licenses and restrictions contained in BCP 78, and 1266 except as set forth therein, the authors retain all their rights. 1268 Acknowledgment 1270 Funding for the RFC Editor function is currently provided by the 1271 Internet Society.