idnits 2.17.1 draft-dupont-mipv6-3bombing-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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 273. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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 (January 10, 2005) is 7046 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-dupont-mipv6-rrcookie-00 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: July 11, 2005 January 10, 2005 6 A note about 3rd party bombing in Mobile IPv6 7 draft-dupont-mipv6-3bombing-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 July 11, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Mobile IPv6 introduces some new kinds of reflection attacks, as known 43 as 3rd party bombing. This memo analyses these attacks and makes 44 some recommendations: the goal is to avoid anything, including in new 45 optimized mechanisms, which can make the life of bad guys easier. 47 1. Introduction 49 The standard reflection attack is based on the "bombing" of a 3rd 50 party, the victim, by a reflector: 51 - the attacker A sends requests to the reflector R using the address 52 of the victim V as the source address of requests 53 - the reflector R sends (large) answers to V. 54 In the mobile IPv6 [RFC3775] context, the attacker is a mobile node, 55 the reflector a correspondent node (a common one or the home agent). 57 There are two basic defenses against the reflection attack: 58 - ingress filtering [BCP38] (improved in [BCP84]), i.e., checking 59 that source addresses are topologically correct 60 - all protocols which needs some kind of positive feedback from 61 peers, as TCP or RTP/RTCP. 62 As a correspondent node sees two addresses (a transient care-of 63 address and the home address) per mobile node, it is clear that 64 mobile IPv6 can add new opportunities to reflection attacks... 66 2. Analysis 68 There are three different kinds of reflection attacks using mobile 69 IPv6 mechanisms, one for each mode of operation: triangular routing, 70 bidirectional tunneling and routing optimization. 72 Note that the attack is always from the mobile node itself, i.e., no 73 intermediate node can successfully modify packets in transit to 74 launch an attack as in the transient pseudo-nat attack 75 [ID.transient-pseudonat]. 77 At the opposite, a local / visited network access control with an AAA 78 architecture [ID.aaa-mipv6-requirements] or an equivalent can give 79 some real guarantees about a care-of address, i.e., something better 80 than just trusting mobile nodes. 82 The basic argument of this document is the ingress filtering is right 83 defense against reflection attacks and similar threats like address 84 stealing and network bombing. 86 2.1 Triangular routing 88 In this case the mobile node sends packets carrying in the home 89 address option a fake home address. The correspondent node sends 90 back traffic to this home address. In order to avoid a very 91 dangerous attack (bombing traffic has no trace of the attacker) the 92 mobile IPv6 specifications [RFC3775] mandates the verification of 93 home address options: 94 - when a packet with a home address option matches a binding cache 95 entry it is accepted, but routing optimization is active: this 96 case will be analyzed further. 98 - when a proper IPsec security association exists, but in this case 99 the home address is proven. 100 So there is no reflection attack issue with triangular routing. 102 2.2 Bidirectional tunneling 104 This mode is the basic one: all traffic from or to the mobile node 105 goes through a bidirectional tunnel between the mobile node and its 106 home agent. 108 In order to launch a reflection attack the mobile node has to put a 109 fake care-of address in binding updates sent to its home agent (home 110 registrations). The home agent does not perform a routing 111 routability check, i.e., it does not check if the mobile node is 112 really reachable at its current care-of address. This point was 113 discussed (issue 34 [ISSUE34]) by the mobileip working group which 114 decided: 116 "The above mechanisms do not show that the care-of address given in 117 the Binding Update is correct. This opens the possibility for 118 Denial-of-Service attacks against third parties. However, since the 119 mobile node and home agent have a security association, the home 120 agent can always identify an ill-behaving mobile node. This allows 121 the home agent operator to discontinue the mobile node's service, and 122 possibly take further actions based on the business relationship with 123 the mobile node's owner." 125 Note that the registration of a fake care-of address diverts all the 126 traffic to the mobile node via the home agent and at least 40 octets 127 is added to each packet, so for an attacker this attack is more 128 effective than the next one. 130 2.3 Routing optimization 132 The last mode is the routing optimization: binding updates sent by 133 the mobile node create or update binding cache entries on the 134 correspondent node. A routing header of type 2 is added to each 135 packet to the mobile node with its home address, so the extra 136 information uses 24 octets and reveals the home address. 138 The reflection attack in the routing optimization case uses fake 139 care-of addresses in binding updates sent from the mobile node to the 140 correspondent node. Usually the care-of address is in the source 141 address field of the IPv6 header but it can be, with a different 142 value, in an alternate care-of address option too. So the only 143 security issue can come from this option because a fake care-of 144 address in the IPv6 header is not a different case than a fake source 145 address, i.e., the routing optimization does not modify the basic 146 reflection attack. 148 When the return routability procedure is used with an alternate 149 care-of address, it is applied to the right address (issue 5 150 [ISSUE5]). When some other mechanisms is used, usually a longer term 151 one, either a return routability check must be performed, using a 152 third packet (aka a hand-shake) repeating a cookie from the binding 153 acknowledgment [ID.mipv6-rrcookie] or binding updates with different 154 care-of addresses in the IPv6 header and in the alternate care-of 155 address option must be refused. 157 3. Conclusion 159 We recommend that alternative ways to build security associations to 160 protect signaling between mobile and correspondent nodes do not 161 blindly accept "hidden" care-of addresses. As the goal of these ways 162 is to be more efficient than the return routability procedure, IMHO 163 their specifications must forbid alternate care-of address options 164 which carry different addresses than source addresses of IPv6 165 headers. 167 4. Security Considerations 169 This goal of this document is to verify that mobile IPv6 mechanisms 170 cannot be misused to make reflection attacks easier. As the return 171 routability is not considered by many people as very safe or 172 efficient, some new ways to build security associations to protect 173 mobile IPv6 signaling are likely to appear, so they should be 174 carefully designed... 176 5. Acknowledgments 178 Some persons stressed Wassim Haddad to add some defense against 179 reflection attacks to his optimized mobile IPv6 [ID.mipv6-omipv6] 180 when this is both unnecessary and of course against the idea of 181 optimization. 183 Pekka Savola raised our attention about [BCP84] which improved 184 ingress filtering in multi-homed environments. 186 6. References 188 6.1 Normative References 190 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 191 in IPv6", RFC 3775, June 2004. 193 6.2 Informative References 195 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 196 Defeating Denial of Service Attacks which employ IP Source 197 Address Spoofing", RFC 2827, BCP 38, May 2000. 199 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 200 Networks", RFC 3704, BCP 84, March 2004. 202 [ID.aaa-mipv6-requirements] 203 Faccin, S., Le, F., Patil, B., Perkins, C., Dupont, F., 204 Laurent-Maknavicius, M. and J. Bournelle, "Mobile IPv6 205 Authentication, Authorization, and Accounting 206 Requirements", draft-le-aaa-mipv6-requirements-03.txt 207 (work in progress), February 2004. 209 [ID.mipv6-omipv6] 210 Haddad, W., Dupont, F., Madour, L., Krishnan, S. and S. 211 Park, "Optimizing Mobile IPv6 (OMIPv6)", 212 draft-haddad-mipv6-omipv6-01.txt (work in progress), 213 February 2004. 215 [ID.mipv6-rrcookie] 216 Dupont, F. and J-M. Combes, "Care-of Address Test for 217 MIPv6 using a State Cookie", 218 draft-dupont-mipv6-rrcookie-00.txt (work in progress), 219 January 2005. 221 [ID.transient-pseudonat] 222 Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks 223 or how NATs are even more evil than you believed", 224 draft-dupont-transient-pseudonat-04.txt (work in 225 progress), June 2004. 227 [ISSUE34] Yegin, A., Arkko, J. and F. Dupont, "MIPv6 issue 34: CoA 228 test also for home registrations? (Rejected, included in 229 draft 18)", May 2004, 230 . 233 [ISSUE5] Arkko, J., Ed., "MIPv6 issue 5: Alternative-CoA usage 234 rules (Adopted, included in draft 17)", May 2004, 235 . 238 Author's Address 240 Francis Dupont 241 Point6 242 c/o GET/ENST Bretagne 243 2 rue de la Chataigneraie 244 CS 17607 245 35576 Cesson-Sevigne Cedex 246 France 248 Fax: +33 2 99 12 70 30 249 EMail: Francis.Dupont@enst-bretagne.fr 251 Intellectual Property Statement 253 The IETF takes no position regarding the validity or scope of any 254 Intellectual Property Rights or other rights that might be claimed to 255 pertain to the implementation or use of the technology described in 256 this document or the extent to which any license under such rights 257 might or might not be available; nor does it represent that it has 258 made any independent effort to identify any such rights. Information 259 on the procedures with respect to rights in RFC documents can be 260 found in BCP 78 and BCP 79. 262 Copies of IPR disclosures made to the IETF Secretariat and any 263 assurances of licenses to be made available, or the result of an 264 attempt made to obtain a general license or permission for the use of 265 such proprietary rights by implementers or users of this 266 specification can be obtained from the IETF on-line IPR repository at 267 http://www.ietf.org/ipr. 269 The IETF invites any interested party to bring to its attention any 270 copyrights, patents or patent applications, or other proprietary 271 rights that may cover technology that may be required to implement 272 this standard. Please address the information to the IETF at 273 ietf-ipr@ietf.org. 275 Disclaimer of Validity 277 This document and the information contained herein are provided on an 278 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 279 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 280 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 281 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 282 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 283 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 285 Copyright Statement 287 Copyright (C) The Internet Society (2005). This document is subject 288 to the rights, licenses and restrictions contained in BCP 78, and 289 except as set forth therein, the authors retain all their rights. 291 Acknowledgment 293 Funding for the RFC Editor function is currently provided by the 294 Internet Society.