Network Working Group F. Dupont Internet-Draft CELAR Expires: December 27, 2006 June 25, 2006 IPsec transport mode in Mobike environments draft-dupont-mobike-transport-04.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 December 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies how to use transport mode IPsec security associations in a Mobike environment, i.e., in an environment with sequential (mobility) or parallel (multi-homing) addresses. 1. Introduction The Mobike protocol [RFC4555] deals with "peer addresses" which are the addresses IKE runs over and which are the addresses used as outer Dupont Expires December 27, 2006 [Page 1] Internet-Draft Transport mode and Mobike June 2006 or endpoint addresses by tunnel mode IPsec security associations between security gateways [RFC4301]. Mobike specifies in IKEv2 [RFC4306] both a way to define alternate peer addresses and a way to update security associations, when one or both parties are mobile or multi-homed. But transport mode IPsec security associations are end-to-end and have no outer / endpoint addresses: current designs for Mobike do not support their management, for instance updates of their addresses, because the endpoint addresses are also traffic selectors. But there are two ways to take benefit from Mobike in some cases: the first one is to assume that the peer addresses are the addresses of peers for authorization, the second is to update addresses which do not select traffic. 2. Terms and Definitions Terms like "peer addresses" are taken from the certificate profile proposal [IKECERT]. This document uses the standard keywords [BCP14] to indicate requirement levels. 3. Transport mode and addresses The endpoint addresses of a transport mode IPsec security association are usually addresses of the peers but are taken from the traffic selectors, not from the peer addresses. When they are not the same than the peer addresses, they MUST be authorized by the local policy. The Mobike protocol provides peer address lists or sets so this rule can be relaxed into: by default, any peer address MAY be used as an endpoint address of a transport mode IPsec security association. 4. Reuses of address management This section provides two examples of transport mode taking benefit from the peer address set management provided by Mobike. 4.1. MIPv6 example The first example is the IPv6 mobility [RFC3775] where a mobile node uses two kinds of addresses: Dupont Expires December 27, 2006 [Page 2] Internet-Draft Transport mode and Mobike June 2006 - the fixed home address in the remote/home network, - transient care-of addresses assigned in the local/visited network. In communications with its home agent, a mobile node uses a care-of address (because its home address is not usable until the home registration) so its peer address is a care-of address. But to protect the mobility signaling [RFC3776] a transport mode IPsec security association pair is established using the home address. Using the Mobike peer address management, a mobile node MAY add its home address as an alternate peer address and be authorized to use it in its traffic selector for the mandatory transport mode IPsec security association pair. Note some other IPsec security associations which are in tunnel mode are updated in case of handoffs by the mobility support itself, not by Mobike. 4.2. Multi-homing example The second example is multi-homing using SCTP [RFC2960], (itself or what we call the SCTP model of multi-homing) between two hosts. Using the peer address management of Mobike, a multi-homed peer SHOULD register its addresses as peer addresses. It is also authorized to use them (i.e., it MAY use them) to build multiple transport mode IPsec security associations using only one IKE session, i.e., within the same IKE security association. Without this authorization facility from Mobike, each pair of peer addresses has to be managed by an independent IKE session, wasting resources and making a higher layer of management for handling peer events (in place of address events) necessary. Note this document does not address the question of using multiple simultaneous addresses in IPsec security associations in the outgoing side, even if the main implementation issue, the address selection, does not exist for transport mode. 5. Reuses of endpoint updates The Mobike protocol cannot directly update transport mode IPsec security associations, in particular it cannot change their traffic selectors. But when there are not addresses in traffic selectors (i.e., address selectors are set to ANY) or when all the involved addresses are in traffic selectors, this obstacle no more exists. An exterior (to IPsec/IKE) mechanism has to handle both the decision to change addresses and to update the endpoints of the transport mode IPsec security associations. The role of Mobike is to update the IKE security association and the house-keeping of the IPsec security Dupont Expires December 27, 2006 [Page 3] Internet-Draft Transport mode and Mobike June 2006 associations. One can compare this to the K flag mechanism of MIPv6 [RFC3776]. 5.1. SCTP example Again SCTP [RFC2960] is a good candidate, in this example the current SCTP endpoint management is followed: when a path, i.e., a pair of a soure and destination endpoint addresses, fails, another (backup) path is selected and all the communications between the two endpoints are switched over it. When some of the SCTP communications are protected by IPsec, the Mobike peer address update mechanism MAY be used to notify IKE of peer address changes. This case is limited: - the whole list of possible peer addresses SHOULD be known in advance, i.e., multi-homing is supported but not mobility. - all involved addresses MUST be in traffic selectors. 5.2. IP-IP example The last example is about some special transport mode IPsec security associations over IP-IP tunnels [RFC3884]. The traffic selectors MAY be reduced to the tunnel transport mechanism parameters, for instance a protocol number, and the endpoint addresses hidden by the choice of the security policy database attached to the tunnel interface. With this special configuration there is no constraint on the use of Mobike as soon as the tunnel and IPsec managements are implemented to work together (i.e., all parameters are updated exactly once). 6. Acknowledgments The Mobike Working Group agreed to put transport mode outside of its immediate scope. But as transport mode can take indirect benefit from Mobike mechanisms, an as short as possible document (this one) was proposed. Mohan Parthasarathy provides a big part of the update reuse cases, Joe Touch proposed for consideration the IP-IP one. 7. Security Considerations IKEv2 and Mobike mechanisms do verify that the primary peer address (for IKEv2) and further alternate peer address (for Mobike mechanisms) are correctly authenticated and authorized, so they MAY safely be used for transport mode IPsec security associations as Dupont Expires December 27, 2006 [Page 4] Internet-Draft Transport mode and Mobike June 2006 endpoint addresses. Rationale: "authenticated" means that one verified the address belongs to the peer and may be trusted, "authorized" means that one checks in its policy whether the peer is authorized to use this address. The mechanisms to provide the authentication and authorization are outside the scope of this document which only assumes they exist and are enforced. The peer address update of Mobike is only an optimization of re- keying or re-establishing of a set of security associations so this mechanism does not introduce new issues when it is performed in the same conditions. 8. References 8.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [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. [RFC4555] Eronen, P., Ed., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. 8.2. Informative References [IKECERT] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", draft-ietf-pki4ipsec-ikecert-profile-10.txt (work in progress), April 2006. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [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 Dupont Expires December 27, 2006 [Page 5] Internet-Draft Transport mode and Mobike June 2006 Home Agents", RFC 3776, June 2004. [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004. Dupont Expires December 27, 2006 [Page 6] Internet-Draft Transport mode and Mobike June 2006 Author's Address Francis Dupont CELAR Email: Francis.Dupont@point6.net Dupont Expires December 27, 2006 [Page 7] Internet-Draft Transport mode and Mobike June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dupont Expires December 27, 2006 [Page 8]