idnits 2.17.1 draft-patil-mext-mip6issueswithipsec-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 26, 2009) is 5296 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 (Obsoleted by RFC 6275) == Outdated reference: A later version (-01) exists of draft-ebalard-mext-pfkey-enhanced-migrate-00 == Outdated reference: A later version (-06) exists of draft-korhonen-mext-mip6-altsec-02 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions (MEXT) B. Patil 3 Internet-Draft Nokia 4 Intended status: Standards Track D. Premec 5 Expires: April 29, 2010 Unaffiliated 6 C. Perkins 7 WiChorus 8 H. Tschofenig 9 Nokia Siemens Networks 10 October 26, 2009 12 Problems with the use of IPsec as the security protocol for Mobile IPv6 13 draft-patil-mext-mip6issueswithipsec-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 29, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the 52 signaling messages and user plane traffic between the mobile node and 53 home agent. An IPsec SA between the mobile node and the home agent 54 provides security for the mobility signaling. Use of IPsec for 55 securing the data traffic between the mobile node and home agent is 56 optional. This document analyses the implications of the design 57 decision to mandate IPsec as the default security protocol for Mobile 58 IPv6 and consequently Dual-stack Mobile IPv6 and recommends 59 revisiting this decision in view of the experience gained from 60 implementation and adoption in other standards bodies. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 66 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 5. General issues with the use of IPsec for MIP6 security . . . . 6 69 6. Implementation Issues with IPsec . . . . . . . . . . . . . . . 8 70 6.1. Triggering IKEv2 on the MN . . . . . . . . . . . . . . . . 8 71 6.2. Instructing IKEv2 to ask for the MN HoA/prefix . . . . . . 9 72 6.3. Providing the MN prefix to the IKEv2 daemon . . . . . . . 9 73 6.4. Registering the MN's FQDN in DNS . . . . . . . . . . . . . 9 74 6.5. Providing the Home Network Prefix to the MIP6 75 application . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.6. SPD Entry for the HoA on the MN side . . . . . . . . . . . 10 77 6.7. SPD Entry for the HoA on the HA side . . . . . . . . . . . 10 78 6.8. The K bit . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.9. UDP encapsulation of DSMIP6 signaling . . . . . . . . . . 11 80 6.10. Transport mode IPsec SAs and NATs . . . . . . . . . . . . 12 81 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec 93 security association between the mobile node (MN) and home agent 94 (HA). The IPsec SA protects the mobility signaling messages between 95 the MN and HA. The user data may be optionally protected by the 96 IPsec SA but is not required. The use of IPsec by most hosts today 97 is primarily as a solution for enterprise connectivity through VPN 98 applications. IPsec has not evolved into a generic security 99 protocol. 101 The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified 102 in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 103 working groups in the IETF chose to mandate IPsec as the default 104 security protocol for Mobile IPv6 based on various criteria and 105 lengthy discussions that occured between the years 2000 and 2004. 106 Implementation experience with Mobile IPv6 and the security variants 107 with which it has been specified in some SDOs indicates a need to 108 revisit the design choice for MIP6 signaling security. The analysis 109 and recommendation to revisit the security protocol architecture for 110 MIP6 should not be interpreted as a recommendation for Authentication 111 Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight 112 the misfit of IPsec and IKEv2 as the security protocol for MIP6 and 113 hence the need for considering alternatives. A simpler security 114 architecture for securing the signaling and traffic between the MN 115 and HA can co-exist with the IPsec based solution as well. 117 2. Terminology and Abbreviations 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 This document refers to [RFC3775][RFC4877] for terminology. 125 3. Background 127 IP mobility support in IPv6 was considered to be an integral feature 128 of the IPv6 stack based on the experience gained from developing 129 mobility support for IPv4. The design of Mobile IPv6 was worked on 130 by the Mobile IP WG in the late 90s and by the MIP6 WG until its 131 publication as [RFC3775] in 2004. 133 IPsec [RFC4301] was also intended to be a default component of the 134 IPv6 stack and was the preferred protocol choice for use by any other 135 IPv6 protocol that needed security. Rather than design security into 136 every protocol feature, the intent was to reuse a well-defined 137 security protocol to meet the security needs. Hence Mobile IPv6 has 138 been designed with a security architecture that relies on reusing 139 IPsec. 141 The Mobile IPv6 specification [RFC3775] was published along with the 142 companion specification "Using IPsec to Protect Mobile IPv6 Signaling 143 Between Mobile Nodes and Home Agents", [RFC3776]. The establishment 144 of the IPsec SA between the MN and HA as per RFC 3776 is based on the 145 use of IKE. The use of IKE in the context of Mobile IPv6 for IPsec 146 SA establishment did not gain traction because of factors such as 147 complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG 148 completed the specification, Mobile IPv6 Operation with IKEv2 and the 149 Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] 150 is considered as the default security protocol solution for MIP6 and 151 updates [RFC3776]. 153 4. Problem Statement 155 Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an 156 implementation and deployment perspective. As a protocol solution 157 for host based mobility, MIP6 can be simpler without the IPsec 158 baggage. The issues with IPsec are even more exacerbated in the case 159 of dual-stack MIP6 [RFC5555]. 161 IPsec SAs between the MN and HA are established either manually or 162 via the use of IKEv2 [RFC4306]. Manual SA configuration is not a 163 scalable solution and hence MIP6 hosts and Home agents rely on IKEv2 164 for establishing dynamically IPsec SAs. As a result MIP6 depends on 165 the existence of IPsec and IKEv2 for successful operation. 167 IPsec is unable to provide security protection for MIP6 in a 168 transparent way, and numerous interactions between the host's 169 security subsystems and the MIP6 application are needed in the course 170 of the regular operation of the MIP6 application. Besides requiring 171 an extensive communications channel between the security subsystems 172 and the MIP6 application, those interactions often also require 173 modification of the MNs security subsystems code. The situation 174 today is such that the communications channel between the IPsec 175 subsystems and the MIP6 application is non existent and this is 176 generally true for most of the commercially available platforms. 177 Even if such a channel were to be available, there does not exist a 178 standardized protocol over that channel which would enable the MIP6 179 application to communicate with the security modules in a non- 180 implementation specific way. 182 Considering a third party application developer who would like to 183 provide a MIP6 application for a particular platform, the need for 184 numerous interactions with the IPsec subsystem and the unavailability 185 of the standardized communications channel through which such 186 interactions could take place is a major obstacle to the 187 implementation of the mobility protocol. Without such a 188 communication channel being available it is not possible to implement 189 a MIP6 application as a third party developer. 191 Even if the platform would provide such a communication interface for 192 the MIP6 daemon, this is still insufficient as the MIP6 protocol 193 standardized today [RFC3775] requires numerous changes to the host's 194 IPsec and IKEv2 implementation. This document enumerates various 195 implementation issues related to the interactions between the MIP6 196 application and the host's security subsystems. 198 An argument can be made that the MIP6 application itself should 199 provide the required changes to the IPsec subsystems of the platform 200 (maybe in the form of patches). While this is possible at least for 201 some open source platforms to provide modifications to the host's 202 IPsec implementation as well as the key management application(s), 203 this is still an issue for several reasons: 205 o Target platform could be a commercial platform for which no source 206 code for the security modules (IPsec and IKEv2) is available. 207 o If the MIP6 application were to patch the IPsec subsystems, then 208 multiple MIP6 applications from different developers would 209 implement it in different ways, which would inevitably lead to 210 variations and problems with interoperability at a minimum, for 211 instance when the user tries to install several MIP6 applications 212 it is difficult to determine which one is the best suited for his/ 213 her needs. 214 o Key management daemons are usually provided as third party 215 software for which no source code may be available, even if the 216 platform itself is available as open source. 217 o Even if the MIP6 application developer would be willing to provide 218 patches for the key management daemon to make it work with his 219 MIP6 application, how would the MIP6 application developer know 220 which of the several available key management daemons the user is 221 running? 222 o Each application would be able to work only with a single key 223 management daemon, namely the one for which the MIP6 application 224 provides the patches. The user may be running another key 225 management daemon and may be unwilling to change its daemon to the 226 one that comes as part of the MIP6 application. 227 o Patches for the IPsec part in the kernel and the key management 228 daemon would typically be valid only for the particular version of 229 the kernel and the key management daemon for which they were 230 written. This might prevent the user from upgrading the platform 231 or applying OS security patches that are provided as part of the 232 regular platform maintenance since this would in all probability 233 make the MIP6 application defunct. 234 o Modifying the security subsystems by a third party is a security 235 issue and users are generally advised to refrain from allowing the 236 security subsystems to be modified in any way. 237 o The developer may not have the knowledge or the time to modify the 238 platform's IKEv2 and IPsec subsystems, although it might be 239 perfectly capable to deliver the MIP6 application itself. 240 o There could be copyright issues as well that would prevent 241 modifications of the platform's security subsystems or the 242 delivery of the modifications by the third party. 243 o Even if the MIP6 application developer is able to come up with the 244 necessary patches for the security subsystem, it is not realistic 245 to expect the prospective user of MIPv6 to first patch the kernel 246 and the key management daemons before using the MIPv6 service. 248 The above discussion shows why it is unrealistic to expect that the 249 MIP6 application could provide the needed modifications to the IKEv2 250 and IPsec subsystems of the host. Section 6 presents a more 251 technical discussion of various implementation issues related to the 252 interworking between the MIP6 application and the IPsec/key 253 management modules. 255 The problem in a nutshell for MIP6 is the dependence on IPsec and 256 IKEv2 for successful operation. 258 5. General issues with the use of IPsec for MIP6 security 260 This section captures several issues with the use of IPsec by MIP6. 262 (1) The design of Mobile IPv6 emphasized the reuse of IPv6 features 263 such as IPsec. IPsec for IPv4 was a bolt-on solution. With the 264 increasing need for security, IPv6 designers chose to 265 incorporate IPsec as a default feature. There existed an 266 assumption in the MIP6 working group that every IPv6 host would 267 have IPsec capability as a standard feature. While this is true 268 in many host implementations today, the existence of IPsec in 269 every IPv6 stack is not a given. Hence a host which needs to 270 implement Mobile IPv6 must ensure that IPsec and IKEv2 are also 271 available. As a result of this dependence, MIP6 is no longer a 272 standalone host-based mobility protocol. A good example of a 273 host based mobility protocol that works as a self-sufficient 274 module is Mobile IPv4 [RFC3344]. The security associated with 275 MIP4 signaling is integrated into the protocol itself. MIP4 has 276 been successfully deployed on a large scale in several networks. 278 (2) IPsec use in most hosts is generally for the purpose of VPN 279 connectivity to enterprises. It has not evolved into a generic 280 security protocol that can be used by Mobile IPv6 easily. While 281 RFC4877 does specify the details which enable only the MIP6 282 signaling to be encapsulated with IPsec, the general method of 283 IPsec usage has been such that all traffic between a host and 284 the IPsec gateway is carried via the tunnel. Selective 285 application of IPsec to protocols is not the norm. Use of IPsec 286 with Mobile IPv6 requires configuration which in many cases is 287 not easily achievable because of reasons such as enterprise 288 environments preventing changes to IPsec policies. 289 (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one 290 relationship. A MIP6 HA may support a very large number of 291 mobile nodes which could be in the hundreds of thousands to 292 millions. The ability to terminate a large number of IPsec SAs 293 (millions) requires signifiant hardware and platform capability. 294 The cost issues of such an HA are detrimental and hence act as a 295 barrier to deployment. 296 (4) The implementation complexity of Mobile IPv6 is greatly 297 increased because of the interaction with IKEv2. The complexity 298 of the protocol implementation is even more so in the case of 299 Dual stack MIP6 [RFC5555] wherein NAT traversal scenarios are 300 considered. 301 (5) IPsec and IKEv2 are not implemented or available by default in 302 every IPv6 or dual stack host. Mobile IPv6 support on such 303 devices is not an option. Many low-end cellular hosts have IP 304 stacks. The need for IPsec and IKEv2 in these devices is not 305 important whereas mobility support is needed in many cases. A 306 simpler security protocol than the use of IPsec/IKEv2 would make 307 MIP6 much more attractive to implement and deploy. 308 (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile 309 IPv6 essentially results in a variant of IPsec which is specific 310 to Mobile IP. Hence this results in added complexity to 311 implementations. 312 (7) Mobile IPv6 needs to be capable of being deployed in situations 313 where alternative security mechanisms are already well- 314 understood by the network administration. It should be possible 315 to enable Mobile IPv6 to work in situations where alternative 316 security mechanisms already supply the necessary authentication 317 and privacy. 318 (8) IPsec has been successfully applied to VPN and other 319 infrastructure operations, but not for general end-to-end 320 applications. Thus, the granularity for selectors was 321 originally not at all sufficient for Mobile IPv6. 323 (9) The way that the IPsec code sits in the usual kernel, and the 324 access mechanisms for the SA database, are not very convenient 325 for use by straightforward implementations of Mobile IPv6. 326 Unusual calling sequences and parameter passing seems to be 327 required on many platforms. 328 (10) In certain environments the use of IPsec and IKEv2 for 329 establishing the SA is considered as an overhead. Bandwidth 330 constrained links such as cellular networks and air interfaces 331 which are in the licensed spectrum tend to be optimized for user 332 traffic. MIP6 signaling with the IPsec overhead and the IKEv2 333 messages are viewed negatively. It is more acceptable to have 334 signaling without IPsec encapsulation. 336 The issues listed above can be speculatively attributed as some of 337 the causes for MIP6 not being implemented widely. 339 6. Implementation Issues with IPsec 341 6.1. Triggering IKEv2 on the MN 343 When the MIP6 application is invoked on the MN, as part of the 344 initialization steps it is expected to install the appropriate SPD 345 entries for protecting the mobility management signaling. Creation 346 of the SPD entry works fine assuming that the MN is statically 347 preconfigured with the HoA information since the HoA address is 348 needed to create the SPD entries. Once the SPD entries are created, 349 the MIP6 application generates the BU message and sends it via the 350 socket. Based on the previously installed SPD entry the IP stack 351 detects that the BU message needs IPsec protection and since there is 352 no appropriate IPsec SA available, the OS kernel triggers the key 353 management daemon to establish the needed IPsec SA. 355 Things are not that straightforward when the HoA is assigned 356 dynamically. MIP6 allows the MN to obtain the HoA dynamically during 357 the establishment of the initial IPsec SA with the HA [RFC4877] and 358 in this case the HoA is provided in the CONF IKEv2 payload. How is 359 the key management daemon triggered to establish the IPsec SA with 360 the HA in this case? Normally there should be an SPD entry in the 361 SPD with the HoA address as part of the selector and the outgoing BU 362 message would be matched against that entry and this would trigger 363 the kernel to request the establishment of the IPsec SA. But the 364 MIP6 application is not able to install the appropriate SPD entry nor 365 to generate the BU message since it doesn't have yet the HoA that is 366 needed for this, the HoA becomes available only later as part of the 367 IPsec SA establishment. So this is sort of a chicken and egg 368 problem: the HoA is needed to trigger the establishment of the IPsec 369 SAs, but the HoA is not available prior to the IPsec SA being 370 established. 372 The solution to this issue could be an out-of-band communication 373 channel between the MIP6 application and the key management daemon 374 through which the MIP6 application could request the establishment of 375 the appropriate IPsec SA from the key management daemon without 376 having to install the appropriate SPD entries and generate the BU 377 message. 379 6.2. Instructing IKEv2 to ask for the MN HoA/prefix 381 In case of dynamic HoA assignment, the MIP6 application needs to 382 instruct the key management daemon to request the HoA information 383 from the HA. The MIP6 application must be able to tell whether it 384 would like to get the complete address or only the prefix [RFC5026] 385 from the HA, and also whether it would like to get the IPv4 HoA as 386 part of the IKEv2 exchange. This requires an interface between the 387 MIP6 application and the key management daemon. 389 6.3. Providing the MN prefix to the IKEv2 daemon 391 When the key management daemon on the HA side receives a request from 392 the initiator to allocate the MIP6_HOME_PREFIX it needs to get the 393 prefix from the MIP6 daemon running on the HA. Therefore there must 394 be a communication channel between the key management daemon and the 395 MIP6 application through which the key management daemon could 396 request the HoA/prefix information. Further, when assigning the 397 prefix, the MIP6 application needs to create state and save the 398 assigned address information and associate it with the MN which 399 created the IPsec SA. So this looks like at this point there is a 400 need to create the BCE in a some type of a "larval" state as a place 401 where to save this information on the HA side. 403 Request to assign an address (IPv6 and/or IPv4) via the CONF payload 404 raises an additional concern, namely, how does the key management 405 daemon know that it needs to obtain the address from the MIP6 406 application? A generic key management daemon would by default have 407 some other means to provide the addresses in the CONF payload without 408 consulting the MIP6 application, so there must be some method to tell 409 the key management daemon that it should request the addresses from 410 the MIP6 application. The author is not aware of any such method 411 being available currently. 413 6.4. Registering the MN's FQDN in DNS 415 [RFC4877] allows the HA to register the MN's FQDN in the DNS. In 416 this case the MN must provide the FQDN in the IDi payload in the 417 IKE_AUTH step of the IKEv2 exchange. Consequently, there must be 418 some interface between the key management daemon and the MIP6 419 application on the HA side through which the FQDN could be made 420 available to the MIP6 application so that it can register the FQDN in 421 DNS. 423 6.5. Providing the Home Network Prefix to the MIP6 application 425 When the key management daemon on the MN side obtains the home 426 network prefix information from the HA, it needs to relay this 427 information to the MIP6 application. This again requires a 428 communication channel between the key management daemon and the MIP6 429 application. 431 6.6. SPD Entry for the HoA on the MN side 433 Once the MIP6 application on the MN obtains the HoA (either assigned 434 via the CONF IKEv2 payload [RFC4877] or autoconfigured from the 435 MIP6_HOME_PREFIX [RFC5026]), the appropriate SPD entries need to be 436 created in the SPD. Some key management daemons may require that 437 they have full control of the SPD. In such cases the MIP6 438 application should not create the SPD entries by itself as this might 439 confuse the MIP6 daemon and cause inconsistent state. Instead, the 440 MIP6 application would need to instruct the key management daemon to 441 create the appropriate SPD entries. So depending on the expectations 442 of the key management daemon, the MIP6 application should either 443 instruct the key management daemon to create the SPD entries or the 444 MIP6 application should create them by itself at this point. 446 If the policy requires protection of the data traffic the SPD entries 447 for the data traffic would also need to be created at this point. 449 6.7. SPD Entry for the HoA on the HA side 451 The creation of the SPD entry on the HA side for protecting the MN's 452 mobility signaling is similar to what is happening on the MN side and 453 is described in the previous section. As soon as the HA assigns an 454 HoA it may proceed with the creation of the appropriate SPD entry. 455 The SPD entries for protecting the data traffic should also be 456 created at this time. 458 However, the issue gets more complicated in the case where the HA 459 provides the prefix to the MN and the MN autoconfigures the HoA. In 460 this case neither the key management daemon nor the MIP6 application 461 on the HA are aware of the MN's autoconfigured HoA so neither of them 462 is in a position to install an appropriate SPD entry during (or 463 immediately after) the IKEv2 exchange. Even worse, since the 464 autoconfigured MN address is not known on the HA side it is not clear 465 what is the contents of the TSi and TSr payloads in the final 466 IKE_AUTH message sent by the HA. It is unclear whether or not the SA 467 for protecting the MN's mobility signaling gets established at all in 468 such a situation. 470 6.8. The K bit 472 The K bit [RFC3775] requires an interface between the IPsec subsystem 473 and the MIP6 application that is not available today, at least not in 474 a standardized form. Such an interface that would enable the support 475 for the K bit has been proposed before and additional information how 476 it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate] 477 and [I-D.ebalard-mext-pfkey-enhanced-migrate]. However, those 478 proposals were not standardized and as such there is no publicly 479 available interface specification that could be used by the third 480 party MIP6 application developers to invoke the key management daemon 481 and IPsec kernel. Note also that the MIP6 application must have a 482 detailed knowledge about the established IPsec SAs (complete SPD 483 entries, old and new tunnel end points) in order to be able to 484 indicate to the key management daemon which SAs needs to be updated, 485 which is not in the spirit of the original IPsec intention to provide 486 security to the applications in a transparent manner. 488 6.9. UDP encapsulation of DSMIP6 signaling 490 The DSMIP6 specification enables the MIP6 enabled MN to roam in IPv4 491 networks [RFC5555]. To cope with NATs the DSMIP6 specification 492 introduces a UDP encapsulation feature for the MIP6 signaling 493 messages as well as for the data traffic. The UDP encapsulation 494 feature requires very tight coupling between the IPsec subsystems and 495 the MIP6 application. 497 To send the BU message the MIP6 daemon first needs to generate the BU 498 message and then hand it over to the IPsec subsystem which adds the 499 transport mode ESP protection. Then in the next step the message 500 must go back from the kernel to the MIP6 daemon in the user space 501 which adds DSMIP6 UDP encapsulation and then the packet is finally 502 sent out on the interface. 504 When the UDP encapsulated Binding Acknowledgment message is received 505 on the MN side, it is first delivered to the MIP6 application which 506 strips the UDP header and then somehow hands over the stripped 507 message to the kernel's IPsec subsystem. The IPsec subsystems takes 508 care of the transport mode ESP protecting the BU message and after 509 removing the ESP header delivers the BU message back to the MIP6 510 application. 512 6.10. Transport mode IPsec SAs and NATs 514 In order to establish an IPsec SA in the case of DSMIP6 when the MN 515 is behind a NAT, it is required to use transport mode SAs only. 516 Implementation experience at least has shown that it is not easily 517 done and the operation itself of establishing the IPsec SA is flaky 518 at best. 520 7. Conclusion 522 Examples in Section 6 show that there is a need for an extensive 523 communication between the MIP6 application and the IPsec subsystem on 524 the host. Standardizing such communication channel and having it 525 available in a commercial OS implementations is not a realistic 526 proposal in any practical time frame. On the technical side, this is 527 due to the fact that the IPsec is usually provided as part of the OS 528 kernel and it is always difficult to convince the OS vendor to change 529 the kernel and in particular the security related subsystems. The 530 other difficulty is that the key management is usually provided as 531 the user space service and as such there are multiple key management 532 daemons available. Convincing vendors of various key management 533 daemons to provide a unified or standardized communication channel 534 for the MIP6 application might prove equally difficult and is not a 535 realistic option either. Besides the technical reasons, there are 536 also other non-technical reasons of business or political nature why 537 such proposals would be unrealistic. 539 Therefore this draft recommends that an alternate security framework 540 be considered for MIP6. This alternate mechanism should be self 541 contained so that it can be developed and delivered as part of the 542 MIP6 application itself (from an implementation perspective analogous 543 to the way web browsers handle security today). This would enable 544 third party developers that have no access or are otherwise not in a 545 position to change the IPsec code of the platform they are developing 546 for to come up with a self contained and working MIP6 application. 547 Such alternative security mechanisms would remove one of the major 548 impediments, i.e the interactions with IPsec - why it is so difficult 549 today to implement a working MIP6 application. This would foster the 550 diversity of the MIP6 solutions and should therefore have beneficial 551 effects on the availability of MIP6 solutions and promote the 552 adoption of MIP6 in general. 554 In order to make the Mobile IPv6 protocol a solution that is easy to 555 implement and available in even low-end devices, it is necessary to 556 simplify the protocol. The design or the security architecture for 557 MIP6 needs to be revisited and a solution that simplifies the 558 implementability of the protocol considered. The implementation 559 experience shows that a working solution of Mobile IPv6 is possible 560 to build. However it is not easily done. 562 The authors recommend that while Mobile IPv6 and Dual-stack Mobile 563 IPv6 implementations can indeed use IPsec and IKEv2 for the security, 564 it should also be possible to rely on an alternative security 565 framework. One such alternative security solution is proposed in 566 'Security architecture for Mobile IPv6 using TLS' 567 [I-D.korhonen-mext-mip6-altsec]. 569 8. Security Considerations 571 This I-D discusses the security architecture of Mobile IPv6 which is 572 based on IPsec. The dependency on IPsec for security of MIP6 573 signaling is a detriment to the protocol implementation and 574 deployment. Hence the current security architecture needs to be 575 reconsidered. 577 The experience gained over the last few years indicates that IPsec 578 cannot necessarily be used as a generic solution for security. The 579 design choice made for MIP6 in the initial stages no longer are valid 580 and is hampering the implementation and use. 582 9. IANA Considerations 584 This document does not have any information which requires IANA 585 review. 587 10. Acknowledgements 589 Jouni Korhonen would like to point out the importance of sustained 590 supply of caffeine rich coffee when doing IETF work. Authors would 591 also like to recognize Satyabrata Sahu, NK Garg, Sandeep Minocha and 592 Harsh Verma for working on the implementation. 594 11. References 596 11.1. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 602 in IPv6", RFC 3775, June 2004. 604 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 605 Protect Mobile IPv6 Signaling Between Mobile Nodes and 606 Home Agents", RFC 3776, June 2004. 608 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 609 IKEv2 and the Revised IPsec Architecture", RFC 4877, 610 April 2007. 612 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 613 Bootstrapping in Split Scenario", RFC 5026, October 2007. 615 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 616 Routers", RFC 5555, June 2009. 618 11.2. Informative References 620 [I-D.ebalard-mext-pfkey-enhanced-migrate] 621 Ebalard, A. and S. Decugis, "PF_KEY Extension as an 622 Interface between Mobile IPv6 and IPsec/IKE", 623 draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in 624 progress), August 2008. 626 [I-D.korhonen-mext-mip6-altsec] 627 Korhonen, J., "Security architecture for Mobile IPv6 using 628 TLS", draft-korhonen-mext-mip6-altsec-02.txt (work in 629 progress), Ocober 2009. 631 [I-D.sugimoto-mip6-pfkey-migrate] 632 Sugimoto, S., Dupont, F., and M. Nakamura, "PF_KEY 633 Extension as an Interface between Mobile IPv6 and IPsec/ 634 IKE", draft-sugimoto-mip6-pfkey-migrate-04 (work in 635 progress), December 2007. 637 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 638 August 2002. 640 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 641 Chowdhury, "Authentication Protocol for Mobile IPv6", 642 RFC 4285, January 2006. 644 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 645 Internet Protocol", RFC 4301, December 2005. 647 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 648 RFC 4306, December 2005. 650 Authors' Addresses 652 Basavaraj Patil 653 Nokia 654 6021 Connection Drive 655 Irving, TX 75039 656 USA 658 Email: basavaraj.patil@nokia.com 660 Domagoj Premec 661 Unaffiliated 662 Heinzelova 70a 663 Zagreb, 10000 664 CROATIA 666 Phone: 667 Fax: 668 Email: domagoj.premec.ext@gmail.com 670 Charles Perkins 671 WiChorus 672 3590 N. 1st Street, Suite 300 673 San Jose, CA 95134 674 USA 676 Email: charliep@wichorus.com 678 Hannes Tschofenig 679 Nokia Siemens Networks 680 Linnoitustie 6 681 Espoo 02600 682 Finland 684 Phone: +358 (50) 4871445 685 Email: Hannes.Tschofenig@gmx.net 686 URI: http://www.tschofenig.priv.at