idnits 2.17.1 draft-iab-iwout-report-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1999. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 12, 2007) is 6276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Acreo AB 4 Intended status: Informational E. Davies 5 Expires: August 16, 2007 Folly Consulting 6 L. Zhang 7 UCLA 8 February 12, 2007 10 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006 11 draft-iab-iwout-report-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 16, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document reports the outcome of a workshop held by the Internet 45 Architecture Board (IAB) on Unwanted Internet Traffic. The workshop 46 was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. 47 The primary goal of the workshop was to foster interchange between 48 the operator, standards, and research communities on the topic of 49 unwanted traffic, as manifested in, for example, Distributed Denial 50 of Service (DDoS) attacks, spam, and phishing, to gain understandings 51 on the ultimate sources of these unwanted traffic, and to assess 52 their impact and the effectiveness of existing solutions. It was 53 also a goal of the workshop to identify engineering and research 54 topics that could be undertaken by the IAB, the IETF, the IRTF, and 55 the network research and development community at large to develop 56 effective countermeasures against the unwanted traffic. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. The Root of All Evils: An Underground Economy . . . . . . . . 6 62 2.1. The Underground Economy . . . . . . . . . . . . . . . . . 6 63 2.2. Our Enemy Using Our Networks, Our Tools . . . . . . . . . 8 64 2.3. Compromised Systems Being A Major Source of Problems . . . 8 65 2.4. Lack of Meaningful Deterrence . . . . . . . . . . . . . . 10 66 2.5. Consequences . . . . . . . . . . . . . . . . . . . . . . . 11 67 3. How Bad Is The Problem? . . . . . . . . . . . . . . . . . . . 13 68 3.1. Backbone Providers . . . . . . . . . . . . . . . . . . . . 13 69 3.1.1. DDoS Traffic . . . . . . . . . . . . . . . . . . . . . 13 70 3.1.2. Problem Mitigation . . . . . . . . . . . . . . . . . . 13 71 3.2. Access Providers . . . . . . . . . . . . . . . . . . . . . 14 72 3.3. Enterprise Networks: Perspective from a Large 73 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 15 74 3.4. Domain Name Services . . . . . . . . . . . . . . . . . . . 16 75 4. Current Vulnerabilities and Existing Solutions . . . . . . . . 18 76 4.1. Internet Vulnerabilities . . . . . . . . . . . . . . . . . 18 77 4.2. Existing Solutions . . . . . . . . . . . . . . . . . . . . 19 78 4.2.1. Existing Solutions for Backbone Providers . . . . . . 19 79 4.2.2. Existing Solutions for Enterprise Networks . . . . . . 20 80 4.3. Shortfalls in the Existing Network Protection . . . . . . 21 81 4.3.1. Inadequate Tools . . . . . . . . . . . . . . . . . . . 21 82 4.3.2. Inadequate Deployments . . . . . . . . . . . . . . . . 21 83 4.3.3. Inadequate Education . . . . . . . . . . . . . . . . . 21 84 4.3.4. Is Closing Down Open Internet Access Necessary? . . . 22 85 5. Active and Potential Solutions in the Pipeline . . . . . . . . 23 86 5.1. Central Policy Repository . . . . . . . . . . . . . . . . 23 87 5.2. Flow Based Tools . . . . . . . . . . . . . . . . . . . . . 23 88 5.3. Internet Motion Sensor (IMS) . . . . . . . . . . . . . . . 24 89 5.4. BCP38 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 5.5. Layer 5 to 7 Awareness . . . . . . . . . . . . . . . . . . 25 91 5.6. How To's . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5.7. SHRED . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 6. Research in Progress . . . . . . . . . . . . . . . . . . . . . 26 94 6.1. Ongoing Research . . . . . . . . . . . . . . . . . . . . . 26 95 6.1.1. Exploited Hosts . . . . . . . . . . . . . . . . . . . 26 96 6.1.2. Distributed Denial of Service (DDoS) Attacks . . . . . 27 97 6.1.3. Spyware . . . . . . . . . . . . . . . . . . . . . . . 29 98 6.1.4. Forensic Aids . . . . . . . . . . . . . . . . . . . . 29 99 6.1.5. Measurements . . . . . . . . . . . . . . . . . . . . . 29 100 6.1.6. Traffic Analysis . . . . . . . . . . . . . . . . . . . 29 101 6.1.7. Protocol and Software Security . . . . . . . . . . . . 30 102 6.2. Research on the Internet . . . . . . . . . . . . . . . . . 30 103 6.2.1. Research and Standards . . . . . . . . . . . . . . . . 30 104 6.2.2. Research and the Bad Guys . . . . . . . . . . . . . . 31 105 7. Aladdin's Lamp . . . . . . . . . . . . . . . . . . . . . . . . 33 106 7.1. Security Improvements . . . . . . . . . . . . . . . . . . 33 107 7.2. Unwanted Traffic . . . . . . . . . . . . . . . . . . . . . 34 108 8. Workshop Summary . . . . . . . . . . . . . . . . . . . . . . . 35 109 8.1. Hard Questions . . . . . . . . . . . . . . . . . . . . . . 35 110 8.2. Medium or Long Term Steps . . . . . . . . . . . . . . . . 35 111 8.3. Immediately Actionable Steps . . . . . . . . . . . . . . . 36 112 9. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 37 113 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 114 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 43 115 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 116 13. Informative References . . . . . . . . . . . . . . . . . . . . 45 117 Appendix A. Participants in the workshop . . . . . . . . . . . . 46 118 Appendix B. Workshop agenda . . . . . . . . . . . . . . . . . . . 47 119 Appendix C. Slides . . . . . . . . . . . . . . . . . . . . . . . 48 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 121 Intellectual Property and Copyright Statements . . . . . . . . . . 50 123 1. Introduction 125 The Internet carries a lot of unwanted traffic today. To gain a 126 better understanding of the driving forces behind such unwanted 127 traffic and to assess existing countermeasures, the IAB organized an 128 "Unwanted Internet Traffic" Workshop and invited experts on different 129 aspects of unwanted traffic from operator, vendor and the research 130 communities to the workshop. The intention was to share information 131 among people from different fields and organizations, fostering an 132 interchange of experiences, views and ideas between the various 133 communities on this important topic. The major goal of this workshop 134 was to stimulate discussion at a deep technical level to assess 135 today's situation as regards: 137 o the kinds of unwanted traffic that are seen on the Internet, 139 o how bad the picture looks, 141 o who and where are the major sources of the problem, 143 o which solutions work and which do not, and 145 o what needs to be done. 147 The workshop was very successful. Over one and half days of 148 intensive discussions, the major sources of the unwanted traffic were 149 identified, and a critical assessment of the existing mitigation 150 tools was conducted. However due to the limitation of available 151 time, it was impossible to cover the topic of unwanted traffic in its 152 entirety. Thus for some of the important issues, only the surface 153 was touched. Furthermore, because the primary focus of the workshop 154 was to collect and share information on the current state of affairs, 155 it is left as the next step to attempt to derive solutions to the 156 issues identified. This will be done in part as activities within 157 the IAB, the IETF, and the IRTF. 159 During the workshop a number of product and company names were cited, 160 which are reflected in the report to a certain extent. However, a 161 mention of any product in this report should not be taken as an 162 endorsement of that product; there may well be alternative equally 163 relevant or efficacious products in the market place. 165 This report is a summary of the contributions by the workshop 166 participants, and thus it is not an IAB document. The views and 167 positions documented in the report do not necessarily reflect IAB 168 views and positions. 170 The workshop participant list is attached in Appendix A. The agenda 171 of the workshop can be found in Appendix B. Links to a subset of the 172 presentations are provided in Appendix C; the rest of the 173 presentations are of a sensitive nature and it has been agreed that 174 they will not be made public. Definitions of the jargon used in 175 describing unwanted traffic can be found in Section 9. 177 2. The Root of All Evils: An Underground Economy 179 The first important message this workshop would like to bring to the 180 Internet community's attention is the existence of an underground 181 economy. This underground economy provides an enormous amount of 182 monetary fuel that drives the generation of unwanted traffic. This 183 economic incentive feeds on an Internet that is to a large extent 184 wide open. The open nature of the Internet fosters innovations but 185 offers virtually no defense against abuses. It connects to millions 186 of mostly unprotected hosts owned by millions of mostly naive users. 187 These users explore and benefit from the vast opportunities offered 188 by the new cyberspace, with little understanding of its vulnerability 189 to abuse and the potential danger of their computers being 190 compromised. Moreover, the Internet was designed without built-in 191 auditing trails. This was an appropriate choice at the time but now 192 the lack of traceability makes it difficult to track down malicious 193 activities. Combined with a legal system that is yet to adapt to the 194 new challenge of regulating the cyberspace, this means the Internet, 195 as of today, has no effective deterrent to miscreants. The 196 unfettered design and freedom from regulation have contributed to the 197 extraordinary success of the Internet. At the same time, the 198 combination of these factors has also led to an increasing volume of 199 unwanted traffic. The rest of this section provides a more detailed 200 account of each of the above factors. 202 2.1. The Underground Economy 204 As in any economic system, the underground economy is regulated by a 205 demand and supply chain. The underground economy, which began as a 206 barter system, has evolved into a giant shopping mall, commonly 207 running on IRC (Internet Relay Chat) servers. The IRC servers 208 provide various online stores selling information about stolen credit 209 cards and bank accounts, malware, bot code, botnets, root accesses to 210 compromised hosts and web servers, and much more. There are DDoS 211 attack stores, credit card stores, PayPal and bank account stores, as 212 well as Cisco and Juniper router stores which sell access to 213 compromised routers. Although not everything can be found on every 214 server, most common tools used to operate in the underground economy 215 can be found on almost all the servers. 217 How do miscreants turn attack tools and compromised machines into 218 real assets? In the simplest case, miscreants electronically 219 transfer money from stolen bank accounts directly to an account that 220 they control, often in another country. In a more sophisticated 221 example, miscreants use stolen credit cards or PayPal accounts for 222 online purchases. To hide their trails, they often find remailers 223 who receive the purchased goods and then repackage them to send to 224 the miscreants for a fee. The miscreants may also sell the goods 225 through online merchandising sites such as eBay. They request the 226 payments be made in cashier checks or money orders, to be sent to the 227 people who provide money laundering services for the miscreants by 228 receiving the payments and sending them to banks in a different 229 country, again in exchange for a fee. In either case the destination 230 bank accounts are used only for a short period and closed as soon as 231 the money is withdrawn by the miscreants. 233 The miscreants obtain private and financial information from 234 compromised hosts and install bots (a.k.a. zombies) on them. They 235 can also obtain such information from phishing attacks. Spam 236 messages mislead naive users into accessing spoofed web sites run by 237 the miscreants where their financial information is extracted and 238 collected. 240 The miscreants in general are not skilled programmers. With money, 241 however, they can hire professional writers to produce well phrased 242 spam messages, and hire coders to develop new viruses, worms, spyware 243 and botnet control packages, thereby resupplying the underground 244 market with new tools which produce more unwanted traffic on the 245 Internet: spam messages which spread phishing attacks, botnets which 246 are used to launch DDoS attacks, click fraud that "earns" income by 247 deceiving online commercial advertisers, and new viruses and worms 248 which compromise more hosts and steal additional financial 249 information as well as system passwords and personal identity 250 information. 252 The income gained from the above illegal activities allows miscreants 253 to hire spammers, coders, and IRC server providers. Spammers use 254 botnets. Direct marketing companies set up dirty affiliate programs. 255 Some less than scrupulous banks are also involved to earn transaction 256 fees from moving the dirty money around. In the underground market, 257 everything can be traded, and everything has a value. Thus is 258 spawned unwanted traffic of all kinds. 260 The underground economy has evolved very rapidly over the past few 261 years. In the early days of bots and botnets their activities were 262 largely devoted to DDoS attacks and were relatively easy to detect. 263 As the underground economy has evolved so have the botnets. They 264 have moved from easily detectable behavior to masquerading as normal 265 user network activity to achieve their goals, making detection very 266 difficult even by vigilant system administrators. 268 The drive for this rapid evolution comes to a large extent from the 269 change in the intention of miscreant activity. Early virus attacks 270 and botnets were largely anarchic activities. Many were done by 271 "script kiddies" to disrupt systems without a real purpose or to 272 demonstrate the prowess of the attacker, for example in compromising 273 systems that were touted as "secure". Mirroring the 274 commercialization of the Internet and its increasing use for 275 e-business, miscreant activity is now mostly focused on conventional 276 criminal lines. Systems are quietly subverted with the goal of 277 obtaining illicit financial gain in the future, rather than causing 278 visible disruptions as was often the aim of the early hackers. 280 2.2. Our Enemy Using Our Networks, Our Tools 282 Internet Relay Chat (IRC) servers are commonly used as the command & 283 control channel for the underground market. These servers are paid 284 for by miscreants and are professionally supported. They are 285 advertised widely to attract potential consumers, and thus are easy 286 to find. The miscreants first talk to each other on the servers to 287 find out who is offering what on the market, then exchange encrypted 288 private messages to settle the deals. 290 The miscreants are not afraid of network operators seeing their 291 actions. If their activities are interrupted, they simply move to 292 another venue. When ISPs take actions to protect their customers, 293 revenge attacks are uncommon as long as the miscreants' cash flow is 294 not disturbed. When a botnet is taken out, they move on to the next 295 one as there is a plentiful supply. However if an IRC server is 296 taken out which disturbs their cash flow, miscreants can be ruthless 297 and severe attacks may follow. They currently have no fear, as they 298 know the chances of their being caught is minimal. 300 Our enemies make good use of the Internet's global connectivity as 301 well as all the tools the Internet has developed. IRC servers 302 provide a job market for the miscreants and shopping malls of attack 303 tools. Networking research has produced abundant results making it 304 easier to build large scale distributed systems and these have been 305 adopted by miscreants to build large size, well-controlled botnets. 306 Powerful search engines also enable one to quickly find readily 307 available tools and resources. The sophistication of attacks has 308 increased with time, while the skills required to launch effective 309 attacks have become minimal. Attackers can be hiding anywhere in the 310 Internet while attacks get launched on a global scale. 312 2.3. Compromised Systems Being A Major Source of Problems 314 The current Internet provides a field ripe for exploitation. The 315 majority of end hosts run vulnerable platforms. People from all 316 walks of life eagerly jump into the newly discovered online world, 317 yet without the proper training needed to understand the full 318 implications. This is at least partially due to most users failing 319 to anticipate how such a great invention can be readily abused. As a 320 result, the Internet has ended up with a huge number of compromised 321 hosts, without their owners being aware that it has happened. 323 Unprotected hosts can be compromised in multiple ways. Viruses and 324 worms can get into the system through exploiting bugs in the existing 325 operating systems or applications, sometimes even in anti-virus 326 programs. A phishing site may also take the opportunity to install 327 malware on a victim's computer when a user is lured to the site. 328 More recently viruses have also started being propagated through 329 popular peer-to-peer file sharing applications. With multiple 330 channels of propagation, malware has become wide-spread, and infected 331 machines include not only home PCs (although they do represent a 332 large percentage), but also corporate servers, and even government 333 firewalls. 335 News of new exploits of vulnerabilities of Microsoft Windows 336 platforms is all too frequent, which leads to a common perception 337 that the Microsoft Windows platform is a major source of 338 vulnerability. One of the reasons for the frequent vulnerability 339 exploits of the Windows system is its popularity in the market place, 340 thus miscreant's investment in each exploit can gain big returns from 341 infecting millions of machines. As a result, each incident is also 342 likely to make headlines in the news. In reality, all other 343 platforms such as Linux, Solaris, and MAC OS for example, are also 344 vulnerable to compromises. Routers are not exempt from security 345 break-ins either, and using a high-end router as a DoS launchpad can 346 be a lot more effective than using a bundle of home PCs. 348 Quietly subverting large numbers of hosts and making them part of a 349 botnet, while leaving their normal functionality and connectivity 350 essentially unimpaired, is now a major aim of miscreants and it 351 appears that they are being all too successful. Bots and the 352 functions they perform are often hard to detect and most of the time 353 their existence are not known to system operators or owners (hence 354 the alternative name for hosts infected with bots controlled by 355 miscreants - zombies); by the time they are detected it might very 356 well be too late as they have carried out the intended 357 (mal-)function. 359 The existence of a large number of compromised hosts is a 360 particularly challenging problem to the Internet's security. Not 361 only does the stolen financial information lead to enormous economic 362 losses, but also there has been no quick fix to the problem. As 363 noted above, in many cases the owners of the compromised computers 364 are unaware of the problem. Even after being notified, some owners 365 still do not care about fixing the problem as long as their own 366 interest, such as playing online games, is not affected, even though 367 the public interest is endangered --- large botnets can use multi- 368 millions of such compromised hosts to launch DDoS attacks, with each 369 host sending an insignificant amount of traffic but the aggregate 370 exceeding the capacity of the best engineered systems. 372 2.4. Lack of Meaningful Deterrence 374 One of the Internet's big strengths is its ability to provide 375 seamless interconnection among an effectively unlimited number of 376 parties. However the other side of the same coin is that there may 377 not be clear ways to assign responsibilities when something goes 378 wrong. Taking DDoS attacks as an example, an attack is normally 379 launched from a large number of compromised hosts, the attack traffic 380 travels across the Internet backbone to the access network(s) linking 381 to the victims. As one can see there are a number of independent 382 stake-holders involved, and it is not immediately clear which party 383 should take responsibility for resolving the problem. 385 Furthermore, tracking down an attack is an extremely difficult task. 386 The Internet architecture enables any IP host to communicate with any 387 other hosts, and it provides no audit trails. As a result, not only 388 is there no limit to what a host may do, but also there is no trace 389 after the event of what a host may have done. At this time there is 390 virtually no effective tool available for problem diagnosis or packet 391 trace back. Thus tracking down an attack is labor intensive and 392 requires sophisticated skills. As will be mentioned in the next 393 section, there is also a lack of incentive to report security 394 attacks. Compounded with the high cost, these factors make forensic 395 tracing of an attack to its root a rare event. 397 In human society the legal systems provide protection against 398 criminals. However in the cyberspace the legal systems are lagging 399 behind in establishing regulations. The laws and regulations aim at 400 penalizing the conduct after the fact. If the likelihood of 401 detection is low, the deterrence would be minimal. Many national 402 jurisdictions have regulations about acts of computer fraud and 403 abuse, and they often carry significant criminal penalties. In the 404 US (and many other places) it is illegal to access government 405 computers without authorization, illegal to damage protected 406 government computers, and illegal to access confidential information 407 on protected computers. However the definition of "access" can be 408 difficult to ascertain. For example, is sending an ICMP (Internet 409 Control Messaging Protocol) packet to a protected computer considered 410 illegal access? There is a lack of technical understanding among 411 lawmakers that would be needed to specify the laws precisely and 412 provide effective targeting limited to undesirable acts. Computer 413 fraud and liabilities laws provide a forum to address illegal access 414 activities and enable prosecution of cybercriminals. However one 415 difficulty in prosecuting affiliate programs using bot infrastructure 416 is that they are either borderline legal, or there is little 417 evidence. There is also the mentality of taking legal action only 418 when the measurable monetary damage exceeds a high threshold, while 419 it is often difficult to quantify the monetary damage in individual 420 cases of cyberspace crimes. 422 There is a coalition between countries on collecting cybercriminal 423 evidence across the world, but there is no rigorous way to trace 424 across borders. Laws and rules are mostly local to a country, 425 policies (when they exist) are mostly enacted and enforced locally, 426 while the Internet itself, that carries the unwanted traffic, 427 respects no borders. One estimate suggests that most players in the 428 underground economy are outside the US, yet most IRC servers 429 providing the underground market may be running in US network 430 providers, enjoying the reliable service and wide connectivity to the 431 rest of the world provided by the networks. 433 In addition, the definition of "unwanted" traffic also varies between 434 different countries. For example, China bans certain types of 435 network traffic that are considered legitimate elsewhere. Yet 436 another major difficulty is the trade-off and blurred line between 437 having audit trails to facilitate forensic analysis and to enforce 438 censorship. The greater ability we build into the network to control 439 traffic, the stronger would be the monitoring requirements coming 440 from the legislators. 442 It should be emphasized that, while a legal system is necessary to 443 create effective deterrence and sanctions against miscreants, it is 444 by no means sufficient on its own. Rather it must be accompanied by 445 technical solutions to unwanted traffic detection and damage 446 recovery. It is also by no means a substitute for user education. 447 Only a well informed user community can collectively establish an 448 effective defense in the cyberspace. 450 2.5. Consequences 452 What we have today is not a rosy picture: there are 454 o big economic incentives and a rich environment to exploit, 456 o no specific party to carry responsibility, 458 o no auditing system to trace back to the sources of attacks, and 460 o no well established legal regulations to punish offenders. 462 The combination of these factors inevitably leads to ever increasing 463 types and volume of unwanted traffic. However our real threats are 464 not the bots or DDoS attacks, but the criminals behind them. 466 Unwanted traffic is no longer only aiming for maximal disruption; in 467 many cases it is now a means to illicit ends with the specific 468 purpose of generating financial gains for the miscreants. Their 469 crimes cause huge economic losses, counted in multiple billions of 470 dollars and continuing. 472 3. How Bad Is The Problem? 474 There are quite a number of different kinds of unwanted traffic on 475 the Internet today; the discussions at this workshop were mainly 476 around DDoS traffic and spam. The impact of DDoS and spam on 477 different parts of the network differs. Below we summarize the 478 impact on backbone providers, access providers, and enterprise 479 customers, respectively. 481 3.1. Backbone Providers 483 Since backbone providers' main line of business is packet forwarding, 484 the impact of unwanted traffic is mainly measured by whether DDoS 485 traffic affects network availability. Spam or malware is not a major 486 concern because backbone networks do not directly support end users. 487 Router compromises may exist but they are rare events at this time. 489 3.1.1. DDoS Traffic 491 Observation shows that, in majority of DDoS attacks, attack traffic 492 can originate from almost anywhere in the Internet. In particular, 493 those regions with high speed user connectivity but poorly managed 494 end hosts are often the originating sites of DDoS attacks. The 495 miscreants tend to find targets that offer maximal returns with 496 minimal efforts. 498 Backbone networks in general are well-provisioned in regard to 499 traffic capacities. Therefore core routers and backbone link 500 capacity do not get affected much by most DDoS attacks; a 5Gbps 501 attack could be easily absorbed without causing noticeable impact on 502 the performance of backbone networks. However DDoS attacks often 503 saturate access networks and make a significant impact on customers. 504 In particular, multihomed customers who have multiple well- 505 provisioned connections for high throughput and performance may 506 suffer from aggregated DDoS traffic coming in from all directions. 508 3.1.2. Problem Mitigation 510 Currently backbone networks do not have effective diagnosis or 511 mitigation tools against DDoS attacks. The foremost problem is a 512 lack of incentives to deploy security solutions. Because IP transit 513 services are a commodity, controlling cost is essential to surviving 514 the competition. Thus any expenditure tends to require clearly 515 identified return-on-investment (ROI). Even when new security 516 solutions become available, providers do not necessarily upgrade 517 their infrastructure to deploy the solutions, as security solutions 518 are often prevention mechanisms which may not have an easily 519 quantifiable ROI. To survive in the competitive environment in which 520 they find themselves, backbone providers also try to recruit more 521 customers. Thus a provider's reputation is important. Due to the 522 large number of attacks and inadequate security solution deployment, 523 effective attacks and security glitches can be expected. However it 524 is not in a provider's best interest to report all the observed 525 attacks. Instead the provider's first concern is to minimize the 526 number of publicized security incidents. For example a "trouble 527 ticket" acknowledging the problem is issued only after a customer 528 complains. An informal estimate suggested that only about 10% of 529 DDoS attacks are actually reported (some other estimates have put the 530 figure as low as 2%). In short, there is a lack of incentives to 531 either report problems or deploy solutions. 533 Partly as a consequence of the lack of incentive and lack of funding, 534 there exist few DDoS mitigation tools for backbone providers. 535 Network operators often work on their own time to fight the battle 536 against malicious attacks. Their primary mitigation tools today are 537 Access Control Lists (ACL) and BGP (Border Gateway Protocol) null 538 routes to black-hole unwanted traffic. These tools can be turned on 539 locally and do not require coordination across administrative 540 domains. When done at, or near, DDoS victims, these simple tools can 541 have an immediate effect to reduce the DDoS traffic volume. However 542 these tools are rather rudimentary and inadequate, as we will 543 elaborate in Section 4.2.1. 545 3.2. Access Providers 547 A common issue that access providers share with backbone providers is 548 the lack of incentive, and the shortage of funding, needed to deploy 549 security solutions. As with the situation with security incidents on 550 the backbone, the number of security incidents reported by access 551 providers is estimated to be significantly lower than the number of 552 the actual incidents that occurred. 554 Because access providers are directly connected to end customers, 555 they also face unique problems of their own. From the access 556 providers' viewpoint, the most severe impact of unwanted traffic is 557 not the bandwidth exhaustion, but the customer support load it 558 engenders. The primary impact of unwanted traffic is on end users, 559 and access providers must respond to incident reports from their 560 customers. Today access providers are playing the role of IT help 561 desk for many of their customers, especially residential users. 562 According to some access providers, during the Microsoft Blaster worm 563 attack, the average time taken to handle a customer call was over an 564 hour. Due to the high cost of staffing the help desks, it is 565 believed that, if a customer calls the help desk just once, the 566 provider would lose the profit they would otherwise have made over 567 the lifetime of that customer account. 569 To reduce the high customer service cost caused by security breaches, 570 most access providers offer free security software to their 571 customers. It is much cheaper to give the customer "free" security 572 software in the hope of preventing system compromises than handling 573 the system break-ins after the event. However, perhaps due to their 574 lack of understanding of the possible security problems they may 575 face, many customers fail to install security software despite the 576 free offer from their access providers, or even when they do, they 577 may lack the skill needed to configure a complex system correctly. 579 What factors may influence how quickly customers get the security 580 breaches fixed? Past experience suggests the following observations: 582 o Notification has little impact on end user repair behavior. 584 o There is no significant difference in terms of repair behavior 585 between different industries or between business and home users. 587 o Users' patching behavior follows an exponential decay pattern with 588 a time constant of approximately 40% per month. Thus about 40% of 589 computers tend to be patched very quickly when a patch is 590 released, and approximately 40% of the remaining vulnerable 591 computers in each following month will show signs of being 592 patched. This leaves a few percent still unpatched after 6 593 months. In the very large population of Internet hosts this 594 results in a significant number of hosts that will be vulnerable 595 for the rest of their life. 597 o There is a general lack of user understanding: after being 598 compromised, unmanaged computers may get replaced rather than 599 repaired, and this often results in infections occurring during 600 the installation process on the replacement. 602 3.3. Enterprise Networks: Perspective from a Large Enterprise 604 The operators of one big enterprise network reported to the workshop 605 their experience regarding unwanted traffic. Enterprises perceive 606 many forms of bad traffic including worms, malware, spam, spyware, 607 Instant Messaging (IM), peer-to-peer (P2P) traffic, and DoS. 608 Compared to backbone and access providers, enterprise network 609 operators are more willing to investigate security breaches, although 610 they may hesitate to pay a high price for security solutions. False 611 positives are very costly. Most operators prefer false negative to 612 false positive. In general enterprises prefer prevention solutions 613 to detection solutions. 615 Deliberately created unwanted traffic (as opposed to unwanted traffic 616 that might arise from misconfiguration) in enterprise networks can be 617 sorted into three categories. The first is "Nuisance", which 618 includes unwanted traffic such as spam and peer-to-peer file sharing. 619 Although there were different opinions among the workshop 620 participants as to whether P2P traffic should, or should not, be 621 considered as unwanted traffic, enterprise network operators are 622 concerned not only that P2P traffic represents a significant share of 623 the total network load, but are also sensitive to potential copyright 624 infringement issues which might lead to significant financial and 625 legal impacts on the company as a whole. In addition, P2P file 626 sharing applications have also became a popular channel for malware 627 propagation. 629 The second category of unwanted traffic is labeled "Malicious", which 630 includes the traffic that spreads malware. This class of traffic can 631 be small in volume but the cost from the resulting damage can be 632 high. The clean up after an incident also requires highly skilled 633 operators. 635 The third category of unwanted traffic is "Unknown": it is known that 636 there exists a class of traffic in the network that can be best 637 described in this way as no one knows its purpose or locations of the 638 sources. Malicious traffic can be obscured by encryption, 639 encapsulation, or covered up as legitimate traffic. The existing 640 detection tools are ineffective for this type of traffic. Noisy 641 worms are easy to identify, but stealth worms can open a backdoor on 642 hosts and stay dormant for a long time without causing any noticeable 643 detrimental effect. This type of bad traffic has the potential to 644 make the greatest impact on an enterprise from a threat perspective. 646 There are more mitigation tools available for enterprise networks 647 than for backbone and access network providers; one explanation might 648 be the greater affordability of solutions for enterprise networks. 649 The costs of damage from a security breach can also have a very 650 significant impact on the profits of an enterprise. At the same 651 time, however, the workshop participants also expressed concerns 652 regarding the ongoing arms race between security exploits and 653 patching solutions. Up to now security efforts have, by and large, 654 been reactive, creating a chain of security exploits and a consequent 655 stream of "fixes". Such a reactive mode has not only created a big 656 security market, but also does not enable us to get ahead of 657 attackers. 659 3.4. Domain Name Services 661 Different from backbone and access providers, there also exists a 662 class of Internet service infrastructure providers. Provision of 663 Domain Name System (DNS) services offers an example here. As 664 reported by operators from a major DNS hosting company, over time 665 there have been increasingly significant DDoS attacks on .com, .net 666 and root servers. 668 DNS service operators have witnessed large scale DDoS attacks. The 669 most recent ones include reflection attacks resulting from queries 670 using spoofed source addresses. The major damage caused by these 671 attacks are bandwidth and resource exhaustion, which led to 672 disruption of critical services. The peak rate of daily DNS 673 transactions has been growing at a much faster rate than the number 674 of Internet users, and this trend is expected to continue. The heavy 675 load on the DNS servers has led to increasing complexity in providing 676 the services. 678 In addition to intentional DDoS Attacks, some other causes of the 679 heavy DNS load included (1) well known bugs in a small number of DNS 680 servers which still run an old version of the BIND software, causing 681 significant load increase at top level servers; and (2) 682 inappropriately configured firewalls that allow DNS queries to come 683 out but block returning DNS replies, resulting in big adverse impacts 684 on the overall system. Most of such issues have been addressed in 685 the DNS operational guidelines drafted by the IETF DNS Operations 686 Working Group, however many DNS operators have not taken appropriate 687 actions accordingly. 689 At this time, the only effective and viable mitigation approach is 690 over-engineering the DNS service infrastructure by increasing link 691 bandwidth, number of servers and server processing power, as well as 692 deploying network anycast. There is a concern about whether the 693 safety margin gained from over-engineering is, or is not, adequate in 694 sustaining DNS services over future attacks. Looking forward, there 695 are also a few new issues looming ahead. Two imminent ones are the 696 expected widespread deployment of IPv6 whose new DNS software would 697 inevitably contain new bugs, and the DNS Security Extensions (DNSSEC) 698 which could potentially be abused to generate DDoS attacks. 700 4. Current Vulnerabilities and Existing Solutions 702 This section summarizes three aspects of the workshop discussions. 703 We first collected the major vulnerabilities mentioned in the 704 workshop, then made a summary of the existing solutions, and followed 705 up with an examination of the effectiveness, or lack of it, of the 706 existing solutions. 708 4.1. Internet Vulnerabilities 710 Below is a list of known Internet vulnerabilities and issues around 711 unwanted traffic. 713 o Packet source address spoofing: there has been speculation that 714 attacks using spoofed source addresses are decreasing, due to the 715 proliferation of botnets which can be used to launch various 716 attacks without using spoofed source addresses. It is certainly 717 true that not all the attacks use spoofed addresses, however many 718 attacks, especially reflection attacks, do use spoofed source 719 addresses. 721 o BGP route hijacking: in a survey conducted by Arbor Networks, 722 route hijacking together with source address spoofing are listed 723 as the two most critical vulnerabilities on the Internet. It has 724 been observed that miscreants hijack bogon prefixes for spam 725 message injections. Such hijacks do not affect normal packet 726 delivery and thus have a low chance of being noticed. 728 o Everything over HTTP: port scan attacks occur frequently in 729 today's Internet, looking for open TCP or UDP ports through which 730 to gain access to computers. The reaction from computer system 731 management has been to close down all the unused ports, especially 732 in firewalls. One result of this reaction is that application 733 designers have moved to transporting all data communications over 734 HTTP to avoid firewall traversal issues. Transporting "everything 735 over HTTP" does not block attacks but has simply moved the 736 vulnerability from one place to another. 738 o Everyone comes from Everywhere: in the earlier life of the 739 Internet it had been possible to get some indication of the 740 authenticity of traffic from a specific sender based for example 741 on the Time To Live (TTL). The TTL would stay almost constant 742 when traffic from a certain sender to a specific host entered an 743 operators network, since the sender will "always" set the TTL to 744 same value. If a change in the TTL value occurred, without an 745 accompanying change in the routing, one could draw the conclusion 746 that this was potential unwanted traffic. However, since hosts 747 have become mobile, they may be roaming within an operator's 748 network and the resulting path changes may be put more (or less) 749 hops between the source and the destination. Thus it is no longer 750 possible to interpret a change in the TTL value, even if it occurs 751 without any corresponding change in routing, as an indication that 752 the traffic has been subverted. 754 o Complex Network Authentication: Network authentication as it is 755 used today is far too complex to be feasible for users to use 756 effectively. It will also be difficult to make it work with new 757 wireless access technologies. 759 A possible scenario envisages a customers handset that is 760 initially on a corporate wireless network. If that customer 761 steps out of the corporate building the handset may get 762 connected to the corporate network through a GPRS network. The 763 handset may then roam to a wireless LAN network when the user 764 enters a public area with a hotspot. Consequently we need 765 authentication tools for cases when the underlying data link 766 layer technology changes quickly, possibly during a single 767 application session. 769 o Unused Security Tools: Vendors and standards have produced quite a 770 number of useful security tools; however not all, even most, of 771 them get used extensively. 773 4.2. Existing Solutions 775 4.2.1. Existing Solutions for Backbone Providers 777 Several engineering solutions exist that operators can deploy to 778 defend the network against unwanted traffic. Adequate provisioning 779 is one commonly used approach that can diminish the impact of DDoS on 780 the Internet backbone. The solution that received most mentions at 781 the workshop was BCP38 on ingress filtering: universal deployment of 782 BCP38 can effectively block DDoS attacks using spoofed source IP 783 addresses. At present Access Control List (ACL) and BGP null routing 784 are the two tools most commonly used by network operators to mitigate 785 DDoS attacks. They are effective in blocking DDoS attacks, 786 especially when being applied at or near a victim's site. 788 Unfortunately BCP38 is not widely deployed today. BCP38 may require 789 device upgrades, and is considered tedious to configure and maintain. 790 Although widespread deployment of BCP38 could benefit the Internet as 791 a whole, deployment by individual sites imposes a certain amount of 792 cost to the site, and does not provide a direct and tangible benefit 793 in return. In other words, BCP38 suffers from a lack of deployment 794 incentives. 796 Both BGP null routing and ACL have the drawback of relying on manual 797 configuration and thus are labor intensive. In addition, they also 798 suffer from blocking both attack and legitimate packets. There is 799 also a potential that some tools could back-fire, e.g., an overly 800 long ACL list might significantly slow down packet forwarding in a 801 router. 803 Unicast Reverse Path Filtering (uRPF), which is available on some 804 routers, provides a means of implementing a restricted form of BCP38 805 ingress filtering without the effort of maintaining ACLs. uRPF uses 806 the routing table to check that a valid path back to the source 807 exists. However its effectiveness depends on the specificity of the 808 routes against which source addresses are compared. The prevalence 809 of asymmetric routing means that the strict uRPF test (where the 810 route to the source must leave from the same interface on which the 811 packet being tested arrived) may have to be replaced by the loose 812 uRPF test (where the route may leave from any interface). The loose 813 uRPF test is not a guarantee against all cases of address spoofing, 814 and it may still be necessary to maintain an ACL to deal with 815 exceptions. 817 4.2.2. Existing Solutions for Enterprise Networks 819 A wide variety of commercial products is available for enterprise 820 network protection. Three popular types of protection mechanisms are 822 o Firewalls: firewalls are perhaps the most widely deployed 823 protection products. However the effectiveness of firewalls in 824 protecting enterprise confidential information can be weakened by 825 spyware installed internally and they are ineffective against 826 attacks carried out from inside the perimeter established by the 827 firewalls. Too often spyware installation is a byproduct of 828 installing other applications permitted by end users. 830 o Application level gateways: these are becoming more widely used. 831 However because they require application-specific support, and in 832 many cases caching all the in-flight documents, configuration can 833 be difficult and the costs high. Thus enterprise network 834 operators prefer network level protections over layer-7 solutions. 836 o Anti-spam software: Anti-spam measures consume significant human 837 resources. Current spam mitigation tools include blacklists and 838 content filters. The more recent "learning" filters may help 839 significantly reduce the human effort needed and decrease the 840 number of both false positives and negatives. 842 A more recent development is computer admission control, where a 843 computer is granted network access if and only if it belongs to a 844 valid user and appears to have the most recent set of security 845 patches installed. It is however a more expensive solution. A major 846 remaining issue facing enterprise network operators is how to solve 847 the user vulnerability problem and reduce reliance on user's 848 understanding of the need for security maintenance. 850 4.3. Shortfalls in the Existing Network Protection 852 4.3.1. Inadequate Tools 854 Generally speaking network and service operators do not have adequate 855 tools for network problem diagnosis. The current approaches largely 856 rely on the experience and skills of the operators, and on time- 857 consuming manual operations. The same is true for mitigation tools 858 against attacks. 860 4.3.2. Inadequate Deployments 862 The limited number of existing Internet protection measures have not 863 been widely deployed. Deployment of security solutions requires 864 resources which may not be available. It also requires education 865 among the operational community to recognize the critical importance 866 of patch installation and software upgrades; for example a bug in the 867 BIND packet was discovered and fixed in 2003, yet a number of DNS 868 servers still run the old software today. Perhaps most importantly, 869 a security solution must be designed with the right incentives to 870 promote their deployment. Effective protection also requires 871 coordination between competing network providers. For the time 872 being, it is often difficult to even find the contact information for 873 operators of other networks. 875 A number of workshop participants shared the view that, if all the 876 known engineering approaches and bug fixes were universally deployed, 877 the Internet could have been enjoying a substantially reduced number 878 of security problems today. In particular, the need for, and lack 879 of, BCP38 deployment was mentioned numerous times during the 880 workshop. There is also a lack of enthusiasm about the routing 881 security requirements document being developed by the IETF RPSEC 882 (Routing Protocol Security) Working Group, which focuses heavily on 883 cryptographically-based protection requirements. Not only would 884 cryptographically-based solutions face the obstacle of funding for 885 deployment, but also they are likely to bring with them their own set 886 of problems. 888 4.3.3. Inadequate Education 890 There exists an educational challenge to disseminate the knowledge 891 needed for secure Internet usage and operations. Easily guessed 892 passwords and plain text password transmission are still common in 893 many parts of the Internet. One common rumor claims that Cisco 894 routers were shipped with a default password "cisco" and this was 895 used by attackers to break into routers. In reality operators often 896 configure Cisco routers with that password, perhaps because of the 897 difficulty of disseminating passwords to multiple maintainers. A 898 similar problem exists for Juniper routers and other vendors' 899 products. 901 How to provide effective education to the Internet user community at 902 large remains a great challenge. As mentioned earlier in this 903 report, the existence of a large number of compromised hosts is one 904 major source of the unwanted traffic problem, and the ultimate 905 solution to this problem is a well-informed, vigilant user community. 907 4.3.4. Is Closing Down Open Internet Access Necessary? 909 One position made at the workshop is that, facing the problems of 910 millions of vulnerable computers and lack of effective deterrence, 911 protecting the Internet might require a fundamental change to the 912 current Internet architecture, by replacing unconstrained open access 913 to the Internet with strictly controlled access. Although the 914 participants held different positions on this issue, a rough 915 consensus was reached that, considering the overall picture, 916 enforcing controlled access does not seem the best solution to 917 Internet protection. Instead the workshop identified a number of 918 needs that should be satisfied to move towards a well protected 919 Internet: 921 o the need for risk assessment for service providers; at this time 922 we lack a commonly agreed bar for security assurance; 924 o the need to add traceability to allow tracking of abnormal 925 behavior in the network, and 927 o the need for liability if someone fails to follow recommended 928 practices. 930 Adding traceability has been difficult due to the distributed nature 931 of the Internet. Collaboration among operators is a necessity in 932 fighting cybercrimes. We must also pay attention to preparation for 933 the next cycle of miscreant activity, and not devote all our efforts 934 to fixing up the existing problems. As discussed above, the current 935 reactive approach to security problems is not a winning strategy. 937 5. Active and Potential Solutions in the Pipeline 939 This section addresses the issues that vendors recognized as 940 important and for which there will be solutions available in the near 941 future. 943 There are a number of potential solutions that vendors are working 944 on, but are not yet offering as part of their product portfolio, that 945 will allegedly remedy or diagnose the problems described in 946 Section 4.1. 948 Inevitably, when vendors have or are about to take a decision on 949 implementing new features in their products but have not made any 950 announcement, the vendors are not willing to talk about the new 951 features openly, which limits what can be said in this section. 953 5.1. Central Policy Repository 955 One idea is to build a Central Policy Repository that holds policies 956 that are known to work properly, e.g., policies controlling from whom 957 one would accept traffic when under attack. This repository could, 958 for example, keep information on which neighbor router or AS is doing 959 proper ingress address filtering. The repository could also hold the 960 configurations that operators use to upgrade configurations on their 961 routers. 963 If such a repository is to be a shared resource used by multiple 964 operators, it will necessarily require validation and authentication 965 of the stored policies to ensure that the repository does not become 966 the cause of vulnerabilities. Inevitably this would mean that the 967 information comes with a cost and it will only be viable if the sum 968 of the reductions in individual operators' costs is greater than the 969 costs of maintaining the repository. 971 5.2. Flow Based Tools 973 A set of tools based on flow data is widely used to extract 974 information from both network and data link layers. Tools have been 975 built that can be used to find out the sources of almost any type of 976 traffic, including certain unwanted traffic. These flow-based tools 977 make it possible to do things like DDoS traceback, traffic/peering 978 analyses, and detection of botnets, worms and spyware. 980 These tools monitor flows on the network and build baselines for what 981 is the "normal" behavior. Once the baseline is available it is 982 possible to detect anomalous activity. It is easy to detect 983 variations over time, and decide if the variation is legitimate or 984 not. It is possible to take this approach further, typically 985 involving the identification of signatures of particular types of 986 traffic. 988 These flow-based tools are analogous to the "sonar" that is used by 989 navies to listen for submarines. Once a particular submarine is 990 identified it is possible to record its sonar signature, to be used 991 to provide rapid identification in the future when the same submarine 992 is encountered again. 994 Examples of existing tools include 995 Cisco IOS NetFlow , 997 sFlow , and 998 NeTraMet 999 1000 based on the IETF RTFM and IPFIX standards. 1002 There are also tools for working with the output of NetFlow such as 1003 jFlow and 1004 Arbor Networks' Peakflow 1005 . 1007 The Cooperative Association for Internet Data Analysis (CAIDA) 1008 maintains a taxonomy of available tools on its web site at 1009 . 1011 5.3. Internet Motion Sensor (IMS) 1013 The Internet Motion Sensor (IMS) [IMS] may be used to watch traffic 1014 to or from "Darknets" (routable prefixes that don't have end hosts 1015 attached to), unassigned address spaces and unannounced address 1016 spaces. By watching activities in these types of address spaces one 1017 can understand and detect, e.g., scanning activities, DDoS worms, 1018 worm infected hosts and misconfigured hosts. 1020 Currently the IMS is used to monitor approximately 17 million 1021 prefixes, about 1.2% of the IPv4 address space. The use of IMS has 1022 highlighted two major characteristics of attacks; malicious attacks 1023 are more targeted than one might have assumed, and a vulnerability in 1024 a system does not necessarily lead to a threat to that system (e.g., 1025 the vulnerability may not be exploited to launch attacks if the 1026 perceived "benefit" to the attacker appears small). Data from IMS 1027 and other sources indicates that attackers are making increased use 1028 of information from social networking sites to target their attacks 1029 and select perceived easy targets such as computers running very old 1030 versions of systems or new, unpatched vulnerabilities. 1032 This form of passive data collection is also known as a "Network 1033 Telescope". Links to similar tools can be found on the CAIDA web 1034 site at . 1036 5.4. BCP38 1038 In the year 2000 the IETF developed a set of recommendations to limit 1039 DOS attacks and Address Spoofing published as BCP38 [RFC2827] 1040 "Network Ingress Filtering: Defeating Denial of Service Attacks which 1041 employ IP Source Address Spoofing". However up to now BCP38 1042 capabilities still have not been widely deployed, perhaps due to the 1043 incentive issue discussed earlier. 1045 The IETF has also developed an additional set of recommendations 1046 extending BCP38 to multihomed networks. These recommendations are 1047 published as BCP84 [RFC3704]. 1049 5.5. Layer 5 to 7 Awareness 1051 Tools are being developed that will make it possible to perform deep 1052 packet inspection at high speed. Some companies are working on 1053 hardware implementation to inspect all layers from 2 to 7 (e.g. 1054 EZchip ). A number of 1055 other companies, including Cisco and Juniper, offer tools capable of 1056 analyzing packets at transport layer and above. 1058 5.6. How To's 1060 One idea that was discussed at the workshop envisaged operators and 1061 standards bodies cooperating to produce a set of "How To" documents 1062 as guidelines on how to configure networks. Dissemination and use of 1063 these "How To's" should be encouraged by vendors, operators and 1064 standards bodies. 1066 This type of initiative needs a "sponsor" or "champion" that takes 1067 the lead and starts collecting a set of "How To's" that could be 1068 freely distributed. The workshop did not discuss this further. 1070 5.7. SHRED 1072 Methods to discourage the dissemination of spam by punishing the 1073 spammers, such as Spam Harassment Reduction via Economic Disincentive 1074 (SHRED) [SHRED], were discussed. The idea is to make it increasingly 1075 expensive for spammers to use the email system, while normal users 1076 retain what they have come to expect as normal service. There was no 1077 agreement on the effectiveness of this type of system. 1079 6. Research in Progress 1081 In preparation for this session, several researchers active in 1082 Internet Research were asked two rather open ended questions "Where 1083 is the focus on Internet research today?" and "Where should it be?" 1085 A summary of the answers to these questions is given below. 1086 Section 6.2.2 covers part of the relationship between research and 1087 miscreants. For example research activities in each area, please 1088 refer to the slide set for Workshop Session 8 which can be found at 1089 the link referred to in Appendix C. 1091 6.1. Ongoing Research 1093 Section 6.1 discusses briefly areas where we see active research on 1094 unwanted traffic today. 1096 6.1.1. Exploited Hosts 1098 One area where researchers are very active is analyzing situations 1099 where hosts are exploited. This has been a major focus for a long 1100 time, and an abundance of reports have been published. Current 1101 research may be divided into three different categories: prevention, 1102 detection and defense. 1104 6.1.1.1. Prevention 1106 Code quality is crucial when it comes to preventing exploitation of 1107 Internet hosts. Quite a bit of research effort has therefore gone 1108 into improvement of code quality. Researchers are looking into 1109 automated methods for finding bugs and maybe in the end fixes for any 1110 bugs detected. 1112 A second approach designed to stop hosts becoming compromised, is to 1113 reduce the "attack surface". Researchers are thinking about changes 1114 or extensions to the Internet architecture. The idea is to create a 1115 strict client server architecture, where the clients only are allowed 1116 to initiate connections, and while servers may only accept 1117 connections. 1119 Researchers have put a lot of effort into better scaling of honey 1120 pots and honey farms to better understand and neutralize the methods 1121 miscreants are using to exploit hosts. Research also goes into 1122 developing honey monkeys in order to understand how hosts are 1123 vulnerable. Both honey pots/farms and honey monkeys are aimed at 1124 taking measures that prevent further (mis-)use of possible exploits. 1126 6.1.1.2. Detection 1128 When an attack is launched against a computer system, the attack 1129 typically leaves evidence of the intrusion in the system logs. Each 1130 type of intrusion leaves a specific kind of footprint or signature. 1131 The signature can be evidence that certain software has been 1132 executed, that logins have failed, that administrative privileges 1133 have been misused or that particular files and directories have been 1134 accessed. Administrators can document these attack signatures and 1135 use them to detect the same type of attack in the future. This 1136 process can be automated. 1138 Because each signature is different, it is possible for system 1139 administrators to determine by looking at the intrusion signature 1140 what the intrusion was, how and when it was perpetrated, and even how 1141 skilled the intruder is. 1143 Once an attack signature is available it can be used to create a 1144 vulnerability filter, i.e., the stored attack signature is compared 1145 to actual events in real time and an alarm is given when this pattern 1146 is repeated. 1148 A further step may be taken with automated vulnerability signatures, 1149 i.e., when a new type of attack is found a vulnerability filter is 1150 automatically created. This vulnerability filter can be made 1151 available for nodes to defend themselves against this new type of 1152 attack. The automated vulnerability signatures may be part of an 1153 Intrusion Detection System (IDS). 1155 6.1.1.3. Defense 1157 An IDS can be a part of the defense against actual attacks, e.g., by 1158 using vulnerability filters. An intrusion detection system (IDS) 1159 inspects inbound and outbound network activities and detects 1160 signatures that indicate that a system is under attack from someone 1161 attempting to break into or compromise the system. 1163 6.1.2. Distributed Denial of Service (DDoS) Attacks 1165 Research on DDoS attacks follows two separate approaches, the first 1166 has the application as its focus, while the second focuses on the 1167 network. 1169 6.1.2.1. Application Oriented DDoS Research 1171 The key issue with application oriented research is to distinguish 1172 between legitimate activities and attacks. Today several tools exist 1173 that can do this and research has moved on to more advanced things. 1175 Research today looks into tools that can detect and filter activities 1176 that have been generated by bots and botnets. 1178 One approach is to set up a tool that sends challenges to senders 1179 that want to send traffic to a certain node. The potential sender 1180 then has to respond correctly to that challenge, otherwise the 1181 traffic will be filtered out. 1183 The alternative is to get more capacity between sender and receiver. 1184 This is done primarily by some form of use of a peer-to-peer 1185 technology. 1187 Today there is "peer-to-peer hype" in the research community; a sure 1188 way of making yourself known as a researcher is to publish something 1189 that solves old problems by means of some peer-to-peer technology. 1190 Proposals now exist for peer-to-peer DNS, peer-to-peer backup 1191 solutions, peer-to-peer web-cast, etc. Whether these proposals can 1192 live up to the hype remains to be seen. 1194 6.1.2.2. Network Oriented DDoS Research 1196 Research on DDoS attacks that takes a network oriented focus may be 1197 described by the following oversimplified three steps. 1199 1. Find the bad stuff 1201 2. Set the "evil bit" on those packets 1203 3. Filter out the packets with the "evil bit" set 1205 This rather uncomplicated scheme has to be carried out on high-speed 1206 links and interfaces. Automation is the only way of achieving this. 1208 One way of indirectly setting the "evil bit" is to use a normalized 1209 TTL. The logic goes; the TTL for traffic from this sender has always 1210 been "x", but has now suddenly become "y", without any corresponding 1211 change in routing. The conclusion is that someone is masquerading as 1212 the legitimate sender. Traffic with the "y" TTL is filtered out. 1214 Another idea is to give traffic that is received from ISPs that are 1215 known to do source address validation the "red carpet treatment", 1216 i.e., to set the "good-bit". When an attack is detected traffic from 1217 everyone that doesn't have the "good-bit" is filtered out. Apart 1218 from reacting to the attack, this also give ISPs an incentive to do 1219 source address validation. It they don't do it their peers won't set 1220 the "good-bit" and the ISP's customers will suffer, dragging down 1221 their reputation. 1223 Overlay networks can also be used to stop a DDoS attack. The idea 1224 here is that traffic is not routed directly to the destination. 1225 Instead it is hidden behind some entry points in the overlay. The 1226 entry points make sure the sender is the host he claims he is, and in 1227 that case marks the packet with a "magic bit". Packets lacking the 1228 "magic bit" are not forwarded on the overlay. This has good scaling 1229 properties; you only need to have enough capacity to tag the amount 1230 of traffic you want to receive, not the amount you actually receive. 1232 6.1.3. Spyware 1234 Current research on spyware and measurements of spyware are aiming to 1235 find methods to understand when certain activities associated with 1236 spyware happen and to understand the impact of this activity. 1238 There are quite a number of research activities around spyware, e.g., 1239 looking into threats caused by spyware, however these were only 1240 briefly touched upon at the workshop. 1242 6.1.4. Forensic Aids 1244 Lately research has started to look into tools and support to answer 1245 the "What happened here?" question. These tools are called "forensic 1246 aids", and can be used to "recreate" an illegal activity just as the 1247 police do when working on a crime scene. 1249 The techniques that these forensic aids take as their starting point 1250 involve the identification of a process or program that should not be 1251 present on a computer. The effort goes into building tools and 1252 methods that can trace the intruder back to its origin. Methods to 1253 understand how a specific output depends on a particular input also 1254 exists. 1256 6.1.5. Measurements 1258 Measurements are always interesting for the research community, 1259 because they generate new data. Consequently lots of effort goes 1260 into specifying how measurements should be performed and into 1261 development of measurement tools. Measurements have been useful in 1262 creating effective counter-measures against worms. Before 1263 measurements gave actual data of how worms behave actions taken 1264 against worms were generally ineffective. 1266 6.1.6. Traffic Analysis 1268 One aspect of research that closely relates to measurements is 1269 analysis. Earlier it was common to look for the amount of traffic 1270 traversing certain transport ports. Lately it has become common to 1271 tunnel "everything" over something else, and a shift has occurred 1272 towards looking for behavior and/or content. When you see a certain 1273 behavior or content over a protocol that is not supposed to behave in 1274 this way, it is likely that something bad is going on. 1276 Since this is an arms race, the miscreants that use tunneling 1277 protocols have started to mimic the pattern of something that is 1278 acceptable. 1280 6.1.7. Protocol and Software Security 1282 The general IETF design guidelines for robust Internet protocols 1283 says: "Be liberal in what you receive and conservative in what you 1284 send". The downside is that most protocols believe what they get and 1285 as a consequence also get what they deserve. The IAB is intending to 1286 work on new design guidelines, e.g., rules of thumb and things you do 1287 and things you don't. This is not ready yet, but will offered as 1288 input to a BCP in due course. 1290 An area where there is an potential overlap between standards people 1291 and researchers is protocol analysis languages. The protocol 1292 analysis languages could be used, for example, look for 1293 vulnerabilities. 1295 6.2. Research on the Internet 1297 The workshop discussed the interface between people working in 1298 standardization organizations in general and IETF in particular on 1299 the one hand and people working with research on the other. The 1300 topic of discussion was broader than just "Unwanted traffic". Three 1301 topics were touched on what motivates researchers, how to attract 1302 researchers to problems that are hindering or have been discovered in 1303 the context of standardization, and the sometimes rocky relations 1304 between the research community and the "bad boys". 1306 6.2.1. Research and Standards 1308 The workshop discussed how research and standardization could 1309 mutually support each other. Quite often there is a commonality of 1310 interest between the two groups. The IAB supports the Internet 1311 Research Task Force (IRTF) as a venue for Internet research. The 1312 delta between what is done and what could be is still substantial. 1313 The discussion focused on how standardization in general and the IETF 1314 in particular can get help from researchers. 1316 Since standardization organizations don't have the economic strength 1317 to simply finance the research they need or want, other means have to 1318 be used. One is to correctly and clearly communicate problems, 1319 another is to supply adequate and relevant information. 1321 To attract the research community to work with standardization 1322 organizations it is necessary to identify the real problems and state 1323 them in such a way that they are amenable to solution. General 1324 unspecified problems are of no use, e.g., "This is an impossible 1325 problem!" or "All the problems are because my users behave badly!" 1327 Instead, saying "This is an absolutely critical problem, and we have 1328 no idea how to solve it!" is much more attractive. 1330 The potential research problem should also be communicated in a way 1331 that is public. A researcher that wants to take on a problem is 1332 helped if she/he can point at a slide from NANOG or RIPE identifying 1333 this problem. 1335 The way researchers go about solving problems is basically to 1336 identify all the existing constraints, and then relax one of the 1337 constraints and see what happens. Therefore rock solid constraints 1338 are a show stopper, e.g., "We can't do that, because it has to go 1339 into an ASIC!". Real constraints have to be clearly communicated to 1340 and understood by the researcher. 1342 One reasonable way of fostering cooperation is to entice two or three 1343 people and have them write a paper on the problem. What will happen 1344 then is that this paper will be incrementally improved by other 1345 researchers. The vast majority of all research goes into improving 1346 on someone else's paper. 1348 A second important factor is to supply relevant and enough 1349 information. New information that opens up possibilities to address 1350 new problems or improve on old or partial solutions are attractive. 1351 Often, understanding of important problems comes from the operator 1352 community; when trying to initiate research from a standards 1353 perspective keeping operators in the loop may be beneficial. 1355 Today the research community is largely left on its own, and 1356 consequently tends to generate essentially random, untargeted 1357 results. If the right people in the standards community say the 1358 right things to the right people in the research community, it can 1359 literally focus hundreds of graduate students on a single problem. 1360 What is needed is supplying problem statements and data. 1362 6.2.2. Research and the Bad Guys 1364 A general problem with all research and development is that what can 1365 be used may also be misused. In some cases miscreants have received 1366 help from research that was never intended. 1368 There are several examples of Free Nets, i.e., networks designed to 1369 allow end-users to participate without revealing their identity or 1370 how and where they are connected to the network. The Free Nets are 1371 designed based on technologies such as onion routing or mix networks. 1372 Free Nets create anonymity that allows people to express opinions 1373 without having to reveal their true identity and thus can be used to 1374 promote free speech. However, these are tools that can also work 1375 just as well to hide illegal activities in democracies. 1377 Mix networks create hard-to-trace communications by using a chain of 1378 proxy servers. A message from a sender to a receiver passes by the 1379 chain of proxies. A message is encrypted with a layered encryption 1380 where the each layer is understood by only one of the proxies in the 1381 chain; the actual message as the innermost layer. A mixed network 1382 will achieve untraceable communication even if all but one of the 1383 proxies are compromised by a potential tracer. 1385 Onion routing is a technique for anonymous communication over a 1386 computer network, it is a technique that encodes routing information 1387 in a set of encrypted layers. Onion routing is a further development 1388 of mix networks. 1390 Research projects have resulted in methods for distributed command 1391 and control, e.g., in the form of Distributed Hash Tables (DHT) and 1392 gossip protocols. This of course has legitimate uses, e.g., for 1393 security and reliability applications, but it also is extremely 1394 useful for DDoS attacks and unwanted traffic in general. 1396 A lot of effort has gone into research around worms, the result is 1397 that we have a very good understanding of the characteristics of the 1398 technology associated with worms and how they behave. This is a very 1399 good basis when we want to protect against worms. The downside is 1400 that researchers also understand how to implement future worms, 1401 including knowledge on how to design faster worms that won't leave a 1402 footprint. 1404 7. Aladdin's Lamp 1406 If we had an Aladdin's Lamp and could be granted anything we wanted 1407 in the context of remedying unwanted traffic or effects of such 1408 traffic - what would we wish for? The topic of this session was 1409 wishes, i.e., loosening the constraints that depend on what we have 1410 and focus on what we really want. 1412 There certainly are lots of "wishes" around, not least around making 1413 things simpler and safer. On the other hand very few of these wishes 1414 are clearly stated. One comment on this lack of clarity was that we 1415 are too busy putting out the fires of today and don't have the time 1416 to be thinking ahead. 1418 7.1. Security Improvements 1420 Operators expressed wishes on improving and simplifying security. 1421 The list below for actions to improve security are examples. The 1422 content is still at the "wish-level", i.e., no effort has gone in to 1423 trying to understand the feasibility of realizing these wishes. 1425 Wish: Reliable point of contact in each administrative domain for 1426 security coordination. 1427 First and foremost operators would like to see correct and complete 1428 contact information to coordinate security problems across operators. 1430 The "whois" database of registration details for IP addresses and 1431 Autonomous System numbers held by Regional Internet Registries (e.g., 1432 ARIN, RIPE, APNIC) was intended to be a directory for this type of 1433 information, and RFC2142 [RFC2142] established common mailbox names 1434 for certain roles and services. There are several reasons why these 1435 tools are largely unused, including unwanted traffic. 1437 Wish: Organized testing for security. 1438 Today new hardware and software are extensively tested for 1439 performance. There is almost no testing of this hardware and 1440 software for security. 1442 Wish: Infrastructure or test bed for security. 1443 It would be good to have an organized infrastructure or test bed for 1444 testing of security for new products. 1446 Wish: Defaults for security. 1447 Equipment and software should come with a simple and effective 1448 default setting for security. 1450 Wish: Shared information regarding attacks. 1451 It would be useful to have an automated sharing mechanism for 1452 attacks, vulnerabilities and sources of threats between network users 1453 and providers in order to meet attacks in a more timely and efficient 1454 manner. 1456 7.2. Unwanted Traffic 1458 Wish: Automatic filtering of unwanted traffic. 1459 It would be useful, not least for enterprises, to have possibilities 1460 to automatically filter out the unwanted traffic. 1462 Some filtering of spam, viruses and malware that is sent by email is 1463 already practicable but inevitably is imperfect because it mainly 1464 relies on "heuristics" to identify the unwanted traffic. This is 1465 another example of the "arms race" between filtering and the 1466 ingenuity of spammers trying to evade the filters. This "wish" needs 1467 to be further discussed and developed to make it something that could 1468 be turned into practical ideas. 1470 Wish: Fix Spam. 1471 A large fraction of the email traffic coming into enterprises today 1472 is spam, and consequently any fixes to the spam problem are very high 1473 on their priority list. 1475 8. Workshop Summary 1477 The workshop spent its last two hours discussing the following 1478 question: What are the engineering (immediate and longer term) and 1479 research issues that might be pursued within the IETF and the IRTF, 1480 and what actions could the IAB take? The suggested actions can be 1481 summarized into three classes. 1483 8.1. Hard Questions 1485 The discussions during this concluding section raised a number of 1486 questions that touched upon the overall network architecture designs. 1488 o What should be the roles of cryptographic mechanisms in the 1489 overall Internet architecture? For example, do we need to apply 1490 cryptographic mechanisms to harden the shell, or rely on deep 1491 packet inspection to filter out bad traffic? 1493 o To add effective protection to the Internet, how far are we 1494 willing to go in 1496 * curtailing its openness, and 1498 * increasing the system complexity? 1500 And what architectural principles do we need to preserve as we go 1501 along these paths? 1503 o A simple risk analysis would suggest that an ideal attack target 1504 of minimal cost but maximal disruption is the core routing 1505 infrastructure. However do we really need an unlinked and 1506 separately managed control plane to secure it? This requires a 1507 deep understanding of the architectural design trade-offs. 1509 o Can we, and how do we change the economic substructure? A special 1510 workshop was suggested as a next step to gain a better 1511 understanding of the question. 1513 8.2. Medium or Long Term Steps 1515 While answering the above hard questions may take some time and 1516 effort, several specific steps were suggested as medium or long term 1517 efforts to add protection to the Internet: 1519 o Tightening the security of the core routing infrastructure. 1521 o Cleaning up the Internet Routing Registry repository [IRR], and 1522 securing both the database and the access, so that it can be used 1523 for routing verifications. 1525 o Take down botnets. 1527 o Although we do not have a magic wand to wave all the unwanted 1528 traffic off the Internet, we should be able to develop effective 1529 measures to reduce the unwanted traffic to a tiny fraction of its 1530 current volume and keep it under control. 1532 o Community education, to try to ensure people *use* updated host, 1533 router and ingress filtering BCPs 1535 8.3. Immediately Actionable Steps 1537 The IETF is recommended to take steps to carry out the following 1538 actions towards enhancing the network protection. 1540 o Update the host requirements RFC. The Internet host requirements 1541 ([RFC1122], [RFC1123]) were developed in 1989. The Internet has 1542 gone through fundamental changes since then, including the 1543 pervasive security threats. Thus a new set of requirements is 1544 overdue. 1546 o Update the router requirements. The original router requirements 1547 [RFC1812] were developed in 1995. As with the host requirements, 1548 it is also overdue for an update. 1550 o Update ingress filtering (BCP38 [RFC2827] and BCP 84 [RFC3704]). 1552 One immediate action that the IAB should carry out is to inform the 1553 community about the existence of the underground economy. 1555 The IRTF is recommended to take further steps toward understanding 1556 the Underground Economy and to initiate research on developing 1557 effective countermeasures. 1559 Overall, the workshop attendees wish to raise the community's 1560 awareness of the underground economy. The community as a whole 1561 should undertake a systematic examination of the current situation, 1562 and develop both near- and long-term plans. 1564 9. Terminology 1566 This section gives an overview of some of the key concepts and 1567 terminology used in this document. It is not intended to be 1568 complete, but is offered as a quick reference for the reader of the 1569 report. 1571 ACL 1572 Access Control List in the context of Internet networking refers to a 1573 set of IP addresses or routing prefixes (layer 3 or Internet layer 1574 information) possibly combined with transport protocol port numbers 1575 (layer 4 or transport layer information). The layer 3 and/or layer 4 1576 information in the packets making up a flow entering or leaving a 1577 device in the Internet is matched against the entries in an ACL to 1578 determine whether the packets should, for example, be allowed or 1579 denied access to some resources. The ACL effectively specifies a 1580 filter to be used on a flow of packets. 1582 BGP route hijacking 1583 Attack in which an inappropriate route is injected into the global 1584 routing system with the intent of diverting traffic from its intended 1585 recipient either as a DoS attack (q.v.) where the traffic is just 1586 dropped or as part of some wider attack on the recipient. Injecting 1587 spurious routes specifying addresses used for bogons can, for 1588 example, provide bogus assurance to email systems that spam is coming 1589 from legitimate addresses. 1591 Bogon 1592 A bogon is an IP packet that has a source address taken for a range 1593 of addresses that has not yet been allocated to legitimate users, or 1594 is a private [RFC1918] or reserved address [RFC3330]. 1596 Bogon prefix 1597 A bogon prefix is a route that should never appear in the Internet 1598 routing table, e.g., from the private or unallocated address blocks. 1600 Bot 1601 is common parlance on the Internet for a software program that is a 1602 software agent. A Bot interacts with other network services intended 1603 for people as if it were a real person. One typical use of bots is 1604 to gather information. The term is derived from the word "robot," 1605 reflecting the autonomous character in the "virtual robot"-ness of 1606 the concept. 1607 The most common bots are those that covertly install themselves on 1608 people's computers for malicious purposes, and that have been 1609 described as remote attack tools. Bots are sometimes called 1610 "zombies". 1612 Botnet 1613 is a jargon term for a collection of software robots, or bots, which 1614 run autonomously. This can also refer to the network of computers 1615 using distributed computing software. While the term "botnet" can be 1616 used to refer to any group of bots, such as IRC bots, the word is 1617 generally used to refer to a collection of compromised machines 1618 running programs, usually referred to as worms, Trojan horses, or 1619 backdoors, under a common command and control infrastructure. 1621 Click fraud 1622 occurs in pay per click (PPC) advertising when a person, automated 1623 script, or computer program imitates a legitimate user of a web 1624 browser clicking on an ad, for the purpose of generating an improper 1625 charge per click. Pay per click advertising is when operators of web 1626 sites, acts as publishers and offer clickable links from advertisers, 1627 in exchange for a charge per click. 1629 Darknet 1630 A Darknet (also known as a Network Telescope, a Blackhole or an 1631 Internet Sink) is a globally routed network that has no "real" 1632 machines attached and carries only a very small amount of specially 1633 crafted legitimate traffic. It is therefore easily possible to 1634 separate out and analyze unwanted traffic that can arise from a wide 1635 variety of events including misconfiguration (e.g., a human being 1636 mis-typing an IP address), malicious scanning of address space by 1637 hackers looking for vulnerable targets, backscatter from random 1638 source denial-of-service attacks, and the automated spread of 1639 malicious software called Internet worms. 1641 Dirty affiliate program 1642 Affiliate programs are distributed marketing programs that recruit 1643 agents to promote a product or service. Affiliates get financially 1644 compensated for each sale associated with their unique 'affiliate 1645 ID.' Affiliates are normally instructed by the operator of the 1646 affiliate program to not break any laws while promoting the product 1647 or service. Sanctions (typically loss of unpaid commissions, or 1648 removal from the affiliate program) are normally applied if the 1649 affiliate spams or otherwise violates the affiliate program's 1650 policies. 1652 Dirty affiliate programs allow spamming, or if they do nominally 1653 prohibit spamming, they don't actually sanction violators. Dirty 1654 affiliate programs often promote illegal or deceptive products 1655 (prescription drugs distributed without regard to normal dispensing 1656 requirements, body part enlargement products, etc.), employ anonymous 1657 or untraceable affiliates, offer payment via anonymous online 1658 financial channels, and may fail to follow normal tax withholding and 1659 reporting practices. 1661 DoS attack 1662 Denial-Of-Service attack, a type of attack on a network that is 1663 designed to bring the network to its knees by flooding it with 1664 useless traffic or otherwise blocking resources necessary to allow 1665 normal traffic flow. 1667 DDoS attack 1668 Distributed Denial of Service, an attack where multiple compromised 1669 systems are used to target a single system causing a Denial of 1670 Service (DoS) attack. 1672 Honey farm 1673 A honey farm is a set of honey pots working together. 1675 Honey monkey 1676 A honey monkey is a honey pot in reverse, instead of sitting and 1677 waiting for miscreants, a honey monkey actively mimics the actions of 1678 a user surfing the Web. The honey monkey runs on virtual machines in 1679 order to detect exploit sites. 1681 Honey pot 1682 A honey pot is a server attached to the Internet that acts as a 1683 decoy, attracting potential miscreants in order to study their 1684 activities and monitor how they are able to break into a system. 1685 Honeypots are designed to mimic systems that an intruder would like 1686 to break into but limit the intruder from having access to an entire 1687 network. 1689 IRC 1690 Internet Relay Chat is a form of instant communication over the 1691 Internet. It is mainly designed for group (many-to-many) 1692 communication in discussion forums called channels, but also allows 1693 one-to-one communication originally standardized by RFC 1459 1694 [RFC1459] but much improved and extended since its original 1695 invention. IRC clients rendezvous and exchange messages through IRC 1696 servers. IRC servers are run by many organizations for both benign 1697 and nefarious purposes. 1699 Malware 1700 Malware is software designed to infiltrate or damage a computer 1701 system, without the owner's informed consent. There are 1702 disagreements about the etymology of the term itself, the primary 1703 uncertainty being whether it is a portmanteau word (of "malicious" 1704 and "software") or simply composed of the prefix "mal-" and the 1705 morpheme "ware". Malware references the intent of the creator, 1706 rather than any particular features. It includes computer viruses, 1707 worms, Trojan horses, spyware, adware, and other malicious and 1708 unwanted software. In law, malware is sometimes known as a computer 1709 contaminant. 1711 Mix networks 1712 create hard-to-trace communications by using a chain of proxy servers 1713 [MIX]. Each message is encrypted to each proxy; the resulting 1714 encryption is layered like a Russian doll with the message as the 1715 innermost layer. Even if all but one of the proxies are compromised 1716 by a tracer, untraceability is still achieved. More information can 1717 be found at 1718 . 1721 Onion routing 1722 is a technique for anonymous communication over a computer network, 1723 it is a technique that encodes routing information in a set of 1724 encrypted layers. Onion routing is based on mix cascades (see mix 1725 networks (q.v.)). More information can be found at 1726 . 1728 Phishing 1729 is a form of criminal activity using social engineering techniques. 1730 It is characterized by attempts to fraudulently acquire sensitive 1731 information, such as passwords and credit card details, by 1732 masquerading as a trustworthy person or business in an apparently 1733 official electronic communication. Phishing is typically carried out 1734 using spoofed websites, email or an instant message. The term 1735 phishing derives from password harvesting and the use of increasingly 1736 sophisticated lures to "fish" for users' financial information and 1737 passwords. 1739 Root access 1740 Access to a system with full administrative privileges bypassing any 1741 security restrictions placed on normal users. Derived from the name 1742 traditionally used for the 'superuser' on Unix systems. 1744 Script kiddy 1745 Derogatory term for an inexperienced hacker who mindlessly uses 1746 scripts and other programs developed by others with the intent of 1747 compromising computers or generating DoS attacks. 1749 Spam 1750 Spamming is the abuse of electronic messaging systems to send 1751 unsolicited, undesired bulk messages. The individual messages are 1752 refereed to as spam. The term is frequently used to refer 1753 specifically to the electronic mail form of spam. 1755 Spoofing 1756 (IP) spoofing is a technique where the illegitimate source of IP 1757 packets is obfuscated by contriving to use IP address(es) that the 1758 receiver recognizes as a legitimate source. Spoofing is often used 1759 to gain unauthorized access to computers or mislead filtering 1760 mechanisms, whereby the intruder sends packets into the network with 1761 an IP source address indicating that the message is coming from a 1762 legitimate host. To engage in IP spoofing, a hacker must first use a 1763 variety of techniques to find an IP address of a valid host and then 1764 modify the packet headers so that it appears that the packets are 1765 coming from that host. 1767 Spyware 1768 Any software that covertly gathers user information through the 1769 user's Internet connection without his or her knowledge, e.g., for 1770 spam purposes. 1772 UBE 1773 Unsolicited Bulk Email: an official term for spam 1775 UCE 1776 Unsolicited Commercial Email: an official term for spam 1778 Virus 1779 A program or piece of code that is loaded onto a computer without the 1780 owner's knowledge and runs without their consent. A virus is self- 1781 replicating code that spreads by inserting copies of itself into 1782 other executable code or documents which are then transferred to 1783 other machines. Typically the virus has a payload that causes some 1784 harm to the infected machine when the virus code is executed. 1786 Worm 1787 A computer worm is a self-replicating computer program. It uses a 1788 network to send copies of itself to other systems and it may do so 1789 without any user intervention. Unlike a virus, it does not need to 1790 attach itself to an existing program. Worms always harm the network 1791 (if only by consuming bandwidth), whereas viruses always infect or 1792 corrupt files on a targeted computer. 1794 Zombie 1795 is another name for a bot. 1797 10. Security Considerations 1799 This document does not specify any protocol or "bits on the wire". 1801 11. IANA considerations 1803 There are no requests to the IANA herein. 1805 12. Acknowledgements 1807 The IAB would like to thank the University of Southern California 1808 Information Sciences Institute (ISI) who hosted the workshop and all 1809 those people at ISI and elsewhere who assisted with the organization 1810 and logistics of the workshop at ISI. 1812 The IAB would also like to thank the scribes listed in Appendix A who 1813 diligently recorded the proceedings during the workshop. 1815 A special thanks to all the participants in the workshop, who took 1816 the time, came to the workshop to participate in the discussions and 1817 who put in the effort to make this workshop a success. The IAB 1818 especially appreciate the effort of those prepared and made 1819 presentations at the workshop. 1821 13. Informative References 1823 [IMS] University of Michigan, "Internet Motion Sensor", 2006, 1824 . 1826 [IRR] Merit Network Inc, "Internet Routing Registry Routing 1827 Assets Database", 2006, . 1829 [MIX] Hill, R., Hwang, A., and D. Molnar, "Approaches to Mix 1830 Nets", December 1999, . 1833 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1834 Communication Layers", STD 3, RFC 1122, October 1989. 1836 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1837 and Support", STD 3, RFC 1123, October 1989. 1839 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 1840 RFC 1459, May 1993. 1842 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1843 RFC 1812, June 1995. 1845 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1846 E. Lear, "Address Allocation for Private Internets", 1847 BCP 5, RFC 1918, February 1996. 1849 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 1850 FUNCTIONS", RFC 2142, May 1997. 1852 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1853 Defeating Denial of Service Attacks which employ IP Source 1854 Address Spoofing", BCP 38, RFC 2827, May 2000. 1856 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 1857 September 2002. 1859 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1860 Networks", BCP 84, RFC 3704, March 2004. 1862 [SHRED] Krishnamurthy, B. and E. Blackmond, "SHRED: Spam 1863 Harassment Reduction via Economic Disincentives", 2003, 1864 . 1866 Appendix A. Participants in the workshop 1868 Bernard Aboba (IAB) 1869 Loa Andersson (IAB) 1870 Ganesha Bhaskara (scribe) 1871 Bryan Burns 1872 Leslie Daigle (IAB chair) 1873 Sean Donelan 1874 Rich Draves (IAB Executive Director) 1875 Aaron Falk (IAB, IRTF chair) 1876 Robert Geigle 1877 Minas Gjoka (scribe) 1878 Barry Greene 1879 Sam Hartman (IESG, Security Area Director) 1880 Bob Hinden (IAB) 1881 Russ Housely (IESG, Security Area Director) 1882 Craig Huegen 1883 Cullen Jennings 1884 Rodney Joffe 1885 Mark Kosters 1886 Bala Krishnamurthy 1887 Gregory Lebovitz 1888 Ryan McDowell 1889 Danny McPherson 1890 Dave Merrill 1891 David Meyer (IAB) 1892 Alan Mitchell 1893 John Morris 1894 Eric Osterweil (scribe) 1895 Eric Rescorla (IAB) 1896 Pete Resnick (IAB) 1897 Stefan Savage 1898 Joe St Sauver 1899 Michael Sirivianos (scribe) 1900 Rob Thomas 1901 Helen Wang 1902 Lixia Zhang (IAB) 1904 Appendix B. Workshop agenda 1906 Session 1: 1907 How bad is the problem? What are the most important symptoms? 1909 Session 2: 1910 What are the sources of the problem? 1912 Lunch session (session 3): 1913 Solutions in regulatory and societal space 1915 Session 4: 1916 The underground economy 1918 Session 5: 1919 Current countermeasures, what works, what doesn't 1921 Session 6: 1922 If all our wishes could be granted, what would they be? 1924 Session 7: 1925 What's in the pipeline, or should be in the pipeline 1927 Session 8: 1928 What is being actively researched on? 1930 Session 9: 1931 What are the engineering (immediate and longer term) and 1932 research issues that might be pursued within the IETF/IAB/IRTF? 1934 Appendix C. Slides 1936 Links to a subset of the presentations given by the participants at 1937 the workshop can be found via the IAB Workshops page on the IAB web 1938 site at . As mentioned in Section 1, this is not a complete set 1940 of the presentations because certain of the presentations were of a 1941 sensitive nature which it would be inappropriate to make public at 1942 this time. 1944 Authors' Addresses 1946 Loa Andersson 1947 Acreo AB 1949 Email: loa@pi.se 1951 Elwyn Davies 1952 Folly Consulting 1954 Email: elwynd@dial.pipex.com 1956 Lixia Zhang 1957 UCLA 1959 Email: lixia@cs.ucla.edu 1961 Full Copyright Statement 1963 Copyright (C) The IETF Trust (2007). 1965 This document is subject to the rights, licenses and restrictions 1966 contained in BCP 78, and except as set forth therein, the authors 1967 retain all their rights. 1969 This document and the information contained herein are provided on an 1970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1972 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1973 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1974 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1977 Intellectual Property 1979 The IETF takes no position regarding the validity or scope of any 1980 Intellectual Property Rights or other rights that might be claimed to 1981 pertain to the implementation or use of the technology described in 1982 this document or the extent to which any license under such rights 1983 might or might not be available; nor does it represent that it has 1984 made any independent effort to identify any such rights. Information 1985 on the procedures with respect to rights in RFC documents can be 1986 found in BCP 78 and BCP 79. 1988 Copies of IPR disclosures made to the IETF Secretariat and any 1989 assurances of licenses to be made available, or the result of an 1990 attempt made to obtain a general license or permission for the use of 1991 such proprietary rights by implementers or users of this 1992 specification can be obtained from the IETF on-line IPR repository at 1993 http://www.ietf.org/ipr. 1995 The IETF invites any interested party to bring to its attention any 1996 copyrights, patents or patent applications, or other proprietary 1997 rights that may cover technology that may be required to implement 1998 this standard. Please address the information to the IETF at 1999 ietf-ipr@ietf.org. 2001 Acknowledgment 2003 Funding for the RFC Editor function is provided by the IETF 2004 Administrative Support Activity (IASA).