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