idnits 2.17.1 draft-ietf-itrace-intention-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 379 lines 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 24 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 256: '...unity string. The originating AS MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 325 has weird spacing: '...r scope of...' == Line 326 has weird spacing: '... any intell...' == Line 327 has weird spacing: '... use of the ...' == Line 328 has weird spacing: '... nology descr...' == Line 329 has weird spacing: '...ight or might...' == (18 more instances...) -- 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 (November 2001) is 8197 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft Dan Massey, Allison Mankin 2 Internet Engineering Task Force USC/ISI 3 File: draft-ietf-itrace-intention-00.txt C.L. Wu X.L. Zhao 4 Expires May 2002 NCSU 5 S. Felix Wu, W. Huang 6 UC Davis 7 Lixia Zhang 8 UCLA 9 November 2001 11 Intention-Driven ICMP Trace-Back 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance 17 with all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet 20 Engineering Task Force (IETF), its areas, and its working 21 groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Distribution of this memo is unlimited. 38 This Internet Draft expires January 31, 2002. 40 1. Abstract 42 This draft describe an enhancement over the current iTrace proposal 43 such that we can trace more closely to the DDoS slaves faster. 45 1. Introduction: 47 The probability of iTrace message generation on a particular router in 48 the current internet draft is static and small (about 1 over 20,000 49 packets) such that the overhead introduced by the iTrace messages is 50 small. However, if each DDoS slave produces a relatively small amount 51 of attack traffic, then, it might take a long time for a nearby router 52 to generate a valuable iTrace packet. Statistically, routers closer to 53 the victim will generate "useful" iTrace messages toward the true 54 victim faster than the routers closer to the true slaves. 56 For example, we have one DDoS victim, X and R is one of the router 57 forwarding DDoS traffic toward X. When the router R generates an 58 iTrace message, the iTrace probability 1/20,000 is for all the packets 59 being sent through e[x]. If the packet rate for e[x] is 10,000 packets 60 per second, then, statistically one useful iTrace packet will be 61 generated in about 2 seconds. However, if the packet rate is 100 62 packets per second, then the time will be 200 seconds. If a slave 63 (attacking X) is in the campus of UCDavis, then routers closer to X 64 will statistically generate an iTrace message toward X right after the 65 attack. On the other hand, it will take maybe a few minutes before the 66 victim will see the first iTrace message from the border router of 67 UCDavis. 69 A related problem to the above scenario is that many "useless" iTrace 70 messages might be generated. While it might not be a big problem for a 71 non-victim to receive iTrace messages, resources (CPU cycles, for 72 example) are wasted and the tracing activities toward the true victim 73 are delayed. 75 We propose a mechanism, "intention-driven" iTrace, to enhance the 76 iTrace performance. Our objectives are: 77 (a) With a specified probability, the resources for generating 78 iTrace messages will be spent, more likely, on packets toward DDoS 79 victims. In other words, a selected set of destinations will have 80 more than 1/20,000 probability to get iTrace messages. 81 (b) The total number of iTrace messages generated by each router 82 remains the same. I.e., statistically still 1 over 20,000. 83 (c) The new mechanism is compatible with the current iTrace scheme 84 such that we do not require every router to support the new 85 mechanism. 86 (d) This new mechanism must be scaleable and simple to implement. 88 2. Intention-Driven iTrace: 90 2.1. Prob(iiT-Control): Probabilistic Control of Invoking 91 "Intention" iTrace 93 For each router, a probability Prob(iiT-Control) (probability for 94 intention iTrace) is given. Every time, when a packet is selected, 95 through the standard iTrace scheme (1/20,000 probability), we will 96 flip another random coin, controlled by Prob(iiT-Control), to determine 97 whether this iTrace message should be sent "as it is" or we should invoke 98 the "intention" iTrace mechanism. 100 For example, if Prob(iiT-Control) is 0.5, then 50% of the iTrace messages 101 will be used to handle the "original" iTrace scheme, while the rest will be 102 used for only those who really want to receive iTrace messages. While 103 we dedicate 50% of the iTrace resources for the true victims, we 104 essentially reduce the 1/20,000 iTrace probability to 1/40,000 105 statistically for all the traffic. 107 2.2. iTrace Intention Bit (iiB) and iTrace Execution Bit (ieB) 109 A router conceptually has two tables: routing information table and 110 packet forwarding table. We propose to associate each routing entry 111 with one extra bit called "iTrace intention bit (iiB)", and for each 112 forwarding entry, we introduce a new bit called "iTrace execution bit 113 (ieB)". In a routing table, more than one entries might have "iiB" on, 114 while, in a forwarding table, normally at most one entry can have "ieB" 115 on. However, if the ieB of a particular forwarding table entry is on 116 but no data packets use this entry before the next iTrace trigger, then 117 it is possible to have multiple one's in the forwarding table as well. 119 The "iTrace intention bit (iiB)" will be distributed via routing 120 information protocols such as BGP. If the iiB for a particular route 121 entry is 1, then the network destination under this route entry 122 indicates its desire in receiving iTrace messages. For instance, some 123 of them might be currently under serious DDoS attacks and they have 124 running applications that will utilize the information being carried 125 by iTrace messages. On the other hand, if the iTrace intention bit is 126 0, then it indicates that either the destination's intrusion detection 127 system does not believe that its network is under DDoS attacks or it 128 believes that iTrace messages would not help to handle the attacks it 129 observed. For instance, if an intrusion detection system detects that 130 its network is under reflective DDoS attacks, then the normal (so 131 called) "forward" iTrace messages will not help because iTrace 132 messages will only lead to a hugh number of reflectors, but not to the 133 real DDoS slaves. 135 The "iTrace execution bit (ieB)" indicates that the very next data 136 packet going through that forwarding entry must be iTraced. And, 137 usually, right after this happens, this ieB bit will be cleared. 138 Please note that the iTrace execution bit might be only conceptually 139 associated with the forwarding table. In implementation, this extra 140 bit might be completely outside of the packet forwarding process. 142 3. Packet Forwarding for Intention iTrace 144 In the original iTrace proposal, an iTrace message will be generated 145 with a small probability. When an iTrace message is about to generate 146 but the Prob(iiT-Control) control determines to invoke intention iTrace, 147 instead of sending a normal iTrace message, an "iTrace trigger" will be 148 generated. The frequency of iTrace trigger can happen at most 1/20,000 149 (i.e., if Prob(iiT-Control) is 1.0). 151 Under the intention iTrace, we separate the implementation into two 152 parts: the processing for each incoming data packet and the processing 153 for each iTrace trigger. Please note that it is desirable to have a 154 very efficient per-data packet process, while it is more tolerable to 155 spend more processing time for per-iTrace trigger processing. 157 3.1. Per-Data Packet Processing: 159 When an IP packet arrives, the router will first decide which 160 forwarding entry should be used to forward this packet. If the iTrace 161 execution bit for this route entry is 1, then an iTrace message is 162 generated toward this particular packet. After the iTrace message is 163 sent, the ieB bit for this entry will be set to 0 again. The following 164 is the pseudo code (in C) for this part of processing: 166 int 167 perDataPacketProcess 168 (IP *p) 169 { 170 ForwardEntry *fe = findForwardEntry(p->destinationIPaddr); 171 if (fe == NULL) return -1; 172 if (fe->ieB == 1) 173 { 174 sendiTrace(p); 175 fe->ieB = 0; 176 } 177 regularPacketForwarding(p, fe); 178 return 0; 179 } 181 3.2. Per-iTrace-Trigger Processing: 183 When an iTrace trigger (i.e., a packet has been chosen for the regular 184 iTrace, but the Prob(iiT_Control) control determines to invoke intention 185 iTrace) occurs, instead of directly sending an iTrace message, the router 186 will randomly choose one entry among all the "route" entries (not 187 "forwarding" entries) with the "iTrace intention bit (iiB)" on. This 188 random selection process can be as simple as a random number 189 generation, or a round-robin fashion of selection (maybe based on traffic 190 distribution) to enhance fairness. 192 The result of the selection process is a particular route entry with 193 iiB on. Then, the corresponding forwarding entry will have its ieB set 194 on. The following pseudo code is an "example" of how the selection 195 "might" work: 197 int 198 periTraceTriggerProcess 199 (RouteEntry *RETable) 200 { 201 int i, iiB_count; 202 int iTr_rand; 204 iiB_count = 0; 205 for(i=0; iiiB == 1) 219 { 220 if (iTr_rand == 0) 221 { 222 re->fe->ieB = 1; 223 return 1; 224 } 225 iTr_rand--; 226 } 227 } 228 return -1; 229 } 231 3.3. The iTrace probability attribute 233 Instead of one constant probability, Prob(iiT-Normal), (e.g., 1/20000) 234 in the normal iTrace, two different probability values are defined for 235 intention driven iTrace: Prob(iiT-Intention) and Prob(iiT-Other). To 236 "approximately" obtain these values, we propose the following method: 238 (1). Assume that the traffic ratio for iiT-intention and iiT-other 239 is Ratio(intention) and Ratio(other), respectively. 240 Ratio(intention) + Ratio(other) = 1.0. 242 (2). Prob(iiT-Other) = Prob(iiT-Normal) * (1 - Prob(iiT-Control)) 243 (3). Prob(iiT-Intention) = (Prob(iiT-Noraml) - Ratio(other) * Prob(iiT-Other)) 244 /Ratio(intention) 246 4. How to Distribute the iTrace Intention Value? 248 In this section, we present a way to distribute the Intention value 249 for each router and for each route entry. We propose to have two new BGP 250 community string values for the iTrace intention. 252 BGP community string, an existing BGP attribute, is a 32 bit unsigned 253 integer. We would like to use one value to signal the positive 254 intention to receive iTrace messages. In other words, including 255 this intention commuity string means 1 for iiB. Only the originating 256 AS may set the intention community string. The originating AS MUST 257 apply a local dampening rule to limit the frequency of changes in 258 the intention community string. 260 When a BGP router advertises the reachability of some network address, 261 it will also attach the iTrace intention bit for that network. Therefore, 262 when this BGP update is received by some downstream BGP routers, the 263 intention value of the corresponding route entry will be updated the 264 attached iiB. Furthermore, when BGP updates are aggregated, the iiB 265 will also be aggregated. 267 Therefore, when a particular network is under DDoS attack, the 268 intrusion detection system will inform the BGP router to boost up its 269 iTrace receiving intention. This new iTrace intention bit will be 270 distributed through the whole internet using BGP (or piggyback on BGP 271 updates). 273 The exact value of the new community attribute values will be given 274 in the later version of this draft. 276 5. Evaluation: 278 The proposed scheme will enhance the probability of receiving iTrace 279 messages closer to the DDoS slaves. 281 The new extension is fairly simple to implement (as shown in the 282 pseudo code) and the per-data packet processing overhead is reasonably 283 small - one comparison operation. The memory cost for ieB 284 might be a concern as we conceptually need one bit for each forwarding 285 entry. However, we potentially can implement the same scheme without 286 the requirement of adding one bit to the forwarding table. For 287 example, we can choose a packet to iTrace among a pool of logged 288 packets. The per-iTrace trigger process part is more expensive then 289 the original iTrace proposal. While the overhead here mainly involves 290 a random number generation (hardware can certainly speed up), this 291 process will happen very rarely (e.g., 1 in 20,000 packets at most). 293 Our proposal to distribute the intention values requires a small 294 change to BGP. Furthermore, because of the nature of community string, 295 it is not necessary to have all the routers supporting the new 296 feature. I.e., even if we have sparsely a few new BGP routers 297 supporting intention iTrace, these routers can still utilize the 298 intention bits, while others traditional routers will still pass the 299 intention bits around, Because of BGP route aggregation, our proposal 300 will not increase the number of entries in the routing or forwarding 301 tables. 303 6. Security Consideration: 305 Since our scheme will introduce exactly the same amount of iTrace 306 messages as the original iTrace proposal, our proposal will not 307 introduce any new vulnerability related to denial of service attacks 308 based on the iTrace messages themselves. 310 Since we propose using BGP to distribute the intention values, our 311 scheme is subject to the same security risks as BGP. The risks with 312 respect to intention values would be that an attacker who can 313 tamper with the BGP contents could modify the behavior of itrace to 314 divert itrace away from the attacker's location. 316 With the P_IIT control, destinations without the intention iTrace 317 support can still receive iTrace messages but with a smaller 318 probability such as 1 over 40,000. A malicious destination can 319 distribute positive intention bits to attract more intention iTrace 320 messages, but it still need to compete probabilistically against 321 other DDoS victim over about 50% of the iTrace messages. 323 7. Intellectual Property 325 The IETF takes no position regarding the validity or scope of 326 any intellectual property or other rights that might be 327 claimed to pertain to the implementation or use of the tech- 328 nology described in this document or the extent to which any 329 license under such rights might or might not be available; 330 neither does it represent that it has made any effort to iden- 331 tify any such rights. Information on the IETF's procedures 332 with respect to rights in standards-track and standards- 333 related documentation can be found in BCP-11. 335 Copies of claims of rights made available for publication and 336 any assurances of licenses to be made available, or the result 337 of an attempt made to obtain a general license or permission 338 for the use of such proprietary rights by implementors or 339 users of this specification can be obtained from the IETF Sec- 340 retariat. 342 The IETF invites any interested party to bring to its atten- 343 tion any copyrights, patents or patent applications, or other 344 proprietary rights which may cover technology that may be 345 required to practice this standard. Please address the infor- 346 mation to the IETF Executive Director. 348 8. References 350 [iTrace] S. Bellovin, M. Leech, "ICMP Trace-Back", 351 Internet-Draft, July 2001. 353 9. Acknowledgements 355 Our research is sponsored by DARPA under the fault tolerant 356 networking program. 358 10. Author Information 360 S. Felix Wu 361 Computer Science Department 362 University of California at Davis 363 One Shields Avenue 364 Davis, CA 95616 365 phone: +1 530 754 7070 366 email: wu@cs.ucdavis.edu 368 Lixia Zhang 369 Computer Science Department 370 UCLA 371 Los Angeles, CA 372 phone +310 825 2695 373 email: lixia@cs.ucla.edu 375 Dan Massey 376 USC/ISI 377 4350 N. Fairfax Drive, Suite 620 378 Arlington VA 22203 379 phone +703 812 3731 380 email: masseyd@isi.edu 382 Allison Mankin 383 USC/ISI 384 4350 N. Fairfax Drive, Suite 620 385 Arlington VA 22203 386 phone +703 812 3706 387 email: mankin@isi.edu 389 11. Full Copyright Statement 391 Copyright (C) The Internet Society (2001). All Rights 392 Reserved. 394 This document and translations of it may be copied and fur- 395 nished to others, and derivative works that comment on or oth- 396 erwise explain it or assist in its implementation may be pre- 397 pared, copied, published and distributed, in whole or in part, 398 without restriction of any kind, provided that the above copy- 399 right notice and this paragraph are included on all such 400 copies and derivative works. However, this document itself 401 may not be modified in any way, such as by removing the copy- 402 right notice or references to the Internet Society or other 403 Internet organizations, except as needed for the purpose of 404 developing Internet standards in which case the procedures for 405 copyrights defined in the Internet Standards process must be 406 followed, or as required to translate it into languages other 407 than English. 409 The limited permissions granted above are perpetual and will 410 not be revoked by the Internet Society or its successors or 411 assigns. 413 This document and the information contained herein is provided 414 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 415 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 416 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 417 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 418 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 419 PARTICULAR PURPOSE."