idnits 2.17.1 draft-dupont-movesptun-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ID1,ID2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 130: '...n correspondents MUST interoperate wit...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 -- Possible downref: Normative reference to a draft: ref. 'ID2' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2367 Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Francis Dupont 2 INTERNET DRAFT ENST Bretagne 3 Expires in August 2001 February 22. 2001 5 Mobility-aware IPsec ESP tunnels 7 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Abstract 35 A common usage of IPsec is bidirectional ESP tunnels (secure 36 Virtual Private Networks): the original packet is encapsulated in 37 a new IP header and protected (ESP can provide confidentiality, 38 authentication, integrity and anti-replay) by IPsec ESP (in tunnel 39 mode). 41 This conflicts with all mobility devices [ID1, ID2] which are based 42 on addresses for no good reasons when some of these mobility devices 43 should be able to use the four addresses in the two headers. 45 This document tries to solve this conflict in order to make secure 46 and mobile supports colaborating, ie. to pay for the two features 47 only once. 49 1. Introduction 51 IPsec [RFC 2401] defines Encapsulation Security Payload (ESP) 52 [RFC 2406] tunnel mode as an encapsulation of an original/inner 53 IP packet in an outer IP packet: 55 +--------------------+-------------------------------------------+ 56 | | +------------------------+ | 57 | IP header | ESP header | original IP packet | | 58 | | +------------------------+ | 59 +--------------------+-------------------------------------------+ 61 Address based mobility protocols use two addresses for a mobile node: 62 - the home address which is static but virtual 63 - a care-of address which is temporary but denotes the current 64 position of the mobile node. 65 These protocols can use options (source routing header and home 66 address destination option) for the optimized version or a tunnel 67 for the unoptimized version. Both versions apply the same rules: 68 - the mobile node should send packets with a care-of address as 69 the outer source and the home address as the inner source. 70 - a correspondent node should send packets with a care-of address 71 as the outer destination and the home address as the inner 72 destination. 74 If an ESP tunnel is already used we want to add no option or new 75 encapsulation. If security and mobility protocols can colaborate 76 we shall get mobility support without overhead. This document 77 describes how this colaboration can be archieved: packets are 78 transported as for ESP tunnels, IPsec and mobility signaling 79 control together outer addresses. 81 2. IPsec issues 83 IPsec specifications [RFC 2401] do not mandate any check of the 84 outer source address in incoming processing but many implementations 85 do this kind of check. They are (still) compliant but they cannot 86 interoperate if the source address can change, ie. with an address 87 based mobility device or a Network Address Translator. 89 There is no real issue with Internet Key Exchange [RFC 2409] 90 but the phase one is done with a care-of address then: 91 - the lifetime of ISAKMP Security Association built by the 92 phase one should be in the same order than the lifetime of 93 the care-of address. 94 - the care-of address should not be used in an Identity payload 95 (ie. user_FQDN Identity payload is recommended for phase one). 96 - in some case the care-of address of the peer is not known then 97 the initiator should be the mobile node. 98 In phase two the home-address should be used in the Identity payload, 99 the policy should tie the phase one identity with the home-address in 100 order to authorize the setup and update of proper IPsec SAs. 102 The PF_KEY API [RFC 2367] defines identities and addresses (three 103 kind of addresses, source, destination and proxy) for SAs. 104 For a mobile node the care-of address is the source and 105 the home address the proxy according to section 5.2 example. 106 The current specifications need to be updated in order to 107 provide a way to update the source or the destination address. 109 There is not yet a PF_POLICY document but the requirements are 110 exactly the same than for PF_KEY: the source or the destination 111 address of the outer headers must be updatable. 113 3. Signaling 115 Address based mobility protocols manage a care-of/home address 116 pair on both ends of a mobility session. In the case covered 117 by the document this pair is the outer/inner source address pair 118 on the mobile node, the outer/inner destination address pair 119 on the correspondent node. 121 The signaling function provides a way to update the care-of address 122 in this pair on correspondent nodes when the mobile node has moved, 123 ie. has acquired a new care-of address. 125 If the signaling is done inline, ie. signaling protocol elements 126 are transported through the ESP tunnel from the mobile node to 127 a correspondent, then ESP must provide authentication, integrity 128 check and anti-replay protection. 130 The signaling responder on correspondents MUST interoperate with 131 IPsec management, for instance using standard extended APIs like 132 PF_KEY as decribed before. 134 4. Extensions 136 Most of this document was written with bidirectional tunnels in mind 137 but it can be applied in the unidirectional case where previous 138 issues are less critical but still exist. 140 AH in tunnel mode is not commonly used but this document applies 141 to it too. The only difference is that AH protects the whole outer 142 header, including the outer source address. 144 5. Security Considerations 146 Signaling devices have some security requirements which can be 147 provided by ESP. 149 The correspondent policy have to authorize both the setup of SAs 150 negociated by an initiator using a (a priori random) care-of address 151 and the update of the mobile node outer address in these SAs. 153 6. Acknowledgements 155 I would like to thank Richard Draves (Microsoft Research) to point 156 to that the interaction between mobile IPv6 and IPsec is near a 157 complete disaster and something must be done. 159 7. References 161 [ID1] D. Johnson, C. Perkins, "Mobility Support in IPv6", 162 draft-ietf-mobileip-ipv6-13.tx, work in progress, 163 November 2000. 165 [ID2] F. Dupont, "IPv6 over IPv4 tunnels for home to Internet 166 access", draft-ietf-ngtrans-hometun-01.txt, work in progress, 167 November 2000. 169 [RFC 2401] S. Kent, R. Atkinson, "Security Architecture for the 170 Internet Protocol", RFC 2401, November 1998. 172 [RFC 2406] S. Kent, R. Atkinson, "IP Encapsulating Security 173 Payload (ESP)", RFC 2406, November 1998. 175 [RFC 2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 176 RFC 2409, November 1998. 178 [RFC 2367] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management 179 API, Version 2", RFC 2367, July 1998. 181 8. Author's Address 183 Francis Dupont 184 ENST Bretagne 185 Campus de Rennes 186 2 rue de la Chataigneraie 187 BP 78 188 35512 Cesson-Sevigne Cedex 189 FRANCE 190 Fax: +33 2 99 12 70 30 191 EMail: Francis.Dupont@enst-bretagne.fr 193 Expire in 6 months (August 22, 2001)