idnits 2.17.1 draft-arkko-mipv6-binding-lifetime-extension-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 3978, Section 5.5 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 602. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 618), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 293 has weird spacing: '... Update is no...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 21, 2004) is 7270 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-00 == Outdated reference: A later version (-04) exists of draft-haddad-mip6-cga-omipv6-00 -- Duplicate reference: draft-vogt-mip6-early-binding-updates, mentioned in '9', was also mentioned in '6'. -- Duplicate reference: draft-vogt-mip6-early-binding-updates, mentioned in '10', was also mentioned in '9'. -- No information found for draft-ietf-mip6-precfgKbm - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobility Optimizations J. Arkko 2 Internet-Draft Ericsson Research NomadicLab 3 Expires: November 19, 2004 C. Vogt 4 University of Karlsruhe 5 May 21, 2004 7 Credit-Based Authorization for Binding Lifetime Extension 8 draft-arkko-mipv6-binding-lifetime-extension-00 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 3667. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 19, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Mobile IPv6 return routability mechanisms require home and care-of 41 address keygen tokens to be used to authorize a binding update to 42 correspondent nodes. The current rules dictate that such 43 authorization be performed every seven minutes, using tokens at most 44 three and half minutes old. This requirement results in an average 45 signaling traffic of around 7 bits per second when the hosts are not 46 moving around. This traffic load by itself is neglible, but can be 47 problematic for hosts in standby mode. We present a secure and 48 lightweight extension of return routability that can reduce this 49 signaling load to around 0.1 bits per second, and require hosts to 50 wake up much less frequently. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 56 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 5 58 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2 Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3 State Requirements . . . . . . . . . . . . . . . . . . . 8 61 4.4 Lifetime Credit Authorization Option . . . . . . . . . . 8 62 5. Performance Considerations . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Normative References . . . . . . . . . . . . . . . . . . . . . 12 67 Informative References . . . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 69 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . 14 72 1. Introduction 74 This document focuses on mobile nodes that stay long periods on the 75 same care-of address, and wish to retain efficient routing throughout 76 these periods. In order to keep Mobile IPv6 route optimization state 77 alive, periodic signaling is needed. Such periodic signaling consumes 78 a small amount of bandwidth from the point of view of the 79 participants, but the total amount of signaling load in a commercial 80 network can be large. 82 More importantly, typical implementations of hand-held devices employ 83 a standby mode in order to conserve battery energy. Periodic 84 signaling causes a need to wake up for such nodes, and can consume 85 extra energy. While it is possible to re-establish route optimization 86 at the time when the mobile node has some actual traffic to send, 87 this will cause additional signaling and delay before actual payload 88 traffic can flow efficiently. 90 Current Mobile IPv6 return routability mechanisms require home and 91 care-of keygen tokens to be used to authorize a Binding Update to 92 correspondent nodes. According to the current rules, such tokens may 93 be used at most MAX_TOKEN_LIFETIME seconds (3.5 minutes) after they 94 have been acquired in an address test procedure. Section 5.2.7 of the 95 base specification [2] states: 97 A fast moving mobile node MAY reuse a recent home keygen token 98 from a correspondent node when moving to a new location, and just 99 acquire a new care-of keygen token to show routability in the new 100 location. 102 Vogt et al defined the Early Binding Updates [6] procedure to expand 103 on this approach a little bit by suggesting that a pre-emptive home 104 test exchange be used to ensure that a home keygen token is available 105 when it is needed. Early Binding Updates could also be used to 106 perform a care-of address test in parallel with sending payload 107 traffic. In this application the Early Binding Updates do not fully 108 protect against flooding attacks. This has since then been corrected 109 in [12]. 111 The problem with the base mechanism and the Early Binding Update 112 scheme is, however, that both require extra signaling. A number of 113 proposals have been made to reduce this, see for instance [13], [7], 114 and [8]. Some of these mechanisms are extremely efficient, such as 115 the preconfigured binding keys [13] which adds no signaling at all. 116 Other proposals such as [8] employ techniques such as the 117 Cryptographically Generated Addresses (CGAs) that can achieve both 118 high security and efficiency, particularly for testing home address 119 ownership. 121 This document explores the design space into a new direction, namely 122 stretching the signaling frequency limits of the current return 123 routability mechanism without introducing new vulnerabilities. Our 124 design is based on explicitly addressing the costs and benefits of 125 attacks. This proposal is not necessarily intended to be a standalone 126 proposal for Mobile IPv6 optimization. Rather, it is intended as a 127 research idea that could be used as a possible component in a 128 solution that addresses all aspects of the optimization problem. The 129 proposal is in its early stages, however, so additional discussion is 130 warranted. 132 This document is organized as follows. In Section 3 we discuss the 133 performance of the current return routability mechanism. Section 4 134 describes our solution. Finally, Section 5 evaluates the performance 135 of this solution, and Section 6 analyzes its security implications. 137 2. Specification of Requirements 139 In this document, several words are used to signify the requirements 140 of the specification. These words are often capitalized. The key 141 words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and 142 "MAY" in this document are to be interpreted as described in [1]. 144 3. The Problem 146 The performance of the current return routability mechanism can be 147 evaluated according to its impact on handover delay, the amount of 148 bandwidth it uses per movement, and the amount of bandwith it uses 149 when not moving. In this document we focuse only on the last aspect. 151 Current specifications require a periodic return routability test and 152 the re-establishment of the binding at the correspondent node. One 153 round of a full return routability procedure requires the following 154 messages: 156 HOTI: This needs 40 + 8 + 8 or 56 bytes. 158 HOT: This needs 40 + 8 + 16 or 64 bytes. 160 COTI: This needs 40 + 8 + 8 or 56 bytes. 162 COT: This needs 40 + 8 + 16 or 64 bytes. 164 BU: This needs 40 + 6 + 6 + 6 + 2 + 12 or 72 bytes. 166 BA: This needs 40 + 6 + 6 + 12 or 64 bytes. 168 Taken together, this results in 376 bytes, or on the average about 169 7.16 bits/second, if performed every seven minutes. While this is an 170 insignificant bandwidth for nodes that are actually communicating, it 171 can still represent a burden for hosts that just have the bindings 172 ready for a possible packet but are not currently communicating. This 173 can be problematic for hosts in standby mode, for instance. 175 When two mobile nodes are communicating with each other, these 176 numbers double, i.e., 14.32 bits/second. This is because both nodes 177 need to act as receivers and senders of the messages. 179 The bandwidth itself may also be an issue in some scenarios. For 180 instance, a correspondent node such as a SIP proxy may have a large 181 number of mobile nodes, and the sum of the small bandwidth from each 182 of them becomes considerable. The traffic load for a home agent may 183 also be significant. In a network of a 100 million hosts, keeping 184 route optimization up all the time between the hosts and some other 185 node would require 220 Mbits/second of traffic through the home 186 agent(s), and 716 Mbit/second for the other nodes altogether. 188 Note that when evaluating the impact of signaling on performance, one 189 should take into account the whole stack and not inspect just one 190 layer or task. For instance, if the mobile node actually moved, the 191 above signaling would have to be compared to the link layer 192 signaling, access control and authentication signaling, IPv6 neighbor 193 discovery signaling, and so forth. Such other signaling introduces 194 quite significant delays, but is not relevant for discussion in this 195 draft as we assume a stable mobile node. 197 4. Protocol Definition 199 4.1 Overview 201 We take an approach similar to Credit Based Authorization (CBA) [12], 202 developed from Early Binding Updates [6] and a suggestion to track 203 packet counts instead of a fixed time [9] into a fully flegded 204 credit-based scheme [10, 11, 12]. These techniques are specific 205 instances of microeconomics-based solutions to security problems 206 [3, 4]. 208 CBA for Early Binding Updates [12] focuses on the care-of address 209 tests; the objective is to weigh the effort the mobile node has spent 210 in communicating with the correspondent node, and to ensure that any 211 unverified communication sent to a claimed new address causes less 212 damage than this effort. The rationale is that even without Mobile 213 IPv6, attackers can easily cause similar flooding attacks by sending 214 packets to the victim directly or via a reflector; the real issue is 215 avoiding amplification. By ensuring that the amplification achieved 216 via Early Binding Updates is smaller than the amplification achieved 217 via these other attacks, the overall seriousness of vulnerabilities 218 is not increased. 220 In our approach, the same idea is used to reduce the amount of 221 signaling required for address tests. The primary reason why address 222 tests are needed is to ensure that a mobile node "owns" its home 223 address and is reachable at the care-of addresses in question. In 224 basic Mobile IPv6 design, this is achieved by a testing that the 225 mobile node can receive packets at the given address, i.e., is on the 226 routing path to that address. If this test was not regularly done, 227 attackers who only visited the path for a short time could claim 228 address ownership for a long time. This vulnerability does not exist 229 in the Internet today, as was hence considered as something that 230 should be avoided [5]. 232 However, the effort-damage considerations from the Early Binding 233 Updates can be applied also to the frequency of address tests. 234 Assuming at least one test is performed, the frequency of the tests 235 is not related to flooding. Instead, the efforts and damage must be 236 counted in different units than in Early Binding Updates. 237 Specifically, we can track the amount of time the mobile node has 238 been reachable at its home address, and we can set a limit on how 239 long the mobile node can continue to claim this without performing a 240 new test. So, instead of the current fixed limit, the mobile node 241 can, for instance, continue to use an existing address test 30% 242 longer than the time it has already been reachable at this address. 243 The only thing that is needed is that the mobile node can prove it is 244 still the same node than it has been at the time of previous tests. 246 4.2 Behaviour 248 This section shows the steps of the protocol. For brevity, we omit 249 the description of packet formats. 251 First, the mobile node establishes a binding cache entry: 253 Step 1. MN->HA->CN: Home test init 255 Step 2. CN->HA->MN: Home test 257 Step 3. MN->CN: Care-of test init 259 Step 4. MN->CN: Care-of test 261 Step 5. MN->CN: Binding Update + Lifetime Credit Authorization 262 option 264 Step 6. MN->CN: Binding Acknowledgement + Lifetime Credit 265 Authorization option 267 These steps are equivalent to a standard correspondent binding update 268 procedure, except that the initial lifetime specified MUST be less 269 than or equal to 30% of MAX_RR_BINDING_LIFETIME, and that the 270 Lifetime Credit Authorization option is included in the Binding 271 Update and Acknowledgement. The contents of the option is based on 272 the Kbm, and it will be discussed in more detail later. 274 After time t, the mobile node needs to re-establish the binding, as 275 its lifetime is about to run out. (Note that the binding may have 276 been redone several times during time t; the important factor is the 277 total amount of time the binding has existed.) 279 Step 7. MN->HA->CN: Home test init 281 Step 8. CN->HA->MN: Home test 283 Step 9. MN->CN: Care-of test init 285 Step 10. MN->CN: Care-of test 287 A new return routability procedure is run here, again in the standard 288 manner. 290 Step 11. MN->CN: Binding update + Lifetime Credit Authorization 291 option 293 The requested lifetime in the Binding Update is not limited to 294 MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3. To authorize 295 this, the mobile node has to provide a keyed hash using the key 296 Kcredit, proving that it has participated in all the binding updates 297 between Step 5 and Step 10. Kcredit is calculated as follows: 299 Kcredit = hash(KbmN | hash(KbmN-1 | hash(KbmN-2 | ...Kbm1))) 301 Here Kbm1 through KbmN represent the Kbm used to calculate the 302 Binding Authorization Data option in the Step 5 binding update and 303 all subsequent binding updates. Note that neither the mobile nor the 304 correspondent node needs to remember the whole sequence, as they can 305 calculate the next Kcredit value based on the previous Kcredit value 306 and the latest Kbm. However, in order to know Kcredit one has to have 307 had knowledge of all Kbm values. 309 We set an upper bound for these lifetimes in order to ensure that the 310 system can still recover. The upper bound is 8 hours. 312 Finally, the correspondent node responds: 314 Step 12. CN->MN: Binding Acknowledgement + Lifetime Credit 315 Authorization option 317 The returned Lifetime Credit Authorization option assures the mobile 318 node that the correspondent node is also still the same node it has 319 been in the past. It also informs the mobile node that it supports 320 this extension. The returned lifetime is set according to the 321 correspondent node's calculation of the time t. 323 Note that we did not propose any modifications to the actual return 324 routability test, binding updates, or the timing of these events with 325 respect to data packet flows. The solution outlined here can be used 326 in conjunction with other optimizations, such as those defined in 327 [12]. 329 4.3 State Requirements 331 Both mobile and correspondent nodes hold some state in the Binding 332 Cache Entries, related to the credit authorization. The following 333 conceptual information MUST be kept: 335 o The total time there has been a binding for this home address. 337 o The current Kcredit value. 339 o The number of Kbm values included in the Kcredit value. 341 4.4 Lifetime Credit Authorization Option 343 This extension introduces one new mobility option, the Lifetime 344 Credit Authorization option. 346 This option is similar to the Binding Authorization Data option, but 347 uses Kcredit as the key instead of Kbm. 349 The Lifetime Credit Authorization option does not have alignment 350 requirements. The format of this option is as follows: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type = TBD | Option Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | N | Reserved | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 + + 361 | Lifetime Authenticator | 362 + + 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 This option is valid in the Binding Update and Binding 367 Acknowledgement messages. Its field are filled as follows: 369 Type 371 TBD < To Be Assigned By IANA > 373 Option Length 375 This field contains the length of the authenticator in octets. 377 N 379 16-bit counter, representing the number of Kbm keys included in 380 Kcredit so far. This value is used by the correspondent node to 381 ensure that it is synchronized with the mobile node regarding the 382 keying material. If the value sent by the mobile node differs from 383 the expected value, the correspondent node MUST send a value of 1 384 in the Binding Acknowledgement and reset the lifetime to the 385 initial value (see Section Section 4.2). 387 Reserved 389 16-bit reserved field. The value MUST be initialized to zero by 390 the sender, and MUST be ignored by the receiver. 392 Lifetime Authenticator 394 This field contains a keyed MAC calculated as follows: 396 Mobility Data = care-of address | correspondent | MH Data 397 Lifetime Authenticator = First (96, HMAC_SHA1 (Kcredit, 398 Mobility Data)) 400 Where | denotes concatenation and "correspondent" is the IPv6 401 address of the correspondent node. Note that, if the message is 402 sent to a destination which is itself mobile, the "correspondent" 403 address may not be the address found in the Destination Address 404 field of the IPv6 header; instead the home address from the type 2 405 Routing header should be used. 407 "MH Data" is the content of the Mobility Header, excluding the 408 Lifetime Authenticator field itself and the Authenticator field 409 from the Binding Authorization Data option. The Lifetime 410 Authenticator value is calculated as if the Checksum field in the 411 Mobility Header was zero. The Checksum in the transmitted packet 412 is still calculated in the usual manner, with the calculated 413 Authenticator being a part of the packet protected by the 414 Checksum. 416 The first 96 bits from the MAC result are used as the Lifetime 417 Authenticator field. 419 5. Performance Considerations 421 Initially, the token and BCE lifetimes provided by this scheme are 422 smaller than those in the current return routability method. This 423 provides additional security against attackers that just came on the 424 link. However, after a while the lifetimes become higher and there's 425 a significant reduction in the need for signaling. For instance, 426 after the binding has been up for an hour, home address tests can be 427 performed as infrequently as once every eighteen minutes compared to 428 the standard seven minutes. 430 For a connection that stays up continuously, the lifetimes approach 431 the maximum lifetimes (eight hours), which implies that at least 432 three return routability protocol runs have to be performed per day. 433 The signaling load this of this is around 0.104 bits per second, or 434 68 times less than in the baseline method. 436 6. Security Considerations 438 The security of this approach is based on the following principles: 440 o The bindings resulting from running this method are not permanent, 441 i.e., can be overridden at any time by a new run of the return 442 routability procedure and binding procedures. This avoids problems 443 associated with attackers grabbing a binding before legitimate 444 nodes. 446 o With the timing formula that is used, it is guaranteed that 447 whatever exposure there is for on-path attackers, this method 448 increases this exposure by a known amount (30%). It is already 449 known that the only vulnerability in the original return 450 routability mechanism is a slight, constant, increase in exposure 451 to on-path attackers. This problem is called the time shifting 452 vulnerability in [5]. The difference between original return 453 routability and this method is that the exposure increase is 454 variable instead of a constant. In both cases it is, however, 455 limited and quantifiable. 457 o Depending on the amount of time the node has been on the link, 458 this method provides either a smaller or larger window of 459 vulnerability. We argue that this is at least as reasonable as the 460 constant windows in RR. 462 Attackers who are temporarily on the path between the mobile and 463 correspondent nodes (and simultaneously also on the path between the 464 home agent and correspondent node) can fraudulently represent the 465 mobile node in the return routability procedure. This implies that 466 the attacker can get one Kbm value. With this value, it can register 467 a false binding, de-register the existing binding and zero the credit 468 collected by the mobile node, or introduce a new Kbm into the Kcredit 469 value, making it impossible for the mobile node to use its credit. 470 These are denial-of-service attacks; our method is incapable of 471 ensuring that the credit can be retained in the presence of on-path 472 attackers. On the other hand, base Mobile IPv6 mechanisms have 473 similar limitations, and even basic IPv6 is vulnerable to on-path 474 denial-of-service attacks. 476 7. IANA Considerations 478 One new mobility option number has to be allocated for this protocol. 480 8. Conclusions 482 This approach can reduce the amount of signaling needed for home 483 address tests, care-of address tests, and binding updates, all 484 without exposing nodes to significant new vulnerabilities. It does 485 not eliminate all the signaling, however, and works best when the 486 mobile node stays a long time at the same location. 488 This approach is one possible component in further optimizations of 489 Mobile IPv6. As its primary purpose is to reduce signaling, it can be 490 used together with other approaches such as [13] to assist in 491 reducing the frequency of care-of address tests and expand the 492 applicability of the solution, with [12] to provide both reduced 493 signaling and reduced latency upon movements, or with [8] to provide 494 reduced signaling while still performing care-of address tests. 496 Normative References 498 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 499 Levels", BCP 14, RFC 2119, March 1997. 501 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 502 IPv6", RFC 3775, May 2004. 504 Informative References 506 [3] Anderson, R., "Why information security is hard - an economic 507 perspective", Proceedings of the 17th Annual Computer Security 508 Applications Conference, December 2001. 510 [4] Arkko, J. and P. Nikander, "Weak Authentication: How to 511 Authenticate Unknown Principals without Trusted Parties", 512 Proceedings of Security Protocols Workshop 2002, Cambridge, UK, 513 April 16-19, 2002. 515 [5] Nikander, P., "Mobile IP version 6 Route Optimization Security 516 Design Background", draft-ietf-mip6-ro-sec-00 (work in 517 progress), April 2004. 519 [6] Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding 520 Updates for Mobile IPv6", 521 draft-vogt-mip6-early-binding-updates-00 (work in progress), 522 February 2004. 524 [7] Haddad, W., Dupont, F., Madour, L., Krishnan, S. and S. Park, 525 "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01 526 (work in progress), February 2004. 528 [8] Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying 529 Cryptographically Generated Addresses to OMIPv6 (OMIPv6+)", 530 draft-haddad-mip6-cga-omipv6-00 (work in progress), April 2004. 532 [9] Arkko, J., "Comments on 533 draft-vogt-mip6-early-binding-updates-00", E-mail discussion on 534 the mip6 list, February 2004. 536 [10] Vogt, C., "Response to comments on 537 draft-vogt-mip6-early-binding-updates-00", E-mail discussion on 538 the mip6 list, February 2004. 540 [11] Vogt, C., "Early Binding Updates for Mobile IPv6", Presentation 541 in the MOBOPTS IRTF WG, March 2004. 543 [12] Vogt, C., Arkko, J., Bless, R., Doll, M. and T. Kuefner, 544 "Credit-Based Authorization for Mobile IPv6 Early Binding 545 Updates", draft-vogt-mipv6-credit-based-authorization-00 (work 546 in progress), May 2004. 548 [13] Perkins, C., "Preconfigured Binding Management Keys for Mobile 549 IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April 550 2004. 552 Authors' Addresses 554 Jari Arkko 555 Ericsson Research NomadicLab 557 FI-02420 Jorvas 558 Finland 560 EMail: jari.arkko@ericsson.com 562 Christian Vogt 563 Institute of Telematics 564 University of Karlsruhe (TH) 565 P.O. Box 6980 566 76128 Karlsruhe 567 Germany 569 Phone: +49-721-608-8282 570 Fax: +49-721-388-097 571 EMail: chvogt@tm.uka.de 572 URI: http://www.tm.uka.de/~chvogt/ 574 Appendix A. Acknowledgments 576 The authors would like to thank Wassim Haddad, Lila Madour, Roland 577 Bless, Mark Doll, and Tobias Kuefner for interesting discussions in 578 this problem space. 580 Intellectual Property Statement 582 The IETF takes no position regarding the validity or scope of any 583 Intellectual Property Rights or other rights that might be claimed to 584 pertain to the implementation or use of the technology described in 585 this document or the extent to which any license under such rights 586 might or might not be available; nor does it represent that it has 587 made any independent effort to identify any such rights. Information 588 on the IETF's procedures with respect to rights in IETF Documents can 589 be found in BCP 78 and BCP 79. 591 Copies of IPR disclosures made to the IETF Secretariat and any 592 assurances of licenses to be made available, or the result of an 593 attempt made to obtain a general license or permission for the use of 594 such proprietary rights by implementers or users of this 595 specification can be obtained from the IETF on-line IPR repository at 596 http://www.ietf.org/ipr. 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights that may cover technology that may be required to implement 601 this standard. Please address the information to the IETF at 602 ietf-ipr@ietf.org. 604 Disclaimer of Validity 606 This document and the information contained herein are provided on an 607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 609 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 610 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 611 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 614 Copyright Statement 616 Copyright (C) The Internet Society (2004). This document is subject 617 to the rights, licenses and restrictions contained in BCP 78, and 618 except as set forth therein, the authors retain all their rights. 620 Acknowledgment 622 Funding for the RFC Editor function is currently provided by the 623 Internet Society.