idnits 2.17.1 draft-dupont-mipv6-3bombing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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.) ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2004) is 7375 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 (-04) exists of draft-dupont-transient-pseudonat-02 == Outdated reference: A later version (-03) exists of draft-le-aaa-mipv6-requirements-02 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Francis Dupont 2 INTERNET DRAFT GET/ENST Bretagne 3 Expires in August 2004 February 2004 5 A note about 3rd party bombing in Mobile IPv6 7 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "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 29 at http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Abstract 35 Mobile IPv6 [1] introduces some new kinds of reflection attacks, 36 as known as 3rd party bombing. This memo analyses these attacks 37 and makes some recommendations: the goal is to avoid anything, 38 including in new optimized mechanisms, which can make the life 39 of bad guys easier. 41 ^L 43 1. Introduction 45 The standard reflection attack is based on the "bombing" of a 46 3rd party, the victim, by a reflector: 47 - the attacker A sends requests to the reflector R using as 48 its source address in requests the address of the victim V 49 - the reflector R sends (large) answers to V. 50 In the mobile IPv6 context, the attacker is a mobile node, 51 the reflector a correspondent node (common one or the home agent). 53 There are two basic defenses against the reflection attack: 54 - ingress filtering [2], i.e.,checking that source addresses 55 are topologically correct 56 - all protocols which needs some kind of positive feedback from 57 peers, as TCP or RTP/RTCP. 58 As a correspondent node sees two addresses (a transient care-of 59 address and the home address) per mobile node, it is clear that 60 mobile IPv6 can add new opportunities to reflection attacks... 62 2. Analysis 64 There are three different kinds of reflection attacks using 65 mobile IPv6 mechanisms, one for each mode of operation: 66 triangular routing, bidirectional tunneling and routing 67 optimization. 69 Note that the attack is always from the mobile node itself, 70 i.e., no intermediate node can successfully modify packets 71 in transit to launch an attack as in the transient pseudo-nat 72 attack [3]. 74 At the opposite, a local / visited network access control with 75 an AAA architecture [4] or an equivalent can give some real 76 guarantees about a care-of address, i.e., something better than 77 just to trust mobile nodes. 79 2.1 Triangular routing 81 In this case the mobile node sends packets carrying in the 82 home address option a fake home address. The correspondent 83 node sends back traffic to this home address. In order to 84 avoid a very dangerous attack (bombing traffic has no trace 85 of the attacker) the mobile IPv6 specifications [1] mandates 86 the verification of home address options: 87 - when a packet with a home address option matches a binding 88 cache entry it is accepted, but routing optimization is 89 active: this case will be analyzed further. 90 - when a proper IPsec security association exists, but in this 91 case the home address is proven. 92 So there is no reflection attack issue with triangular routing. 94 ^L 96 2.2 Bidirectional tunneling 98 This mode is the basic one: all traffic from or to the mobile 99 node goes through a bidirectional tunnel between the mobile 100 node and its home agent. 102 In order to launch a reflection attack the mobile node has to 103 put a fake care-of address in binding updates sent to its home 104 agent (home registrations). The home agent does not perform 105 a routing routability check, i.e., it does not check if the 106 mobile node is really reachable at its current care-of address. 107 This point was discussed (issue 34 [5]) by the working group 108 which decided: 110 "The above mechanisms do not show that the care-of address 111 given in the Binding Update is correct. This opens the 112 possibility for Denial-of-Service attacks against third 113 parties. However, since the mobile node and home agent 114 have a security association, the home agent can always 115 identify an ill-behaving mobile node. This allows the home 116 agent operator to discontinue the mobile node's service, and 117 possibly take further actions based on the business 118 relationship with the mobile node's owner." 120 Note that the registration of a fake care-of address diverts 121 all the traffic to the mobile node via the home agent and 122 at least 40 octets is added to each packet, so for an attacker 123 this attack is more effective than the next one. 125 2.3 Routing optimization 127 The last mode is the routing optimization: binding updates 128 sent by the mobile node create or update binding cache entries 129 on the correspondent node. A routing header of type 2 is added 130 to each packet to the mobile node with its home address, so 131 the extra information uses 24 octets and reveals the home 132 address. 134 The reflection attack in the routing optimization case uses 135 fake care-of addresses in binding updates sent from the mobile 136 node to the correspondent node. Usually the care-of address 137 is in the source address field of the IPv6 header but it can 138 be, with a different value, in an alternate care-of address 139 option too. So the only security issue can come from this 140 option because a fake care-of address in the IPv6 header is 141 not a different case than a fake source address, i.e., the 142 routing optimization does not modify the basic reflection attack. 144 ^L 145 When the return routability procedure is used with an alternate 146 care-of address, it is applied to the right address (issue 5 [6]). 147 When some other mechanisms is used, usually a longer term one, 148 either a standard return routability check must be specified, 149 using a third packet (aka a hand-shake) repeating a cookie from 150 the binding acknowledgment, or binding updates with different 151 care-of addresses in the IPv6 header and in the alternate care-of 152 address option must be refused. 154 3. Conclusion 156 We recommend that alternative ways to build security associations 157 to protect signaling between mobile and correspondent nodes do not 158 accept "hidden" care-of addresses. As the goal of these ways is 159 to be more efficient than the return routability check, IMHO their 160 specifications must forbid alternate care-of address options which 161 carry different addresses than source addresses of IPv6 headers. 163 4. Security Considerations 165 This goal of this document is to verify that mobile IPv6 mechanisms 166 cannot be misused to make reflection attacks easier. As the return 167 routability is not considered by many people as very safe or 168 efficient, some new ways to build security associations to protect 169 mobile IPv6 signaling are likely to appear, so they should be 170 carefully designed... 172 5. Acknowledgments 174 Some persons stressed Wassim Haddad to add some defense against 175 reflection attacks to his optimized mobile IPv6 [7] when this 176 is both unnecessary and of course against the idea of optimization. 178 6. Normative References 180 [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 181 draft-ietf-mobileip-ipv6-24.txt, June 2003. 183 7. Informative References 185 [2] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating 186 Denial of Service Attacks which employ IP Source Address 187 Spoofing", RFC 2827 / BCP 38, May 2000. 189 [3] F. Dupont, J-J. Bernard, "Transient pseudo-NAT attacks or how 190 NATs are even more evil than you believed", 191 draft-dupont-transient-pseudonat-02.txt, October 2003. 193 ^L 195 [4] F. Le & all, "Mobile IPv6 Authentication, Authorization, and 196 Accounting Requirements", 197 draft-le-aaa-mipv6-requirements-02.txt, April 2003. 199 [5] A. Yegin, J. Arkko, F. Dupont & all, "MIPv6 issue 34: CoA test 200 also for home registrations? (Rejected, included in draft 18)", 201 http://users.piuha.net/jarkko/publications/mipv6/issues/issue34.txt 203 [6] J. Arkko (ed), "MIPv6 issue 5: Alternative-CoA usage rules 204 (Adopted, included in draft 17)", 205 http://users.piuha.net/jarkko/publications/mipv6/issues/issue5.txt 207 [7] W. Haddad, F. Dupont, L. Madour, S. Krishnan, S. D. Park, 208 "Optimizing Mobile IPv6 (OMIPv6)", 209 draft-haddad-mipv6-omipv6-01.txt, February 2004. 211 8. Author's Address 213 Francis Dupont 214 ENST Bretagne 215 Campus de Rennes 216 2, rue de la Chataigneraie 217 CS 17607 218 35576 Cesson-Sevigne Cedex 219 FRANCE 220 Fax: +33 2 99 12 70 30 221 EMail: Francis.Dupont@enst-bretagne.fr