idnits 2.17.00 (12 Aug 2021) /tmp/idnits56381/draft-haddad-mext-mobisoc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (March 13, 2011) is 4080 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) == Outdated reference: draft-ietf-mext-rfc3775bis has been published as RFC 6275 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions for IPv6 W. Haddad 3 (Mext) Ericsson 4 Internet-Draft March 13, 2011 5 Intended status: Standards Track 6 Expires: September 14, 2011 8 Enhancing Mobile IPv6 Route Optimization Mode with Secure Social 9 Dimension 10 draft-haddad-mext-mobisoc-04 12 Abstract 14 This memo introduces the concept of peer-to-peer route optimization 15 mode which enables Mobile IPv6 route optimization, without requiring 16 mobility signaling messages exchange between two mobile endpoints. 17 For this purpose, we use a social dimension within the home network 18 as one tool to implement our concept. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 14, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions used in this document . . . . . . . . . . . . . . 4 56 3. Motivation and Goal . . . . . . . . . . . . . . . . . . . . . 5 57 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 58 5. New Options, Bits and Messages Formats . . . . . . . . . . . . 8 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 63 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 1. Introduction 68 This memo introduces the concept of "peer-to-peer (P2P)" route 69 optimization (RO) mode which enables Mobile IPv6 70 ([I-D.ietf-mext-rfc3775bis]) route optimization, without requiring 71 mobility signaling messages exchange between two mobile endpoints. 72 For this purpose, we use a social dimension within the home network 73 as one tool (among others), to implement our concept. 75 By limiting the scope to the home network, our suggested proposal can 76 be applied only to mobile nodes using the same HA (or cluster of 77 HAs). In this context, our tool enables two mobile endpoints which 78 know each other "fairly" well (e.g., a la Facebook) to trigger the RO 79 mode without exchanging any mobility signaling messages on the direct 80 path. 82 2. Conventions used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Motivation and Goal 90 It is important to start this section by highlighting an important 91 observation related to the selected tool. In fact, neither the 92 selected tool nor any other tool may be needed in order to implement 93 P2P RO mode (i.e., case where the decision to switch or not to the RO 94 mode is made only by the common HA). In fact, using the social 95 variable provides a clear description of how P2P RO mode could work 96 in general. 98 Our tool selection is motivated by the stunning growth of social 99 networking especially now that is becoming a desirable component and 100 enabler for successful and attractive technologies. 102 It is also well known that the RO mode enables a more efficient data 103 packets exchange than the bidirectional tunneling and thus, should be 104 applied whenever possible unless the mobile node (MN) is not 105 interested in disclosing its topological location, i.e., care-of 106 address (CoA), for the correspondent node (CN), e.g., for privacy 107 reasons. 109 However, MIPv6 RO mode requires exchanging a significant amount of 110 mobility signaling messages in order to establish, and periodically 111 refresh a bidirectional security association (BSA) between the MN and 112 the CN. While the mobility signaling exchange severely impacts the 113 handoff latency, the BSA is needed to authenticate two particular 114 messages only, namely the binding update (BU) and binding 115 acknowledgement (BA) messages (although it can be argued that sending 116 a BA is not mandatory). Note also that the amount of mobility 117 signaling messages further increases when the CN is also mobile. 119 Our goal is to enable RO mode between two mobile endpoints at minimum 120 or no cost. This means that two mobile nodes should be able under 121 some specific circumstances, e.g., if they both explicitly ask for 122 it, to switch from BT mode to RO mode without exchanging additional 123 mobility signaling messages on the direct path nor through their HA. 124 The immediate results are a much lower handoff latency to apply RO 125 mode and the absence of BSA. 127 4. Protocol Description 129 Our proposal enables two mobile users who are mutual friends, e.g., 130 two "buddies", to translate their friendship at a network and device 131 levels into a "bidirectional cryptographic relationship (BCR)". At 132 some particular point, e.g., before or during an ongoing session, the 133 two "buddies" confidentially disclose their BCR to their HA, in order 134 to request implementing a fast "zero signaling message" RO mode. 136 An important observation is to mention that expressing mutual 137 friendship is by no means limited to establishing BCR between two or 138 more "buddies". In this proposal, we use crypto-relationship only as 139 an example to demonstrate how social networking can be used in order 140 to optimize dual mobility. 142 To better clarify our ideas, we consider in the following, two mobile 143 "buddies" using each its mobile device, i.e., MN1 and MN2. Our 144 proposal requires the mobile nodes to use "cryptographically 145 generated address (CGA)" technique (described in [RFC3972]), in order 146 to compute and auto-configure their IPv6 home addresses. Note that 147 using CGA in our context can also serve for authentication purposes 148 between the MN and its HA, as described in [I-D.laganier-mext-cga]. 149 We also assume that the two mobile devices have already established a 150 bidirectional cryptographic relationship. For this purpose, the 151 "Secure Neighbor Discovery" protocol ([RFC3971]) can be used. 152 Appendix 1 describes how the BCR can be computed between the two 153 mobile devices and the parameters sent by each MN to the HA, in order 154 to disclose the BCR. It should be noted that the established BCR 155 MUST be disclosed to the HA either before or during an ongoing 156 session between the two mobile devices. In the following, we 157 consider that the BCR is disclosed when MIPv6 handoff signaling is 158 exchanged between each MN and its HA. 160 Let's consider that MN1 is the first to move to a foreign network. 161 After configuring its CoA, MN1 sends a BU message to its HA. An 162 explicit request to enabling P2P RO mode between the two mobile 163 endpoints requires MN1 to disclose its BCR with MN2 to the HA. For 164 this purpose, MN1 inserts BCR parameters related to MN2 in new 165 options carried by the BU message. These parameters are then stored 166 by the HA and a BA message is sent to MN1. No further action is 167 required at this stage until MN2 moves to a foreign network. 169 When MN2 attaches to a foreign network, it exlicitly requests from 170 its HA a P2P RO mode service with MN1. This is done exactly in the 171 same way as with MN1's request, i.e., by sending BCR parameters 172 related to MN1 in the BU message sent to the HA. At this stage, the 173 HA has all necessary BCR parameters to validate and act upon. 174 Assuming that the claimed BCR between the two mobile nodes is valid, 175 the HA proceeds in two directions simultaneously. In the first one, 176 it sends back a BA message to MN2 in which it inserts MN1's CoA (and 177 potentially a selected list of flows that should be moved to the 178 direct path). In another direction, the HA sends a new signaling 179 message ("Neighbor Binding Update (NBU)") to MN1. NBU message 180 carries MN2's new CoA (and the same list of flows which has been sent 181 to MN2 in the BA message). After validating the NBU message, MN1 182 MUST send back a new message ("Neighbor Binding Acknowledgement 183 (NBA)") to the HA. 185 It becomes clear at this stage that both NBU and NBA messages will be 186 authenticated using the same security mechanisms already in place 187 between MN1 and its HA. This means that both messages are injected 188 in the same IPsec tunnel established between the two nodes. 189 Consequently, no additional security mechanism between the MN and its 190 HA is required at any stage. 192 The inclusion of MN1's CoA in the BA message together with sending an 193 NBU message to MN1 allow both mobile nodes to quickly learn each 194 other's current topological location from a "trusted" source, and to 195 create the necessary binding in order to immediately redirect their 196 data packets on the direct path. As previously highlighted, such 197 redirection does not require exchanging direct mobility signaling 198 messages between the two MNs prior to exchanging data packets on the 199 direct path. Hence, the return routability (RR) procedure is not 200 needed anymore. 202 Note that in order to increase the overall performance, the HA can 203 send multiple consecutive copies of the NBU messages until it 204 receives a valid NBA message. 206 Subsequent BU messages sent to the HA and carrying new CoAs are 207 processed in the same way as the first one as long as the selected 208 flows (i.e., the one(s) that were moved to the direct path) are still 209 active. This means that the HA should always simultaneously update 210 the buddy node while acknowledging the BU message. 212 The suggested proposal can be extended to include multiple mobile 213 nodes in which case the neighbor update(s) would consist of sending 214 one or multiple NBU messages to the designated "buddies" nodes 215 located outside the home network. 217 5. New Options, Bits and Messages Formats 219 TBD 221 6. Security Considerations 223 This proposal aims to enhance the RO mode efficiency by removing the 224 need for the return routability procedure. It should be noted that 225 the RR procedure was carefully designed in order to mitigate a 226 significant number of threats. Its main drawback was the amount of 227 signaling messages which was needed between the MN and the CN. By 228 removing the need for the RR procedure, these threats are also 229 eliminated which in turn would significantly increase the overall 230 security. 232 In MIPv6 protocol, there is one mandatory secure path between the MN 233 and its HA and one trusted node, i.e., the HA. Our suggested 234 mechanism introduces two new signaling messages which are exchanged 235 between the MN and its HA over the secure path. Consequently, these 236 two messages do not introduce any new threats as they are exchanged 237 within the IPsec ESP tunnel established between the MN and its HA. 239 In addition to the encryption and integrity protection set up between 240 the MN and the HA, there is also a mutual trust between the two nodes 241 which provides insurance about the validity of the new messages 242 content. However, the mutual trust between the MN and the HA does 243 not propagate among mobile nodes sharing the same HA. 245 7. References 247 7.1. Normative References 249 [I-D.ietf-mext-rfc3775bis] 250 Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 251 in IPv6", draft-ietf-mext-rfc3775bis-13 (work in 252 progress), March 2011. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 258 Neighbor Discovery (SEND)", RFC 3971, March 2005. 260 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 261 RFC 3972, March 2005. 263 7.2. Informative References 265 [I-D.laganier-mext-cga] 266 Laganier, J., "Authorizing Mobile IPv6 Binding Update with 267 Cryptographically Generated Addresses", 268 draft-laganier-mext-cga-01 (work in progress), 269 October 2010. 271 Appendix A. 273 The required BCR between the two mobile nodes is used as a proof of 274 mutual friendship. For this purpose, each unidirectional crypto- 275 relationship can be generated as it follows: 277 When MN2 establishes a unidirectional crypto-relationship with MN1, 278 it generates a 128-bit modifier from hashing MN1's public key 279 together with a 128-bit random number (RAN): 281 Modifier = First [128, SHA-2(PK(MN1) | RAN) ] 283 MN2 confidentially notifies MN1 about the RAN used to generate its 284 CGA address and MN1 stores the RAN together with MN2's CGA address. 285 The same procedure is repeated by MN1 in order to compute its 286 unidirectional relationship with MN2. 288 Each MN can confidentially share its own part of the BCR with its HA 289 whenever needed (e.g., in order to request a P2P RO mode service). 290 For this purpose, the "proof of friendship" is inserted in the first 291 BU message sent by MN1 to its HA. Such proof consists of MN2's IPv6 292 address, public key and RAN. After CGA validation, the HA stores the 293 crypto-relationship in the binding cache entry (BCE) created for MN1. 295 As already mentioned, when MN2 moves to a foreign network, it 296 discloses its own crypto-relationship with MN1. At this stage, the 297 HA can validate the BCR and take appropriate actions. 299 Author's Address 301 Wassim Michel Haddad 302 Ericsson 303 300 Holger Dr 304 San Jose, CA 95134 305 US 307 Phone: +1 646 256 2030 308 Email: Wassim.Haddad@ericsson.com