idnits 2.17.1 draft-dupont-mipv6-rrcookie-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 249. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 2, 2008) is 5807 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-ietf-mip6-cn-ipsec-07 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Dupont 3 Internet-Draft ISC 4 Intended status: Experimental J-M. Combes 5 Expires: December 4, 2008 Orange Labs R&D 6 June 2, 2008 8 Care-of Address Test for MIPv6 using a State Cookie 9 draft-dupont-mipv6-rrcookie-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 4, 2008. 36 Abstract 38 This document defines a procedure which performs a "care-of address 39 test" using a state cookie for routing optimization in Mobile IPv6 40 not protected by the routing routability procedure, i.e., protected 41 by some alternative mechanisms like pre-shared secret or pre- 42 established IPsec security associations. 44 1. Introduction 46 The Mobile IPv6 specifications [RFC3775] defines a default protection 47 for routing optimization, the routing routability procedure, which 48 includes an explicit "care-of address test". Alternative protection 49 mechanisms like pre-shared secret [RFC4449] or pre-established IPsec 50 security associations [CNIPsec] are more efficient and secure but 51 require in some cases a care-of address test to avoid a "3rd party 52 bombing" vulnerability. 54 This document proposes a care-of address test procedure at the 55 initiative of the correspondent node using a state cookie as in SCTP 56 [RFC4960] or IKEv2 [RFC4306]. 58 2. Keywords 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 3. A signaling extension for a care-of address test using a state 65 cookie 67 3.1. Applicability 69 The care-of address test procedure defined by this document MAY be 70 used in order to check whether the mobile node can really receive 71 packets sent to the care-of address of a new binding update. It 72 SHOULD NOT be used for entry deletion, i.e., when the care-of address 73 is the home address. It MUST be used for real alternate care-of 74 address, i.e., when the address carried by an alternate care-of 75 address option is not the source address of the IP header nor the 76 home address of the mobile node (following the recommendation of 77 [bombing]). 79 3.2. Protocol 81 The procedure is based on the state cookie idea of SCTP [RFC4960] 82 which can be found again in IKEv2 [RFC4306]. The binding update is 83 in a first time (1) rejected by a binding acknowledgment with a 84 transient error or a new dedicated status, and a cookie option sent 85 to the tested care-of address. Upon the reception (2) of this 86 binding acknowledgment, the mobile node retransmits (3) the binding 87 update with the exact received cookie placed in a cookie option. 88 When the correspondent node receives (4) the augmented binding 89 update, it can check by recomputing the cookie and comparing it to 90 the cookie option data that the binding update is from the same 91 mobile node and for the same care-of address (so it can infer the 92 mobile node is reachable at this care-of address, i.e., a "care-of 93 address test" has been successfully performed). 95 The cookie MUST reflect the mobile node identity or the binding cache 96 entry or an equivalent, and MUST reflect the tested care-of address. 97 It MUST NOT be easy to infer by the mobile node, including with the 98 knowledge of previous cookies from the same node. 100 The last point is what to do waiting the retransmitted and augmented 101 binding update. Possibilities are: 102 - apply the binding update with the new care-of address. It defeats 103 the purpose of the care-of address test so it SHOULD NOT be done, 104 and it MUST NOT be done for a real alternate care-of address. 105 - keep the previous care-of address. As it is not possible to know 106 whether the previous care-of address is still usable, i.e., 107 whether the mobile node is still reachable at this previous 108 care-of address, the default policy SHOULD NOT be to keep the 109 previous care-of address. The correspondent node MAY keep the 110 previous care-of address in special cases where this is known to 111 be the best solution. 112 - temporarily disable the binding cache entry, i.e., by using the 113 home address for communication to the mobile node until another 114 binding update is received. This SHOULD be the default policy. 116 3.3. Mobile Node Requirement 118 There is only one requirement for mobile nodes: a mobile node MUST 119 include in retries a copy of the cookie option carried by a binding 120 acknowledgment signaling a transient error (examples of such a 121 transient error is of course the new status or a sequence number out 122 of window). 124 3.4. Cookie Generation Example 126 This method assumes a global secret key is available and uses in 127 sequence: 128 - a 16 bit timestamp of when the cookie is created 129 - the tested care-of address 130 - the truncated HMAC [RFC2104], keyed by a secret key, of the 131 preceding two fields, the home address and the correspondent 132 address. 133 The secret key SHOULD be random or pseudo-random and SHOULD be 134 changed reasonably frequently. The timestamp MAY be used to 135 determine which key was used. The HMAC has to be truncated in order 136 to keep the cookie option length less than the maximum, the higher 96 137 bits of the HMAC should be enough. 139 4. Acknowledgments 141 This document was extracted from [CNIPsec] because what it provides 142 is needed by any alternative to the return routability procedure 143 which has no built-in care-of address test. 145 5. Security Considerations 147 Without a test of the care-of address or an other way to trust it, 148 the care-of address presented by the mobile node can be a fake one 149 and offers a 3rd party bombing attack. 151 Binding updates and acknowledgments are validated using an 152 alternative protection mechanisms so they can't be injected by third 153 parties. The cookie sub-option is small enough to make this 154 procedure a poor candidate for a third party bombing mechanism. 156 6. IANA Considerations 158 This document requires: 159 - a new status for binding acknowledgment. 160 - a new option for mobility messages used in binding update and 161 acknowledgment messages. 163 7. References 165 7.1. Normative References 167 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 168 Hashing for Message Authentication", RFC 2104, March 1997. 170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 171 Requirement Levels", RFC 2119, BCP 14, March 1997. 173 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 174 in IPv6", RFC 3775, June 2004. 176 7.2. Informative References 178 [CNIPsec] Dupont, F. and J-M. Combes, "Using IPsec between Mobile 179 and Correspondent IPv6 Nodes", 180 draft-ietf-mip6-cn-ipsec-07.txt (work in progress), 181 February 2008. 183 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 184 Protocol", RFC 4306, December 2005. 186 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization 187 Using a Static Shared Key", RFC 4449, June 2006. 189 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 190 RFC 4960, September 2007. 192 [bombing] Dupont, F., "A note about 3rd party bombing in Mobile 193 IPv6", draft-dupont-mipv6-3bombing-05.txt (work in 194 progress), January 2007. 196 Authors' Addresses 198 Francis Dupont 199 ISC 201 Email: Francis.Dupont@fdupont.fr 203 Jean-Michel Combes 204 Orange Labs R&D 205 38 rue du General Leclerc 206 92794 Issy-les-Moulineaux Cedex 9 207 France 209 Email: jeanmichel.combes@gmail.com 211 Full Copyright Statement 213 Copyright (C) The IETF Trust (2008). 215 This document is subject to the rights, licenses and restrictions 216 contained in BCP 78, and except as set forth therein, the authors 217 retain all their rights. 219 This document and the information contained herein are provided on an 220 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 221 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 222 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 223 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 224 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 225 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 227 Intellectual Property 229 The IETF takes no position regarding the validity or scope of any 230 Intellectual Property Rights or other rights that might be claimed to 231 pertain to the implementation or use of the technology described in 232 this document or the extent to which any license under such rights 233 might or might not be available; nor does it represent that it has 234 made any independent effort to identify any such rights. Information 235 on the procedures with respect to rights in RFC documents can be 236 found in BCP 78 and BCP 79. 238 Copies of IPR disclosures made to the IETF Secretariat and any 239 assurances of licenses to be made available, or the result of an 240 attempt made to obtain a general license or permission for the use of 241 such proprietary rights by implementers or users of this 242 specification can be obtained from the IETF on-line IPR repository at 243 http://www.ietf.org/ipr. 245 The IETF invites any interested party to bring to its attention any 246 copyrights, patents or patent applications, or other proprietary 247 rights that may cover technology that may be required to implement 248 this standard. Please address the information to the IETF at 249 ietf-ipr@ietf.org.