idnits 2.17.1 draft-dupont-mipv6-rrcookie-01.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 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 241. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 23, 2005) is 6880 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-ietf-mip6-cn-ipsec-01 -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Dupont 3 Internet-Draft Point6 4 Expires: December 25, 2005 J-M. Combes 5 France Telecom DR&D 6 June 23, 2005 8 Care-of Address Test for MIPv6 using a State Cookie 9 draft-dupont-mipv6-rrcookie-01.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 25, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines a procedure which performs a "care-of address 43 test" using a state cookie for routing optimization in Mobile IPv6 44 not protected by the routing routability procedure, i.e., protected 45 by some alternative mechanisms like pre-shared secret or pre- 46 established IPsec security associations. 48 1. Introduction 50 The Mobile IPv6 specifications [RFC3775] defines a default protection 51 for routing optimization, the routing routability procedure, which 52 includes an explicit "care-of address test". Alternative protection 53 mechanisms like pre-shared secret [pcfgkbm] or pre-established IPsec 54 security associations [CNIPsec] are more efficient and secure but 55 require in some cases a care-of address test to avoid a "3rd party 56 bombing" vulnerability. 58 This document proposes a care-of address test procedure at the 59 initiative of the correspondent node using a state cookie as in SCTP 60 [RFC2960] or IKEv2 [IKEv2]. 62 2. Keywords 64 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in BCP 14, RFC 2119 67 [RFC2119]. 69 3. A signaling extension for a care-of address test using a state 70 cookie 72 3.1 Applicability 74 The care-of address test procedure defined by this document MAY be 75 used in order to check whether the mobile node can really receive 76 packets sent to the care-of address of a new binding update. It 77 SHOULD NOT be used for entry deletion, i.e., when the care-of address 78 is the home address. It MUST be used for real alternate care-of 79 address, i.e., when the address carried by an alternate care-of 80 address option is not the source address of the IP header nor the 81 home address of the mobile node (following the recommendation of 82 [bombing]). 84 3.2 Protocol 86 The procedure is based on the state cookie idea of SCTP [RFC2960] 87 which can be found again in IKEv2 proposal [IKEv2]. The binding 88 update is in a first time (1) rejected by a binding acknowledgment 89 with a new dedicated status and a cookie option sent to the tested 90 care-of address. Upon the reception (2) of this binding 91 acknowledgment, the mobile node retransmits (3) the binding update 92 with the exact received cookie placed in a cookie option. When the 93 correspondent node receives (4) the augmented binding update, it can 94 check by recomputing the cookie and comparing it to the cookie option 95 data that the binding update is from the same mobile node and for the 96 same care-of address (so it can infer the mobile node is reachable at 97 this care-of address, i.e., a "care-of address test" has been 98 successfully performed). 100 The cookie MUST reflect the mobile node identity or the binding cache 101 entry or an equivalent, and MUST reflect the tested care-of address. 102 It MUST NOT be easy to infer by the mobile node, including with the 103 knowledge of previous cookies from the same node. 105 The last point is what to do waiting the retransmitted and augmented 106 binding update. Possibilities are: 107 - apply the binding update with the new care-of address. It defeats 108 the purpose of the care-of address test so it SHOULD NOT be done, 109 and it MUST NOT be done for a real alternate care-of address. 110 - keep the previous care-of address. As it is not possible to know 111 whether the previous care-of address is still usable, i.e., 112 whether the mobile node is still reachable at this previous 113 care-of address, the default policy SHOULD NOT be to keep the 114 previous care-of address. The correspondent node MAY keep the 115 previous care-of address in special cases where this is known to 116 be the best solution. 117 - temporarily disable the binding cache entry, i.e., by using the 118 home address for communication to the mobile node until another 119 binding update is received. This SHOULD be the default policy. 121 3.3 Cookie Generation Example 123 This method assumes a global secret key is available and uses in 124 sequence: 125 - a 16 bit timestamp of when the cookie is created 126 - the tested care-of address 127 - the truncated HMAC [RFC2104], keyed by a secret key, of the 128 preceding two fields, the home address and the correspondent 129 address. 130 The secret key SHOULD be random or pseudo-random and SHOULD be 131 changed reasonably frequently. The timestamp MAY be used to 132 determine which key was used. The HMAC has to be truncated in order 133 to keep the cookie option length less than the maximum, the higher 96 134 bits of the HMAC should be enough. 136 4. Acknowledgments 138 This document was extracted from [CNIPsec] because what it provides 139 is needed by any alternative to the return routability procedure 140 which has no built-in care-of address test. 142 5. Security Considerations 144 Without a test of the care-of address or an other way to trust it, 145 the care-of address presented by the mobile node can be a fake one 146 and offers a 3rd party bombing attack. 148 Binding updates and acknowledgments are validated using an 149 alternative protection mechanisms so they can't be injected by third 150 parties. The cookie sub-option is small enough to make this 151 procedure a poor candidate for a third party bombing mechanism. 153 6. IANA Considerations 155 This document requires: 156 - a new status for binding acknowledgment. 157 - a new option for mobility messages used in binding update and 158 acknowledgment messages. 160 7. References 162 7.1 Normative References 164 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 165 Hashing for Message Authentication", RFC 2104, March 1997. 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", RFC 2119, BCP 14, March 1997. 170 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 171 in IPv6", RFC 3775, June 2004. 173 7.2 Informative References 175 [CNIPsec] Dupont, F. and J-M. Combes, "Using IPsec between Mobile 176 and Correspondent IPv6 Nodes", 177 draft-ietf-mip6-cn-ipsec-01.txt (work in progress), 178 June 2005. 180 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 181 Protocol", draft-ietf-ipsec-ikev2-17.txt (work in 182 progress), September 2004. 184 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 185 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 186 Zhang, L., and V. Paxson, "Stream Control Transmission 187 Protocol", RFC 2960, October 2000. 189 [bombing] Dupont, F., "A note about 3rd party bombing in Mobile 190 IPv6", draft-dupont-mipv6-3bombing-02.txt (work in 191 progress), June 2005. 193 [pcfgkbm] Perkins, C., "Preconfigured Binding Management Keys for 194 Mobile IPv6", draft-ietf-mip6-precfgkbm-02.txt (work in 195 progress), May 2005. 197 Authors' Addresses 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 Jean-Michel Combes 211 France Telecom DR&D 212 38/40 rue du General Leclerc 213 92794 Issy-les-Moulineaux Cedex 9 214 France 216 Fax: +33 1 45 29 65 19 217 Email: jeanmichel.combes@francetelecom.com 219 Intellectual Property Statement 221 The IETF takes no position regarding the validity or scope of any 222 Intellectual Property Rights or other rights that might be claimed to 223 pertain to the implementation or use of the technology described in 224 this document or the extent to which any license under such rights 225 might or might not be available; nor does it represent that it has 226 made any independent effort to identify any such rights. Information 227 on the procedures with respect to rights in RFC documents can be 228 found in BCP 78 and BCP 79. 230 Copies of IPR disclosures made to the IETF Secretariat and any 231 assurances of licenses to be made available, or the result of an 232 attempt made to obtain a general license or permission for the use of 233 such proprietary rights by implementers or users of this 234 specification can be obtained from the IETF on-line IPR repository at 235 http://www.ietf.org/ipr. 237 The IETF invites any interested party to bring to its attention any 238 copyrights, patents or patent applications, or other proprietary 239 rights that may cover technology that may be required to implement 240 this standard. Please address the information to the IETF at 241 ietf-ipr@ietf.org. 243 Disclaimer of Validity 245 This document and the information contained herein are provided on an 246 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 247 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 248 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 249 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 250 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 253 Copyright Statement 255 Copyright (C) The Internet Society (2005). This document is subject 256 to the rights, licenses and restrictions contained in BCP 78, and 257 except as set forth therein, the authors retain all their rights. 259 Acknowledgment 261 Funding for the RFC Editor function is currently provided by the 262 Internet Society.