Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in August 2001 February 22. 2001 Mobility-aware IPsec ESP tunnels Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. Abstract A common usage of IPsec is bidirectional ESP tunnels (secure Virtual Private Networks): the original packet is encapsulated in a new IP header and protected (ESP can provide confidentiality, authentication, integrity and anti-replay) by IPsec ESP (in tunnel mode). This conflicts with all mobility devices [ID1, ID2] which are based on addresses for no good reasons when some of these mobility devices should be able to use the four addresses in the two headers. This document tries to solve this conflict in order to make secure and mobile supports colaborating, ie. to pay for the two features only once. draft-dupont-movesptun-00.txt [Page 1] INTERNET-DRAFT Mobility-aware IPsec ESP tunnels February 2001 1. Introduction IPsec [RFC 2401] defines Encapsulation Security Payload (ESP) [RFC 2406] tunnel mode as an encapsulation of an original/inner IP packet in an outer IP packet: +--------------------+-------------------------------------------+ | | +------------------------+ | | IP header | ESP header | original IP packet | | | | +------------------------+ | +--------------------+-------------------------------------------+ Address based mobility protocols use two addresses for a mobile node: - the home address which is static but virtual - a care-of address which is temporary but denotes the current position of the mobile node. These protocols can use options (source routing header and home address destination option) for the optimized version or a tunnel for the unoptimized version. Both versions apply the same rules: - the mobile node should send packets with a care-of address as the outer source and the home address as the inner source. - a correspondent node should send packets with a care-of address as the outer destination and the home address as the inner destination. If an ESP tunnel is already used we want to add no option or new encapsulation. If security and mobility protocols can colaborate we shall get mobility support without overhead. This document describes how this colaboration can be archieved: packets are transported as for ESP tunnels, IPsec and mobility signaling control together outer addresses. 2. IPsec issues IPsec specifications [RFC 2401] do not mandate any check of the outer source address in incoming processing but many implementations do this kind of check. They are (still) compliant but they cannot interoperate if the source address can change, ie. with an address based mobility device or a Network Address Translator. draft-dupont-movesptun-00.txt [Page 2] INTERNET-DRAFT Mobility-aware IPsec ESP tunnels February 2001 There is no real issue with Internet Key Exchange [RFC 2409] but the phase one is done with a care-of address then: - the lifetime of ISAKMP Security Association built by the phase one should be in the same order than the lifetime of the care-of address. - the care-of address should not be used in an Identity payload (ie. user_FQDN Identity payload is recommended for phase one). - in some case the care-of address of the peer is not known then the initiator should be the mobile node. In phase two the home-address should be used in the Identity payload, the policy should tie the phase one identity with the home-address in order to authorize the setup and update of proper IPsec SAs. The PF_KEY API [RFC 2367] defines identities and addresses (three kind of addresses, source, destination and proxy) for SAs. For a mobile node the care-of address is the source and the home address the proxy according to section 5.2 example. The current specifications need to be updated in order to provide a way to update the source or the destination address. There is not yet a PF_POLICY document but the requirements are exactly the same than for PF_KEY: the source or the destination address of the outer headers must be updatable. 3. Signaling Address based mobility protocols manage a care-of/home address pair on both ends of a mobility session. In the case covered by the document this pair is the outer/inner source address pair on the mobile node, the outer/inner destination address pair on the correspondent node. The signaling function provides a way to update the care-of address in this pair on correspondent nodes when the mobile node has moved, ie. has acquired a new care-of address. If the signaling is done inline, ie. signaling protocol elements are transported through the ESP tunnel from the mobile node to a correspondent, then ESP must provide authentication, integrity check and anti-replay protection. The signaling responder on correspondents MUST interoperate with IPsec management, for instance using standard extended APIs like PF_KEY as decribed before. draft-dupont-movesptun-00.txt [Page 3] INTERNET-DRAFT Mobility-aware IPsec ESP tunnels February 2001 4. Extensions Most of this document was written with bidirectional tunnels in mind but it can be applied in the unidirectional case where previous issues are less critical but still exist. AH in tunnel mode is not commonly used but this document applies to it too. The only difference is that AH protects the whole outer header, including the outer source address. 5. Security Considerations Signaling devices have some security requirements which can be provided by ESP. The correspondent policy have to authorize both the setup of SAs negociated by an initiator using a (a priori random) care-of address and the update of the mobile node outer address in these SAs. 6. Acknowledgements I would like to thank Richard Draves (Microsoft Research) to point to that the interaction between mobile IPv6 and IPsec is near a complete disaster and something must be done. 7. References [ID1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-13.tx, work in progress, November 2000. [ID2] F. Dupont, "IPv6 over IPv4 tunnels for home to Internet access", draft-ietf-ngtrans-hometun-01.txt, work in progress, November 2000. [RFC 2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC 2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC 2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC 2367] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998. draft-dupont-movesptun-00.txt [Page 4] INTERNET-DRAFT Mobility-aware IPsec ESP tunnels February 2001 8. Author's Address Francis Dupont ENST Bretagne Campus de Rennes 2 rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr Expire in 6 months (August 22, 2001)