idnits 2.17.00 (12 Aug 2021) /tmp/idnits51797/draft-haddad-mipshop-tunneling-optimization-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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.) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (March 9, 2009) is 4814 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) -- Obsolete informational reference (is this intentional?): RFC 5268 (ref. 'FMIPv6') (Obsoleted by RFC 5568) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP WG W. Haddad 3 Internet-Draft 4 Intended status: Standards Track M. Naslund 5 Expires: September 10, 2009 Ericsson Research 6 P. Nikander 7 Ericsson Research Nomadic Lab 8 March 9, 2009 10 IP Tunneling Optimization in a Mobile Environment 11 draft-haddad-mipshop-tunneling-optimization-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 10, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This memo introduces a simple tunneling optimization mechanism, which 50 removes the need for inserting an additional header in the IP packet. 51 The main goals are to minimize the packet size, provide a simpler 52 protocol design and a better efficiency. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Tunneling Optimization for BT mode and HMIPv6 . . . . . . . . 7 60 5. Tunneling Optimization for RO mode . . . . . . . . . . . . . . 11 61 6. Tunneling Optimization for DSMIPv6 . . . . . . . . . . . . . . 12 62 7. Bit and Options Formats . . . . . . . . . . . . . . . . . . . 13 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 67 10.2. Informative References . . . . . . . . . . . . . . . . . 16 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 70 1. Introduction 72 IP tunneling is a mechanism widely used for different purposes. For 73 example, it enables relying on a dedicated third party to modify the 74 IP packet header, in order to re-route the packets to their new 75 destination. This is mainly the case in a mobile environment where 76 IP tunneling is used in most protocols. In fact, the mobile IPv6 77 bidirectional tunneling (BT) mode described in [MIPv6]) uses IP 78 tunneling to route data through the home agent (HA). The same 79 mechanism is applied between the mobility anchor point (MAP) and the 80 mobile node (MN) in the hierarchical mobile IPv6 (HMIPv6) protocol 81 (described in [HMIPv6]). A modified IP tunneling version is also 82 used in MIPv6 route optimization (RO) mode. 84 This memo introduces a simple tunneling optimization (TO) mechanism, 85 which virtualizes the IP tunnel concept often used in traffic 86 exchange. TO mechanism is based on securely exchanging a "pad 87 translator" (PaT) between both sides of the (supposed) tunnel. 88 The PaT main role is to translate incoming/outgoing packet header to 89 another one before injecting it inside/outside the tunnel. TO main 90 goals include a reduced packet size, a simpler protocol design and a 91 better efficiency. 93 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [TERM]. 99 3. Motivation 101 The motivation behind this work is the widespread use of different 102 forms of IP tunneling mechanisms in mobile environment and their 103 negative impact on the protocol efficiency as translated in the data 104 packet size, bandwidth usage and battery power consumption. 106 In the following, we consider IPv6 mobility protocols only and start 107 with a brief description of the IP tunneling mechanism used in both 108 MIPv6 BT mode and HMIPv6 protocol. Next, we describe the MIPv6 RO 109 mode tunneling mechanism, then show in the next section how the TO 110 mechanism completely eliminates the need for IP tunneling in these 111 mobility protocols in a simple and elegant way. 112 Other mobility related protocols, e.g., Fast MIPv6 described in 113 [FMIPv6] and the ongoing work on proxy MIPv6 ([PMIPv6]) can also 114 benefit from using TO mechanism, especially when the path between 115 access routers (ARs) and/or between the HA and a PMIPv6 node(s) 116 includes a wireless medium. 118 A closer look on the tunneling mechanism used in the BT mode (i.e., 119 between the HA and the MN) and HMIPv6 protocol (i.e., between the MAP 120 and the MN) highlights different issues that need to be addressed. A 121 first one is the expansion of the packet size due to the addition of 122 a new IP header. In the two protocols, such expansion is mainly 123 equal to two IP addresses. This means that the MN has to send at 124 least an additional 256 bits each time it transmits a data packet to 125 the CN. The impact of such addition is very significant on the 126 battery life. In fact, it has been shown in [EALDC] that wireless 127 transmission of a single bit can require over 1000 times more energy 128 than a single 32-bit computation. 129 Consequently, it would be more beneficial for the MN to avoid 130 transmitting extra bits over the air interface in exchange for some 131 additional computation only. 133 A second issue is the impact of packet size on the available 134 bandwidth. In fact, as wireless bandwidths have gained the solid 135 reputation of being always scarce, it would be of great importance to 136 monitor carefully how they are managed, especially when real time 137 multimedia applications are introduced on a larger scale. 138 Consequently, eliminating the extra bits added to each IP packet 139 header would also be highly beneficial for the network access 140 provider. 142 A third issue is related to privacy aspects. In fact, when 143 exchanging data traffic with the HA, the MN has to include its IPv6 144 home address (HoA) in each data packet sent to the HA, in addition to 145 its care-of address (CoA) (or its regional care-of address (RCoA) 146 when sending data packets to the MAP in addition to the on-link CoA 147 (LCoA)). Similarly, the HA has to disclose the MN's HoA and CoA in 148 each data packet sent to the MN (or the RCoA and LCoA in each data 149 packet sent by the MAP to the MN). It follows that having the two 150 MN's addresses disclosed in the same data packet enables a malicious 151 node located on path between the MN and the HA or between the MN and 152 the MAP to easily identify, link and trace the MN's movements. Note 153 that the MN's privacy can be better protected if the traffic is 154 encrypted, which may not be always possible for various reasons. 156 When the RO mode is used, the tunneling mechanism applied between the 157 MN and the CN differs from the one used in the BT mode and HMIPv6 158 protocol in the fact that it adds only one additional IP address, 159 i.e., the MN's HoA, in each data packet exchanged between the two 160 endpoints. This means that each data packet sent/received by the MN 161 MUST carry three IP addresses instead of four: the MN's CoA, the CN's 162 address and the MN's HoA. For this purpose, the MN uses a Home 163 Address Option (HAO) to carry its HoA in each data packet sent to the 164 CN and the CN uses a Routing Header (RH) to carry the MN's HoA in 165 each data packet sent to the MN. The use of HAO and RH are in fact 166 degenerated tunnels as shown in [TUN]. This form of tunneling is 167 mandated as long as the MN's corresponding binding lifetime has not 168 expired. 169 The impact of the RO tunneling on the MN's privacy is the same as 170 described earlier in the BT mode and HMIPv6 protocol. The fact that 171 each data packet discloses the MN's HoA and CoA enables a malicious 172 node located on path between the two endpoints to identify, link and 173 trace the MN's movements across the Internet. 175 Note that using a PaT does not completely solve the privacy problem. 176 However, it offers a significant advantage in the fact that it 177 narrows the problem to the critical signaling messages, i.e., Binding 178 Update and Acknowledgment (BU/BA) in the case of BT and RO modes and 179 the Local BU (LBU) in the HMIPv6 case, where applying security 180 measures is not just an option. It follows that hiding/replacing the 181 HoA in and encrypting the PaT sent in the BU message are two measures 182 which can provide privacy protection for the MN against eavesdroppers 183 located on path between the MN and the CN/HA/MAP. 185 4. Tunneling Optimization for BT mode and HMIPv6 187 TO mechanism addresses tunneling issues described earlier by keeping 188 the original packet size unmodified and removing the need for an 189 additional IP header. 191 TO mechanism is based on using a PaT to easily translate IP packets 192 headers to new ones which reflect the topologies of the new chosen 193 origin and destination. We limit the scope of the PaT in this 194 document to IPv6 addresses only but it is important to note that its 195 usefulness can also be expanded to translate content(s) of other 196 particular field(s). Another way to describe the PaT functionality 197 is to consider it as a mechanism which virtualizes the need for 198 explicit tunneling. 200 In order to better describe the suggested mechanism, we apply it to 201 the BT mode and describes the different steps required between the MN 202 and the HA to implement it. In case of HMIPv6 protocol, we note that 203 the same approach can be applied but with HMIPv6 specific signaling 204 messages and IPv6 addresses. After that, we apply the suggested 205 mechanism in the RO mode. 207 The BT mode starts after the MN switches to a foreign network. In 208 this case, the MN configures a new CoA and notifies its HA by 209 securely exchanging a BU and BA messages. After creating the binding 210 between the two MN's addresses, both nodes start tunneling data 211 packets between them. From the MN side, IP tunneling is applied on 212 each data packet sent to the HA by attaching an outer IP header which 213 contains the MN's CoA as source address and the HA's IP address as 214 destination address. The inner IP header carries the MN's HoA as 215 source address and the CN's address as destination address. 216 On the HA side, IP tunneling is applied on incoming data packets 217 (i.e., sent by the CN to the MN's HoA) by attaching to each packet an 218 outer which carries the MN and the HA IP addresses i.e., the source 219 address becomes the HA's address and the destination address is the 220 MN's CoA. 222 The data packet tunneling format on the MN and HA sides is as 223 follows: 225 <-- outer IPv6 header -> <-- inner IPv6 header -> 226 +----+--------+--------+ +----+--------+--------+ +------------ 227 | | | | | | | | | 228 |oNAF| oSRC | oDEST | |iNAF| iSRC | iDEST | | iPAYLOAD 229 | | | | | | | | | 230 +----+--------+--------+ +----+--------+--------+ +------------ 232 where: 234 - NAF represents the non-address fields of an IPv6 header (I.e., the 235 first 8 octets of an IPv6 header) 237 - SRC is an IPv6 source address 239 - DEST is an IPv6 destination address 241 - EXT is zero or more IPv6 extension headers 243 - the prefix "o" means "outer" 245 In the HMIPv6 case, the MN attaches an outer header which contains 246 its LCoA as source address and the selected MAP's IP address as 247 destination address. The inner header contains the MN's RCoA as 248 source address and the CN's IP address as destination address. 249 Similarly, the MAP attaches an outer header to all data packets sent 250 by the CN to the MN's RCoA. The outer header is the same as the one 251 used by the MN but with the two addresses inverted. 253 The first step towards implementing the TO mechanism consists on 254 building the PaT at the MN's side. Since we limit the PaT 255 functionality in this document to the IP addresses only, the PaT will 256 consist on two different 128-bit translator parameters (TPs): 257 PaT = {TP_Source (TPS) , TP_Destination (TPD)} 259 In the BT mode, TPS and TPD are computed in the following way: 261 - TPS = oSrc_Addr XOR iSrc_Addr 263 Where: 264 - oSrc_Addr is the Outer header Source Address (CoA) 265 - iSrc_Addr is the Inner header Source Address (HoA) 267 - TPD = oDst_Addr XOR iDst_Addr 269 Where: 270 - oDst_Addr is the Outer header Destination Address (HA's IP address) 271 - iDst_Addr is the Inner header Destination Address (CN's IP address) 273 In HMIPv6 protocol, the PaT is computed in the same way as in the BT 274 mode but with using the appropriate IP addresses defined in HMIPv6: 276 - CoA = LCoA 277 - HoA = RCoA 278 - HA's IP address = MAP's IP address 280 The next step after building the PaT is to securely share it with the 281 HA or the MAP (i.e., HMIPv6 case). This is done by inserting the PaT 282 components in two new options (called PaT Source (PaTS) and PaT 283 Destination (PaTD)) carried by the BU message. The two options MUST 284 be sent encrypted. 285 Another way to share the PaT would consist on using the BU message 286 (e.g., by setting a new bit) to request the HA to build the PaT. In 287 such case, the MN has to send the CN's IP address(es) in the BU 288 message. For privacy purpose, the CN's address SHOULD be sent 289 encrypted. 291 It follows from the above description, that each time the MN 292 configures a new CoA, it has to build a new PaT and send it in a BU/ 293 LBU (i.e., with the new CoA/LCoA) to the HA/MAP. 295 If the MN is communicating with multiple CNs, then it SHOULD 296 configure one CoA per CN and build the corresponding PaT before 297 sending it to the HA. Such step is required in order to avoid any 298 confusion over which PaT to apply at the HA side on data packets sent 299 by the MN. The same requirement arises in the HMIPv6 case which 300 means that the MN has to configure one LCoA per CN, build the 301 corresponding PaT then send it to the MAP. 302 Consequently, the HA/MAP SHOULD create one entry in its BCE for each 303 MN's CoA/LCoA and SHOULD add the corresponding CN's IP address 304 together with the corresponding PaT. 306 Upon receiving a BU message carrying a PaT, the HA creates first a 307 binding between the two MN's addresses and stores them together with 308 the PaT in its binding cache entries (BCE) table. Then, the HA sends 309 back a BA message to the MN. 310 It follows that, when the MN has multiple CoAs, then the HA SHOULD 311 create one entry in its BCE for each MN's CoA and SHOULD add the 312 corresponding CN's IP address to the MN's addresses and the 313 corresponding PaT. 314 Similarly, in an HMIPv6 domain, the MN sends the PaT encrypted in the 315 LBU message to its MAP and waits for the BA message before applying 316 the PaT on data packets. 318 After creating the binding and sharing the PaT with the HA/MAP, the 319 MN applies it on each data packet sent to the CN (i.e., via the HA/ 320 MAP) and on each data packet received from the HA/MAP. The HA/MAP 321 applies the PaT on each data packet received from the MN before 322 sending it to the CN and on each data packet sent by the CN to the 323 MN's HoA/RCoA before sending it to the MN. 325 When the MN needs to send a data packet to the CN, it applies the PaT 326 on the IP header in the following way (Eq. 1): 328 - Src_Addr = iSrc_Addr XOR TPS 329 - Dst_Addr = iDst_Addr XOR TPD 330 Where Src_Addr is the source address disclosed in the IP header and 331 Dst_Addr is the destination address used in the IP header. It 332 becomes obvious at this stage that the Src_Addr is the MN's CoA (or 333 LCoA in HMIPv6) and the Dst_Addr is the HA's IP address (or MAP's IP 334 address in HMIPv6). 336 When the HA/MAP receives a data packet from the MN, it retrieves the 337 corresponding PaT on the IP header and translates the IP addresses to 338 new ones. Since the PaT used by the HA is the same as the one used 339 by the MN and the required operation is only a XOR, then the 340 resulting IP addresses are the ones used as iSrc_Addr and iDst_Addr 341 in (Eq. 1). This means: 343 - nSrc_Addr = Src_Addr XOR TPS (= iSrc_Addr) 344 - nDst_Addr = Dst_Addr XOR TPD (= iDst_Addr) 346 Where the nSrc_Addr is the new IP source address and nDst_Addr is the 347 new IP destination address used in the data packet sent by the HA to 348 the CN. 350 Similarly, when the CN sends a data packet to the MN's HoA, the HA/ 351 MAP applies the MN's corresponding PaT to the IP packet header and 352 translates the two IP addresses to new ones before sending the data 353 packet to the MN. 355 Finally, when the MN gets a data packet from its HA/MAP, it checks 356 first if the data packet is encapsulated or not. In the latter case, 357 the MN applies the PaT to the IP packet header. Otherwise, the MN 358 follows the BT mode to process the packet. 359 Note that in the current design, the HA SHOULD always tunnel any new 360 data packet sent by a new CN according to the BT mode rules and 361 SHOULD NOT apply any PaT until it receives one from the MN. However, 362 further optimizations are possible and will be introduced in future 363 version of this document. 365 5. Tunneling Optimization for RO mode 367 As mentioned earlier, MIPv6 RO mode uses a different form of IP 368 tunnel between the two endpoints (i.e., MN and CN) than the one used 369 in the BT mode (i.e., between the MN and its HA). The modified IP 370 tunnel discloses three IP addresses to the receiver and is used by 371 both sides when exchanging data packets. Consequently, the TO 372 mechanism requires a slight modification in order to adapt it to the 373 degenerated tunnel used in the RO mode. 375 For this purpose, when the RO mode is used, the PaT components SHOULD 376 be computed by both endpoints in the following way: 378 - TPS = CoA XOR HoA 379 - TPD = 0000:0000:0000:0000:0000:0000:0000:0000 381 Where the CoA and HoA are the MN's IP addresses. Note that when the 382 RO mode is used, the MN does not need to send the PaT in the BU 383 message since the CN can build it. However, the MN SHOULD send an 384 explicit request to the CN to check if both endpoints can use the PaT 385 when exchanging data packets. For this purpose, the request consists 386 on setting a new bit in the BU message sent by the MN to the CN and 387 getting an explicit acknowledgment to the request from the CN in the 388 BA message. If the CN is able to use the PaT, then it SHOULD set a 389 new bit in the BA message. Otherwise, it can only send the BA 390 message without any further action. 392 It follows from the above, that each time the MN needs to send a data 393 packet to the CN following the RO mode rules, it SHOULD apply the PaT 394 to the IP packet header in order to translate it to the right IP 395 address, i.e., the MN's CoA. The same rule applies when receiving a 396 data packet from the CN (i.e., sent to the MN's CoA). On the CN 397 side, the PaT is applied each time a data packet needs to be sent to 398 the MN or each time a data packet is received from the MN. 400 It should be noted that when the RO mode is in use, the PaT can be 401 applied only as long as the MN's CoA binding lifetime has not 402 expired. In addition, the MN SHOULD set the PaT bit in each BU 403 message sent to the CN as long as it prefers to use the TO mechanism 404 during the ongoing session. This also means that a new PaT needs to 405 be built after each BU message carrying a new CoA. 407 6. Tunneling Optimization for DSMIPv6 409 TBD 411 7. Bit and Options Formats 413 TBD 415 8. Security Considerations 417 This memo describes a TO mechanism which is mainly used to avoid 418 explicit IP tunneling in mobility protocols. 420 The proposed mechanism enhances the MN's privacy by removing the need 421 to disclose the MN's two IP addresses in the same data packet. 422 Consequently, it simplifies and narrows the privacy problem in a 423 mobile environment. 425 In the current memo, the PaT is only applied on the IPv6 addresses 426 and as such it does not create nor amplify any new or existing 427 threats. 429 9. Acknowledgments 431 The authors would like to thank Laurent Marchand, Conny Larsson, 432 Shinta Sugimoto, Suresh Krishnan, Hesham Soliman and George Tsirtsis 433 for their valuable comments. 435 10. References 437 10.1. Normative References 439 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 440 for IPv6", RFC 3775, June 2004. 442 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 443 Requirement Levels", RFC 2119, BCP , March 1997. 445 10.2. Informative References 447 [EALDC] Barr, K. and K. Asanovic, "Energy-Aware Lossless Data 448 Compression", ACM Transactions Computer Systems, 449 August 2006. 451 [FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 5268, 452 March 2007. 454 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 455 "Hierarchical Mobile IPv6", RFC 5380, October 2008. 457 [PMIPv6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 458 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 460 [TUN] Deering, S. and B. Zill, "Redundant Address Deletion when 461 Encapsulating IPv6 in IPv6", Internet 462 Draft, draft-deering-ipv6-encap-addr-deletion-00.txt, 463 November 2001. 465 Authors' Addresses 467 Wassim Haddad 468 USA 470 Phone: +1 646 2568041 471 Email: wmhaddad@gmail.com 473 Mats Naslund 474 Ericsson Research 475 Torshamnsgatan 23 476 SE-164 80 Stockholm 477 Sweden 479 Phone: +46 8 58533739 480 Email: Mats.Naslund@ericsson.com 482 Pekka Nikander 483 Ericsson Research Nomadic Lab 484 Jorvas FI-02420 485 Finland 487 Phone: +358 9 299 1 488 Email: Pekka.Nikander@nomadiclab.com