idnits 2.17.1 draft-haddad-mipshop-optisend-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 426. 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 9, 2007) is 6129 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) ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') ** Downref: Normative reference to an Informational RFC: RFC 3756 (ref. 'NDT') Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Optimizations W. Haddad 3 Internet-Draft S. Krishnan 4 Expires: January 10, 2008 Ericsson Research 5 J. Choi 6 Samsung AIT 7 J. Laganier 8 Docomo Euro-Labs 9 July 9, 2007 11 Secure Neighbor Discovery (SeND) Optimizations: The OptiSeND Protocol 12 draft-haddad-mipshop-optisend-03 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 10, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This memo describes a new set of mechanisms, which aim to increase 46 the Secure Neighbor Discovery protocol usability, provide additional 47 deployment incentives and a better adaptation to mobile environment. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Motivation and Goal . . . . . . . . . . . . . . . . . . . . . 6 55 5. Overview of OptiSeND . . . . . . . . . . . . . . . . . . . . . 7 56 6. New Options and Messages Formats . . . . . . . . . . . . . . . 10 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 58 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 61 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 63 Intellectual Property and Copyright Statements . . . . . . . . . . 15 65 1. Introduction 67 Securing Neighbor Discovery Protocol [SeND] has been designed to 68 mitigate potential threats against IPv6 Neighbor Discovery Protocol 69 [NDP]. SeND protocol is based uniquely on the Cryptographically 70 Generated Address [CGA] technology. 72 The reliance on RSA signature may severely hamper SeND protocol 73 usability and deployment in the wireless world. This is mainly due 74 to the fact that the vast majority of mobile devices share a severe 75 limitation in terms of processing power (and battery consumption). 77 This memo describes a new protocol called OptiSeND, which aims to 78 increase SeND protocol usability, provide additional deployment 79 incentives and a better adaptation to mobile environment. 81 We achieve our goals by reducing the reliance on RSA signature to 82 validate the flow of periodic multicast router adverstisement 83 (RtAdv), authenticating the NDP messages and removing the latency 84 caused by running the duplicate address detection (DAD) procedure. 85 Other features may also be provided. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [TERM]. 93 3. Glossary 95 Access Router (AR) 97 The Access Router is the mobile node's default router. 99 Attached Node (AN) 101 An attached node (AN) is a node, which is already attached to the 102 infrastructure via one or many Access Router(s). An AN is able to 103 validate a multicast RtAdv message(s) without checking its 104 signature. An AN can be static or mobile. 106 Soliciting Node (SN) 108 A soliciting node is a node, which has started the procedure to 109 attach itself to the infrastructure by sending a router 110 solicitation (RtSol) message signed with CGA technology to a 111 selected AR. After exchanging the first RtSol/RtAdv messages, the 112 SN is supposed to become an AN. 114 One-Way Chain 116 A one-way chain (Vo...Vn) is a collection of values such that each 117 value Vi (except the last value Vn) is a one-way function of the 118 next value Vi+1. In particular, we have Vi = H(Vi+1), for i 119 belonging to [0,n[. For clarity purpose and to avoid confusion, 120 we'll use in the rest of this document the notation V[i] instead 121 of Vi, which means V[i+1] points to Vi+1... 123 Neighbors 125 Nodes attached to the same link. 127 For more details about the one-way chain, please refer to [OWHC]. 129 4. Motivation and Goal 131 IPv6 NDP has been designed to enable nodes on the same link to 132 discover each other's presence and link-layer addresses, to find 133 routers, and to maintain reachability information about the paths to 134 active neighbors. NDP is used by both hosts and routers. Its 135 functions include Neighbor Discovery, Router Discovery, Address 136 Autoconfiguration and Resolution, Neighbor Unreachability Detection, 137 Duplicate Address Detection (DAD), and Redirection. 139 [NDT] describes different threats, which may appear when NDP is 140 applied without any protection (e.g., public WLAN network). These 141 threats can materialize on a particular link in a severe disruption 142 of information exchange, e.g., due to launching DoS attacks against 143 one or many nodes. SeND protocol has been designed to counter 144 threats described in the NDT. For this purpose, SeND relies solely 145 on CGA technology to provide IPv6 address proof of ownership, sign 146 NDP messages and consequently, build a form of trust relationship 147 between different nodes. SeND protocol is highly recommended when 148 attached nodes (ANs) are using NDP to communicate with the 149 infrastructure and/or between themselves as neighbors. 151 When SeND protocol is used between nodes and the infrastructure, an 152 AR is expected to use CGA technology in all messages sent to any AN. 153 As previously mentioned, CGA technology allows the AR to provide a 154 proof of ownership of its claimed IP address(es) and enables the 155 receiving node(s) to validate information carried in these messages. 156 Note that the SN may or may not be SeND enabled and thus may not be 157 able to secure the RtSol message sent to the AR(s). Similarly, 158 applying SeND protocol to secure NDP exchange enables each node to 159 provide a proof of ownership of its newly configured IP address(es), 160 thus eliminating certain malicious behavior, e.g., when checking its 161 uniqueness via the DAD procedure. 163 The main goal of this document is to provide an alternative solution 164 to the RSA signature, which one one side, encourages all nodes to use 165 SeND and increases the deployment scale, but on the other side, 166 eliminates the reliance on CGA technology whenever possible. Our 167 current design is limited to the exchange of NDP messages between AN 168 and the infrastructure and slightly cover the ND messages exchange 169 between neighbors. This part is left for future work. 171 5. Overview of OptiSeND 173 The first goal behind designing OptiSeND protocol is to eliminate the 174 need for ANs to validate RSA signatures whenever possible. We 175 achieve our goal by exploiting the fact that the content of the 176 router advertisement message itself does not get modified frequently. 177 It follows that prefixes advertised on one particular link together 178 with their associated parameters are likely to appear unmodified in 179 each subsequent RA message. However, there are cases where prefixes 180 do change when renumbering is needed. Such scenario is also 181 supported in our approach. 183 In the following, we refer to such message (i.e., plain message) by 184 RA message and we use the RtAdv notation to refer to an RA message 185 with SeND protection, i.e., carrying RSA signature and associated 186 parameters. 188 Another goal is to enable each SN to share a secret with its AR when 189 exchanging the first pair of RtSol/RtAdv messages. The shared secret 190 is then used to authenticate all NDP messages as they get exchanged 191 via the AR instead of doing it on the link. The NDP messages re- 192 routing is needed in order to avoid sharing secrets between each and 193 every neighbor. In addition, ANs should skip the DAD procedure by 194 delegating such task to the AR whenever possible, in order to reduce 195 the handoff latency in a mobile environment. 197 OptiSeND protocol removes the need to verify RSA signatures in an 198 entire set of RtAdv messages carrying an identical multicast RA 199 message, except for the first one, which MUST be sent to the SN in 200 unicast mode. Note that in our context, "identical" refers to 201 prefixes and associated parameters. We achieve this goal in two 202 steps. The first one consists on using a particular OWHC value as a 203 "hook" to enable the SN to quickly validate the sequence of 204 subsequent RtAdv messages. Such requirement imposes on the AR to 205 send to the SN the last disclosed value, i.e., to be used as the 206 hook, of its OWHC. For this purpose, the OWHC value is carried by 207 the unicast (and first) RtAdv message. The second step is achieved 208 by inserting in the same (first) unicast RtAdv message sent to the SN 209 the hash value, i.e., called "Z", of the next RtAdv message 210 concatenated with the next, i.e., yet undisclosed, OWHC value and the 211 next timestamp value. This means that if OWHC[i] is the last 212 disclosed OWHC value sent to the SN, then "Z" is computed in the 213 following way: 215 Z = First [ 64, Hash [ RA[i+1] | OWHC[i+1] | Timestamp[i+1] ] ] 217 Where: 219 - "Z" is the hash value inserted in a new option in the RtAdv 220 message. 221 - First (size, input) indicates truncation of "input" data so that 222 only the first "size" bits remain to be used. 223 - RA[i+1] is the next multicast router advertisement sent after 224 sending the unicast RtAdv to the SN. 225 - OWHC[i+1] is the new and undisclosed value of the OWHC. 226 - Timestamp[i+1] is the timestamp value which is sent in the next 227 RtAdv message, i.e., RtAdv[i+1]. 229 It follows that the content of the unicast RtAdv message sent to the 230 SN is as it follows: 232 RtAdv[i] = { RA[i] | Z | OWHC[i] | Timestamp[i] | SIG(Kp, RtAdv[i] } 234 Where SIG(K, M) is the signature computed over the entire message M 235 with key K. 237 Such procedure is then repeated in each subsequent multicast RtAdv 238 messages sent on the link. Doing so, enables ANs to easily validate 239 all subsequent multicast RtAdv messages by checking first if the 240 disclosed OWHC value carried in the newly received message is valid 241 and then use it to compute "Z" and compare it to the one sent in the 242 previous RtAdv message. Note that the timestamp used in the RtAdv 243 message will also be used to keep AN(s) synchronized to the OWHC. In 244 case, an AN misses one multicast RtAdv message, it should solicit a 245 re-synchronization by sending an authenticated RtSol message. In 246 this case, the AR SHOULD send back an authenticated unicast RtAdv 247 message similar to the first one sent to any SN in unicast mode. The 248 AR MAY also sign the unicast RtAdv message but the signature 249 validation is not needed. 251 In a mobile environment, the mobile node (MN) may miss the RtAdv 252 message due to switching between ARs. In this particular case, the 253 new AR (nAR) and the MN should share a new secret to authenticate 254 subsequent NDP messages. It follows that the MN should send a new 255 RtSol message signed with CGA in order to get an encrypted copy of 256 the shared secret from the nAR. An optimization to the handoff 257 procedure would consist on enabling a closer collaboration between 258 ARs, in order to avoid sharing a new secret each time the MN switches 259 to a new AR. Such optimization requires secure links and trust 260 between ARs. 262 As mentioned earlier, the proposed solution removes the need to 263 verify the RSA signature in each RtAdv message. This also means that 264 the AR will always sign each RtAdv message sent in unicast or 265 multicast mode. However, the AN will first rely on the OWHC 266 technique to validate its content. In case, crucial data have been 267 modified in the latest multicast RtAdv message, then the signature 268 MUST be checked. Otherwise, the AN can skip such procedure and store 269 the carried hash value (Z) whose components will be disclosed in the 270 next RtAdv. Finally, the AN SHOULD discard any multicast RtAdv 271 message, which carries a non-valid timestamp unless it has been 272 received after a layer 2 handoff. 274 An AR should store in its cache the AN's CGA public key, its MAC 275 address, the CGA-based interface identifier(s) (IID(s)) and the 276 corresponding shared secret (called Ks). Storing the IID(s) can also 277 be used to remove the need for running DAD procedures, and additional 278 IID(s) MAY be generated from combining Ks with additional parameters. 279 Note that an AR can store the AN's corresponding parameters for a 280 limited amount of time after which, it should check again its 281 presence on the link. Ks is computed by the AR and MUST be sent 282 encrypted to SN. For this purpose, the AR MUST use SN's CGA public 283 key sent in the (first) RtSol message to encrypt Ks. The shared 284 secret should be refreshed when its lifetime expires. 286 When a NDP messages exchange is needed between two neighboring ANs, 287 NDP messages MUST be exchanged via the AR in order to avoid using CGA 288 signature in each message while protecting their integrity. For this 289 purpose, and in order to avoid inflating each NDP message with an 290 additional IPv6 header, a new option is defined to indicate to the AR 291 the destination address to be querried. If the received message is 292 valid, the AR sends the NDP message to the destination and 293 authenticates the message with the corresponding shared secret. 294 After receiving a valid response from the destination, the AR sends 295 back an authenticated ND message to the sender, which carries the 296 response provided by the destination. 298 6. New Options and Messages Formats 300 TBD 302 7. Security Considerations 304 This memo introduces a new mechanism which is built on top of SeND 305 protocol. The main goal behind OptiSeND design is to improve the 306 usability, make a strong(er) case for potential deployment and widen 307 its scope to include new features. We believe that this goal can be 308 achieved without introducing new threats nor amplifying existing 309 ones. 311 However, expanding OptiSeND protocol in order to enable additional 312 features, e.g., fast mobility, signaling delegation, etc, requires 313 secure links and trust between ARs and possibly between ARs and the 314 access points. 316 8. Acknowledgments 318 Authors would like to thank Pekka Nikander for his valuable input at 319 the early stage of this work. 321 9. References 323 9.1. Normative References 325 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 326 RFC 3792, March 2005. 328 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 329 "Neighbor Discovery for IP Version 6 (IPv6)", Internet 330 Draft, draft-ietf-ipv6-2461bis-11.txt, March 2007. 332 [NDT] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 333 Discovery (ND) Trust Model and Threats", RFC 3756, May 2004. 335 [SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. 336 Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971, 337 March 2005. 339 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 340 Requirement Levels", RFC 2119, BCP , March 1997. 342 9.2. Informative Reference 344 [OWHC] Hu, Y., Jakobsson, M., and A. Perrig, "Efficient 345 Constructions for One-Way Hash Chains", ACNS Conference, 346 June 2005. 348 Authors' Addresses 350 Wassim Haddad 351 Ericsson Research 352 Torshamnsgatan 23 353 SE-164 80 Stockholm 354 Sweden 356 Phone: +46 8 4044079 357 Email: Wassim.Haddad@ericsson.com 359 Suresh Krishnan 360 Ericsson Research 361 8400 Decarie Blvd. 362 Town of Mount Royal, QC 363 Canada 365 Phone: +1 514 345 7900 366 Email: Suresh.Krishnan@ericsson.com 368 JinHyeock Choi 369 Samsung AIT 370 Communication & N/W Lab 371 Suwon 440-600 372 P.O. Box 111 373 KOREA 375 Phone: +82 31 280 9233 376 Email: jinchoe@samsung.com 378 Julien Laganier 379 Docomo Communications Laboratories Europe GmbH 380 Landsberger Strasse 312 381 Munich 80687 382 Germany 384 Phone: +49 89 56824 231 385 Email: Julien.ietf@laposte.net 386 URI: http://www.docomolab-euro.com 388 Full Copyright Statement 390 Copyright (C) The IETF Trust (2007). 392 This document is subject to the rights, licenses and restrictions 393 contained in BCP 78, and except as set forth therein, the authors 394 retain all their rights. 396 This document and the information contained herein are provided on an 397 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 398 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 399 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 400 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 401 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 402 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 404 Intellectual Property 406 The IETF takes no position regarding the validity or scope of any 407 Intellectual Property Rights or other rights that might be claimed to 408 pertain to the implementation or use of the technology described in 409 this document or the extent to which any license under such rights 410 might or might not be available; nor does it represent that it has 411 made any independent effort to identify any such rights. Information 412 on the procedures with respect to rights in RFC documents can be 413 found in BCP 78 and BCP 79. 415 Copies of IPR disclosures made to the IETF Secretariat and any 416 assurances of licenses to be made available, or the result of an 417 attempt made to obtain a general license or permission for the use of 418 such proprietary rights by implementers or users of this 419 specification can be obtained from the IETF on-line IPR repository at 420 http://www.ietf.org/ipr. 422 The IETF invites any interested party to bring to its attention any 423 copyrights, patents or patent applications, or other proprietary 424 rights that may cover technology that may be required to implement 425 this standard. Please address the information to the IETF at 426 ietf-ipr@ietf.org. 428 Acknowledgment 430 Funding for the RFC Editor function is provided by the IETF 431 Administrative Support Activity (IASA).