idnits 2.17.1 draft-dupont-mipv6-3bombing-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. 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 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 (January 22, 2007) is 6276 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-04 Summary: 3 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 CELAR 4 Expires: July 26, 2007 January 22, 2007 6 A note about 3rd party bombing in Mobile IPv6 7 draft-dupont-mipv6-3bombing-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 26, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 Mobile IPv6 introduces some new kinds of reflection attacks, as known 41 as 3rd party bombing. This memo analyses these attacks and makes 42 some recommendations: the goal is to avoid anything, including in new 43 optimized mechanisms, which can make the life of bad guys easier. 45 1. Introduction 47 The standard reflection attack is based on the "bombing" of a 3rd 48 party, the victim, by a reflector: 49 - the attacker A sends requests to the reflector R using the address 50 of the victim V as the source address of requests 51 - the reflector R sends (large) answers to V. 52 In the mobile IPv6 [RFC3775] context, the attacker is a mobile node, 53 the reflector a correspondent node (a common one or the home agent). 55 There are two basic defenses against the reflection attack: 56 - ingress filtering [BCP38] (improved in [BCP84]), i.e., checking 57 that source addresses are topologically correct 58 - all protocols which needs some kind of positive feedback from 59 peers, as TCP or RTP/RTCP. 60 As a correspondent node sees two addresses (a transient care-of 61 address and the home address) per mobile node, it is clear that 62 mobile IPv6 can add new opportunities to reflection attacks... 64 2. Analysis 66 There are three different kinds of reflection attacks using mobile 67 IPv6 mechanisms, one for each mode of operation: triangular routing, 68 bidirectional tunneling and routing optimization. 70 Note that the attack is always from the mobile node itself, i.e., no 71 intermediate node can successfully modify packets in transit to 72 launch an attack as in the transient pseudo-nat attack 73 [ID.transient-pseudonat]. 75 At the opposite, a local / visited network access control with an AAA 76 architecture [ID.aaa-mipv6-requirements] or an equivalent can give 77 some real guarantees about a care-of address, i.e., something better 78 than just trusting mobile nodes. 80 The basic argument of this document is the ingress filtering is the 81 right defense against reflection attacks and similar threats like 82 address stealing and network bombing. 84 2.1. Triangular routing 86 In this case the mobile node sends packets carrying in the home 87 address option a fake home address. The correspondent node sends 88 back traffic to this home address. In order to avoid a very 89 dangerous attack (bombing traffic with no trace of the attacker) the 90 mobile IPv6 specifications [RFC3775] mandates the verification of 91 home address options: 92 - when a packet with a home address option matches a binding cache 93 entry it is accepted, but routing optimization is active: this 94 case will be analyzed further. 96 - when a proper IPsec security association exists, but in this case 97 the home address is proven. 98 So there is no reflection attack issue with triangular routing. 100 2.2. Bidirectional tunneling 102 This mode is the basic one: all traffic from or to the mobile node 103 goes through a bidirectional tunnel between the mobile node and its 104 home agent. 106 In order to launch a reflection attack the mobile node has to put a 107 fake care-of address in binding updates sent to its home agent (home 108 registrations). The home agent does not perform a routing 109 routability check, i.e., it does not check if the mobile node is 110 really reachable at its current care-of address. This point was 111 discussed (issue 34 [ISSUE34]) by the mobileip working group which 112 decided: 114 "The above mechanisms do not show that the care-of address given in 115 the Binding Update is correct. This opens the possibility for 116 Denial-of-Service attacks against third parties. However, since the 117 mobile node and home agent have a security association, the home 118 agent can always identify an ill-behaving mobile node. This allows 119 the home agent operator to discontinue the mobile node's service, and 120 possibly take further actions based on the business relationship with 121 the mobile node's owner." 123 Note that the registration of a fake care-of address diverts all the 124 traffic to the mobile node via the home agent and at least 40 octets 125 is added to each packet, so for an attacker this attack is more 126 effective than the next one. 128 2.3. Routing optimization 130 The last mode is the routing optimization: binding updates sent by 131 the mobile node create or update binding cache entries on the 132 correspondent node. A routing header of type 2 is added to each 133 packet to the mobile node with its home address, so the extra 134 information uses 24 octets and reveals the home address. 136 The reflection attack in the routing optimization case uses fake 137 care-of addresses in binding updates sent from the mobile node to the 138 correspondent node. Usually the care-of address is in the source 139 address field of the IPv6 header but it can be, with a different 140 value, in an alternate care-of address option too. So the only 141 security issue can come from this option because a fake care-of 142 address in the IPv6 header is not a different case than a fake source 143 address, i.e., the routing optimization does not modify the basic 144 reflection attack. 146 When the return routability procedure is used with an alternate 147 care-of address, it is applied to the right address (issue 5 148 [ISSUE5]). When some other mechanisms is used, usually a longer term 149 one, either a return routability check must be performed, using a 150 third packet (aka a hand-shake) repeating a cookie from the binding 151 acknowledgment [ID.mipv6-rrcookie] or binding updates with different 152 care-of addresses in the IPv6 header and in the alternate care-of 153 address option must be refused. 155 2.4. Home network bombing 157 The last attack uses a fake home address and simulates a "return to 158 the home". Pending traffic is redirected to the the home address and 159 can flood the home network. Further traffic has to be sent from the 160 fake home address so this is the standard reflection attack. 162 3. Current attacks using fake source addresses 164 Reflection attacks are only one kind of attacks based on the use of 165 fake source addresses. Current distributed denials of service (DDoS) 166 use a large number of compromised nodes (BOTs [Botnets]) and do not 167 take advantage of possible amplification by reflection, and this fact 168 should not change in the future. 170 4. Conclusion 172 We recommend that alternative ways to build security associations to 173 protect signaling between mobile and correspondent nodes do not 174 blindly accept "hidden" care-of addresses. As the goal of these ways 175 is to be more efficient than the return routability procedure, IMHO 176 their specifications must either forbid alternate care-of address 177 options which carry different addresses than source addresses of IPv6 178 headers or must provide an explicit counter-measure (like 179 [ID.mipv6-rrcookie]). 181 We recommend to avoid unnecessary return routability checks because: 182 - return routability does not give better assurance than ingress 183 filtering: both check if the source is on the returning path. 184 - return routability is an active device which has a cost in extra 185 messages and delays, ingress filtering is a passive device which 186 can be done at any line speed with hardware support. 187 - if ingress filtering is not applied, the network is open to any 188 attacks based on fake source addresses, including current DDoS 189 which are (as we get the proof everyday) far more then enough to 190 kill a target attached as any speed to the network. 192 5. Security Considerations 194 This goal of this document is to verify that mobile IPv6 mechanisms 195 cannot be misused to make reflection attacks easier. As the return 196 routability procedure [ID.ro-sec] is not considered by many people as 197 very safe or efficient, some new ways to build security associations 198 to protect mobile IPv6 signaling are likely to appear 199 [ID.ro-enhance], so they should be carefully designed... 201 6. Acknowledgments 203 Some persons stressed Wassim Haddad to add some defense against 204 reflection attacks to his optimized mobile IPv6 [ID.mipv6-omipv6] 205 when this is both unnecessary and of course against the idea of 206 optimization. 208 Pekka Savola raised our attention about [BCP84] which improved 209 ingress filtering in multi-homed environments. 211 7. References 213 7.1. Normative References 215 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 216 in IPv6", RFC 3775, June 2004. 218 7.2. Informative References 220 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 221 Defeating Denial of Service Attacks which employ IP Source 222 Address Spoofing", RFC 2827, BCP 38, May 2000. 224 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 225 Networks", RFC 3704, BCP 84, March 2004. 227 [Botnets] Kristoff, J., "Presentation at NANOG 32 on botnets", 228 October 2004, 229 . 231 [ID.aaa-mipv6-requirements] 232 Faccin, S., Le, F., Patil, B., Perkins, C., Dupont, F., 233 Laurent-Maknavicius, M., and J. Bournelle, "Mobile IPv6 234 Authentication, Authorization, and Accounting 235 Requirements", draft-le-aaa-mipv6-requirements-03.txt 236 (work in progress), February 2004. 238 [ID.mipv6-omipv6] 239 Haddad, W., Dupont, F., Madour, L., Krishnan, S., and S. 240 Park, "Optimizing Mobile IPv6 (OMIPv6)", 241 draft-haddad-mipv6-omipv6-01.txt (work in progress), 242 February 2004. 244 [ID.mipv6-rrcookie] 245 Dupont, F. and J-M. Combes, "Care-of Address Test for 246 MIPv6 using a State Cookie", 247 draft-dupont-mipv6-rrcookie-04.txt (work in progress), 248 January 2007. 250 [ID.ro-enhance] 251 Arkko, J. and C. Vogt, "A Taxonomy and Analysis of 252 Enhancements to Mobile IPv6 Route Optimization", 253 draft-irtf-mobopts-ro-enhancements-08.txt (work in 254 progress), May 2006. 256 [ID.ro-sec] 257 Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 258 Nordmark, "Mobile IP version 6 Route Optimization Security 259 Design Background", RFC 4225, December 2005. 261 [ID.transient-pseudonat] 262 Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks 263 or how NATs are even more evil than you believed", 264 draft-dupont-transient-pseudonat-04.txt (work in 265 progress), June 2004. 267 [ISSUE34] Yegin, A., Arkko, J., and F. Dupont, "MIPv6 issue 34: CoA 268 test also for home registrations? (Rejected, included in 269 draft 18)", May 2004, . 272 [ISSUE5] Arkko, J., Ed., "MIPv6 issue 5: Alternative-CoA usage 273 rules (Adopted, included in draft 17)", May 2004, . 277 Author's Address 279 Francis Dupont 280 CELAR 282 Email: Francis.Dupont@fdupont.fr 284 Full Copyright Statement 286 Copyright (C) The IETF Trust (2007). 288 This document is subject to the rights, licenses and restrictions 289 contained in BCP 78, and except as set forth therein, the authors 290 retain all their rights. 292 This document and the information contained herein are provided on an 293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 295 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 296 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 297 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org. 324 Acknowledgment 326 Funding for the RFC Editor function is provided by the IETF 327 Administrative Support Activity (IASA).