idnits 2.17.00 (12 Aug 2021) /tmp/idnits7127/draft-ietf-mip6-cn-ipsec-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 476. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (February 23, 2008) is 5201 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 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-06) exists of draft-dupont-mipv6-rrcookie-05 == Outdated reference: A later version (-03) exists of draft-hoffman-ikev2bis-02 -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group F. Dupont 3 Internet-Draft ISC 4 Expires: August 26, 2008 J-M. Combes 5 Orange Labs/France Telecom R&D 6 February 23, 2008 8 Using IPsec between Mobile and Correspondent IPv6 Nodes 9 draft-ietf-mip6-cn-ipsec-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 26, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Mobile IPv6 uses IPsec to protect signaling between the Mobile Node 43 and the Home Agent. This document defines how IPsec can be used 44 between the Mobile Node and Correspondent Nodes for Home Address 45 Option validation and protection of mobility signaling for Route 46 Optimization. The configuration details for IPsec and IKE are also 47 provided. 49 1. Introduction 51 Mobile IPv6 documents [RFC3775][RFC3776][RFC4877] specify IPsec 52 [RFC4301] for the protection of the signaling between the Mobile Node 53 (MN) and its Home Agent (HA), and the return routability procedure 54 between the Mobile Node and its Correspondent Nodes (CN) for Route 55 Optimization. This document defines an alternative mechanism for 56 Mobile IPv6 route optimization based on strong authentication and 57 IPsec. 59 It specifies which IPsec configurations can be useful in a Mobile 60 IPv6 context and how they can validate Home Address Options (enabling 61 triangular routing) and protect mobility signaling (enabling Route 62 Optimization). It gives detailed IKE [RFC2409][RFC4306] 63 configuration guidelines for common cases. 65 Note when the design goal of the return routability procedure was to 66 be "not worse than the current Internet", the design goal of this 67 document is "not worse than deployed IPsec". 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 IKE terminology is copied from IKEv2 [RFC4306] [IKEv2bis]. 75 2. Applicability 77 The purpose of this document is not to replace the return routability 78 procedure, specified in [RFC3775], by the use of IPsec/IKE. It is 79 unrealistic to expect credentials to be available today for strong 80 authentication between any pair of Internet nodes. 82 The idea is to enable the use of the superior security provided by 83 IPsec when it is already in use (i.e., comes at no extra cost), when 84 obstacles (i.e., authentication) to its use no more stand in the way, 85 or simply when it can be considered as highly desirable. 87 This mechanism should only be turned on by explicit configuration 88 between specific peers. This explicit configuration involves turning 89 on the mechanism specified in this document and turning off the 90 Mobile IPv6 Return Routability mechanism. It does not support 91 automatic capability negotiation at this time. 93 It is expected that certificate enrollment supports the inclusion of 94 the Home Address of a node in the node certificate when the Home 95 Address is known in time. 97 It is REQUIRED that nodes conforming to this specification implement 98 the base Mobile IPv6 as specified in RFC 3775 [RFC3775] (either in 99 Mobile or Correspondent Node role or in both). 101 3. IPsec in a Mobile IPv6 context 103 This document considers only suitable IPsec Security Associations, 104 i.e., anything which does not fulfill the following requirements is 105 out of scope: 106 - IPsec Security Association pairs MUST be between the Mobile Node 107 and one of its Correspondent Nodes. 108 - origin authentication, payload integrity and anti-replay services 109 MUST be enabled. 110 - the Traffic Selectors MUST match exclusively the Home Address of 111 the Mobile Node and an address of the Correspondent Node (the 112 address used for communication between peers). 113 - IPsec transport mode MUST be used. 114 - for Route Optimization, the Mobility Header "upper protocol" with 115 at least Binding Update (BU, from the MN) and Binding 116 Acknowledgment (BA, from the CN) message types MUST be accepted by 117 the Traffic Selectors. 119 The purpose of the first three requirements is to allow IPsec to 120 provide a proof of origin. The third one enforces the use of the 121 proper Home Address. 123 4. Home Address Option validation 125 This document amends the Mobile IPv6 [RFC3775] section 9.3.1 by 126 adding a second way (other than Binding Cache Entry check) to provide 127 Home Address Option validation. 129 When a packet carrying a Home Address Option is protected by a 130 suitable IPsec Security Association, the Home Address Option SHOULD 131 be considered valid. 133 A way to implement this is to mark the Home Address Option as "to be 134 validated" when it is processed. When the upper protocol is reached, 135 in order either: 136 - an IPsec header was processed according to [RFC4301] section 5.2 137 with a suitable IPsec Security Association, or 138 - a Binding Cache Entry check is successfully performed, or 139 - the packet contains a Binding Update, or 140 - the packet MUST be dropped. 142 By just setting up an IPsec SA with the CN, the MN is able to send 143 packets directly to the CN, i.e., triangular routing is enabled. The 144 CN does the Home Address Option validation by successful IPsec 145 processing of the packet. The Care-of Address in the source address 146 field of the IPv6 header is not used by IPsec at all as the IPsec 147 policy checks happen against the Home Address. The CN continues to 148 send the packets via the home network until a Binding Update is 149 processed. 151 5. Route Optimization 153 A suitable IPsec Security Association can protect Binding Updates and 154 Acknowledgments. In Binding Updates the new requirements are: 155 - Nonce Indices and Binding Authorization Data options SHOULD NOT be 156 sent by the Mobile Node and MUST be ignored by the Correspondent 157 Node. 158 - when an Alternate Care-of Address option is present, the alternate 159 Care-of Address MUST match the source address in the IP header or 160 the Home Address itself. Any Binding Update which does not 161 fulfill this requirement MUST be rejected. 163 In Binding Acknowledgments the new requirement is: 164 - Binding Authorization Data option SHOULD NOT be sent by the 165 Correspondent Node and MUST be ignored by the Mobile Node. 167 The use of the K (Key Management Mobility Capability) bit with 168 Correspondent Nodes is not defined. This bit is always set to zero 169 on sending a Binding Update or Binding Acknowledgment, and ignored on 170 receipt. 172 Note that a relatively long lifetime compatible with the IPsec policy 173 (i.e., by default up to the IPsec Security Association lifetime) MAY 174 be used with correspondent registrations, in contrast to the short 175 lifetime required by standard RFC 3775 mechanisms. 177 6. IKE configurations 179 6.1. Introduction 181 This section should be understandable (so applicable) from both the 182 mobility and IPsec/IKE points of view: 183 - IKE is an application like any other, mobility is not directly 184 visible by IKE. This is different and simpler than the Mobile 185 Node - Home Agent [RFC3776] [RFC4877] situation. 186 - the key point in the use of IKE by the mobility is to enforce the 187 Section 3 requirements. 189 In particular, it is REQUIRED the Home Address of the Mobile Node 190 matches exclusively the address of the Mobile Node in the Traffic 191 Selector. So this section can use one of these two terms to indicate 192 this address. 194 6.2. Requirements 196 Addresses IKE runs over (aka. the peer addresses) are the addresses 197 seen at the transport or application layer. With this definition, 198 IKE MUST be run over the Home Address for the Mobile Node side when 199 the Home Address is usable. The case where the Home Address in 200 unusable is the subject of Appendix A. 202 The Home Address MAY be used in (phase 1) Mobile Node Identification 203 payloads. But this does not work well with dynamic Home Addresses, 204 so when it is acceptable by the Correspondent Node policy, name based 205 Identification (i.e., of type ID_FQDN or ID_RFC822_ADDR, [RFC4306] 206 section 3.5) payloads SHOULD be used by the Mobile Node. 208 Note the PKI profile for IKE [RFC4945] applies so when the Mobile 209 Node uses an Identification payload with the ID_IPV6_ADDR type, the 210 Mobile Node MUST put the Home Address in it and the Correspondent 211 Node MUST verify that the address in the Identification payload will 212 be the Home Address. 214 6.3. Authorization 216 The IPsec/IKE configuration MUST constraint the authorized traffic, 217 in particular the Child SA Authorization Data [RFC4301] [IKEv2bis] 218 SHOULD authorize the Home Addresses per Mobile Node and per Address. 219 This requirement applies to the whole IPsec/IKE configuration, not 220 only the mobility related part. 222 The Correspondent Node MUST verify the authorization of the Home 223 Address, and it MUST refuse to established IPsec SAs with a not- 224 authorized Home Address. For instance, this check is REQUIRED when 225 the Home Address can be the address in an iPAddress field in the 226 SubjectAltName extension [RFC3280] of the Mobile Node certificate; or 227 when the Home Address can be the address used to lookup a pre-shared 228 key. 230 Dynamically assigned Home Addresses are not known a priori so it is 231 not possible to individually authorize them. In this case the 232 authorization SHOULD be done using the ranges of the possible 233 dynamically assigned Home Addresses. 235 7. IANA Considerations 237 This document makes no request of IANA. 239 Note to RFC Editor: this section may be removed on publication as an 240 RFC. 242 8. Security Considerations 244 The Mobile IPv6 Route Optimization security design background 245 document [RFC4225] describes the unauthorized creation of Binding 246 Cache entries as the main avenue of attack. The authentication and 247 authorization of the Mobile Node provided by IPsec/IKE is a strong 248 defense against this threat. 250 Where the means to create suitable IPsec security associations exist, 251 this mechanism provides origin authentication, integrity protection, 252 replay protection and optional confidentiality services for the 253 Mobile IPv6 signaling. This improves the security over RFC 3775 254 route optimization, as the signaling packets in the latter are 255 vulnerable to man-in-the-middle attacks. The implications of this 256 vulnerability are that an attacker performing the man-in-the-middle 257 attack can have access to the security material needed to create 258 MIPv6 signaling instead of the Mobile Node. On the other hand, an 259 attacker in the same position is also capable of seeing all the 260 payload packets and could launch other attacks with similar 261 implications. For instance, such an attacker could see or modify the 262 contents of payload packets not protected with end-to-end security 263 and cause denial-of-service for others. However, the RFC 3775 264 mechanism allows such attacks in a short time window even after the 265 attacker is no longer in a position to see the payload packets 266 themselves. The mechanism defined in this specification removes this 267 vulnerability. 269 However, unlike RFC 3775 this mechanism should only be used when the 270 correspondent node has good reason to trust the actions of the mobile 271 node. In particular, the correspondent node needs to be certain that 272 the mobile node will not launch flooding attacks against a third 273 party as described in [RFC4225]. Without such trust the only 274 protection comes from the application of ingress filtering in the 275 network where the attacker resides. However, at the moment ingress 276 filtering has not been universally deployed. This mechanism is 277 vulnerable to flooding attacks as it does not verify the validity of 278 a claimed new care-of address. Note, however, the following: 279 - The attacker has to be the Mobile Node itself, i.e., the IPsec/IKE 280 peer, which is supposed to be the subject of a minimal level of 281 trust. 283 - The attack can be easily traced back to the Mobile Node. 285 In order to avoid granting extra privileges by a side effect, the 286 application of this mechanism must not lead to allowing any new, 287 previously unauthorized traffic to flow between the peers beyond 288 mobility signaling with the Mobility Header (MH) protocol. The IPsec 289 peer policy MAY also restrict IPsec Security Associations to the 290 protection of Mobile IPv6 signaling, i.e., restrict the Traffic 291 Selectors to MH with at least Binding Update and Binding 292 Acknowledgment message types. 294 Although the protection of static addresses is not mandatory in IPsec 295 or Home Addresses do not introduce a specific issue, this document 296 requires authorized Home Addresses, and recommends individual or 297 range authorization according to what is possible. This protects a 298 Mobile Node using a static so likely known Home Address against the 299 theft of its Home Address, both when the security associations are 300 established and without limitations when they are used. Dynamic 301 addresses are not protected against spoofing but the spoofing is 302 limited to the dynamic address ranges, i.e., Mobile Nodes using 303 dynamically assigned Home Addresses can be attacked between them. 304 Finally the authorization requirement applies to the whole 305 configuration so mobility is protected against other usages of IPsec. 307 9. Acknowledgments 309 The authors would like to thank many people for believing in IPsec as 310 a right way to secure Mobile IPv6. Special thanks to Wassim Haddad 311 and Claude Castelluccia for keeping our attention to special cases 312 where Home Addresses are derived from public keys. Thanks to Mohan 313 Parthasarathy for the peer address clarification and to Jari Arkko 314 for the time he spent to improve the document. 316 10. Possible enhancements 318 A number of potential enhancements of this method are possible, 319 including, for instance, various mechanisms for verification of 320 Care-of Addresses or use of addresses bound to keys. [RFC4651] 321 describes many proposals for the general Route Optimization problem. 323 [I-D.dupont-mipv6-rrcookie] is an alternate approach to testing 324 Care-of Addresses. 326 When the Home Address is bound to a public key, for instance when the 327 Home Address is a Cryptographically Generated Address [RFC3972], 328 [I-D.laganier-ike-ipv6-cga] describes an alternative approach to the 329 use of strong authentication. 331 11. Changes from the previous version 333 To be removed prior to publication as an RFC. 335 The support of the base Mobile IPv6 is required. 337 The Home Address authorization must be performed when possible, and 338 the conditions of this "when possible" should be fulfilled by the 339 configuration if the Home Address is not dynamically assigned by the 340 Home Agent. 342 12. References 344 12.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", RFC 2119, BCP 14, March 1997. 349 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 350 (IKE)", RFC 2409, November 1998. 352 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 353 X.509 Public Key Infrastructure Certificate and 354 Certificate Revocation List (CRL) Profile", RFC 3280, 355 April 2002. 357 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 358 in IPv6", RFC 3775, June 2004. 360 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 361 Protect Mobile IPv6 Signaling Between Mobile Nodes and 362 Home Agents", RFC 3776, June 2004. 364 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 365 Internet Protocol", RFC 4301, December 2005. 367 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 368 Protocol", RFC 4306, December 2005. 370 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 371 IKEv2 and the Revised IPsec Architecture", RFC 4877, 372 April 2007. 374 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 375 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 377 12.2. Informative References 379 [I-D.dupont-mipv6-rrcookie] 380 Dupont, F. and J-M. Combes, "Care-of Address Test for 381 MIPv6 using a State Cookie", 382 draft-dupont-mipv6-rrcookie-05.txt (work in progress), 383 November 2007. 385 [I-D.laganier-ike-ipv6-cga] 386 Laganier, J. and G. Montenegro, "Using IKE with IPv6 387 Cryptographically Generated Addresses", 388 draft-laganier-ike-ipv6-cga-02.txt (work in progress), 389 July 2007. 391 [IKEv2bis] 392 Kaufman, C., Hoffman, P., and P. Eronen, "Internet Key 393 Exchange Protocol: IKEv2", draft-hoffman-ikev2bis-02.txt 394 (work in progress), November 2007. 396 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 397 RFC 3972, March 2005. 399 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 400 Nordmark, "Mobile IP Version 6 Route Optimization Security 401 Design Background", RFC 4225, December 2005. 403 [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of 404 Enhancements to Mobile IPv6 Route Optimization", RFC 4651, 405 February 2007. 407 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 408 for Overlay Routable Cryptographic Hash Identifiers 409 (ORCHID)", RFC 4843, April 2007. 411 Appendix A. IKE running over a Care-of Address 413 In special circumstances where the Home Address can be unusable, as 414 when the Home Address is ORCHID [RFC4843] based and not routable, IKE 415 must be run over a Care-of Address but this has many known drawbacks: 416 - a Care-of Address can not be used for authentication nor 417 authorization. 418 - Security Associations do not survive handoffs. 419 - the establishment of transport mode IPsec Security Association 420 using the Home Address as the Mobile Node Traffic Selector raises 421 a policy / authorization issue as IKE runs over another address. 423 Authors' Addresses 425 Francis Dupont 426 ISC 428 Email: Francis.Dupont@fdupont.fr 430 Jean-Michel Combes 431 Orange Labs/France Telecom R&D 432 38 rue du General Leclerc 433 92794 Issy-les-Moulineaux Cedex 9 434 France 436 Email: jeanmichel.combes@gmail.com 438 Full Copyright Statement 440 Copyright (C) The IETF Trust (2008). 442 This document is subject to the rights, licenses and restrictions 443 contained in BCP 78, and except as set forth therein, the authors 444 retain all their rights. 446 This document and the information contained herein are provided on an 447 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 448 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 449 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 450 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 451 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 454 Intellectual Property 456 The IETF takes no position regarding the validity or scope of any 457 Intellectual Property Rights or other rights that might be claimed to 458 pertain to the implementation or use of the technology described in 459 this document or the extent to which any license under such rights 460 might or might not be available; nor does it represent that it has 461 made any independent effort to identify any such rights. Information 462 on the procedures with respect to rights in RFC documents can be 463 found in BCP 78 and BCP 79. 465 Copies of IPR disclosures made to the IETF Secretariat and any 466 assurances of licenses to be made available, or the result of an 467 attempt made to obtain a general license or permission for the use of 468 such proprietary rights by implementers or users of this 469 specification can be obtained from the IETF on-line IPR repository at 470 http://www.ietf.org/ipr. 472 The IETF invites any interested party to bring to its attention any 473 copyrights, patents or patent applications, or other proprietary 474 rights that may cover technology that may be required to implement 475 this standard. Please address the information to the IETF at 476 ietf-ipr@ietf.org. 478 Acknowledgment 480 Funding for the RFC Editor function is provided by the IETF 481 Administrative Support Activity (IASA).