idnits 2.17.1 draft-patil-mext-mip6issueswithipsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 347. 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 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 27, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-05 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Patil 3 Internet-Draft Nokia 4 Intended status: Informational C. Perkins 5 Expires: April 30, 2009 WiChorus 6 H. Tschofenig 7 Nokia Siemens Networks 8 October 27, 2008 10 Issues related to the design choice of IPsec for Mobile IPv6 security 11 draft-patil-mext-mip6issueswithipsec-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 30, 2009. 38 Abstract 40 Mobile IPv6 as specified in RFC3775 relies on IPsec for security. An 41 IPsec SA between the mobile node and the home agent provides security 42 for the mobility signaling. Use of IPsec for securing the data 43 traffic between the mobile node and home agent is optional. This 44 document analyses the implications of the design decision to mandate 45 IPsec as the default security protocol for Mobile IPv6 and recommends 46 revisiting this decision in view of the experience gained from 47 implementation and adoption in other standards bodies. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Issues with the use of IPsec . . . . . . . . . . . . . . . . . 8 57 7. MIP6 evolution . . . . . . . . . . . . . . . . . . . . . . . . 10 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 62 10.2. Informative References . . . . . . . . . . . . . . . . . 13 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Intellectual Property and Copyright Statements . . . . . . . . . . 15 66 1. Requirements notation 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. Introduction 74 Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec 75 security association between the mobile node (MN) and home agent 76 (HA). The IPsec SA protects the mobility signaling messages between 77 the MN and HA. The user data may be optionally protected by the 78 IPsec SA but is not required. 80 The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified 81 in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 82 working groups in the IETF chose to mandate IPsec as the default 83 security protocol for Mobile IPv6 based on various criteria and 84 discussions between the years 2000 and 2004. Implementation 85 experience with Mobile IPv6 and the security variants with which it 86 has been specified in some SDOs indicates a need to revisit the 87 design choice for MIP6 signaling security. 89 This document discusses the issues and concerns with the use of IPsec 90 for MIP6 security and proposes revisiting the security design for 91 MIP6 protocol. 93 3. Terminology 95 This document refers to [RFC3775][RFC4877] for terminology. 97 4. Background 99 IP mobility support in IPv6 was considered to be an integral feature 100 of the IPv6 stack based on the experience gained from developing 101 mobility support for IPv4. The design of Mobile IPv6 was worked on 102 by the Mobile IP WG in the late 90s and by the MIP6 WG until its 103 publication as [RFC3775] in 2004. 105 IPsec was also intended to be a default component of the IPv6 stack 106 and was the preferred protocol choice for use by any other IPv6 107 protocols that needed security. Rather than design security into 108 every protocol feature the intent was to reuse a well-defined 109 security protocol to meet security needs. Hence Mobile IPv6 has been 110 designed with a direct dependency on IPsec. 112 The Mobile IPv6 specification [RFC3775] was published along with the 113 companion specification "Using IPsec to Protect Mobile IPv6 Signaling 114 Between Mobile Nodes and Home Agents", [RFC3776]. The establishment 115 of the IPsec SA between the MN and HA as per RFC 3776 is based on the 116 use of IKE. The use of IKE in the context of Mobile IPv6 for IPsec 117 SA establishment did not gain traction because of factors such as 118 complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG 119 completed the specification, Mobile IPv6 Operation with IKEv2 and the 120 Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] 121 is considered as the default security protocol solution for MIP6 and 122 updates [RFC3776]. 124 5. Problem Statement 126 Mobile IPv6 is encumbered by its reliance on IPsec from an 127 implementation and deployment perspective. As a protocol solution 128 for host based mobility, MIP6 can be simpler without the IPsec 129 baggage. The issues with IPsec are even more exacerbated in the case 130 of dual-stack MIP6 [DSMIP6]. 132 IPsec SAs between the MN and HA are established either manually or by 133 the use of IKEv2. Manual SA configuration is not a scalable solution 134 and hence MIP6 hosts and Home agents rely on IKEv2 for establishing 135 dynamically IPsec SAs. As a result MIP6 depends on the existence of 136 IPsec and IKEv2 for successful operation. 138 The problem in summary for MIP6 is the dependence on IPsec and IKEv2 139 for operation. 141 6. Issues with the use of IPsec 143 This section captures several issues with the use of IPsec by MIP6. 145 (1) The design of Mobile IPv6 emphasized on the reuse of IPv6 146 features such as IPsec. IPsec for IPv4 was a bolt-on solution. 147 With the increasing need for security, IPv6 designers chose to 148 incorporate IPsec as a default feature. There existed an 149 assumption in the MIP6 working group that every IPv6 host would 150 have IPsec capability as a standard feature. While this is true 151 in many host implementations today, the existence of IPsec in 152 every IPv6 stack is not a given. Hence a host which needs to 153 implement Mobile IPv6 must ensure that IPsec and IKEv2 are also 154 available. As a result of this dependence, MIP6 is no longer a 155 standalone host-based mobility protocol. A good example of a 156 host based mobility protocol that works as a self-sufficient 157 module is Mobile IPv4. The security associated with MIP4 158 signaling is integrated into the protocol itself. MIP4 has been 159 successfully deployed on large scale in several networks. 161 (2) IPsec use in most hosts is generally for the purpose of VPN 162 connectivity to enterprises. It has not evolved into a generic 163 security protocol that can be used by Mobile IPv6 easily. While 164 RFC4877 does specify the details which enable only the MIP6 165 signaling to be encapsulated with IPsec, the general method of 166 IPsec usage has been such that all traffic between a host and 167 the IPsec gateway is carried via the tunnel. Selective 168 application of IPsec to protocols is not the norm. Use of IPsec 169 with Mobile IPv6 requires configuration which in many cases is 170 not easily done because of reasons such as enterprise 171 environments preventing changing to IPsec policies or other. 173 (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one 174 relationship. A MIP6 HA may support a very large of mobile 175 nodes which could number in the hundreds of thousands to 176 millions. The ability to terminate a large number of IPsec SAs 177 (millions) requires signifiant hardware and platform capability. 178 The cost issues of such an HA are detrimental and hence act as a 179 barrier to deployment. 181 (4) The implementation complexity of Mobile IPv6 is greatly 182 increased because of the interaction with IPsec and IKEv2. A 183 standalone MIP6 protocol is easier to implement and deploy (such 184 as MIP4 [RFC3344]). The complexity of the protocol 185 implementation is even more so in the case of [DSMIP6]. 187 (5) IPsec and IKEv2 is not implemented in every IPv6 or dual stack 188 host. Mobile IPv6 support on such devices is not an option. 189 Many low-end cellular hosts have IP stacks. The need for IPsec 190 and IKEv2 in these devices is not important whereas mobility 191 support is needed in many cases. MIP6 without any dependencies 192 on protocols for security is easier to implement and has wider 193 applicability. 195 (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile 196 IPv6 essentially results in a variant of IPsec which is specific 197 to Mobile IP. Hence this results in added complexity to 198 implementations. 200 (7) Mobile IPv6 needs to be capable of being deployed in situations 201 where alternative security mechanisms are already well- 202 understood by the network administration. It should be possible 203 to enable Mobile IPv6 to work in situations where alternative 204 security mechanisms already supply the necessary authentication 205 and privacy. 207 (8) IPsec has been successfully applied to VPN and other 208 infrastructure operations, but less so for general end-to-end 209 applications. Thus, the granularity for selectors was 210 originally not at all sufficient for Mobile IPv6. 212 (9) The way that the IPsec code sits in the usual kernel, and the 213 access mechanisms for the SA database, are not very convenient 214 for use by straightforward implementations of Mobile IPv6. 215 Unusual calling sequences and parameter passing seems to be 216 required on many platforms. 218 (10) In certain environments the use of IPsec and IKEv2 for 219 establishing the SA is considered as an overhead. Bandwidth 220 constrained links such as cellular networks and air interfaces 221 which are in the licensed spectrum tend to be optimized for user 222 traffic. MIP6 signaling with the IPsec overhead and the IKEv2 223 messages are viewed negatively. It is more acceptable to have 224 signaling without IPsec encapsulation. 226 The issues listed above have been a cause for MIP6 not being 227 implemented widely or adopted by other SDOs which are considering IP 228 mobility solutions. 230 7. MIP6 evolution 232 In order to make the Mobile Ipv6 protocol a solution that is easy to 233 implement and available in even low-end devices, it is necessary to 234 simplify the protocol. The design or the security architecture for 235 MIP6 needs to be revisited and a solution that does not rely on other 236 components developed. 238 8. Security Considerations 240 This I-D discusses the security architecture of Mobile IPv6 which is 241 based on IPsec. The dependency on IPsec for security of MIP6 242 signaling is a detriment to the protocol implementation and 243 deployment. Hence the security architecture needs to be revisited. 245 The experience gained over the last few years indicates that IPsec 246 cannot necessarily be used as a generic solution for security. The 247 design choice made for MIP6 in the initial stages no longer are valid 248 and is hampering the implementation and use. 250 9. IANA Considerations 252 This document does not have any information which requires IANA 253 review. 255 10. References 257 10.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 263 June 2004. 265 [RFC3776] Arkko, J., "Using IPsec to Protect Mobile IPv6 Signaling 266 Between Mobile Nodes and Home Agents", RFC 3776, 267 June 2004. 269 [RFC4877] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the 270 Revised IPsec Architecture", RFC 4877, April 2007. 272 [DSMIP6] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 273 Hosts and Routers", 274 draft-ietf-mext-nemo-v4traversal-05.txt, July 2008. 276 10.2. Informative References 278 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 279 August 2002. 281 Authors' Addresses 283 Basavaraj Patil 284 Nokia 285 6021 Connection Drive 286 Irving, TX 75039 287 USA 289 Email: basavaraj.patil@nokia.com 291 Charles Perkins 292 WiChorus 293 3590 N. 1st Street, Suite 300 294 San Jose, CA 95134 295 USA 297 Email: charliep@wichorus.com 299 Hannes Tschofenig 300 Nokia Siemens Networks 301 Linnoitustie 6 302 Espoo 02600 303 Finland 305 Phone: +358 (50) 4871445 306 Email: Hannes.Tschofenig@gmx.net 307 URI: http://www.tschofenig.priv.at 309 Full Copyright Statement 311 Copyright (C) The IETF Trust (2008). 313 This document is subject to the rights, licenses and restrictions 314 contained in BCP 78, and except as set forth therein, the authors 315 retain all their rights. 317 This document and the information contained herein are provided on an 318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 320 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 321 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 322 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 325 Intellectual Property 327 The IETF takes no position regarding the validity or scope of any 328 Intellectual Property Rights or other rights that might be claimed to 329 pertain to the implementation or use of the technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; nor does it represent that it has 332 made any independent effort to identify any such rights. Information 333 on the procedures with respect to rights in RFC documents can be 334 found in BCP 78 and BCP 79. 336 Copies of IPR disclosures made to the IETF Secretariat and any 337 assurances of licenses to be made available, or the result of an 338 attempt made to obtain a general license or permission for the use of 339 such proprietary rights by implementers or users of this 340 specification can be obtained from the IETF on-line IPR repository at 341 http://www.ietf.org/ipr. 343 The IETF invites any interested party to bring to its attention any 344 copyrights, patents or patent applications, or other proprietary 345 rights that may cover technology that may be required to implement 346 this standard. Please address the information to the IETF at 347 ietf-ipr@ietf.org.