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