diff options
Diffstat (limited to 'doc/rfc/rfc4948.txt')
| -rw-r--r-- | doc/rfc/rfc4948.txt | 2411 |
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc4948.txt b/doc/rfc/rfc4948.txt new file mode 100644 index 0000000..1fb0a3e --- /dev/null +++ b/doc/rfc/rfc4948.txt @@ -0,0 +1,2411 @@ + + + + + + +Network Working Group L. Andersson +Request for Comments: 4948 Acreo AB +Category: Informational E. Davies + Folly Consulting + L. Zhang + UCLA + August 2007 + + + Report from the IAB workshop on Unwanted Traffic March 9-10, 2006 + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document reports the outcome of a workshop held by the Internet + Architecture Board (IAB) on Unwanted Internet Traffic. The workshop + was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. + The primary goal of the workshop was to foster interchange between + the operator, standards, and research communities on the topic of + unwanted traffic, as manifested in, for example, Distributed Denial + of Service (DDoS) attacks, spam, and phishing, to gain understandings + on the ultimate sources of these unwanted traffic, and to assess + their impact and the effectiveness of existing solutions. It was + also a goal of the workshop to identify engineering and research + topics that could be undertaken by the IAB, the IETF, the IRTF, and + the network research and development community at large to develop + effective countermeasures against the unwanted traffic. + + + + + + + + + + + + + + + +Andersson, et al. Informational [Page 1] + +RFC 4948 Unwanted Traffic August 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Root of All Evils: An Underground Economy . . . . . . . . 4 + 2.1. The Underground Economy . . . . . . . . . . . . . . . . . 5 + 2.2. Our Enemy Using Our Networks, Our Tools . . . . . . . . . 6 + 2.3. Compromised Systems Being a Major Source of Problems . . . 7 + 2.4. Lack of Meaningful Deterrence . . . . . . . . . . . . . . 8 + 2.5. Consequences . . . . . . . . . . . . . . . . . . . . . . . 10 + 3. How Bad Is The Problem? . . . . . . . . . . . . . . . . . . . 10 + 3.1. Backbone Providers . . . . . . . . . . . . . . . . . . . . 10 + 3.1.1. DDoS Traffic . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.2. Problem Mitigation . . . . . . . . . . . . . . . . . . 11 + 3.2. Access Providers . . . . . . . . . . . . . . . . . . . . . 12 + 3.3. Enterprise Networks: Perspective from a Large + Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.4. Domain Name Services . . . . . . . . . . . . . . . . . . . 14 + 4. Current Vulnerabilities and Existing Solutions . . . . . . . . 15 + 4.1. Internet Vulnerabilities . . . . . . . . . . . . . . . . . 15 + 4.2. Existing Solutions . . . . . . . . . . . . . . . . . . . . 16 + 4.2.1. Existing Solutions for Backbone Providers . . . . . . 16 + 4.2.2. Existing Solutions for Enterprise Networks . . . . . . 17 + 4.3. Shortfalls in the Existing Network Protection . . . . . . 18 + 4.3.1. Inadequate Tools . . . . . . . . . . . . . . . . . . . 18 + 4.3.2. Inadequate Deployments . . . . . . . . . . . . . . . . 18 + 4.3.3. Inadequate Education . . . . . . . . . . . . . . . . . 19 + 4.3.4. Is Closing Down Open Internet Access Necessary? . . . 19 + 5. Active and Potential Solutions in the Pipeline . . . . . . . . 20 + 5.1. Central Policy Repository . . . . . . . . . . . . . . . . 20 + 5.2. Flow Based Tools . . . . . . . . . . . . . . . . . . . . . 21 + 5.3. Internet Motion Sensor (IMS) . . . . . . . . . . . . . . . 21 + 5.4. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.5. Layer 5 to 7 Awareness . . . . . . . . . . . . . . . . . . 22 + 5.6. How To's . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.7. SHRED . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 6. Research in Progress . . . . . . . . . . . . . . . . . . . . . 23 + 6.1. Ongoing Research . . . . . . . . . . . . . . . . . . . . . 23 + 6.1.1. Exploited Hosts . . . . . . . . . . . . . . . . . . . 23 + 6.1.2. Distributed Denial of Service (DDoS) Attacks . . . . . 25 + 6.1.3. Spyware . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.1.4. Forensic Aids . . . . . . . . . . . . . . . . . . . . 26 + 6.1.5. Measurements . . . . . . . . . . . . . . . . . . . . . 27 + 6.1.6. Traffic Analysis . . . . . . . . . . . . . . . . . . . 27 + 6.1.7. Protocol and Software Security . . . . . . . . . . . . 27 + 6.2. Research on the Internet . . . . . . . . . . . . . . . . . 27 + 6.2.1. Research and Standards . . . . . . . . . . . . . . . . 28 + 6.2.2. Research and the Bad Guys . . . . . . . . . . . . . . 29 + + + + +Andersson, et al. Informational [Page 2] + +RFC 4948 Unwanted Traffic August 2007 + + + 7. Aladdin's Lamp . . . . . . . . . . . . . . . . . . . . . . . . 30 + 7.1. Security Improvements . . . . . . . . . . . . . . . . . . 30 + 7.2. Unwanted Traffic . . . . . . . . . . . . . . . . . . . . . 31 + 8. Workshop Summary . . . . . . . . . . . . . . . . . . . . . . . 31 + 8.1. Hard Questions . . . . . . . . . . . . . . . . . . . . . . 31 + 8.2. Medium or Long Term Steps . . . . . . . . . . . . . . . . 32 + 8.3. Immediately Actionable Steps . . . . . . . . . . . . . . . 33 + 9. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 + 12. Informative References . . . . . . . . . . . . . . . . . . . . 39 + Appendix A. Participants in the Workshop . . . . . . . . . . . . 40 + Appendix B. Workshop Agenda . . . . . . . . . . . . . . . . . . . 41 + Appendix C. Slides . . . . . . . . . . . . . . . . . . . . . . . 41 + +1. Introduction + + The Internet carries a lot of unwanted traffic today. To gain a + better understanding of the driving forces behind such unwanted + traffic and to assess existing countermeasures, the IAB organized an + "Unwanted Internet Traffic" workshop and invited experts on different + aspects of unwanted traffic from operator, vendor, and research + communities to the workshop. The intention was to share information + among people from different fields and organizations, fostering an + interchange of experiences, views, and ideas between the various + communities on this important topic. The major goal of this workshop + was to stimulate discussion at a deep technical level to assess + today's situation in regards to: + + o the kinds of unwanted traffic that are seen on the Internet, + + o how bad the picture looks, + + o who and where are the major sources of the problem, + + o which solutions work and which do not, and + + o what needs to be done. + + The workshop was very successful. Over one and half days of + intensive discussions, the major sources of the unwanted traffic were + identified, and a critical assessment of the existing mitigation + tools was conducted. However, due to the limitation of available + time, it was impossible to cover the topic of unwanted traffic in its + entirety. Thus, for some of the important issues, only the surface + was touched. Furthermore, because the primary focus of the workshop + was to collect and share information on the current state of affairs, + it is left as the next step to attempt to derive solutions to the + + + +Andersson, et al. Informational [Page 3] + +RFC 4948 Unwanted Traffic August 2007 + + + issues identified. This will be done in part as activities within + the IAB, the IETF, and the IRTF. + + During the workshop, a number of product and company names were + cited, which are reflected in the report to a certain extent. + However, a mention of any product in this report should not be taken + as an endorsement of that product; there may well be alternative, + equally relevant or efficacious products in the market place. + + This report is a summary of the contributions by the workshop + participants, and thus it is not an IAB document. The views and + positions documented in the report do not necessarily reflect IAB + views and positions. + + The workshop participant list is attached in Appendix A. The agenda + of the workshop can be found in Appendix B. Links to a subset of the + presentations are provided in Appendix C; the rest of the + presentations are of a sensitive nature, and it has been agreed that + they will not be made public. Definitions of the jargon used in + describing unwanted traffic can be found in Section 9. + +2. The Root of All Evils: An Underground Economy + + The first important message this workshop would like to bring to the + Internet community's attention is the existence of an underground + economy. This underground economy provides an enormous amount of + monetary fuel that drives the generation of unwanted traffic. This + economic incentive feeds on an Internet that is to a large extent + wide open. The open nature of the Internet fosters innovations but + offers virtually no defense against abuses. It connects to millions + of mostly unprotected hosts owned by millions of mostly naive users. + These users explore and benefit from the vast opportunities offered + by the new cyberspace, with little understanding of its vulnerability + to abuse and the potential danger of their computers being + compromised. Moreover, the Internet was designed without built-in + auditing trails. This was an appropriate choice at the time, but now + the lack of traceability makes it difficult to track down malicious + activities. Combined with a legal system that is yet to adapt to the + new challenge of regulating the cyberspace, this means the Internet, + as of today, has no effective deterrent to miscreants. The + unfettered design and freedom from regulation have contributed to the + extraordinary success of the Internet. At the same time, the + combination of these factors has also led to an increasing volume of + unwanted traffic. The rest of this section provides a more detailed + account of each of the above factors. + + + + + + +Andersson, et al. Informational [Page 4] + +RFC 4948 Unwanted Traffic August 2007 + + +2.1. The Underground Economy + + As in any economic system, the underground economy is regulated by a + demand and supply chain. The underground economy, which began as a + barter system, has evolved into a giant shopping mall, commonly + running on IRC (Internet Relay Chat) servers. The IRC servers + provide various online stores selling information about stolen credit + cards and bank accounts, malware, bot code, botnets, root accesses to + compromised hosts and web servers, and much more. There are DDoS + attack stores, credit card stores, PayPal and bank account stores, as + well as Cisco and Juniper router stores that sell access to + compromised routers. Although not everything can be found on every + server, most common tools used to operate in the underground economy + can be found on almost all the servers. + + How do miscreants turn attack tools and compromised machines into + real assets? In the simplest case, miscreants electronically + transfer money from stolen bank accounts directly to an account that + they control, often in another country. In a more sophisticated + example, miscreants use stolen credit cards or PayPal accounts for + online purchases. To hide their trails, they often find remailers + who receive the purchased goods and then repackage them to send to + the miscreants for a fee. The miscreants may also sell the goods + through online merchandising sites such as eBay. They request the + payments be made in cashier checks or money orders to be sent to the + people who provide money laundering services for the miscreants by + receiving the payments and sending them to banks in a different + country, again in exchange for a fee. In either case, the + destination bank accounts are used only for a short period and are + closed as soon as the money is withdrawn by the miscreants. + + The miscreants obtain private and financial information from + compromised hosts and install bots (a.k.a. zombies) on them. They + can also obtain such information from phishing attacks. Spam + messages mislead naive users into accessing spoofed web sites run by + the miscreants where their financial information is extracted and + collected. + + The miscreants in general are not skilled programmers. With money, + however, they can hire professional writers to produce well phrased + spam messages, and hire coders to develop new viruses, worms, + spyware, and botnet control packages, thereby resupplying the + underground market with new tools that produce more unwanted traffic + on the Internet: spam messages that spread phishing attacks, botnets + that are used to launch DDoS attacks, click fraud that "earns" income + by deceiving online commercial advertisers, and new viruses and worms + that compromise more hosts and steal additional financial information + as well as system passwords and personal identity information. + + + +Andersson, et al. Informational [Page 5] + +RFC 4948 Unwanted Traffic August 2007 + + + The income gained from the above illegal activities allows miscreants + to hire spammers, coders, and IRC server providers. Spammers use + botnets. Direct marketing companies set up dirty affiliate programs. + Some less than scrupulous banks are also involved to earn transaction + fees from moving the dirty money around. In the underground market, + everything can be traded, and everything has a value. Thus is + spawned unwanted traffic of all kinds. + + The underground economy has evolved very rapidly over the past few + years. In the early days of bots and botnets, their activities were + largely devoted to DDoS attacks and were relatively easy to detect. + As the underground economy has evolved, so have the botnets. They + have moved from easily detectable behavior to masquerading as normal + user network activity to achieve their goals, making detection very + difficult even by vigilant system administrators. + + The drive for this rapid evolution comes to a large extent from the + change in the intention of miscreant activity. Early virus attacks + and botnets were largely anarchic activities. Many were done by + "script kiddies" to disrupt systems without a real purpose or to + demonstrate the prowess of the attacker, for example in compromising + systems that were touted as "secure". Mirroring the + commercialization of the Internet and its increasing use for + e-business, miscreant activity is now mostly focused on conventional + criminal lines. Systems are quietly subverted with the goal of + obtaining illicit financial gain in the future, rather than causing + visible disruptions as was often the aim of the early hackers. + +2.2. Our Enemy Using Our Networks, Our Tools + + Internet Relay Chat (IRC) servers are commonly used as the command + and control channel for the underground market. These servers are + paid for by miscreants and are professionally supported. They are + advertised widely to attract potential consumers, and thus are easy + to find. The miscreants first talk to each other on the servers to + find out who is offering what on the market, then exchange encrypted + private messages to settle the deals. + + The miscreants are not afraid of network operators seeing their + actions. If their activities are interrupted, they simply move to + another venue. When ISPs take actions to protect their customers, + revenge attacks are uncommon as long as the miscreants' cash flow is + not disturbed. When a botnet is taken out, they move on to the next + one, as there is a plentiful supply. However, if an IRC server is + taken out that disturbs their cash flow, miscreants can be ruthless + and severe attacks may follow. They currently have no fear, as they + know the chances of their being caught are minimal. + + + + +Andersson, et al. Informational [Page 6] + +RFC 4948 Unwanted Traffic August 2007 + + + Our enemies make good use of the Internet's global connectivity as + well as all the tools the Internet has developed. IRC servers + provide a job market for the miscreants and shopping malls of attack + tools. Networking research has produced abundant results making it + easier to build large scale distributed systems, and these have been + adopted by miscreants to build large size, well-controlled botnets. + Powerful search engines also enable one to quickly find readily + available tools and resources. The sophistication of attacks has + increased with time, while the skills required to launch effective + attacks have become minimal. Attackers can be hiding anywhere in the + Internet while attacks get launched on a global scale. + +2.3. Compromised Systems Being a Major Source of Problems + + The current Internet provides a field ripe for exploitation. The + majority of end hosts run vulnerable platforms. People from all + walks of life eagerly jump into the newly discovered online world, + yet without the proper training needed to understand the full + implications. This is at least partially due to most users failing + to anticipate how such a great invention can be readily abused. As a + result, the Internet has ended up with a huge number of compromised + hosts, without their owners being aware that it has happened. + + Unprotected hosts can be compromised in multiple ways. Viruses and + worms can get into the system through exploiting bugs in the existing + operating systems or applications, sometimes even in anti-virus + programs. A phishing site may also take the opportunity to install + malware on a victim's computer when a user is lured to the site. + More recently, viruses have also started being propagated through + popular peer-to-peer file sharing applications. With multiple + channels of propagation, malware has become wide-spread, and infected + machines include not only home PCs (although they do represent a + large percentage), but also corporate servers, and even government + firewalls. + + News of new exploits of vulnerabilities of Microsoft Windows + platforms is all too frequent, which leads to a common perception + that the Microsoft Windows platform is a major source of + vulnerability. One of the reasons for the frequent vulnerability + exploits of the Windows system is its popularity in the market place; + thus, a miscreant's investment in each exploit can gain big returns + from infecting millions of machines. As a result, each incident is + also likely to make headlines in the news. In reality, all other + platforms such as Linux, Solaris, and MAC OS for example, are also + vulnerable to compromises. Routers are not exempt from security + break-ins either, and using a high-end router as a DoS launchpad can + be a lot more effective than using a bundle of home PCs. + + + + +Andersson, et al. Informational [Page 7] + +RFC 4948 Unwanted Traffic August 2007 + + + Quietly subverting large numbers of hosts and making them part of a + botnet, while leaving their normal functionality and connectivity + essentially unimpaired, is now a major aim of miscreants and it + appears that they are being all too successful. Bots and the + functions they perform are often hard to detect and most of the time + their existence are not known to system operators or owners (hence, + the alternative name for hosts infected with bots controlled by + miscreants - zombies); by the time they are detected, it might very + well be too late as they have carried out the intended + (mal-)function. + + The existence of a large number of compromised hosts is a + particularly challenging problem to the Internet's security. Not + only does the stolen financial information lead to enormous economic + losses, but also there has been no quick fix to the problem. As + noted above, in many cases the owners of the compromised computers + are unaware of the problem. Even after being notified, some owners + still do not care about fixing the problem as long as their own + interest, such as playing online games, is not affected, even though + the public interest is endangered --- large botnets can use multi- + millions of such compromised hosts to launch DDoS attacks, with each + host sending an insignificant amount of traffic but the aggregate + exceeding the capacity of the best engineered systems. + +2.4. Lack of Meaningful Deterrence + + One of the Internet's big strengths is its ability to provide + seamless interconnection among an effectively unlimited number of + parties. However, the other side of the same coin is that there may + not be clear ways to assign responsibilities when something goes + wrong. Taking DDoS attacks as an example, an attack is normally + launched from a large number of compromised hosts, the attack traffic + travels across the Internet backbone to the access network(s) linking + to the victims. As one can see, there are a number of independent + stake-holders involved, and it is not immediately clear which party + should take responsibility for resolving the problem. + + Furthermore, tracking down an attack is an extremely difficult task. + The Internet architecture enables any IP host to communicate with any + other hosts, and it provides no audit trails. As a result, not only + is there no limit to what a host may do, but also there is no trace + after the event of what a host may have done. At this time, there is + virtually no effective tool available for problem diagnosis or packet + trace back. Thus, tracking down an attack is labor intensive and + requires sophisticated skills. As will be mentioned in the next + section, there is also a lack of incentive to report security + attacks. Compounded with the high cost, these factors make forensic + tracing of an attack to its root a rare event. + + + +Andersson, et al. Informational [Page 8] + +RFC 4948 Unwanted Traffic August 2007 + + + In human society, the legal systems provide protection against + criminals. However, in the cyberspace, the legal systems are lagging + behind in establishing regulations. The laws and regulations aim at + penalizing the conduct after the fact. If the likelihood of + detection is low, the deterrence would be minimal. Many national + jurisdictions have regulations about acts of computer fraud and + abuse, and they often carry significant criminal penalties. In the + US (and many other places), it is illegal to access government + computers without authorization, illegal to damage protected + government computers, and illegal to access confidential information + on protected computers. However, the definition of "access" can be + difficult to ascertain. For example, is sending an ICMP (Internet + Control Messaging Protocol) packet to a protected computer considered + illegal access? There is a lack of technical understanding among + lawmakers that would be needed to specify the laws precisely and + provide effective targeting limited to undesirable acts. Computer + fraud and liabilities laws provide a forum to address illegal access + activities and enable prosecution of cybercriminals. However, one + difficulty in prosecuting affiliate programs using bot infrastructure + is that they are either borderline legal, or there is little + evidence. There is also the mentality of taking legal action only + when the measurable monetary damage exceeds a high threshold, while + it is often difficult to quantify the monetary damage in individual + cases of cyberspace crimes. + + There is a coalition between countries on collecting cybercriminal + evidence across the world, but there is no rigorous way to trace + across borders. Laws and rules are mostly local to a country, + policies (when they exist) are mostly enacted and enforced locally, + while the Internet itself, that carries the unwanted traffic, + respects no borders. One estimate suggests that most players in the + underground economy are outside the US, yet most IRC servers + supporting the underground market may be running in US network + providers, enjoying the reliable service and wide connectivity to the + rest of the world provided by the networks. + + In addition, the definition of "unwanted" traffic also varies between + different countries. For example, China bans certain types of + network traffic that are considered legitimate elsewhere. Yet + another major difficulty is the trade-off and blurred line between + having audit trails to facilitate forensic analysis and to enforce + censorship. The greater ability we build into the network to control + traffic, the stronger would be the monitoring requirements coming + from the legislators. + + It should be emphasized that, while a legal system is necessary to + create effective deterrence and sanctions against miscreants, it is + by no means sufficient on its own. Rather, it must be accompanied by + + + +Andersson, et al. Informational [Page 9] + +RFC 4948 Unwanted Traffic August 2007 + + + technical solutions to unwanted traffic detection and damage + recovery. It is also by no means a substitute for user education. + Only a well informed user community can collectively establish an + effective defense in the cyberspace. + +2.5. Consequences + + What we have today is not a rosy picture: there are + + o big economic incentives and a rich environment to exploit, + + o no specific party to carry responsibility, + + o no auditing system to trace back to the sources of attacks, and + + o no well established legal regulations to punish offenders. + + The combination of these factors inevitably leads to ever increasing + types and volume of unwanted traffic. However, our real threats are + not the bots or DDoS attacks, but the criminals behind them. + Unwanted traffic is no longer only aiming for maximal disruption; in + many cases, it is now a means to illicit ends with the specific + purpose of generating financial gains for the miscreants. Their + crimes cause huge economic losses, counted in multiple billions of + dollars and continuing. + +3. How Bad Is The Problem? + + There are quite a number of different kinds of unwanted traffic on + the Internet today; the discussions at this workshop were mainly + around DDoS traffic and spam. The impact of DDoS and spam on + different parts of the network differs. Below, we summarize the + impact on backbone providers, access providers, and enterprise + customers, respectively. + +3.1. Backbone Providers + + Since backbone providers' main line of business is packet forwarding, + the impact of unwanted traffic is mainly measured by whether DDoS + traffic affects network availability. Spam or malware is not a major + concern because backbone networks do not directly support end users. + Router compromises may exist, but they are rare events at this time. + +3.1.1. DDoS Traffic + + Observation shows that, in the majority of DDoS attacks, attack + traffic can originate from almost anywhere in the Internet. In + particular, those regions with high speed user connectivity but + + + +Andersson, et al. Informational [Page 10] + +RFC 4948 Unwanted Traffic August 2007 + + + poorly managed end hosts are often the originating sites of DDoS + attacks. The miscreants tend to find targets that offer maximal + returns with minimal efforts. + + Backbone networks in general are well-provisioned in regard to + traffic capacities. Therefore, core routers and backbone link + capacity do not get affected much by most DDoS attacks; a 5Gbps + attack could be easily absorbed without causing noticeable impact on + the performance of backbone networks. However, DDoS attacks often + saturate access networks and make a significant impact on customers. + In particular, multihomed customers who have multiple well- + provisioned connections for high throughput and performance may + suffer from aggregated DDoS traffic coming in from all directions. + +3.1.2. Problem Mitigation + + Currently, backbone networks do not have effective diagnosis or + mitigation tools against DDoS attacks. The foremost problem is a + lack of incentives to deploy security solutions. Because IP transit + services are a commodity, controlling cost is essential to surviving + the competition. Thus, any expenditure tends to require a clearly + identified return-on-investment (ROI). Even when new security + solutions become available, providers do not necessarily upgrade + their infrastructure to deploy the solutions, as security solutions + are often prevention mechanisms that may not have an easily + quantifiable ROI. To survive in the competitive environment in which + they find themselves, backbone providers also try to recruit more + customers. Thus, a provider's reputation is important. Due to the + large number of attacks and inadequate security solution deployment, + effective attacks and security glitches can be expected. However, it + is not in a provider's best interest to report all the observed + attacks. Instead, the provider's first concern is to minimize the + number of publicized security incidents. For example, a "trouble + ticket" acknowledging the problem is issued only after a customer + complains. An informal estimate suggested that only about 10% of + DDoS attacks are actually reported (some other estimates have put the + figure as low as 2%). In short, there is a lack of incentives to + either report problems or deploy solutions. + + Partly as a consequence of the lack of incentive and lack of funding, + there exist few DDoS mitigation tools for backbone providers. + Network operators often work on their own time to fight the battle + against malicious attacks. Their primary mitigation tools today are + Access Control Lists (ACL) and BGP (Border Gateway Protocol) null + routes to black-hole unwanted traffic. These tools can be turned on + locally and do not require coordination across administrative + domains. When done at, or near, DDoS victims, these simple tools can + have an immediate effect in reducing the DDoS traffic volume. + + + +Andersson, et al. Informational [Page 11] + +RFC 4948 Unwanted Traffic August 2007 + + + However, these tools are rather rudimentary and inadequate, as we + will elaborate in Section 4.2.1. + +3.2. Access Providers + + A common issue that access providers share with backbone providers is + the lack of incentive and the shortage of funding needed to deploy + security solutions. As with the situation with security incidents on + the backbone, the number of security incidents reported by access + providers is estimated to be significantly lower than the number of + the actual incidents that occurred. + + Because access providers are directly connected to end customers, + they also face unique problems of their own. From the access + providers' viewpoint, the most severe impact of unwanted traffic is + not the bandwidth exhaustion, but the customer support load it + engenders. The primary impact of unwanted traffic is on end users, + and access providers must respond to incident reports from their + customers. Today, access providers are playing the role of IT help + desk for many of their customers, especially residential users. + According to some access providers, during the Microsoft Blaster worm + attack, the average time taken to handle a customer call was over an + hour. Due to the high cost of staffing the help desks, it is + believed that, if a customer calls the help desk just once, the + provider would lose the profit they would otherwise have otherwise + made over the lifetime of that customer account. + + To reduce the high customer service cost caused by security breaches, + most access providers offer free security software to their + customers. It is much cheaper to give the customer "free" security + software in the hope of preventing system compromises than handling + the system break-ins after the event. However, perhaps due to their + lack of understanding of the possible security problems they may + face, many customers fail to install security software despite the + free offer from their access providers, or even when they do, they + may lack the skill needed to configure a complex system correctly. + + What factors may influence how quickly customers get the security + breaches fixed? Past experience suggests the following observations: + + o Notification has little impact on end user repair behavior. + + o There is no significant difference in terms of repair behavior + between different industries or between business and home users. + + o Users' patching behavior follows an exponential decay pattern with + a time constant of approximately 40% per month. Thus, about 40% + of computers tend to be patched very quickly when a patch is + + + +Andersson, et al. Informational [Page 12] + +RFC 4948 Unwanted Traffic August 2007 + + + released, and approximately 40% of the remaining vulnerable + computers in each following month will show signs of being + patched. This leaves a few percent still unpatched after 6 + months. In the very large population of Internet hosts, this + results in a significant number of hosts that will be vulnerable + for the rest of their life. + + o There is a general lack of user understanding: after being + compromised, unmanaged computers may get replaced rather than + repaired, and this often results in infections occurring during + the installation process on the replacement. + +3.3. Enterprise Networks: Perspective from a Large Enterprise + + The operators of one big enterprise network reported their experience + regarding unwanted traffic to the workshop. Enterprises perceive + many forms of bad traffic including worms, malware, spam, spyware, + Instant Messaging (IM), peer-to-peer (P2P) traffic, and DoS. + Compared to backbone and access providers, enterprise network + operators are more willing to investigate security breaches, although + they may hesitate to pay a high price for security solutions. False + positives are very costly. Most operators prefer false negatives to + false positives. In general, enterprises prefer prevention solutions + to detection solutions. + + Deliberately created unwanted traffic (as opposed to unwanted traffic + that might arise from misconfiguration) in enterprise networks can be + sorted into three categories. The first is "Nuisance", which + includes unwanted traffic such as spam and peer-to-peer file sharing. + Although there were different opinions among the workshop + participants as to whether P2P traffic should, or should not, be + considered as unwanted traffic, enterprise network operators are + concerned not only that P2P traffic represents a significant share of + the total network load, but they are also sensitive to potential + copyright infringement issues that might lead to significant + financial and legal impacts on the company as a whole. In addition, + P2P file sharing applications have also became a popular channel for + malware propagation. + + The second category of unwanted traffic is labeled "Malicious", which + includes the traffic that spreads malware. This class of traffic can + be small in volume but the cost from the resulting damage can be + high. The clean up after an incident also requires highly skilled + operators. + + The third category of unwanted traffic is "Unknown": it is known that + there exists a class of traffic in the network that can be best + described in this way, as no one knows its purpose or the locations + + + +Andersson, et al. Informational [Page 13] + +RFC 4948 Unwanted Traffic August 2007 + + + of the sources. Malicious traffic can be obscured by encryption, + encapsulation, or covered up as legitimate traffic. The existing + detection tools are ineffective for this type of traffic. Noisy + worms are easy to identify, but stealth worms can open a backdoor on + hosts and stay dormant for a long time without causing any noticeable + detrimental effect. This type of bad traffic has the potential to + make the greatest impact on an enterprise from a threat perspective. + + There are more mitigation tools available for enterprise networks + than for backbone and access network providers; one explanation might + be the greater affordability of solutions for enterprise networks. + The costs of damage from a security breach can also have a very + significant impact on the profits of an enterprise. At the same + time, however, the workshop participants also expressed concerns + regarding the ongoing arms race between security exploits and + patching solutions. Up to now, security efforts have, by and large, + been reactive, creating a chain of security exploits and a consequent + stream of "fixes". Such a reactive mode has not only created a big + security market, but also does not enable us to get ahead of + attackers. + +3.4. Domain Name Services + + Different from backbone and access providers, there also exists a + class of Internet service infrastructure providers. Provision of + Domain Name System (DNS) services offers an example here. As + reported by operators from a major DNS hosting company, over time + there have been increasingly significant DDoS attacks on .com, .net + and root servers. + + DNS service operators have witnessed large scale DDoS attacks. The + most recent ones include reflection attacks resulting from queries + using spoofed source addresses. The major damage caused by these + attacks are bandwidth and resource exhaustion, which led to + disruption of critical services. The peak rate of daily DNS + transactions has been growing at a much faster rate than the number + of Internet users, and this trend is expected to continue. The heavy + load on the DNS servers has led to increasing complexity in providing + the services. + + In addition to intentional DDoS Attacks, some other causes of the + heavy DNS load included (1) well known bugs in a small number of DNS + servers that still run an old version of the BIND software, causing + significant load increase at top level servers; and (2) + inappropriately configured firewalls that allow DNS queries to come + out but block returning DNS replies, resulting in big adverse impacts + on the overall system. Most of such issues have been addressed in + the DNS operational guidelines drafted by the IETF DNS Operations + + + +Andersson, et al. Informational [Page 14] + +RFC 4948 Unwanted Traffic August 2007 + + + Working Group; however, many DNS operators have not taken appropriate + actions. + + At this time, the only effective and viable mitigation approach is + over-engineering the DNS service infrastructure by increasing link + bandwidth, the number of servers, and the server processing power, as + well as deploying network anycast. There is a concern about whether + the safety margin gained from over-engineering is, or is not, + adequate in sustaining DNS services over future attacks. Looking + forward, there are also a few new issues looming. Two imminent ones + are the expected widespread deployment of IPv6 whose new DNS software + would inevitably contain new bugs, and the DNS Security Extensions + (DNSSEC), which could potentially be abused to generate DDoS attacks. + +4. Current Vulnerabilities and Existing Solutions + + This section summarizes three aspects of the workshop discussions. + We first collected the major vulnerabilities mentioned in the + workshop, then made a summary of the existing solutions, and followed + up with an examination of the effectiveness, or lack of it, of the + existing solutions. + +4.1. Internet Vulnerabilities + + Below is a list of known Internet vulnerabilities and issues around + unwanted traffic. + + o Packet source address spoofing: there has been speculation that + attacks using spoofed source addresses are decreasing, due to the + proliferation of botnets, which can be used to launch various + attacks without using spoofed source addresses. It is certainly + true that not all the attacks use spoofed addresses; however, many + attacks, especially reflection attacks, do use spoofed source + addresses. + + o BGP route hijacking: in a survey conducted by Arbor Networks, + route hijacking together with source address spoofing are listed + as the two most critical vulnerabilities on the Internet. It has + been observed that miscreants hijack bogon prefixes for spam + message injections. Such hijacks do not affect normal packet + delivery and thus have a low chance of being noticed. + + o Everything over HTTP: port scan attacks occur frequently in + today's Internet, looking for open TCP or UDP ports through which + to gain access to computers. The reaction from computer system + management has been to close down all the unused ports, especially + in firewalls. One result of this reaction is that application + designers have moved to transporting all data communications over + + + +Andersson, et al. Informational [Page 15] + +RFC 4948 Unwanted Traffic August 2007 + + + HTTP to avoid firewall traversal issues. Transporting "everything + over HTTP" does not block attacks but has simply moved the + vulnerability from one place to another. + + o Everyone comes from Everywhere: in the earlier life of the + Internet it had been possible to get some indication of the + authenticity of traffic from a specific sender based for example + on the Time To Live (TTL). The TTL would stay almost constant + when traffic from a certain sender to a specific host entered an + operators network, since the sender will "always" set the TTL to + the same value. If a change in the TTL value occurred without an + accompanying change in the routing, one could draw the conclusion + that this was potential unwanted traffic. However, since hosts + have become mobile, they may be roaming within an operator's + network and the resulting path changes may put more (or less) hops + between the source and the destination. Thus, it is no longer + possible to interpret a change in the TTL value, even if it occurs + without any corresponding change in routing, as an indication that + the traffic has been subverted. + + o Complex Network Authentication: Network authentication as it is + used today is far too complex to be feasible for users to use + effectively. It will also be difficult to make it work with new + wireless access technologies. + + A possible scenario envisages a customers handset that is + initially on a corporate wireless network. If that customer + steps out of the corporate building, the handset may get + connected to the corporate network through a GPRS network. The + handset may then roam to a wireless LAN network when the user + enters a public area with a hotspot. Consequently, we need + authentication tools for cases when the underlying data link + layer technology changes quickly, possibly during a single + application session. + + o Unused Security Tools: Vendors and standards have produced quite a + number of useful security tools; however, not all, or even most, + of them get used extensively. + +4.2. Existing Solutions + +4.2.1. Existing Solutions for Backbone Providers + + Several engineering solutions exist that operators can deploy to + defend the network against unwanted traffic. Adequate provisioning + is one commonly used approach that can diminish the impact of DDoS on + the Internet backbone. The solution that received most mentions at + the workshop was BCP 38 on ingress filtering: universal deployment of + + + +Andersson, et al. Informational [Page 16] + +RFC 4948 Unwanted Traffic August 2007 + + + BCP 38 can effectively block DDoS attacks using spoofed source IP + addresses. At present, Access Control List (ACL) and BGP null + routing are the two tools most commonly used by network operators to + mitigate DDoS attacks. They are effective in blocking DDoS attacks, + especially when being applied at or near a victim's site. + + Unfortunately, BCP 38 is not widely deployed today. BCP 38 may + require device upgrades, and is considered tedious to configure and + maintain. Although widespread deployment of BCP 38 could benefit the + Internet as a whole, deployment by individual sites imposes a certain + amount of cost to the site, and does not provide a direct and + tangible benefit in return. In other words, BCP 38 suffers from a + lack of deployment incentives. + + Both BGP null routing and ACL have the drawback of relying on manual + configuration and thus are labor intensive. In addition, they also + suffer from blocking both attack and legitimate packets. There is + also a potential that some tools could back-fire, e.g., an overly + long ACL list might significantly slow down packet forwarding in a + router. + + Unicast Reverse Path Filtering (uRPF), which is available on some + routers, provides a means of implementing a restricted form of BCP 38 + ingress filtering without the effort of maintaining ACLs. uRPF uses + the routing table to check that a valid path back to the source + exists. However, its effectiveness depends on the specificity of the + routes against which source addresses are compared. The prevalence + of asymmetric routing means that the strict uRPF test (where the + route to the source must leave from the same interface on which the + packet being tested arrived) may have to be replaced by the loose + uRPF test (where the route may leave from any interface). The loose + uRPF test is not a guarantee against all cases of address spoofing, + and it may still be necessary to maintain an ACL to deal with + exceptions. + +4.2.2. Existing Solutions for Enterprise Networks + + A wide variety of commercial products is available for enterprise + network protection. Three popular types of protection mechanisms are + + o Firewalls: firewalls are perhaps the most widely deployed + protection products. However, the effectiveness of firewalls in + protecting enterprise confidential information can be weakened by + spyware installed internally, and they are ineffective against + attacks carried out from inside the perimeter established by the + firewalls. Too often, spyware installation is a byproduct of + installing other applications permitted by end users. + + + + +Andersson, et al. Informational [Page 17] + +RFC 4948 Unwanted Traffic August 2007 + + + o Application level gateways: these are becoming more widely used. + However, because they require application-specific support, and in + many cases they cache all the in-flight documents, configuration + can be difficult and the costs high. Thus, enterprise network + operators prefer network level protections over layer-7 solutions. + + o Anti-spam software: Anti-spam measures consume significant human + resources. Current spam mitigation tools include blacklists and + content filters. The more recent "learning" filters may help + significantly reduce the human effort needed and decrease the + number of both false positives and negatives. + + A more recent development is computer admission control, where a + computer is granted network access if and only if it belongs to a + valid user and appears to have the most recent set of security + patches installed. It is however a more expensive solution. A major + remaining issue facing enterprise network operators is how to solve + the user vulnerability problem and reduce reliance on user's + understanding of the need for security maintenance. + +4.3. Shortfalls in the Existing Network Protection + +4.3.1. Inadequate Tools + + Generally speaking, network and service operators do not have + adequate tools for network problem diagnosis. The current approaches + largely rely on the experience and skills of the operators, and on + time-consuming manual operations. The same is true for mitigation + tools against attacks. + +4.3.2. Inadequate Deployments + + The limited number of existing Internet protection measures have not + been widely deployed. Deployment of security solutions requires + resources which may not be available. It also requires education + among the operational community to recognize the critical importance + of patch installation and software upgrades; for example, a bug in + the BIND packet was discovered and fixed in 2003, yet a number of DNS + servers still run the old software today. Perhaps most importantly, + a security solution must be designed with the right incentives to + promote their deployment. Effective protection also requires + coordination between competing network providers. For the time + being, it is often difficult to even find the contact information for + operators of other networks. + + A number of workshop participants shared the view that, if all the + known engineering approaches and bug fixes were universally deployed, + the Internet could have been enjoying a substantially reduced number + + + +Andersson, et al. Informational [Page 18] + +RFC 4948 Unwanted Traffic August 2007 + + + of security problems today. In particular, the need for, and lack + of, BCP 38 deployment was mentioned numerous times during the + workshop. There is also a lack of enthusiasm about the routing + security requirements document being developed by the IETF RPSEC + (Routing Protocol Security) Working Group, which focuses heavily on + cryptographically-based protection requirements. Not only would + cryptographically-based solutions face the obstacle of funding for + deployment, but also they are likely to bring with them their own set + of problems. + +4.3.3. Inadequate Education + + There exists an educational challenge to disseminate the knowledge + needed for secure Internet usage and operations. Easily guessed + passwords and plaintext password transmission are still common in + many parts of the Internet. One common rumor claims that Cisco + routers were shipped with a default password "cisco" and this was + used by attackers to break into routers. In reality, operators often + configure Cisco routers with that password, perhaps because of the + difficulty of disseminating passwords to multiple maintainers. A + similar problem exists for Juniper routers and other vendors' + products. + + How to provide effective education to the Internet user community at + large remains a great challenge. As mentioned earlier in this + report, the existence of a large number of compromised hosts is one + major source of the unwanted traffic problem, and the ultimate + solution to this problem is a well-informed, vigilant user community. + +4.3.4. Is Closing Down Open Internet Access Necessary? + + One position made at the workshop is that, facing the problems of + millions of vulnerable computers and lack of effective deterrence, + protecting the Internet might require a fundamental change to the + current Internet architecture, by replacing unconstrained open access + to the Internet with strictly controlled access. Although the + participants held different positions on this issue, a rough + consensus was reached that, considering the overall picture, + enforcing controlled access does not seem the best solution to + Internet protection. Instead, the workshop identified a number of + needs that should be satisfied to move towards a well protected + Internet: + + o the need for risk assessment for service providers; at this time, + we lack a commonly agreed bar for security assurance; + + o the need to add traceability to allow tracking of abnormal + behavior in the network, and + + + +Andersson, et al. Informational [Page 19] + +RFC 4948 Unwanted Traffic August 2007 + + + o the need for liability if someone fails to follow recommended + practices. + + Adding traceability has been difficult due to the distributed nature + of the Internet. Collaboration among operators is a necessity in + fighting cybercrimes. We must also pay attention to preparation for + the next cycle of miscreant activity, and not devote all our efforts + to fixing the existing problems. As discussed above, the current + reactive approach to security problems is not a winning strategy. + +5. Active and Potential Solutions in the Pipeline + + This section addresses the issues that vendors recognized as + important and for which there will be solutions available in the near + future. + + There are a number of potential solutions that vendors are working + on, but are not yet offering as part of their product portfolio, that + will allegedly remedy or diagnose the problems described in + Section 4.1. + + Inevitably, when vendors have or are about to make a decision on + implementing new features in their products but have not made any + announcement, the vendors are not willing to talk about the new + features openly, which limits what can be said in this section. + +5.1. Central Policy Repository + + One idea is to build a Central Policy Repository that holds policies + that are known to work properly, e.g., policies controlling from whom + one would accept traffic when under attack. This repository could, + for example, keep information on which neighbor router or AS is doing + proper ingress address filtering. The repository could also hold the + configurations that operators use to upgrade configurations on their + routers. + + If such a repository is to be a shared resource used by multiple + operators, it will necessarily require validation and authentication + of the stored policies to ensure that the repository does not become + the cause of vulnerabilities. Inevitably, this would mean that the + information comes with a cost and it will only be viable if the sum + of the reductions in individual operators' costs is greater than the + costs of maintaining the repository. + + + + + + + + +Andersson, et al. Informational [Page 20] + +RFC 4948 Unwanted Traffic August 2007 + + +5.2. Flow Based Tools + + A set of tools based on flow data is widely used to extract + information from both network and data link layers. Tools have been + built that can be used to find out the sources of almost any type of + traffic, including certain unwanted traffic. These flow-based tools + make it possible to do things like DDoS traceback, traffic/peering + analyses, and detection of botnets, worms, and spyware. + + These tools monitor flows on the network and build baselines for what + is the "normal" behavior. Once the baseline is available, it is + possible to detect anomalous activity. It is easy to detect + variations over time, and decide if the variation is legitimate or + not. It is possible to take this approach further, typically + involving the identification of signatures of particular types of + traffic. + + These flow-based tools are analogous to the "sonar" that is used by + navies to listen for submarines. Once a particular submarine is + identified, it is possible to record its sonar signature to be used + to provide rapid identification in the future when the same submarine + is encountered again. + + Examples of existing tools include + Cisco IOS NetFlow <http://www.cisco.com/en/US/products/ps6601/ + products_ios_protocol_group_home.html>, + sFlow <http://www.sflow.org/>, and + NeTraMet <http://www.caida.org/tools/measurement/netramet/> based on + the IETF RTFM and IPFIX standards. + + There are also tools for working with the output of NetFlow such as + jFlow <http://www.net-track.ch/opensource/jflow/> and + Arbor Networks' Peakflow + <http://www.arbor.net/products_platform.php>. + + The Cooperative Association for Internet Data Analysis (CAIDA) + maintains a taxonomy of available tools on its web site at + <http://www.caida.org/tools/taxonomy/index.xml>. + +5.3. Internet Motion Sensor (IMS) + + The Internet Motion Sensor (IMS) [IMS] may be used to watch traffic + to or from "Darknets" (routable prefixes that don't have end hosts + attached), unassigned address spaces, and unannounced address spaces. + By watching activities in these types of address spaces, one can + understand and detect, e.g., scanning activities, DDoS worms, worm + infected hosts, and misconfigured hosts. + + + + +Andersson, et al. Informational [Page 21] + +RFC 4948 Unwanted Traffic August 2007 + + + Currently, the IMS is used to monitor approximately 17 million + prefixes, about 1.2% of the IPv4 address space. The use of IMS has + highlighted two major characteristics of attacks; malicious attacks + are more targeted than one might have assumed, and a vulnerability in + a system does not necessarily lead to a threat to that system (e.g., + the vulnerability may not be exploited to launch attacks if the + perceived "benefit" to the attacker appears small). Data from IMS + and other sources indicates that attackers are making increased use + of information from social networking sites to target their attacks + and select perceived easy targets, such as computers running very old + versions of systems or new, unpatched vulnerabilities. + + This form of passive data collection is also known as a "Network + Telescope". Links to similar tools can be found on the CAIDA web + site at <http://www.caida.org/data/passive/network_telescope.xml>. + +5.4. BCP 38 + + In the year 2000, the IETF developed a set of recommendations to + limit DOS attacks and Address Spoofing published as BCP 38 [RFC2827], + "Network Ingress Filtering: Defeating Denial of Service Attacks which + employ IP Source Address Spoofing". However, up to now BCP 38 + capabilities still have not been widely deployed, perhaps due to the + incentive issue discussed earlier. + + The IETF has also developed an additional set of recommendations + extending BCP 38 to multihomed networks. These recommendations are + published as BCP 84 [RFC3704]. + +5.5. Layer 5 to 7 Awareness + + Tools are being developed that will make it possible to perform deep + packet inspection at high speed. Some companies are working on + hardware implementation to inspect all layers from 2 to 7 (e.g., + EZchip <http://www.ezchip.com/t_npu_whpaper.htm>). A number of other + companies, including Cisco and Juniper, offer tools capable of + analyzing packets at the transport layer and above. + +5.6. How To's + + One idea that was discussed at the workshop envisaged operators and + standards bodies cooperating to produce a set of "How To" documents + as guidelines on how to configure networks. Dissemination and use of + these "How To's" should be encouraged by vendors, operators, and + standards bodies. + + + + + + +Andersson, et al. Informational [Page 22] + +RFC 4948 Unwanted Traffic August 2007 + + + This type of initiative needs a "sponsor" or "champion" that takes + the lead and starts collecting a set of "How To's" that could be + freely distributed. The workshop did not discuss this further. + +5.7. SHRED + + Methods to discourage the dissemination of spam by punishing the + spammers, such as Spam Harassment Reduction via Economic Disincentive + (SHRED) [SHRED], were discussed. The idea is to make it increasingly + expensive for spammers to use the email system, while normal users + retain what they have come to expect as normal service. There was no + agreement on the effectiveness of this type of system. + +6. Research in Progress + + In preparation for this session, several researchers active in + Internet Research were asked two rather open ended questions: "Where + is the focus on Internet research today?" and "Where should it be?" + + A summary of the answers to these questions is given below. + Section 6.2.2 covers part of the relationship between research and + miscreants. For example, research activities in each area (please + refer to the slide set for Workshop Session 8 which can be found at + the link referred to in Appendix C). + +6.1. Ongoing Research + + Section 6.1 discusses briefly areas where we see active research on + unwanted traffic today. + +6.1.1. Exploited Hosts + + One area where researchers are very active is analyzing situations + where hosts are exploited. This has been a major focus for a long + time, and an abundance of reports have been published. Current + research may be divided into three different categories: prevention, + detection, and defense. + +6.1.1.1. Prevention + + Code quality is crucial when it comes to preventing exploitation of + Internet hosts. Quite a bit of research effort has therefore gone + into improvement of code quality. Researchers are looking into + automated methods for finding bugs and maybe in the end fixes for any + bugs detected. + + A second approach designed to stop hosts from becoming compromised is + to reduce the "attack surface". Researchers are thinking about + + + +Andersson, et al. Informational [Page 23] + +RFC 4948 Unwanted Traffic August 2007 + + + changes or extensions to the Internet architecture. The idea is to + create a strict client server architecture, where the clients only + are allowed to initiate connections, and while servers may only + accept connections. + + Researchers have put a lot of effort into better scaling of honey + pots and honey farms to better understand and neutralize the methods + miscreants are using to exploit hosts. Research also goes into + developing honey monkeys in order to understand how hosts are + vulnerable. Both honey pots/farms and honey monkeys are aimed at + taking measures that prevent further (mis-)use of possible exploits. + +6.1.1.2. Detection + + When an attack is launched against a computer system, the attack + typically leaves evidence of the intrusion in the system logs. Each + type of intrusion leaves a specific kind of footprint or signature. + The signature can be evidence that certain software has been + executed, that logins have failed, that administrative privileges + have been misused, or that particular files and directories have been + accessed. Administrators can document these attack signatures and + use them to detect the same type of attack in the future. This + process can be automated. + + Because each signature is different, it is possible for system + administrators to determine by looking at the intrusion signature + what the intrusion was, how and when it was perpetrated, and even how + skilled the intruder is. + + Once an attack signature is available, it can be used to create a + vulnerability filter, i.e., the stored attack signature is compared + to actual events in real time and an alarm is given when this pattern + is repeated. + + A further step may be taken with automated vulnerability signatures, + i.e., when a new type of attack is found, a vulnerability filter is + automatically created. This vulnerability filter can be made + available for nodes to defend themselves against this new type of + attack. The automated vulnerability signatures may be part of an + Intrusion Detection System (IDS). + +6.1.1.3. Defense + + An IDS can be a part of the defense against actual attacks, e.g., by + using vulnerability filters. An Intrusion Detection System (IDS) + inspects inbound and outbound network activities and detects + signatures that indicate that a system is under attack from someone + attempting to break into or compromise the system. + + + +Andersson, et al. Informational [Page 24] + +RFC 4948 Unwanted Traffic August 2007 + + +6.1.2. Distributed Denial of Service (DDoS) Attacks + + Research on DDoS attacks follows two separate approaches, the first + has the application as its focus, while the second focuses on the + network. + +6.1.2.1. Application Oriented DDoS Research + + The key issue with application oriented research is to distinguish + between legitimate activities and attacks. Today, several tools + exist that can do this and research has moved on to more advanced + things. + + Research today looks into tools that can detect and filter activities + that have been generated by bots and botnets. + + One approach is to set up a tool that sends challenges to senders + that want to send traffic to a certain node. The potential sender + then has to respond correctly to that challenge; otherwise, the + traffic will be filtered out. + + The alternative is to get more capacity between sender and receiver. + This is done primarily by some form of use of peer-to-peer + technology. + + Today, there is "peer-to-peer hype" in the research community; a sure + way of making yourself known as a researcher is to publish something + that solves old problems by means of some peer-to-peer technology. + Proposals now exist for peer-to-peer DNS, peer-to-peer backup + solutions, peer-to-peer web-cast, etc. Whether these proposals can + live up to the hype remains to be seen. + +6.1.2.2. Network Oriented DDoS Research + + Research on DDoS attacks that takes a network oriented focus may be + described by the following oversimplified three steps. + + 1. Find the bad stuff + + 2. Set the "evil bit" on those packets + + 3. Filter out the packets with the "evil bit" set + + This rather uncomplicated scheme has to be carried out on high-speed + links and interfaces. Automation is the only way of achieving this. + + One way of indirectly setting the "evil bit" is to use a normalized + TTL. The logic goes: the TTL for traffic from this sender has always + + + +Andersson, et al. Informational [Page 25] + +RFC 4948 Unwanted Traffic August 2007 + + + been "x", but has now suddenly become "y", without any corresponding + change in routing. The conclusion is that someone is masquerading as + the legitimate sender. Traffic with the "y" TTL is filtered out. + + Another idea is to give traffic received from ISPs that are known to + do source address validation the "red carpet treatment", i.e., to set + the "good bit". When an attack is detected, traffic from everyone + that doesn't have the "good bit" is filtered out. Apart from + reacting to the attack, this also give ISPs an incentive to do source + address validation. If they don't do it, their peers won't set the + "good bit" and the ISP's customers will suffer, dragging down their + reputation. + + Overlay networks can also be used to stop a DDoS attack. The idea + here is that traffic is not routed directly to the destination. + Instead, it is hidden behind some entry points in the overlay. The + entry points make sure the sender is the host he claims he is, and in + that case, marks the packet with a "magic bit". Packets lacking the + "magic bit" are not forwarded on the overlay. This has good scaling + properties; you only need to have enough capacity to tag the amount + of traffic you want to receive, not the amount you actually receive. + +6.1.3. Spyware + + Current research on spyware and measurements of spyware are aiming to + find methods to understand when certain activities associated with + spyware happen and to understand the impact of this activity. + + There are a number of research activities around spyware, e.g., + looking into threats caused by spyware; however, these were only + briefly touched upon at the workshop. + +6.1.4. Forensic Aids + + Lately, research has started to look into tools and support to answer + the "What happened here?" question. These tools are called "forensic + aids", and can be used to "recreate" an illegal activity just as the + police do when working on a crime scene. + + The techniques that these forensic aids take as their starting point + involve the identification of a process or program that should not be + present on a computer. The effort goes into building tools and + methods that can trace the intruder back to its origin. Methods to + understand how a specific output depends on a particular input also + exist. + + + + + + +Andersson, et al. Informational [Page 26] + +RFC 4948 Unwanted Traffic August 2007 + + +6.1.5. Measurements + + Measurements are always interesting for the research community, + because they generate new data. Consequently, lots of effort goes + into specifying how measurements should be performed and into + development of measurement tools. Measurements have been useful in + creating effective counter-measures against worms. Before + measurements gave actual data of how worms behave, actions taken + against worms were generally ineffective. + +6.1.6. Traffic Analysis + + One aspect of research that closely relates to measurements is + analysis. Earlier, it was common to look for the amount of traffic + traversing certain transport ports. Lately, it has become common to + tunnel "everything" over something else, and a shift has occurred + towards looking for behavior and/or content. When you see a certain + behavior or content over a protocol that is not supposed to behave in + this way, it is likely that something bad is going on. + + Since this is an arms race, the miscreants that use tunneling + protocols have started to mimic the pattern of something that is + acceptable. + +6.1.7. Protocol and Software Security + + The general IETF design guidelines for robust Internet protocols + says: "Be liberal in what you receive and conservative in what you + send". The downside is that most protocols believe what they get and + as a consequence also get what they deserve. The IAB is intending to + work on new design guidelines, e.g., rules of thumb and things you do + and things you don't. This is not ready yet, but will be offered as + input to a BCP in due course. + + An area where there is a potential overlap between standards people + and researchers is protocol analysis languages. The protocol + analysis languages could be used, for example, look for + vulnerabilities. + +6.2. Research on the Internet + + The workshop discussed the interface between people working in + standardization organizations in general and IETF in particular on + the one hand and people working with research on the other. The + topic of discussion was broader than just "Unwanted traffic". Three + topics were touched on: what motivates researchers, how to attract + researchers to problems that are hindering or have been discovered in + + + + +Andersson, et al. Informational [Page 27] + +RFC 4948 Unwanted Traffic August 2007 + + + the context of standardization, and the sometimes rocky relations + between the research community and the "bad boys". + +6.2.1. Research and Standards + + The workshop discussed how research and standardization could + mutually support each other. Quite often there is a commonality of + interest between the two groups. The IAB supports the Internet + Research Task Force (IRTF) as a venue for Internet research. The + delta between what is done and what could be is still substantial. + The discussion focused on how standardization in general and the IETF + in particular can get help from researchers. + + Since standardization organizations don't have the economic strength + to simply finance the research they need or want, other means have to + be used. One is to correctly and clearly communicate problems, + another is to supply adequate and relevant information. + + To attract the research community to work with standardization + organizations, it is necessary to identify the real problems and + state them in such a way that they are amenable to solution. General + unspecified problems are of no use, e.g., "This is an impossible + problem!" or "All the problems are because my users behave badly!" + + Instead, saying "This is an absolutely critical problem, and we have + no idea how to solve it!" is much more attractive. + + The potential research problem should also be communicated in a way + that is public. A researcher that wants to take on a problem is + helped if she/he can point at a slide from NANOG or RIPE that + identifies this problem. + + The way researchers go about solving problems is basically to + identify all the existing constraints, and then relax one of the + constraints and see what happens. Therefore, rock solid constraints + are a show stopper, e.g., "We can't do that, because it has to go + into an ASIC!". Real constraints have to be clearly communicated to + and understood by the researcher. + + One reasonable way of fostering cooperation is to entice two or three + people and have them write a paper on the problem. What will happen + then is that this paper will be incrementally improved by other + researchers. The vast majority of all research goes into improving + on someone else's paper. + + A second important factor is to supply sufficient relevant + information. New information that suggests possible ways to address + new problems or improve on old or partial solutions to previously + + + +Andersson, et al. Informational [Page 28] + +RFC 4948 Unwanted Traffic August 2007 + + + investigated problems are attractive. Often, understanding of + important problems comes from the operator community; when trying to + initiate research from a standards perspective, keeping operators in + the loop may be beneficial. + + Today, the research community is largely left on its own, and + consequently tends to generate essentially random, untargeted + results. If the right people in the standards community say the + right things to the right people in the research community, it can + literally focus hundreds of graduate students on a single problem. + Problem statements and data are needed. + +6.2.2. Research and the Bad Guys + + A general problem with all research and development is that what can + be used may also be misused. In some cases, miscreants have received + help from research that was never intended. + + There are several examples of Free Nets, i.e., networks designed to + allow end-users to participate without revealing their identity or + how and where they are connected to the network. The Free Nets are + designed based on technologies such as onion routing or mix networks. + Free Nets create anonymity that allows people to express opinions + without having to reveal their true identity and thus can be used to + promote free speech. However, these are tools that can also work + just as well to hide illegal activities in democracies. + + Mix networks create hard-to-trace communications by using a chain of + proxy servers. A message from a sender to a receiver passes by the + chain of proxies. A message is encrypted with a layered encryption + where each layer is understood by only one of the proxies in the + chain; the actual message is the innermost layer. A mix network will + achieve untraceable communication, even if all but one of the proxies + are compromised by a potential tracer. + + Onion routing is a technique for anonymous communication over a + computer network; it is a technique that encodes routing information + in a set of encrypted layers. Onion routing is a further development + of mix networks. + + Research projects have resulted in methods for distributed command + and control, e.g., in the form of Distributed Hash Tables (DHT) and + gossip protocols. This of course has legitimate uses, e.g., for + security and reliability applications, but it also is extremely + useful for DDoS attacks and unwanted traffic in general. + + A lot of effort has gone into research around worms, the result is + that we have a very good understanding of the characteristics of the + + + +Andersson, et al. Informational [Page 29] + +RFC 4948 Unwanted Traffic August 2007 + + + technology associated with worms and how they behave. This is a very + good basis when we want to protect against worms. The downside is + that researchers also understand how to implement future worms, + including knowledge on how to design faster worms that won't leave a + footprint. + +7. Aladdin's Lamp + + If we had an Aladdin's Lamp and could be granted anything we wanted + in the context of remedying unwanted traffic or effects of such + traffic - what would we wish for? The topic of this session was + wishes, i.e., loosening the constraints that depend on what we have + and focus on what we really want. + + There certainly are lots of "wishes" around, not least of which is + making things simpler and safer. On the other hand, very few of + these wishes are clearly stated. One comment on this lack of clarity + was that we are too busy putting out the fires of today and don't + have the time to be thinking ahead. + +7.1. Security Improvements + + Operators at the workshop expressed a number of wishes that, if + fulfilled, would help to improve and simplify security. The list + below contains a number of examples of actions that ought to improve + security. The content is still at the "wish-level", i.e., no effort + has gone in to trying to understand the feasibility of realizing + these wishes. + + Wish: Reliable point of contact in each administrative domain for + security coordination. + First and foremost, operators would like to see correct and complete + contact information to coordinate security problems across operators. + + The "whois" database of registration details for IP addresses and + Autonomous System numbers held by Regional Internet Registries (e.g., + ARIN, RIPE, APNIC) was intended to be a directory for this type of + information, and RFC 2142 [RFC2142] established common mailbox names + for certain roles and services. There are several reasons why these + tools are largely unused, including unwanted traffic. + + Wish: Organized testing for security. + Today, new hardware and software are extensively tested for + performance. There is almost no testing of this hardware and + software for security. + + + + + + +Andersson, et al. Informational [Page 30] + +RFC 4948 Unwanted Traffic August 2007 + + + Wish: Infrastructure or test bed for security. + It would be good to have an organized infrastructure or test bed for + testing of security for new products. + + Wish: Defaults for security. + Equipment and software should come with a simple and effective + default setting for security. + + Wish: Shared information regarding attacks. + It would be useful to have an automated sharing mechanism for + attacks, vulnerabilities, and sources of threats between network + users and providers in order to meet attacks in a more timely and + efficient manner. + +7.2. Unwanted Traffic + + Wish: Automatic filtering of unwanted traffic. + It would be useful, not least for enterprises, to have mechanisms + that would automatically filter out the unwanted traffic. + + Some filtering of spam, viruses, and malware that is sent by email is + already practicable but inevitably is imperfect because it mainly + relies on "heuristics" to identify the unwanted traffic. This is + another example of the "arms race" between filtering and the + ingenuity of spammers trying to evade the filters. This "wish" needs + to be further discussed and developed to make it something that could + be turned into practical ideas. + + Wish: Fix Spam. + A large fraction of the email traffic coming into enterprises today + is spam, and consequently any fixes to the spam problem are very high + on their priority list. + +8. Workshop Summary + + The workshop spent its last two hours discussing the following + question: What are the engineering (immediate and longer term) and + research issues that might be pursued within the IETF and the IRTF, + and what actions could the IAB take? The suggested actions can be + summarized into three classes. + +8.1. Hard Questions + + The discussions during this concluding section raised a number of + questions that touched upon the overall network architecture designs. + + o What should be the roles of cryptographic mechanisms in the + overall Internet architecture? For example, do we need to apply + + + +Andersson, et al. Informational [Page 31] + +RFC 4948 Unwanted Traffic August 2007 + + + cryptographic mechanisms to harden the shell, or rely on deep + packet inspection to filter out bad traffic? + + o To add effective protection to the Internet, how far are we + willing to go in + + * curtailing its openness, and + + * increasing the system complexity? + + And what architectural principles do we need to preserve as we go + along these paths? + + o A simple risk analysis would suggest that an ideal attack target + of minimal cost but maximal disruption is the core routing + infrastructure. However, do we really need an unlinked and + separately managed control plane to secure it? This requires a + deep understanding of the architectural design trade-offs. + + o Can we, and how do we, change the economic substructure? A + special workshop was suggested as a next step to gain a better + understanding of the question. + +8.2. Medium or Long Term Steps + + While answering the above hard questions may take some time and + effort, several specific steps were suggested as medium or long term + efforts to add protection to the Internet: + + o Tightening the security of the core routing infrastructure. + + o Cleaning up the Internet Routing Registry repository [IRR], and + securing both the database and the access, so that it can be used + for routing verifications. + + o Take down botnets. + + o Although we do not have a magic wand to wave all the unwanted + traffic off the Internet, we should be able to develop effective + measures to reduce the unwanted traffic to a tiny fraction of its + current volume and keep it under control. + + o Community education, to try to ensure people *use* updated host, + router, and ingress filtering BCPs. + + + + + + + +Andersson, et al. Informational [Page 32] + +RFC 4948 Unwanted Traffic August 2007 + + +8.3. Immediately Actionable Steps + + The IETF is recommended to take steps to carry out the following + actions towards enhancing the network protection. + + o Update the host requirements RFC. The Internet host requirements + ([RFC1122], [RFC1123]) were developed in 1989. The Internet has + gone through fundamental changes since then, including the + pervasive security threats. Thus, a new set of requirements is + overdue. + + o Update the router requirements. The original router requirements + [RFC1812] were developed in 1995. As with the host requirements, + it is also overdue for an update. + + o Update ingress filtering (BCP 38 [RFC2827] and BCP 84 [RFC3704]). + + One immediate action that the IAB should carry out is to inform the + community about the existence of the underground economy. + + The IRTF is recommended to take further steps toward understanding + the Underground Economy and to initiate research on developing + effective countermeasures. + + Overall, the workshop attendees wish to raise the community's + awareness of the underground economy. The community as a whole + should undertake a systematic examination of the current situation + and develop both near- and long-term plans. + +9. Terminology + + This section gives an overview of some of the key concepts and + terminology used in this document. It is not intended to be + complete, but is offered as a quick reference for the reader of the + report. + + ACL + Access Control List in the context of Internet networking refers to a + set of IP addresses or routing prefixes (layer 3 or Internet layer + information), possibly combined with transport protocol port numbers + (layer 4 or transport layer information). The layer 3 and/or layer 4 + information in the packets making up a flow entering or leaving a + device in the Internet is matched against the entries in an ACL to + determine whether the packets should, for example, be allowed or + denied access to some resources. The ACL effectively specifies a + filter to be used on a flow of packets. + + + + + +Andersson, et al. Informational [Page 33] + +RFC 4948 Unwanted Traffic August 2007 + + + BGP route hijacking + Attack in which an inappropriate route is injected into the global + routing system with the intent of diverting traffic from its intended + recipient either as a DoS attack (q.v.) where the traffic is just + dropped or as part of some wider attack on the recipient. Injecting + spurious routes specifying addresses used for bogons can, for + example, provide bogus assurance to email systems that spam is coming + from legitimate addresses. + + Bogon + A bogon is an IP packet that has a source address taken for a range + of addresses that has not yet been allocated to legitimate users, or + is a private [RFC1918] or reserved address [RFC3330]. + + Bogon prefix + A bogon prefix is a route that should never appear in the Internet + routing table, e.g., from the private or unallocated address blocks. + + Bot + A bot is common parlance on the Internet for a software program that + is a software agent. A Bot interacts with other network services + intended for people as if it were a real person. One typical use of + bots is to gather information. The term is derived from the word + "robot," reflecting the autonomous character in the "virtual robot"- + ness of the concept. + The most common bots are those that covertly install themselves on + people's computers for malicious purposes, and that have been + described as remote attack tools. Bots are sometimes called + "zombies". + + Botnet + Botnet is a jargon term for a collection of software robots, or bots, + which run autonomously. This can also refer to the network of + computers using distributed computing software. While the term + "botnet" can be used to refer to any group of bots, such as IRC bots, + the word is generally used to refer to a collection of compromised + machines running programs, usually referred to as worms, Trojan + horses, or backdoors, under a common command and control + infrastructure. + + Click fraud + Click fraud occurs in pay per click (PPC) advertising when a person, + automated script, or computer program imitates a legitimate user of a + web browser clicking on an ad for the purpose of generating an + improper charge per click. Pay per click advertising is when + operators of web sites act as publishers and offer clickable links + from advertisers in exchange for a charge per click. + + + + +Andersson, et al. Informational [Page 34] + +RFC 4948 Unwanted Traffic August 2007 + + + Darknet + A Darknet (also known as a Network Telescope, a Blackhole, or an + Internet Sink) is a globally routed network that has no "real" + machines attached and carries only a very small amount of specially + crafted legitimate traffic. It is therefore easily possible to + separate out and analyze unwanted traffic that can arise from a wide + variety of events including misconfiguration (e.g., a human being + mis-typing an IP address), malicious scanning of address space by + hackers looking for vulnerable targets, backscatter from random + source denial-of-service attacks, and the automated spread of + malicious software called Internet worms. + + Dirty affiliate program + Affiliate programs are distributed marketing programs that recruit + agents to promote a product or service. Affiliates get financially + compensated for each sale associated with their unique 'affiliate + ID.' Affiliates are normally instructed by the operator of the + affiliate program to not break any laws while promoting the product + or service. Sanctions (typically loss of unpaid commissions or + removal from the affiliate program) are normally applied if the + affiliate spams or otherwise violates the affiliate program's + policies. + + Dirty affiliate programs allow spamming, or if they do nominally + prohibit spamming, they don't actually sanction violators. Dirty + affiliate programs often promote illegal or deceptive products + (prescription drugs distributed without regard to normal dispensing + requirements, body part enlargement products, etc.), employ anonymous + or untraceable affiliates, offer payment via anonymous online + financial channels, and may fail to follow normal tax withholding and + reporting practices. + + DoS attack + Denial-Of-Service attack, a type of attack on a network that is + designed to bring the network to its knees by flooding it with + useless traffic or otherwise blocking resources necessary to allow + normal traffic flow. + + DDoS attack + Distributed Denial of Service, an attack where multiple compromised + systems are used to target a single system causing a Denial of + Service (DoS) attack. + + Honey farm + A honey farm is a set of honey pots working together. + + + + + + +Andersson, et al. Informational [Page 35] + +RFC 4948 Unwanted Traffic August 2007 + + + Honey monkey + A honey monkey is a honey pot in reverse; instead of sitting and + waiting for miscreants, a honey monkey actively mimics the actions of + a user surfing the Web. The honey monkey runs on virtual machines in + order to detect exploit sites. + + Honey pot + A honey pot is a server attached to the Internet that acts as a + decoy, attracting potential miscreants in order to study their + activities and monitor how they are able to break into a system. + Honeypots are designed to mimic systems that an intruder would like + to break into but limit the intruder from having access to an entire + network. + + IRC + Internet Relay Chat is a form of instant communication over the + Internet. It is mainly designed for group (many-to-many) + communication in discussion forums called channels, but also allows + one-to-one communication, originally standardized by RFC 1459 + [RFC1459] but much improved and extended since its original + invention. IRC clients rendezvous and exchange messages through IRC + servers. IRC servers are run by many organizations for both benign + and nefarious purposes. + + Malware + Malware is software designed to infiltrate or damage a computer + system, without the owner's informed consent. There are + disagreements about the etymology of the term itself, the primary + uncertainty being whether it is a portmanteau word (of "malicious" + and "software") or simply composed of the prefix "mal-" and the + morpheme "ware". Malware references the intent of the creator, + rather than any particular features. It includes computer viruses, + worms, Trojan horses, spyware, adware, and other malicious and + unwanted software. In law, malware is sometimes known as a computer + contaminant. + + Mix networks + Mix networks create hard-to-trace communications by using a chain of + proxy servers [MIX]. Each message is encrypted to each proxy; the + resulting encryption is layered like a Russian doll with the message + as the innermost layer. Even if all but one of the proxies are + compromised by a tracer, untraceability is still achieved. More + information can be found at + <http://www.adastral.ucl.ac.uk/~helger/crypto/link/protocols/ + mix.php>. + + + + + + +Andersson, et al. Informational [Page 36] + +RFC 4948 Unwanted Traffic August 2007 + + + Onion routing + Onion routing is a technique for anonymous communication over a + computer network, it is a technique that encodes routing information + in a set of encrypted layers. Onion routing is based on mix cascades + (see mix networks (q.v.)). More information can be found at + <http://www.onion-router.net/>. + + Phishing + Phishing is a form of criminal activity using social engineering + techniques. It is characterized by attempts to fraudulently acquire + sensitive information, such as passwords and credit card details, by + masquerading as a trustworthy person or business in an apparently + official electronic communication. Phishing is typically carried out + using spoofed websites, email, or an instant message. The term + phishing derives from password harvesting and the use of increasingly + sophisticated lures to "fish" for users' financial information and + passwords. + + Root access + Access to a system with full administrative privileges bypassing any + security restrictions placed on normal users. Derived from the name + traditionally used for the 'superuser' on Unix systems. + + Script kiddy + Derogatory term for an inexperienced hacker who mindlessly uses + scripts and other programs developed by others with the intent of + compromising computers or generating DoS attacks. + + Spam + Spamming is the abuse of electronic messaging systems to send + unsolicited, undesired bulk messages. The individual messages are + refereed to as spam. The term is frequently used to refer + specifically to the electronic mail form of spam. + + Spoofing + (IP) spoofing is a technique where the illegitimate source of IP + packets is obfuscated by contriving to use IP address(es) that the + receiver recognizes as a legitimate source. Spoofing is often used + to gain unauthorized access to computers or mislead filtering + mechanisms, whereby the intruder sends packets into the network with + an IP source address indicating that the message is coming from a + legitimate host. To engage in IP spoofing, a hacker must first use a + variety of techniques to find an IP address of a valid host and then + modify the packet headers so that it appears that the packets are + coming from that host. + + + + + + +Andersson, et al. Informational [Page 37] + +RFC 4948 Unwanted Traffic August 2007 + + + Spyware + Any software that covertly gathers user information through the + user's Internet connection without his or her knowledge, e.g., for + spam purposes. + + UBE + Unsolicited Bulk Email: an official term for spam. + + UCE + Unsolicited Commercial Email: an official term for spam. + + Virus + A program or piece of code that is loaded onto a computer without the + owner's knowledge and runs without their consent. A virus is self- + replicating code that spreads by inserting copies of itself into + other executable code or documents, which are then transferred to + other machines. Typically, the virus has a payload that causes some + harm to the infected machine when the virus code is executed. + + Worm + A computer worm is a self-replicating computer program. It uses a + network to send copies of itself to other systems and it may do so + without any user intervention. Unlike a virus, it does not need to + attach itself to an existing program. Worms always harm the network + (if only by consuming bandwidth), whereas viruses always infect or + corrupt files on a targeted computer. + + Zombie + This is another name for a bot. + +10. Security Considerations + + This document does not specify any protocol or "bits on the wire". + +11. Acknowledgements + + The IAB would like to thank the University of Southern California + Information Sciences Institute (ISI) who hosted the workshop and all + those people at ISI and elsewhere who assisted with the organization + and logistics of the workshop at ISI. + + The IAB would also like to thank the scribes listed in Appendix A who + diligently recorded the proceedings during the workshop. + + A special thanks to all the participants in the workshop, who took + the time, came to the workshop to participate in the discussions, and + who put in the effort to make this workshop a success. The IAB + + + + +Andersson, et al. Informational [Page 38] + +RFC 4948 Unwanted Traffic August 2007 + + + especially appreciates the effort of those that prepared and made + presentations at the workshop. + +12. Informative References + + [IMS] University of Michigan, "Internet Motion Sensor", 2006, + <http://ims.eecs.umich.edu/>. + + [IRR] Merit Network Inc, "Internet Routing Registry Routing + Assets Database", 2006, <http://www.irr.net/>. + + [MIX] Hill, R., Hwang, A., and D. Molnar, "Approaches to Mix + Nets", MIT 6.857 Final Project, December 1999, <http:// + www.mit.edu/afs/athena/course/6/6.857/OldStuff/Fall99/ + papers/mixnet.ps.gz>. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. + + [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", + RFC 1459, May 1993. + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", + RFC 1812, June 1995. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND + FUNCTIONS", RFC 2142, May 1997. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, + September 2002. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + [SHRED] Krishnamurthy, B. and E. Blackmond, "SHRED: Spam + Harassment Reduction via Economic Disincentives", 2003, + <http://www.research.att.com/~bala/papers/shred-ext.ps>. + + + +Andersson, et al. Informational [Page 39] + +RFC 4948 Unwanted Traffic August 2007 + + +Appendix A. Participants in the Workshop + + Bernard Aboba (IAB) + Loa Andersson (IAB) + Ganesha Bhaskara (scribe) + Bryan Burns + Leslie Daigle (IAB chair) + Sean Donelan + Rich Draves (IAB Executive Director) + Aaron Falk (IAB, IRTF chair) + Robert Geigle + Minas Gjoka (scribe) + Barry Greene + Sam Hartman (IESG, Security Area Director) + Bob Hinden (IAB) + Russ Housely (IESG, Security Area Director) + Craig Huegen + Cullen Jennings + Rodney Joffe + Mark Kosters + Bala Krishnamurthy + Gregory Lebovitz + Ryan McDowell + Danny McPherson + Dave Merrill + David Meyer (IAB) + Alan Mitchell + John Morris + Eric Osterweil (scribe) + Eric Rescorla (IAB) + Pete Resnick (IAB) + Stefan Savage + Joe St Sauver + Michael Sirivianos (scribe) + Rob Thomas + Helen Wang + Lixia Zhang (IAB) + + + + + + + + + + + + + + +Andersson, et al. Informational [Page 40] + +RFC 4948 Unwanted Traffic August 2007 + + +Appendix B. Workshop Agenda + + Session 1: + How bad is the problem? What are the most important symptoms? + + Session 2: + What are the sources of the problem? + + Lunch session (session 3): + Solutions in regulatory and societal space + + Session 4: + The underground economy + + Session 5: + Current countermeasures, what works, what doesn't + + Session 6: + If all our wishes could be granted, what would they be? + + Session 7: + What's in the pipeline, or should be in the pipeline + + Session 8: + What is being actively researched on? + + Session 9: + What are the engineering (immediate and longer term) and + research issues that might be pursued within the IETF/IAB/IRTF? + +Appendix C. Slides + + Links to a subset of the presentations given by the participants at + the workshop can be found via the IAB Workshops page on the IAB web + site at <http://utgard.ietf.org/iab/about/workshops/unwantedtraffic/ + index.html>. As mentioned in Section 1, this is not a complete set + of the presentations because certain of the presentations were of a + sensitive nature which it would be inappropriate to make public at + this time. + + + + + + + + + + + + +Andersson, et al. Informational [Page 41] + +RFC 4948 Unwanted Traffic August 2007 + + +Authors' Addresses + + Loa Andersson + Acreo AB + + EMail: loa@pi.se + + + Elwyn Davies + Folly Consulting + + EMail: elwynd@dial.pipex.com + + + Lixia Zhang + UCLA + + EMail: lixia@cs.ucla.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Andersson, et al. Informational [Page 42] + +RFC 4948 Unwanted Traffic August 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Andersson, et al. Informational [Page 43] + |