Network Working Group F. Dupont Internet-Draft Point6 Expires: April 25, 2006 October 22, 2005 IPsec transport mode in Mobike environments draft-dupont-mobike-transport-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 April 25, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies how to use IPsec transport mode security associations in a Mobike environment, i.e., in an environment with sequential (mobility) or parallel (multi-homing) addresses. 1. Introduction Mobike deals with "peer addresses" which are the addresses IKE runs over and which are the addresses used as outer addresses by tunnel Dupont Expires April 25, 2006 [Page 1] Internet-Draft Transport mode and Mobike October 2005 mode IPsec security associations between security gateways [RFC2401bis]. Mobike both specifies in IKEv2 [IKEv2] 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 addresses: current designs for Mobike do not support their management, for instance updates of their addresses. But there is an indirect way to take benefits from Mobike: assume that the peer addresses are the addresses of peers. This document applies only in the case where there is no NAT. The current Mobike protocol mandates NAT detection or prohibition, and the IKEv2 NAT traversal does not support transport mode, so there should not be ambiguities about cases the document is not applicable. 2. Terms and Definitions Terms like "peer addresses" are taken from the address management proposal [ADDRMGT]. This document uses the standard keywords [BCP14] to indicate requirement levels. 3. Transport mode and addresses The endpoint addresses of an IPsec transport mode 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. When a Mobike mechanism provides peer address lists or sets as described in section 3.1 of the Mobike design document [MOBIKE], this rule can be relaxed into: by default, any peer address MAY be used as an endpoint address of an IPsec transport mode security association. 4. Two examples This section provides two examples of transport mode taking benefits of Mobike mechanisms. 4.1. MIPv6 example The first example is the IPv6 mobility [RFC3775] where a mobile node Dupont Expires April 25, 2006 [Page 2] Internet-Draft Transport mode and Mobike October 2005 uses two addresses: - 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 a Mobike peer address management (as in [ADDRMGT]) a mobile node can 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 the other IPsec security associations, in tunnel mode, are updated in case of handoffs by the mobility support itself, not by Mobike. 4.2. SCTP 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 Mobike, a multi-homed peer can register its addresses as peer addresses. It is also authorized to use them to build multiple transport mode IPsec security associations using only one IKE session, i.e., within the same IKE security association. Without Mobike, each pair of peer addresses has to be management 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. Acknowledgments The Mobike Working Group agreed at the 60th IETF meeting in San Diego to put transport mode outside of its immediate scope. But as transport mode can take indirect benefits of Mobike mechanisms, an as short as possible document (this one) was proposed. Note it does not try to justify the decision in details (decision which can be reversed if an interesting direct application of Mobike mechanisms to transport mode is found). Some special transport mode IPsec security associations over IP-IP tunnels [RFC3884] were proposed for consideration by Joe Touch but in Dupont Expires April 25, 2006 [Page 3] Internet-Draft Transport mode and Mobike October 2005 fact they are another example of security associations which are updated by an external (to IPsec) mechanism, i.e., as in the IPv6 mobility case, Mobike mechanisms can only help to easily solve authorization issues. 6. 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 endpoint addresses. Rationale: "authenticated" means that one verified the address belongs to the peer and must be trusted, "authorized" means that one checks in its policy 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. 7. References 7.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. 7.2. Informative References [ADDRMGT] Dupont, F., "Address Management for IKE version 2", draft-dupont-ikev2-addrmgmt-07.txt (work in progress), May 2005. [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17.txt (work in progress), September 2004. [MOBIKE] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-03.txt (work in progress), October 2005. [RFC2401bis] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06.txt (work in progress), March 2005. Dupont Expires April 25, 2006 [Page 4] Internet-Draft Transport mode and Mobike October 2005 [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 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 April 25, 2006 [Page 5] Internet-Draft Transport mode and Mobike October 2005 Author's Address Francis Dupont Point6 c/o GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: Francis.Dupont@enst-bretagne.fr Dupont Expires April 25, 2006 [Page 6] Internet-Draft Transport mode and Mobike October 2005 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 (2005). 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 April 25, 2006 [Page 7]