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