MIP6 Working Group F. Dupont Internet-Draft CELAR Intended status: Informational J-M. Combes Expires: February 4, 2007 France Telecom DR&D August 3, 2006 Using IPsec between Mobile and Correspondent IPv6 Nodes draft-ietf-mip6-cn-ipsec-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobile IPv6 uses IPsec to protect signaling between the mobile node and the home agent. This document defines how IPsec can be used between the mobile node and correspondent nodes for home address option validation (aka. triangular routing) and protection of mobility signaling for route optimizations. The configuration details for IPsec and IKE are also provided. Dupont & Combes Expires February 4, 2007 [Page 1] Internet-Draft Using IPsec between MN and CN August 2006 1. Introduction Mobile IPv6 documents [RFC3775][RFC3776] specifies IPsec [RFC4301] for the protection of the signaling between the mobile node (MN) and its home agent (HA), and the return routability procedure between the mobile node and its correspondent nodes (CN) for routing optimization. But any stronger mechanism (i.e., more secure than the return routability procedure) may be used, including of course IPsec (cf. [RFC3775] Appendix 3 "New Authorization Methods"). This document specifies which IPsec configurations can be useful in a Mobile IPv6 context and how they can validate home address options (enabling triangular routing) and protect mobility signaling (enabling routing optimization). It gives detailed IKE [RFC2409][RFC4306] configuration guidelines for common cases. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. IKE terminology is copied from IKEv2 [RFC4306]. 2. Applicability The purpose of this document is not to replace the [RFC3775] return routability procedure by the use of IPsec/IKE which has some authentication requirements which make its universal deployment more than unrealistic. The idea is to enable the use of the superior security provided by IPsec when it is already in use (i.e., comes at no extra cost), obstacles (i.e., authentication) to its use no more stand in the way, or simply when it can be considered as highly desirable. 3. IPsec in a Mobile IPv6 context This document considers only suitable IPsec security associations, i.e., anything which does not fulfill the following requirements is out of scope: - IPsec security association pairs MUST be between the mobile node and one of its correspondent nodes. - origin authentication, payload integrity and anti-replay services MUST be selected. - the traffic selectors MUST match exclusively the home address of the mobile node and an address of the correspondent node (the address used for communication between peers). Dupont & Combes Expires February 4, 2007 [Page 2] Internet-Draft Using IPsec between MN and CN August 2006 - the transport mode MUST be used. - for routing optimization, the mobility header "upper protocol" with at least binding update (BU, from the MN) and acknowledgment (BA, from the CN) message types MUST be accepted by the traffic selectors. The purpose of the first three requirements is to allow to use IPsec as a proof of origin. 4. Home address option validation This document amends the Mobile IPv6 [RFC3775] section 9.3.1 by adding a second way (other than binding cache entry check) to provide home address option validation. When a packet carrying a home address option is protected by a suitable IPsec security association, the home address option SHOULD be considered valid. A way to implement this is to mark the home address option as "to be validated" when it is processed. When the upper protocol is reached, in order either: - an IPsec header was processed according to [RFC4301] section 5.2 with a suitable IPsec security association, or - a binding cache entry check is successfully performed, or - the packet contains a binding update, or - the packet MUST be dropped. By just setting up an IPsec SA with the CN, the MN is able to send packets directly to the CN, i.e., triangular routing is enabled. The CN does the home address option validation by successful IPsec processing of the packet. The care-of address in the source address field of the IPv6 header is not used by IPsec at all as the IPsec policy checks happen against the home address. The CN continues to send the packets via the home network until a binding update is processed. 5. Routing Optimization A suitable IPsec security association can protect binding updates and acknowledgments. In binding updates the new requirements are: - the H (home registration) and K (key management mobility capability) bits MUST be cleared. - Nonce indices and binding authorization data options SHOULD NOT be sent by the mobile node and MUST be ignored by the correspondent node. Dupont & Combes Expires February 4, 2007 [Page 3] Internet-Draft Using IPsec between MN and CN August 2006 - when an alternate care-of address option is present and is not checked using the state cookie mechanism [COOKIE], the alternate care-of address MUST match the source address in the IP header or the home address itself. Any binding update which does not fulfill this requirement MUST be rejected. - as ESP can only protect the payload, an alternate care-of address option MUST be used in conjunction with ESP (cf. [RFC3775] section 11.7.1). In binding acknowledgments the new requirements are: - the K (key management mobility capability) bit MUST be cleared. - binding authorization data option SHOULD NOT be sent by the correspondent node and MUST be ignored by the mobile node. - "long" lifetime compatible with the IPsec policy (i.e., by default up to the IPsec security association lifetime) MAY be granted. 6. IKE configurations This document considers only IKE where it is used for mobility purpose. Peer addresses (addresses IKE runs over) are the addresses seen at the transport or application layer, i.e., when the mobile node uses its home address as the source of an IKE message, the source address in the IP header can (should!) be a care-of address. IKE MUST be run over the home address for the mobile node side when the home address is usable. The case where the home address in unusable is the subject of Appendix A. The home address MAY be used in (phase 1) mobile node Identification payloads. But this does not work well with dynamic home addresses, so when it is acceptable by the correspondent node policy, name based Identification (i.e., of type ID_FQDN or ID_RFC822_ADDR, [RFC4306] section 3.5) payloads SHOULD be used by the mobile node. When the home address is bound to a public key, for instance when the home address is a Cryptographically Generated Addresses [RFC3972], the strong authentication MAY be replaced by an address ownership proof as described for instance in [IKECGA]. The IKE peer policy MAY restrict IPsec security associations to the protection of Mobile IPv6 signaling, i.e., restrict the traffic selectors to the mobility header "upper protocol" with at least binding update and acknowledgment message types. This SHOULD be the default policy when authentication or authorization can be considered as being weak, for instance when the previous paragraph is applied. Dupont & Combes Expires February 4, 2007 [Page 4] Internet-Draft Using IPsec between MN and CN August 2006 7. Security Considerations IPsec is far more secure than the return routability procedure, thus it should be used where it is applicable. So this document can increase at least the overall security of Mobile IPv6. Two points are worthy of special considerations: - no care-of address test is required when ingress filtering can reject fake care-of addresses from a rogue mobile node but a correspondent node can use the return routability state cookie procedure to get extra insurance as well as for the support of real alternate care-of addresses. - in order to avoid granting any extra privilege by a side effect of using IPsec, the peers (i.e., the mobile and correspondent nodes) may restrict the traffic selectors to the protection of mobility signaling only. This should be applied to any dubious cases, including by default when security administration is known to be too light. 8. Acknowledgments The authors would like to thank many people for believing in IPsec as a right way to secure Mobile IPv6. Special thanks to Wassim Haddad and Claude Castelluccia for keeping our attention to special cases where home addresses are derived from public keys. 9. Changes from previous versions To be removed prior to publication as an RFC. An applicability section was added. The IKE running over a care-of address was moved to an appendix as it is not at all the standard case. The care-of address test annex was moved to its own document [COOKIE]. Peer address clarification (thanks to Mohan Parthasarathy). Change SHOULD/MAY to MUST/MUST for mobile node peer address. 10. References Dupont & Combes Expires February 4, 2007 [Page 5] Internet-Draft Using IPsec between MN and CN August 2006 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 10.2. Informative References [COOKIE] Dupont, F. and J-M. Combes, "Care-of Address Test for MIPv6 using a State Cookie", draft-dupont-mipv6-rrcookie-03.txt (work in progress), July 2006. [IKECGA] Laganier, J. and G. Montenegro, "Using IKE with IPv6 Cryptographically Generated Address", draft-laganier-ike-ipv6-cga-01.txt (work in progress), June 2003. [ORCHID] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", draft-laganier-ipv6-khi-02.txt (work in progress), June 2006. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. Appendix A. IKE running over a care-of address In special circumstances where the home address can be unusable, like when the home address is ORCHID [ORCHID] based and not routable, IKE must be run over a care-of address but this has many known drawbacks: Dupont & Combes Expires February 4, 2007 [Page 6] Internet-Draft Using IPsec between MN and CN August 2006 - a care-of address can not be used for authentication nor authorization. - security associations do not survive handoffs. - the establishment of transport mode IPsec security association using the home address as the mobile node traffic selector raises a policy / authorization issue as IKE runs over another address. Authors' Addresses Francis Dupont CELAR Email: Francis.Dupont@fdupont.fr Jean-Michel Combes France Telecom DR&D 38/40 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France Fax: +33 1 45 29 65 19 Email: jeanmichel.combes@orange-ft.com Dupont & Combes Expires February 4, 2007 [Page 7] Internet-Draft Using IPsec between MN and CN August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Dupont & Combes Expires February 4, 2007 [Page 8]