idnits 2.17.1 draft-dupont-mobike-transport-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 232. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (April 25, 2005) is 6939 days in the past. Is this intentional? 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 (-08) exists of draft-dupont-ikev2-addrmgmt-06 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-02 -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Dupont 2 Internet-Draft Point6 3 Expires: October 27, 2005 April 25, 2005 5 IPsec transport mode in Mobike environments 6 draft-dupont-mobike-transport-02.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "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 This Internet-Draft will expire on October 27, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 37 Abstract 39 This document specifies how to use IPsec transport mode security 40 associations in a Mobike environment, i.e., in an environment with 41 sequential (mobility) or parallel (multi-homing) addresses. 43 1. Introduction 45 Mobike deals with "peer addresses" which are the addresses IKE runs 46 over and which are the addresses used as outer addresses by tunnel 47 mode IPsec security associations between security gateways 49 [RFC2401bis]. Mobike both specifies in IKEv2 [IKEv2] a way to define 50 alternate peer addresses and a way to update security associations, 51 when one or both parties are mobile or multi-homed. 53 But transport mode IPsec security associations are end-to-end and 54 have no outer addresses: current designs for Mobike do not support 55 their management, for instance updates of their addresses. But there 56 is an indirect way to take benefits from Mobike: assume that the peer 57 addresses are the addresses of peers. 59 2. Terms and Definitions 61 Terms like "peer addresses" are taken from the address management 62 proposal [ADDRMGT]. 64 This document uses the standard keywords [BCP14] to indicate 65 requirement levels. 67 3. Transport mode and addresses 69 The endpoint addresses of an IPsec transport mode security 70 association are usually addresses of the peers but are taken from the 71 traffic selectors, not from the peer addresses. When they are not 72 the same than the peer addresses, they MUST be authorized by the 73 local policy. 75 When a Mobike mechanism provides peer address lists or sets as 76 described in section 3.1 of the Mobike design document [MOBIKE], this 77 rule can be relaxed into: by default, any peer address MAY be used as 78 an endpoint address of an IPsec transport mode security association. 80 4. Two examples 82 This section provides two examples of transport mode taking benefits 83 of Mobike mechanisms. 85 4.1 MIPv6 example 87 The first example is the IPv6 mobility [RFC3775] where a mobile node 88 uses two addresses: 89 - the fixed home address in the remote/home network; 90 - transient care-of addresses assigned in the local/visited network. 91 In communications with its home agent, a mobile node uses a care-of 92 address (because its home address is not usable until the home 93 registration) so its peer address is a care-of address. But to 94 protect the mobility signaling [RFC3776] a transport mode IPsec 95 security association pair is established using the home address. 97 Using a Mobike peer address management (as in [ADDRMGT]) a mobile 98 node can add its home address as an alternate peer address and be 99 authorized to use it in its traffic selector for the mandatory 100 transport mode IPsec security association pair. Note the other IPsec 101 security associations, in tunnel mode, are updated in case of 102 handoffs by the mobility support itself, not by Mobike. 104 4.2 SCTP example 106 The second example is multi-homing using SCTP [RFC2960], (itself or 107 what we call the SCTP model of multi-homing) between two hosts. 108 "Using Mobike, a multi-homed peer can register its addresses as peer 109 addresses. It is also authorized to use them to build multiple 110 transport mode IPsec security associations using only one IKE 111 session, i.e., within the same IKE security association. 113 Without Mobike, each pair of peer addresses has to be management by 114 an independent IKE session, wasting resources and making a higher 115 layer of management for handling peer events (in place of address 116 events) necessary. 118 Note this document does not address the question of using multiple 119 simultaneous addresses in IPsec security associations in the outgoing 120 side, even if the main implementation issue, the address selection, 121 does not exist for transport mode. 123 5. Acknowledgments 125 The Mobike Working Group agreed at the 60th IETF meeting in San Diego 126 to put transport mode outside of its immediate scope. But as 127 transport mode can take indirect benefits of Mobike mechanisms, an as 128 short as possible document (this one) was proposed. Note it does not 129 try to justify the decision in details (decision which can be 130 reversed if an interesting direct application of Mobike mechanisms to 131 transport mode is found). 133 Some special transport mode IPsec security associations over IP-IP 134 tunnels [RFC3884] were proposed for consideration by Joe Touch but in 135 fact they are another example of security associations which are 136 updated by an external (to IPsec) mechanism, i.e., as in the IPv6 137 mobility case, Mobike mechanisms can only help to easily solve 138 authorization issues. 140 6. Security Considerations 142 IKEv2 and Mobike mechanisms do verify that the primary peer address 143 (for IKEv2) and further alternate peer address (for Mobike 144 mechanisms) are correctly authenticated and authorized, so they MAY 145 safely be used for transport mode IPsec security associations as 146 endpoint addresses. 148 Rationale: "authenticated" means that one verified the address 149 belongs to the peer and must be trusted, "authorized" means that one 150 checks in its policy the peer is authorized to use this address. The 151 mechanisms to provide the authentication and authorization are 152 outside the scope of this document which only assumes they exist and 153 are enforced. 155 7. References 157 7.1 Normative References 159 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 160 Requirement Levels", RFC 2119, BCP 14, March 1997. 162 7.2 Informative References 164 [ADDRMGT] Dupont, F., "Address Management for IKE version 2", 165 draft-dupont-ikev2-addrmgmt-06.txt (work in progress), 166 October 2004. 168 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 169 Protocol", draft-ietf-ipsec-ikev2-17.txt (work in 170 progress), September 2004. 172 [MOBIKE] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 173 protocol", draft-ietf-mobike-design-02.txt (work in 174 progress), February 2005. 176 [RFC2401bis] 177 Kent, S. and K. Seo, "Security Architecture for the 178 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06.txt 179 (work in progress), March 2005. 181 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 182 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 183 Zhang, L., and V. Paxson, "Stream Control Transmission 184 Protocol", RFC 2960, October 2000. 186 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 187 in IPv6", RFC 3775, June 2004. 189 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 190 Protect Mobile IPv6 Signaling Between Mobile Nodes and 191 Home Agents", RFC 3776, June 2004. 193 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 194 Transport Mode for Dynamic Routing", RFC 3884, 195 September 2004. 197 Author's Address 199 Francis Dupont 200 Point6 201 c/o GET/ENST Bretagne 202 2 rue de la Chataigneraie 203 CS 17607 204 35576 Cesson-Sevigne Cedex 205 France 207 Fax: +33 2 99 12 70 30 208 Email: Francis.Dupont@enst-bretagne.fr 210 Intellectual Property Statement 212 The IETF takes no position regarding the validity or scope of any 213 Intellectual Property Rights or other rights that might be claimed to 214 pertain to the implementation or use of the technology described in 215 this document or the extent to which any license under such rights 216 might or might not be available; nor does it represent that it has 217 made any independent effort to identify any such rights. Information 218 on the procedures with respect to rights in RFC documents can be 219 found in BCP 78 and BCP 79. 221 Copies of IPR disclosures made to the IETF Secretariat and any 222 assurances of licenses to be made available, or the result of an 223 attempt made to obtain a general license or permission for the use of 224 such proprietary rights by implementers or users of this 225 specification can be obtained from the IETF on-line IPR repository at 226 http://www.ietf.org/ipr. 228 The IETF invites any interested party to bring to its attention any 229 copyrights, patents or patent applications, or other proprietary 230 rights that may cover technology that may be required to implement 231 this standard. Please address the information to the IETF at 232 ietf-ipr@ietf.org. 234 Disclaimer of Validity 236 This document and the information contained herein are provided on an 237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 239 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 240 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 241 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 Copyright Statement 246 Copyright (C) The Internet Society (2005). This document is subject 247 to the rights, licenses and restrictions contained in BCP 78, and 248 except as set forth therein, the authors retain all their rights. 250 Acknowledgment 252 Funding for the RFC Editor function is currently provided by the 253 Internet Society.