idnits 2.17.1 draft-haddad-mipshop-mobisig-del-03.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.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 8, 2007) is 6136 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. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ietf-dna-frd-01 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Optimizations: MIPSHOP WG W. Haddad 3 Internet-Draft S. Krishnan 4 Expires: January 9, 2008 Ericsson Research 5 F. Dupont 6 CELAR 7 July 8, 2007 9 Mobility Signaling Delegation 10 draft-haddad-mipshop-mobisig-del-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This memo describes a mechanism which delegates the exchange of 44 mobility signaling messages between the mobile and correspondent 45 nodes to the network infrastructure. Goals outlining the proposed 46 delegation are to further reduce the IP handoff latency and to 47 relieve the mobile node from exchanging a considerable amount of 48 signaling messages with correspondent nodes while retaining full 49 control on the critical ones. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . 4 55 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Suggested Solution . . . . . . . . . . . . . . . . . . . . . . 7 57 5. New Options and Messages . . . . . . . . . . . . . . . . . . . 9 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . . . 13 65 1. Introduction 67 Optimized Mobile IPv6 (OMIPv6) protocol (described in [OMIPv6]) 68 provides a mechanism, which allows significant reduction in the 69 amount of signaling messages generated by the Mobile IPv6 protocol 70 ([MIPv6]), a shorter handoff latency and a better overall security. 71 However, a care-of address (CoA) test exchange between the mobile 72 node (MN) and each correspondent node (CN) remains a compulsory step 73 prior to exchanging critical mobility signaling messages between 74 them, namely binding updates (BU) and acknowledgments (BA) messages. 75 The CoA reachability test involves two mobility signaling messages 76 (CoTI/CoT) and is unaffected by the optimization introduced by OMIPv6 77 protocol. 79 This memo describes a mechanism which delegates the exchange of 80 mobility signaling messages between the MN and CN(s) to the network 81 infrastructure, as part of the ongoing work on designing an 82 optimization to the IPv6 secure neighbor discovery (described in 83 [SeND]) protocol. Goals outlining the proposed delegation are to 84 further reduce the IP handoff latency and to relieve the MN from 85 exchanging a considerable amount of signaling messages with each CN 86 while retaining full control on the BU/BA messages. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [TERM]. 94 3. Motivation 96 OMIPv6 protocol achieves three different goals: it alleviates the 97 mobility signaling messages load, improves the overall security and 98 reduces the IP handoff latency. 100 The latency reduction caused by OMIPv6 is mainly due to eliminating 101 the MN's home address reachability test, which requires a signaling 102 message exchange through the MN's Home Agent (HA). Another set of 103 factors (excluding the link layer), e.g., network detection, network 104 prefix discovery and IP address configuration are still among the 105 main contributors to the handoff latency. These factors remain 106 totally unaffected by using OMIPv6. 108 In addition, OMIPv6 still require a CoA reachability test with each 109 CN, prior to updating them with its new CoA (nCoA), i.e., exchanging 110 BU/BA messages. Consequently, such exchange guarantees a residual 111 latency and additional mobility signaling messages. 113 Furthermore, it is important to mention that a fast growing class of 114 mobile devices tend to have very limited battery power. Thus, the 115 available energy must be meticulously controlled and consumed, i.e., 116 not to be wasted on exchanging non-critical signaling messages. Such 117 requirement becomes more challenging when the MN is talking to 118 different CNs at the same time (which may probably be a very common 119 case) while moving fast. 121 In fact, it has been shown that the wireless transmission of one bit 122 can require over 1000 times more energy than a single 32-bit 123 computation [EALDC]. Consequently, a fast moving MN communicating 124 with multiple CNs will have to dedicate a significant amount of its 125 available energy to exchange only mobility signaling messages with 126 the CNs. 128 OMIPv6 provides a credit-based Authorization (CBA) mechanism, which 129 aims to reduce further the latency caused by the care-of address test 130 exchange. However, such mechanism has two drawbacks: the CN may not 131 provide this feature, in which case the latency problem remains 132 unsolved, and it consumes battery power in both scenarios due to 133 exchanging signaling messages (i.e., as they get only delayed). 134 Note that the suggested protocol does not prevent both endpoints from 135 using the CBA mechanism on top of the suggested protocol. 137 On the other side, the Optimized Secure Neighbor Discovery protocol 138 (described in [OptiSeND]) is an ongoing work, which aims to better 139 adapt the requirements for securing the IPv6 neighbor discovery to 140 low computation and battery power devices (e.g., mobile devices and 141 sensors). OptiSeND enables fixed/mobile nodes to avoid using 142 expensive RSA signatures to secure neighbor discovery messages 143 exchange by providing a mechanism to quickly share a long lifetime 144 symmetric key with the AR(s). On the infrastructure side, OptiSeND 145 enables ARs to use one-way hash chains to authenticate the Router 146 Advertisement (RtAdv) messages sent to the fixed/mobile node(s) 147 attached to the same link. 149 4. Suggested Solution 151 Our proposal delegates the task of performing CoA reachability 152 test(s) to the network infrastructure, which in turn enables 153 eliminating the residual latency due to the CoA rechability test, 154 ensures that the messages exchanged are authenticated and optimizes 155 the battery power consumption by relieving the MN from performing CoA 156 reachability tests. In fact, our protocol adopts another approach to 157 perform reachability tests, which consists on testing the 158 reachability of the new MN's 64-bit subnet prefix only instead of 159 testing the reachability of the whole nCoA, and thus relies on two 160 new messages to perform such test. 162 For these purposes, the MN must securely send to the access network 163 infrastructure necessary information (called mobility package) to 164 enable performing the CoA reachability test(s) on its behalf and to 165 forward the mobility package to potential new ARs (nARs). To achieve 166 this goal, a new message called "Router Mobility Solicitation" 167 (RtMoSol) is used by the MN to send its mobility package to its 168 current AR(s). The RtMoSol message MUST carry all CNs'IPv6 addresses 169 and the MN's IPv6 home address(es) (HoAs) and MUST be authenticated 170 with the shared key obtained from OptiSeND. 172 Upon receiving a valid RtMoSol message, the selected AR SHOULD reply 173 with an authenticated unicast "Router Mobility Acknowledgment" 174 (RtMAck) message. The RtMoSol message content SHOULD be forwarded to 175 neighboring ARs and should be stored together with data obtained from 176 running OptiSeND protocol. 177 The RtMoSol message is also used by the MN to add or delete entries 178 from a mobility package stored in the AR cache memory. For example, 179 when the MN establishes a session with a new CN, it SHOULD send a 180 RtMoSol message to its current AR and SHOULD set a new bit (called 181 Add "A" bit) to request the AR to forward the new CN's IPv6 address 182 to potential new AR(s). Similarily, the MN MAY also set another bit 183 (called Suppress "S" bit) to request the AR(s) to remove an existing 184 CN's IPv6 address from its list. 186 In order to eliminate the residual latency due to performing the CoA 187 reachability test, the nAR SHOULD perform the test immediately after 188 receiving a first hint (e.g., on layer 2) indicating an attachment of 189 the MN (e.g., when using [FRD]) and SHOULD forward the message(s) 190 sent by the CN(s) to the MN after it attaches to the nAR. For this 191 purpose, the nAR SHOULD use its source address, which includes the 192 prefix advertised on the link and MUST authenticate the message with 193 a mobility signaling key (Kms). We call such message "Prefix Test 194 Init" (PreTI). In addition, the PreTI message MUST carry the MN's 195 HoA to allow the CN to fetch/generate the Kms associated with the 196 corresponding Binding Cache Entry (BCE) in order to validate the 197 message authenticity. 199 Upon receiving a valid PreTI message, the CN computes a prefix keygen 200 (prekey) token from the prefix used in the IPv6 source address and 201 the long lifetime shared secret (i.e., kbmperm) generated from using 202 OMIPv6 protocol. After computing the token, the CN SHOULD send back 203 an acknowledgment message called "Prefix Test" (PreT), which carries 204 the prekey token to the same IPv6 source address carried in the PreTI 205 message. The PreT message MUST also carry the MN's HoA and MUST be 206 authenticated with Kms. 208 The Prekey token MUST be computed by the CN in the following way: 210 Prekey Token = First [64, SHA1 (SA_Prefix | nonce | SHA1 (Kbmperm))] 212 Where SA_Prefix is the 64-bit prefix included in the IPv6 source 213 address sent in the PreTI message and Kbmperm is the long lifetime 214 shared secret generated by the CN when running OMIPv6 protocol. 216 As mentioned above, the prefix reachability test SHOULD be 217 authenticated with Kms. In order to do so, Kms SHOULD be computed 218 from using the symmetric key generated from running OptiSeND protocol 219 and the MN's HoA, and MUST be send encrypted to each CN. One way to 220 achieve a confidential transmission of Kms is to send it encrypted in 221 the first BU message sent by the MN. In such scenario, the MN will 222 use its Kbm (computed from running the return routability procedure) 223 to encrypt Kms. Finally, Kms will be carried in a new option called 224 signaling delegation (SID). 226 Upon receiving a BU message carrying a SID option, the CN decrypts 227 Kms and stores it in the MN's corresponding BCE. All subsequent 228 reachability test messages SHOULD be sent by the MN's current AR on 229 behalf of the MN and SHOULD be authenticated with Kms. 231 5. New Options and Messages 233 TBD 235 6. Security Considerations 237 This draft proposes a scheme to delegate mobility signaling from the 238 mobile node to the network infrastructure. Since the network 239 infrastructure nodes are well known and trustworthy, it makes 240 firewalling easier at the administrative boundaries. Also, since the 241 network infrastructure nodes are likely to have more resources than 242 mobile nodes, this scheme will allow us to use higher strength crypto 243 to protect the signaling. This draft does not introduce any new 244 security holes into existing route optimization solutions. 246 7. References 248 7.1. Normative References 250 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 251 in IPv6", RFC 3775, June 2004. 253 [OMIPv6] Vogt, C., Arkko, J., and W. Haddad, "Enhanced Route 254 Optimization for Mobile IPv6", RFC 4866, June 2006. 256 [SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. 257 Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971, 258 March 2005. 260 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 261 Requirement Levels", RFC 2119, BCP , March 1997. 263 7.2. Informative References 265 [EALDC] Barr, K. and K. Asanovic, "Energy Aware Lossless Data 266 Compression", ACM Proceedings of MobiSys, May 2003. 268 [FRD] Choi, J., Shin, D., and W. Haddad, "Fast Router Discovery 269 with L2 Support", Internet 270 Draft, draft-ietf-dna-frd-01.txt, June 2006. 272 [OptiSeND] 273 Haddad, W., Krishnan, S., and J. Choi, "Secure Neighbor 274 Discovery (SeND) Optimization: The OptiSeND Protocol", 275 Internet Draft, draft-haddad-mipshop-optisend-03.txt, 276 July 2007. 278 Authors' Addresses 280 Wassim Haddad 281 Ericsson Research 282 Torshamnsgatan 23 283 SE-164 80 Stockholm 284 Sweden 286 Phone: +46 8 4044079 287 Email: Wassim.Haddad@ericsson.com 289 Suresh Krishnan 290 Ericsson Research 291 8400 Decarie Blvd. 292 Town of Mount Royal, QC 293 Canada 295 Phone: +1 514 345 7900 296 Email: Suresk.Krishnan@ericsson.com 298 Francis Dupont 299 CELAR 301 Email: Francis.Dupont@fdupont.fr 303 Full Copyright Statement 305 Copyright (C) The IETF Trust (2007). 307 This document is subject to the rights, licenses and restrictions 308 contained in BCP 78, and except as set forth therein, the authors 309 retain all their rights. 311 This document and the information contained herein are provided on an 312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 314 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 315 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 316 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 Intellectual Property 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Acknowledgment 345 Funding for the RFC Editor function is provided by the IETF 346 Administrative Support Activity (IASA).