idnits 2.17.1 draft-haddad-mipshop-netflood-defense-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** 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 and authors 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 (October 20, 2009) is 5292 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 (-13) exists of draft-ietf-mext-rfc3775bis-04 ** Downref: Normative reference to an Informational RFC: RFC 4225 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility for IP (MIPSHOP) W. Haddad 3 Internet-Draft M. Naslund 4 Intended status: Standards Track Ericsson 5 Expires: April 23, 2010 October 20, 2009 7 On Using 'Symbiotic Relationship' to Repel Network Flooding Attack 8 draft-haddad-mipshop-netflood-defense-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "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 at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 23, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo describes a simple defense mechanism against a specific 47 type of network flooding attacks. The suggested mechanism requires a 48 mobile node to establish a 'symbiotic relationship' with the 49 infrastructure, in order to empower it to repel such attack while 50 giving enough insurance to the source(s) of the traffic about the 51 need to cease sending traffic to the targeted network. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions used in this document . . . . . . . . . . . . . . 4 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 5. New Messages and Options . . . . . . . . . . . . . . . . . . . 8 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 Network flooding attacks aim to saturate the targeted network, e.g., 69 the access infrastructure, with junk packets in order to create an 70 environment where all hosts located on a particular link(s) become 71 victims to a denial-of service attack (DoS). 73 As the name suggests, network flooding attacks targets a whole 74 portion of the network infrastructure instead of targeting one 75 particular node (e.g., SYN flooding attack) and thus, can have a more 76 devastating effect. 78 This memo describes a simple defense mechanism against a specific 79 type of network flooding attacks. The suggested mechanism requires a 80 mobile (and potentially multihomed) host to establish a 'symbiotic 81 relationship (SR)' as described in 82 [I-D.haddad-csi-symbiotic-sendproxy], with the network infrastructure 83 in order to empower it to repel such attack. In order to be 84 successful, the defense mechanism described as a "counter attack" 85 mounted by the targeted infrastructure must provide enough insurance 86 to the source(s) of harmful traffic about the need to cease sending 87 packets towards the targeted network. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. Motivation 97 It is safe to assume that any practical defense against network 98 flooding attacks does not need to be motivated! However, we feel 99 important to highlight how such attack can be mounted in a mobile 100 and/or multihomed environment(s) and describe the current defense 101 mechanism and its consequences on the mobile node (MN). 103 A specific type of network flooding attack can be launched from using 104 Mobile IPv6 protocol (described in [I-D.ietf-mext-rfc3775bis]). Such 105 attack is mounted by having the malicious MN attaching to the 106 targeted network then updating each of its correspondent nodes (CNs) 107 about its new care-of address (CoA) by sending binding updates (BU) 108 messages. Once the update(s) is done, each CN is supposed to start 109 re-routing data packets to the MN's new CoA. The next step for the 110 attacker is to detach itself from the foreign link while keeping 111 sending ACK messages to each CN via its home agent (HA). Such step 112 requires the MN to switch to another network or to use another 113 interface in case it is multihomed. However, the impact will be the 114 same on the targeted network in both scenarios, since each CN will 115 keep sending data packets to the MN's CoA as long as it keeps 116 receiving ACK messages and the binding lifetime has not expired (for 117 more details, refer to [RFC4225]). 119 In MIPv6 protocol, the defense against the type of network flooding 120 attack described in the above, is provided by repeating the return 121 routability (RR) procedure every 7 minutes. This means also that 122 even if the MN is not moving, then it has to perform the HoTI/HoT and 123 CoTI/CoT signaling exchange with each correspondent node (CN). It 124 follows that a significant amount of signaling messages can be 125 imposed on the MN in some cases. 127 Enhanced Mobile IPv6 (EMIPv6), described in [RFC4866], introduces a 128 strong optimization to MIPv6 protocol by exploiting the crypto- 129 generated address technique [RFC3972] for the purpose of establishing 130 a long lifetime bidirectional security association (SA) between the 131 MN and the CN. However, while EMIPv6 succeeds in reducing the load 132 of signaling messages, it does not provide strong defense against the 133 type of network flooding attack described earlier. 135 Our main motivation in this document is to provide an efficient and 136 simpler mechanism, which enables the targeted (visited) network to 137 repel network flooding attacks mounted by an attacker using mobility 138 and multihoming protocols. 140 4. Protocol Overview 142 In order to empower the network infrastructure to repel the type of 143 network flooding attack described earlier, the suggested protocol 144 puts a strong -yet neutral in its effect- requirement on any node 145 attaching to the network access infrastructure. The new requirement 146 consists on establishing an SR with any public key(s) advertised by 147 the access router (AR) in the router advertisement (RtAdv) messages. 148 This is motivated by the fact that an AR may or may not be the 149 node(s), which can launch a counter attack to repel the flooding 150 attack. Consequently, the AR has to advertise the public keys of 151 other dedicated node(s), which has this feature. It follows, that a 152 main assumption in our protocol is to have the secure neighbor 153 discovery [RFC3971] protocol deployed in the targeted infrastructure. 154 For simplicity reasons, we assume in the following that the AR is the 155 node able to carry counter attacks if/when needed. This means that 156 no additional public key(s) is advertised in the RtAdv messages. 158 When configuring its IPv6 address, e.g., CoA, the MN MUST establish 159 the SR and sends back the RAN(128) to the AR. The MN SHOULD encrypt 160 the RAN(128) with the AR's public key and the latter SHOULD NOT allow 161 access to any node which does not establish an SR upon attachment to 162 its corresponding link(s). Upon receiving a neighbor discovery 163 message [RFC4861] carrying the SR component, the AR should validate 164 it before storing it in its cache memory. Only after storing the SR 165 in its cache memory and approving it in a signed NDP message, that a 166 MN can trigger the exchange of mobility signaling messages with the 167 CN(s), in order to request re-routing data traffic to its new CoA. 169 Let's assume that after resuming data packets exchange using its new 170 CGA, the MN (being malicious!) decides to mount the same type of 171 network flooding attack against the visited network. This means that 172 once it has synchronized the transmission of ACK messages sent via 173 other paths with data packets rates received from the CNs, it can 174 detach itself from the foreign link and keep sending ACK messages to 175 the CNs at the appropriate frequencies. 177 After leaving the link, the AR will notice at some point (e.g., using 178 NDP messages) that the MN has vanished while data packets are still 179 routed to the MN's CoA. At this stage, the AR MAY decide to act 180 immediately or within a pre-configured time interval. In both 181 scenarios, the AR will launch its counter attack by fetching first 182 all IP source address(es) carried in data packets sent to the MN's 183 CoA, then sending a new mobility message (called "Flush Request 184 (FR)") to each corresponding CN. The FR message MUST carry the MN's 185 CoA together with the SR corresponding "proof of relationship (PoR)" 186 and MUST be signed with the AR's CGA private key. 188 Upon receiving a FR message, the CN validates it by checking first if 189 the CoA is stored in its binding cache entries (BCE) table. Then, it 190 checks in the following order: 192 - the SR PoR 193 - the AR's CGA address 194 - the signature 196 If the FR message is valid, the CN MUST immediately flush out the 197 MN's CoA from its BCE and tear down all ongoing sessions using the 198 MN's IPv6 home address which is bind to the CoA carried in the FR 199 message. Then, the CN SHOULD send a "Flush Acknowledgment (FA)" 200 message to the AR which MUST carry the token and the PoR. Finally, 201 the CN MUST also sign the FA message with its CGA private key. In 202 case any of the above validation steps fail, the CN SHOULD silently 203 discard the message and keeps exchanging data packets with the MN. 205 As mentioned earlier, the AR MUST send a FR message to each CN in 206 order to completely stop the attack. This means that the intensity 207 of the flooding attack should gradually decrease gradually before it 208 comes to a halt. 210 5. New Messages and Options 212 TBD 214 6. Security Considerations 216 This document describes a defense mechanism against a specific type 217 of network flooding attack which can be mounted by one or many 218 malicious node(s) having to attach to the targeted network before 219 triggering the attack. Consequently, the main goal behind this 220 document is to increase the overall network infrastructure security. 221 It should be noted however, that the suggested defense mechanism 222 looses its efficiency when the CN is also involved in the attack. 224 A key feature in our mechanism is the SR between any host and the AR. 225 However, such feature can easily be turned into a denial-of-service 226 (DoS) attack against the host itself in case it accepts to establish 227 an SR with any node whose claimed certificate cannot be verified. It 228 follows that a key requirement is to have SeND deployed in order to 229 protect the link between the AR and the MN. Note that in case the AR 230 gets compromised then it can send at anytime an FR message to the CN 231 to tear down the MN's ongoing session(s). However, such scenario is 232 no different than having the AR dropping data packets sent to the MN. 234 Finally, it should be noted that the AR is not taking any step in 235 order to protect the CN against attacks which aim to exhaust its 236 processing power by flooding it with fake FR messages. In fact, 237 there are three reasons for not imposing a preventive step, e.g., a 238 CoTI/CoT message exchange. First, the CN is able to check the SR 239 before it validates the signature. This means that the CN will drop 240 the message in case the SR is not valid. The second reason is that 241 the RAN(128) parameter is sent in an encrypted form to the AR only. 242 Consequently, prior to sending an FR message, the SR is known only by 243 the MN and its AR. The third one is the fact that after sending a FR 244 message, the MN's CoA won't be used anymore so disclosing it in a FR 245 message should not introduce any new threat against the CN. 247 7. References 249 7.1. Normative References 251 [I-D.ietf-mext-rfc3775bis] 252 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 253 in IPv6", draft-ietf-mext-rfc3775bis-04 (work in 254 progress), July 2009. 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 260 Neighbor Discovery (SEND)", RFC 3971, March 2005. 262 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 263 RFC 3972, March 2005. 265 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 266 Nordmark, "Mobile IP Version 6 Route Optimization Security 267 Design Background", RFC 4225, December 2005. 269 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 270 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 271 September 2007. 273 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 274 Optimization for Mobile IPv6", RFC 4866, May 2007. 276 7.2. Informative References 278 [I-D.haddad-csi-symbiotic-sendproxy] 279 Haddad, W. and M. Naslund, "On Secure Neighbor Discovery 280 Proxying Using 'Symbiotic' Relationship", 281 draft-haddad-csi-symbiotic-sendproxy-01 (work in 282 progress), July 2009. 284 Authors' Addresses 286 Wassim Michel Haddad 287 Ericsson 288 6210 Spine Road 289 Boulder, CO 80301 290 US 292 Phone: +1 303 473 6963 293 Email: Wassim.Haddad@ericsson.com 295 Mats Naslund 296 Ericsson 297 Torshamnsgatan 23 298 SE-164 80 Stockholm 299 Sweden 301 Phone: +46 8 58533739 302 Email: Mats.Naslund@ericsson.com