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).
AbstractThis 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.
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
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
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.
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.
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.
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.
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
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.
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.
However, these tools are rather rudimentary and inadequate, as we will elaborate in Section 4.2.1.
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.
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.
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.
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. BCP 38 on ingress filtering: universal deployment of
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.
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.
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.
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. 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.
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>. 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.
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>. 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]. 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.
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. 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. 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). Section 6.1 discusses briefly areas where we see active research on unwanted traffic today.
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.
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.
the context of standardization, and the sometimes rocky relations between the research community and the "bad boys".
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.
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. 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.
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.
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. 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.
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.
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.
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.
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>.
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.
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. 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
especially appreciates the effort of those that prepared and made presentations at the workshop. [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>.
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.
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 email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.