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