doc: Add RFC documents

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]
+