<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY rfc1123 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1123.xml">
<!ENTITY rfc1812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1812.xml">
<!ENTITY rfc1459 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1459.xml">
<!ENTITY rfc1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY rfc3330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3330.xml">
<!ENTITY rfc2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY rfc2142 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2142.xml">
<!ENTITY rfc3704 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes" ?>
<rfc number="4948" category="info">
  <!-- the 03-version -->

  <front>
    <title abbrev="Unwanted Traffic">Report from the IAB workshop on Unwanted
    Traffic March 9-10, 2006</title>

    <author fullname="Loa Andersson" initials="L" surname="Andersson">
      <organization>Acreo AB</organization>

      <address>
        <email>loa@pi.se</email>
      </address>
    </author>

    <!-- I added Elwyn here, given how much he helped withis this report.  But feel free to remove -->

    <author fullname="Elwyn Davies" initials="E. B." surname="Davies">
      <organization>Folly Consulting</organization>

      <address>
        <email>elwynd@dial.pipex.com</email>
      </address>
    </author>

    <author fullname="Lixia Zhang" initials="L" surname="Zhang">
      <organization>UCLA</organization>

      <address>
        <email>lixia@cs.ucla.edu</email>
      </address>
    </author>

    <date month="July" year="2007" />

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/rfcsearch.html. -->
    <keyword>example</keyword>

    <abstract>
      <t>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
<!-- [rfced] We recommend expanding IETF and IRTF if you are going to
expand IAB (as was done earlier in the paragraph) or remove the expansion
of IAB. -->
      development community at large to develop effective countermeasures
      against the unwanted traffic.</t>
    </abstract>
  </front>

  <middle>
    <!-- section 1 -->

    <section anchor="intro" title="Introduction">
      <t>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: <list style="symbols">
<t></t>
          <t>the kinds of unwanted traffic that are seen on the Internet,</t>

          <t>how bad the picture looks,</t>

          <t>who and where are the major sources of the problem,</t>

          <t>which solutions work and which do not, and</t>

          <t>what needs to be done.</t>
        </list></t>

      <t>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 issues identified. This
      will be done in part as activities within the IAB, the IETF, and the
      IRTF.</t>

      <t>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.</t>

      <t>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.</t>

      <t>The workshop participant list is attached in <xref
      target="participants"></xref>. The agenda of the workshop can be found
      in <xref target="agenda"></xref>. Links to a subset of the presentations
      are provided in <xref target="Slides"></xref>; 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 <!-- and the mechanisms used to create it and facilitate its distribution -->
      can be found in <xref target="terminology"></xref>.</t>
    </section>

    <!-- section 1 -->

    <!-- new section 2 -->

    <section anchor="evil"
             title="The Root of All Evils: An Underground Economy">
      <t>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
<!-- [rfced] Is common use "the cyberspace" or "cyberspace"? -->
      the potential danger of their computers being compromised. Moreover, the
      Internet was designed without built-in auditing trails. <!-- while this has
      contributed significantly to the Internet's success,--> 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.</t>

      <!-- section 2.1 -->

      <section title="The Underground Economy">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <!-- section 2.1 -->

      <!-- section 2.2 -->

      <section title="Our Enemy Using Our Networks, Our Tools">
        <t>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. <!-- One can typically see 35-40 busy IRC servers at any given moment.-->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.</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <!-- section 2.2 -->

      <!-- section 2.3 -->

      <section title="Compromised Systems Being a Major Source of Problems">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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. <!-- below was moved from 2.1, they seem to fit here better -->
        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.</t>

        <t>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.</t>
      </section>

      <!-- section 2.3 -->

      <!-- section 2.4 -->

      <section title="Lack of Meaningful Deterrence">
        <t>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.</t>

        <t>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.</t>

        <t>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. <!-- for example, a number of US congressmen still
        think the Internet is just the WEB.--> 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.</t>

        <!-- The
        number of independent stake-holders also results in 'distributed' loss
        and lack of clear victims in many cases. -->

        <t>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 providing the
<!-- [rfced] We suggest using "supporting the underground market"
instead of "providing the underground market".  -->
        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.</t>

        <t>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.</t>

        <t>It should be emphasized that, while a legal system is necessary to
        create effective deterrence and sanctions against miscreants, it is by
        no means sufficient on its own. Rather, it must be accompanied by
        technical solutions to unwanted traffic detection and damage recovery.
        It is also by no means a substitute for user education. Only a well
        informed user community can collectively establish an effective
        defense in the cyberspace.</t>

        <!--
        Consumer focused problems tend to get the most attention at least 
	in the US legislature. The effort so far has mostly focused on 
	traffic unwanted by end users, and SPAM is the first on the list.  
	The US Federal anti-SPAM law was passed in 2003, to ban unsolicited 
	commercial email, and the use of false/forged message headers.  
	It requires that the commercial nature of email distribution must be 
	clearly stated, and that users must be given opt-out options.  
	The law's main impact has been on legitimate bulk advertisers,  but 
	has had little impact on the illegal spammers. Under federal laws, 
	ISPs can take legal action against spammers. In addition to SPAMs, 
	there are also a large number of complaints about spyware.  But the 
	US federal government has not made any anti-spyware proposals. There 
	is also a big challenge of how to enforce laws in the cyberpace once 
	they are made.  In US the "Do not call" protection against unsolicited 
	advertisements has seen increasing incidences of violations, "do not 
	email" will likely face much greater enforcement challenges.
        -->
      </section>

      <!-- section 2.4 -->

      <!-- section 2.5 -->

      <section title="Consequences">
        <t>What we have today is not a rosy picture: there are <list
            style="symbols">
            <t>big economic incentives and a rich environment to exploit,</t>

            <t>no specific party to carry responsibility,</t>

            <t>no auditing system to trace back to the sources of attacks,
            and</t>

            <t>no well established legal regulations to punish offenders.</t>
          </list> The combination of these factors inevitably leads to ever
        increasing types and volume of unwanted traffic. <!-- Viruses and worms
        open backdoors on end hosts; malware is pervasive and bots are
        prevalent.--> 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.
<!-- [rfc-ed] We recommend deleting the word "multiple" as it is
redundant, and we recommend using "increasing" instead of
"continuing".  -->
</t>
      </section>

      <!-- section 2.5 -->
    </section>

    <!-- section 2 -->

    <!-- section 3 -->

    <section anchor="seen" title="How Bad Is The Problem?">
      <t>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.</t>

      <!-- section 3.1 -->

      <section anchor="backbone" title="Backbone Providers">
        <t>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.</t>

        <!-- section 3.1.1 -->

        <section title="DDoS Traffic">
          <t>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
          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.</t>

          <t>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.</t>
        </section>

        <!-- section 3.1.1 -->

        <!-- section 3.1.2 -->

        <section title="Problem Mitigation">
          <t>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 how to quickly
          resolve a trouble ticket that does get registered.--> 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%).
          <!-- Many
          customers and providers see little utility in reporting problems
          while others are concerned with the exposure or negative publicity
          that may follow.--> In short, there is a lack of incentives to
          either report problems or deploy solutions.</t>

          <t>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. However, these tools are rather rudimentary and inadequate,
          as we will elaborate in <xref
          target="backbone-solutions"></xref>.</t>
        </section>

        <!-- section 3.1.2 -->
      </section>

      <!-- section 3.1 -->

      <!-- section 3.2 -->

      <section anchor="access" title="Access Providers">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>What factors may influence how quickly customers get the security
        breaches fixed? Past experience suggests the following observations:
        <list style="symbols">
            <t>Notification has little impact on end user repair behavior.</t>

            <t>There is no significant difference in terms of repair behavior
            between different industries or between business and home
            users.</t>

            <t>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
            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.</t>

            <t>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.</t>
          </list></t>
      </section>

      <!-- section 3.2 -->

      <!-- section 3.3 -->

      <section anchor="enterprise"
               title="Enterprise Networks: Perspective from a Large Enterprise">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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 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.</t>

        <t>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.</t>
      </section>

      <!-- section 3.3 -->

      <!-- section 3.4 -->

      <section anchor="dns" title="Domain Name Services">
        <t>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.</t>

        <t>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.</t>

        <t>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 Working
        Group; however, many DNS operators have not taken appropriate actions.</t>

        <t>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.</t>
      </section>

      <!-- section 3.4 -->
    </section>

    <!-- section 3 -->

    <!-- section 4 -->

    <section anchor="exist"
             title="Current Vulnerabilities and Existing Solutions">
      <t>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.</t>

      <!-- section 4.1 -->

      <section anchor="vulnerable" title="Internet Vulnerabilities">
        <t>Below is a list of known Internet vulnerabilities and issues around
        unwanted traffic. <list style="symbols">
            <t>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.</t>

            <t>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.</t>

            <!--Editors note: Comment from Elwyn: Interesting! The reaction to
          the proposed SAVA seems to say that many have thrown up their hands
          and said the source spoofing is insoluble! -->

            <t>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
            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.</t>

            <t>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.</t>

            <!--LZ: The above is copied from Loa's message; I couldn't recall 
	    much of the above from the workshop-->

            <t>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. <list style="empty">
                <t>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.</t>
              </list></t>

            <!--From Loa message: "the data link layer" came in whith Elwyns 
	    editing, orignally it was "L2 technology" earlier, but I guess 
	    what was pointed at is that different types of access network 
	    technologies has impact on authentication mechanisms  -->

            <t>Unused Security Tools: Vendors and standards have produced
            quite a number of useful security tools; however, not all,
            even most, of them get used extensively.
<!-- [rfced] Should this read: not all, or even most? -->
</t>
          </list></t>
      </section>

      <!-- end of section 4.1 -->

      <!-- section 4.2 -->

      <section title="Existing Solutions">
        <!-- section 4.2.1 -->

        <section anchor="backbone-solutions"
                 title="Existing Solutions for Backbone Providers">
          <t>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 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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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 may lead to a false sense of security --> and it may still
          be necessary to maintain an ACL to deal with exceptions.</t>
        </section>

        <!-- section 4.2.1 -->

        <!-- section 4.2.2 -->

        <section title="Existing Solutions for Enterprise Networks">
          <t>A wide variety of commercial products is available for enterprise
          network protection. Three popular types of protection mechanisms are
          <list style="symbols">
              <t>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.</t>

              <t>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.</t>

              <t>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.</t>
            </list></t>

          <t>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.</t>

          <!-- Some comments from Joe St Sauver: Under 4.2.2, firewalls,
	 application level gateways, anti-spam software, and
	connection time admission control are mentioned, but some other common
	solutions are not. For example, passive intrustion detection systems (such 
	as Snort or Bro) aren't mentioned, nor are active scanning solutions (such 
	as Nessus). These are two basic classes of enterprise network protective
	tools that really should be mentioned (unless the intent is just to reflect 
	solely what was said during the symposia).-->
        </section>

        <!-- section 4.2.2 -->
      </section>

      <!-- section 4.2 -->

      <!-- section 4.3 -->

      <section title="Shortfalls in the Existing Network Protection">
        <!-- Section 4.3.1 -->

        <section title="Inadequate Tools">
          <t>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.</t>
        </section>

        <!-- Section 4.3.1 -->

        <!-- Section 4.3.2 -->

        <section title="Inadequate Deployments">
          <t>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.</t>

          <t>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 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.</t>
        </section>

        <!-- Section 4.3.2 -->

        <!-- Section 4.3.3 -->

        <section title="Inadequate Education">
          <t>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.</t>

          <t>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.</t>
        </section>

        <!-- Section 4.3.3 -->

        <!-- Section 4.3.4 -->

        <section title="Is Closing Down Open Internet Access Necessary?">
          <t>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: <list style="symbols">
              <t>the need for risk assessment for service providers; at this
              time, we lack a commonly agreed bar for security assurance;</t>

              <t>the need to add traceability to allow tracking of abnormal
              behavior in the network, and</t>

              <t>the need for liability if someone fails to follow recommended
              practices.</t>
            </list></t>

          <t>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.</t>
        </section>

        <!-- Section 4.3.4 -->
      </section>

      <!-- Section 4.3 -->
    </section>

    <!-- section 4 -->

    <!-- section 5 -->

    <section anchor="pipeline"
             title="Active and Potential Solutions in the Pipeline">
      <t>This section addresses the issues that vendors recognized as
      important and for which there will be solutions available in the near
      future.</t>

      <t>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 <xref
      target="vulnerable"></xref>.</t>

      <t>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.</t>

      <!-- section 5.1 -->

      <section anchor="central" title="Central Policy Repository">
        <t>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.<!--This type of tool of course requires more than just the database keeping the policies. 
For it to be fully effective a certain amount of coordination and authentication will be required.--></t>

        <t>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.</t>
      </section>

      <!-- section 5.2 -->

      <section anchor="flow" title="Flow Based Tools">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>Examples of existing tools include <vspace blankLines="0" />Cisco
        IOS NetFlow <eref
        target="http://www.cisco.com/en/US/products/ps6601/products_ios_protocol_group_home.html"></eref>,
        <vspace blankLines="0" />sFlow <eref
        target="http://www.sflow.org/"></eref>, and <vspace
        blankLines="0" />NeTraMet <eref
        target="http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html"></eref>
<!-- [rfced] Note, you may want to update this url; we were not able
to locate this page. -->
        based on the IETF RTFM and IPFIX standards.</t>

        <t>There are also tools for working with the output of NetFlow such as
        <vspace blankLines="0" />jFlow <eref
        target="http://www.net-track.ch/opensource/jflow/"></eref> and <vspace
        blankLines="0" />Arbor Networks' Peakflow <eref
        target="http://www.arbor.net/products_platform.php"></eref>.</t>

        <t>The Cooperative Association for Internet Data Analysis (CAIDA)
        maintains a taxonomy of available tools on its web site at <eref
        target="http://www.caida.org/tools/taxonomy/index.xml"></eref>.</t>
      </section>

      <!-- section 5.3 -->

      <section anchor="monitor" title="Internet Motion Sensor (IMS)">
        <t>The Internet Motion Sensor (IMS) <xref target="IMS"></xref> 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.</t>

        <t>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, <!-- (e.g., the majority of
        attacks are targeted against very old versions of systems or new,
        unpatched vulnerabilities)--> 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. </t>

        <t>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 <eref
        target="http://www.caida.org/data/passive/network_telescope.xml"></eref>.</t>
      </section>

      <!-- section 5.4 -->

      <section anchor="bcp-38" title="BCP 38">
        <t>In the year 2000, the IETF developed a set of recommendations to
        limit DOS attacks and Address Spoofing published as BCP 38 <xref
        target="RFC2827"></xref>, "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.</t>

        <t>The IETF has also developed an additional set of recommendations
        extending BCP 38 to multihomed networks. These recommendations are
        published as BCP 84 <xref target="RFC3704"></xref>.</t>
      </section>

      <!-- section 5.5 -->

      <section anchor="layer" title="Layer 5 to 7 Awareness">
        <t>Tools are being developed that will make it possible to <!--inspect packets (including Layer 5, 6 and 7)
	LZ: not sure what is layer 6 --> perform deep packet inspection at high
        speed. Some companies are working on hardware implementation to
        inspect all layers from 2 to 7 (e.g., <vspace blankLines="0" />EZchip
        <eref target="http://www.ezchip.com/html/tech_7layers.html"></eref>).
<!-- [rfced] Note, you may want to update this url; we were not able
to locate this page. -->
        A number of other companies, including Cisco and Juniper, offer tools
        capable of analyzing packets at the transport layer and above.</t>
      </section>

      <!-- section 5.6 -->

      <section anchor="how-to" title="How To's">
        <t>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.</t>

        <t>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.</t>
      </section>

      <!-- section 5.7 -->

      <section anchor="shred" title="SHRED">
        <t>Methods to discourage the dissemination of spam by punishing the
        spammers, such as Spam Harassment Reduction via Economic Disincentive
        (SHRED) <xref target="SHRED"></xref>, 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.</t>
      </section>
    </section>

    <!-- end of section 5 -->

    <!-- section 6 -->

    <section anchor="research" title="Research in Progress">
      <t>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?"</t>

      <t>A summary of the answers to these questions is given below. <!-- There is also a discussion on what motivates researchers and draws
	research to certain areas (see <xref target="motive"></xref>). --> <xref
      target="bad"></xref> 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 <xref target="Slides"></xref>).</t>

      <!-- section 6.1 -->

      <section anchor="ongoing" title="Ongoing Research">
        <t><xref target="ongoing"></xref> discusses briefly areas where we see
        active research on unwanted traffic today.</t>

        <!-- section 6.1.1 -->

        <section anchor="hosts" title="Exploited Hosts">
          <t>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.</t>

          <!-- section 6.1.1.1 -->

          <section anchor="prevent" title="Prevention">
            <t>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 may be in the
            end fixes for any bugs detected.</t>

            <t>A second approach designed to stop hosts from becoming compromised
            is to reduce the "attack surface". Researchers are thinking about
            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.</t>

            <t>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.</t>
          </section>

          <!-- section 6.1.1.2 -->

          <section anchor="detect" title="Detection">
            <t>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.</t>

            <t>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.</t>

            <t>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.</t>

            <t>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).</t>
          </section>

          <!-- section 6.1.1.3 -->

          <section anchor="defend" title="Defense">
            <t>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.</t>
          </section>
        </section>

        <!-- section 6.1.2 -->

        <section anchor="DDOS"
                 title="Distributed Denial of Service (DDoS) Attacks">
          <t>Research on DDoS attacks follows two separate approaches, the
          first has the application as its focus, while the second focuses on
          the network.</t>

          <!-- section 6.1.2.1 -->

          <section anchor="applic" title="Application Oriented DDoS Research">
            <t>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.</t>

            <t>Research today looks into tools that can detect and filter
            activities that have been generated by bots and botnets.</t>

            <t>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.</t>

            <t>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.</t>

            <t>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.</t>
          </section>

          <!-- section 6.1.2.2 -->

          <section anchor="network" title="Network Oriented DDoS Research">
            <t>Research on DDoS attacks that takes a network oriented focus
            may be described by the following oversimplified three steps.</t>

            <t><list style="numbers">
                <t>Find the bad stuff</t>

                <t>Set the "evil bit" on those packets</t>

                <t>Filter out the packets with the "evil bit" set</t>
              </list></t>

            <t>This rather uncomplicated scheme has to be carried out on
            high-speed links and interfaces. Automation is the only way of
            achieving this.</t>

            <t>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 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.</t>

            <t>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
<!-- [rfced] We are curious as to why it is the "good-bit" (with the
hyphen), but it is the "evil bit" (with a space)?  You may want to
make these consistent.  -->
            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. It they don't
            do it, their peers won't set the "good-bit" and the ISP's customers
            will suffer, dragging down their reputation.</t>

            <t>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.</t>
          </section>
        </section>

        <!-- section 6.1.3 -->

        <section anchor="spyware" title="Spyware">
          <t>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.</t>

          <t>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.</t>
        </section>

        <!-- section 6.1.4 -->

        <section anchor="forensic" title="Forensic Aids">
          <t>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.</t>

          <t>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.
          </t>
        </section>

        <!-- section 6.1.5 -->

        <section anchor="measurements" title="Measurements">
          <t>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.</t>
        </section>

        <!-- section 6.1.6 -->

        <section anchor="analysis" title="Traffic Analysis">
          <t>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.</t>

          <t>Since this is an arms race, the miscreants that use tunneling
          protocols have started to mimic the pattern of something that is
          acceptable.</t>
        </section>

        <!-- section 6.1.7 -->

        <section anchor="secure" title="Protocol and Software Security">
          <t>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.</t>

          <t>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.</t>
        </section>
      </section>

      <!-- section 6.2 -->

      <section anchor="unwant" title="Research on the Internet">
        <t>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 the context of
        standardization, and the sometimes rocky relations between the
        research community and the "bad boys".</t>

        <!--
	<section anchor="motive" title="What Motivates a Researcher">
          <t>[Editor's note: some reader of this draft suggested that this
          section on "What Motivates a Researcher" be removed from the final
          report, as this is a discussion on a more general issue and not
          specific to unwanted traffic. We would like to hear from workshop
          participants whether you disagree. This subsection will be removed
          if we do not hear disagreement.]</t>

          <t>It is no surprise that people within the research community are
          driven by pretty much the same motives as anyone else.</t>

          <t>One primary driving force is "fame", this is not famous in the
          same way as movie stars or people getting their picture on the front
          page of Time. Researchers want to be recognized, valued, and accepted
          within their own community. They look to their colleagues and peers,
          and want to feel like they matter.</t>

          <t>"Money" is also a strong motivator for researchers. Not in the
          sense that researchers expect to become immensely rich, but research
          has to be financed.</t>

          <t>Often the combination of "fame" and "money" results in what may
          appear as a "herd mentality", many researchers gather around a
          popular topic.</t>

          <t>Research around BGP convergence is a good example. "No one"
          studied BGP 10 years ago. Not because BGP wasn't out there or that
          there were not interesting problems. Researchers were more or less
          ignorant where BGP mattered and they had no data. Craig Labowitz
          started to publish his work and got into SigComm and suddenly RIPE
          and others made data available. Someone started, then data became
          available and now there are many BGP-experts in the research
          community.</t>
        </section>
	-->

        <!-- section 6.2.2 -->

        <section anchor="standard" title="Research and Standards">
          <t>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.</t>

          <t>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.</t>

          <t>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!"</t>

          <t>Instead, saying "This is an absolutely critical problem, and we
          have no idea how to solve it!" is much more attractive.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>A second important factor is to supply relevant and enough
          information. New information that opens up possibilities to address
          new problems or improve on old or partial solutions are attractive.
<!-- [rfced] We recommend the following text:

   A second important factor is to supply relevant and sufficient
   information. New information that can be used to address
   new problems or improve on old or partial solutions 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.</t>

          <t>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.</t>
        </section>

        <!--6.2.3-->

        <section anchor="bad" title="Research and the Bad Guys">
          <t>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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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 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.</t>
        </section>

        <!-- 6.2.3 -->
      </section>

      <!-- 6.2 -->
    </section>

    <!-- section 6 -->

    <!-- section 7 -->

    <section anchor="wishes" title="Aladdin's Lamp">
      <t>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.</t>

      <t>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.</t>

      <section anchor="sec-imp" title="Security Improvements">
        <t>Operators expressed wishes to improve and simplify security.
        The list below for actions to improve security are examples. 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.</t>

        <t>Wish: Reliable point of contact in each administrative domain for
        security coordination. <vspace blankLines="0" /> First and foremost,
        operators would like to see correct and complete contact information
        to coordinate security problems across operators.</t>

        <t>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 <xref target="RFC2142"></xref> established
        common mailbox names for certain roles and services. There are several
        reasons why these tools are largely unused, including unwanted
        traffic.</t>

        <t>Wish: Organized testing for security. <vspace blankLines="0" />
        Today, new hardware and software are extensively tested for
        performance. There is almost no testing of this hardware and software
        for security.</t>

        <t>Wish: Infrastructure or test bed for security. <vspace
        blankLines="0" /> It would be good to have an organized infrastructure
        or test bed for testing of security for new products.</t>

        <t>Wish: Defaults for security. <vspace blankLines="0" /> Equipment
        and software should come with a simple and effective default setting
        for security.</t>

        <t>Wish: Shared information regarding attacks. <vspace
        blankLines="0" /> 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.</t>
      </section>

      <section anchor="unwant-wish" title="Unwanted Traffic">
        <t>Wish: Automatic filtering of unwanted traffic. <vspace
        blankLines="0" /> It would be useful, not least for enterprises, to
<!-- [rfced] Do you mean "especially" instead of "not least"?  -->
        have possibilities to automatically filter out the unwanted
        traffic.</t>

        <t>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.</t>

        <t>Wish: Fix Spam. <vspace blankLines="0" />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.</t>
      </section>
    </section>

    <!-- section 8 -->

    <section anchor="summary" title="Workshop Summary">
      <t>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.</t>

      <!-- section 8.1 -->

      <section title="Hard Questions">
        <t>The discussions during this concluding section raised a number of
        questions that touched upon the overall network architecture designs.
        <list style="symbols">
            <t>What should be the roles of cryptographic mechanisms in the
            overall Internet architecture? For example, do we need to apply
            cryptographic mechanisms to harden the shell, or rely on deep
            packet inspection to filter out bad traffic?</t>

            <t>To add effective protection to the Internet, how far are we
            willing to go in <list style="symbols">
                <t>curtailing its openness, and</t>

                <t>increasing the system complexity?</t>
              </list> And what architectural principles do we need to preserve
            as we go along these paths?</t>

            <t>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.</t>

            <t>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.</t>
          </list></t>
      </section>

      <!-- section 8.1 -->

      <!-- section 8.2 -->

      <section title="Medium or Long Term Steps">
        <t>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:</t>

        <t><list style="symbols">
            <t>Tightening the security of the core routing infrastructure.</t>

            <t>Cleaning up the Internet Routing Registry repository <xref
            target="IRR"></xref>, and securing both the database and the
            access, so that it can be used for routing verifications.</t>

            <t>Take down botnets.</t>

            <t>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.</t>

            <t>Community education, to try to ensure people *use* updated
            host, router, and ingress filtering BCPs.</t>
          </list></t>
      </section>

      <!-- section 8.3 -->

      <section title="Immediately Actionable Steps">
        <t>The IETF is recommended to take steps to carry out the following
        actions towards enhancing the network protection. <list
            style="symbols">
            <t>Update the host requirements RFC. The Internet host
            requirements (<xref target="RFC1122"></xref>, <xref
            target="RFC1123"></xref>) 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.</t>

            <t>Update the router requirements. The original router
            requirements <xref target="RFC1812"></xref> were developed in
            1995. As with the host requirements, it is also overdue for an
            update.</t>

            <t>Update ingress filtering (BCP 38 <xref target="RFC2827"></xref>
            and BCP 84 <xref target="RFC3704"></xref>).</t>

            <!--LZ: need to dig out what needs to be updated here-->
          </list></t>

        <t>One immediate action that the IAB should carry out is to inform the
        community about the existence of the underground economy.</t>

        <t>The IRTF is recommended to take further steps toward understanding
        the Underground Economy and to initiate research on developing
        effective countermeasures.</t>

        <t>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.</t>
      </section>

      <!-- section 8.3 -->
    </section>

    <!-- section 8 -->

    <!-- Section 9 -->

    <section anchor="terminology" title="Terminology">
      <t>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.</t>

      <t>ACL <vspace blankLines="0" />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.</t>

      <t>BGP route hijacking<vspace blankLines="0" />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
<!-- [rfced] We do not understand the use of q.v. here; what do you
intend to direct the reader to?  -->
      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.</t>

      <t>Bogon<vspace blankLines="0" />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 <xref
      target="RFC1918"></xref> or reserved address <xref
      target="RFC3330"></xref>.</t>

      <t>Bogon prefix<vspace blankLines="0" />A bogon prefix is a route that
      should never appear in the Internet routing table, e.g., from the
      private or unallocated address blocks.</t>

      <t>Bot <vspace blankLines="0" /> A bot is a 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. <vspace blankLines="0" /> 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".</t>

      <t>Botnet <vspace blankLines="0" /> 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.</t>

      <t>Click fraud<vspace blankLines="0" />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.</t>

      <t>Darknet<vspace blankLines="0" />A Darknet (also known as a Network
      Telescope, a Blackhole, or an Internet Sink) is a globally routed network
      that has no "real" machine 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.</t>

      <t>Dirty affiliate program <vspace blankLines="0" />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.</t>

      <t>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.</t>

      <t>DoS attack <vspace blankLines="0" /> 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.</t>

      <t>DDoS attack <vspace blankLines="0" /> Distributed Denial of Service,
      an attack where multiple compromised systems are used to target a single
      system causing a Denial of Service (DoS) attack.</t>

      <t>Honey farm <vspace blankLines="0" /> A honey farm is a set of honey
      pots working together.</t>

      <t>Honey monkey <vspace blankLines="0" /> 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.</t>

      <t>Honey pot <vspace blankLines="0" /> 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.</t>

      <t>IRC <vspace blankLines="0" /> 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
      <xref target="RFC1459"></xref> 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.</t>

      <t>Malware <vspace blankLines="0" />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.</t>

      <t>Mix networks <vspace blankLines="0" />Mix networks create hard-to-trace
      communications by using a chain of proxy servers <xref
      target="MIX"></xref>. 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 <eref
      target="http://www.adastral.ucl.ac.uk/~helger/crypto/link/protocols/mix.php">
      </eref>.</t>

      <t>Onion routing <vspace blankLines="0" />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 <eref target="http://www.onion-router.net/"></eref>.</t>

      <t>Phishing <vspace blankLines="0" /> 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.</t>

      <t>Root access <vspace blankLines="0" /> 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.</t>

      <t>Script kiddy<vspace blankLines="0" />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.</t>

      <t>Spam <vspace blankLines="0" />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.</t>

      <t>Spoofing <vspace blankLines="0" />(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.</t>

      <t>Spyware <vspace blankLines="0" /> Any software that covertly gathers
      user information through the user's Internet connection without his or
      her knowledge, e.g., for spam purposes.</t>

      <t>UBE <vspace blankLines="0" />Unsolicited Bulk Email: an official term
      for spam.</t>

      <t>UCE <vspace blankLines="0" />Unsolicited Commercial Email: an
      official term for spam.</t>

      <t>Virus <vspace blankLines="0" />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.</t>

      <t>Worm <vspace blankLines="0" />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.</t>

      <t>Zombie<vspace blankLines="0" />This is another name for a bot.</t>
    </section>

    <section title="Security Considerations">
      <t>This document does not specify any protocol or "bits on the
      wire".</t>
    </section>

    <section title="Acknowledgements">
      <t>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.</t>

      <t>The IAB would also like to thank the scribes listed in <xref
      target="participants"></xref> who diligently recorded the proceedings
      during the workshop.</t>

      <t>A special thanks to all the participants in the workshop, who took
      the time, came to the workshop to participate in the discussions, and who
      put in the effort to make this workshop a success. The IAB especially
      appreciates the effort of those that prepared and made presentations at the
      workshop.</t>

      <!--The editors gratefully acknowledge the esteemed assistance of Elwyn
      Davies without whom the highfalutin phraseology of this document would
      have been greatly impoverished.-->
    </section>
  </middle>

  <back>
    <references title="Informative References">
      &rfc1122;

      &rfc1123;

      &rfc1812;

      &rfc1459;

      &rfc1918;

      &rfc3330;

      &rfc2827;

      &rfc2142;

      &rfc3704;

      <reference anchor="IMS" target="http://ims.eecs.umich.edu/">
        <front>
          <title>Internet Motion Sensor</title>

          <author>
            <organization>University of Michigan</organization>
          </author>

          <date year="2006" />
        </front>
      </reference>

      <reference anchor="IRR" target="http://www.irr.net/">
        <front>
          <title>Internet Routing Registry Routing Assets Database</title>

          <author>
            <organization>Merit Network Inc</organization>
          </author>

          <date year="2006" />
        </front>
      </reference>

      <reference anchor="MIX"
                 target="http://www.mit.edu/afs/athena/course/6/6.857/OldStuff/Fall99/papers/mixnet.ps.gz">
        <front>
          <title>Approaches to Mix Nets</title>

          <author fullname="Raquel Hill" initials="R." surname="Hill">
            <organization>Harvard</organization>
          </author>

          <author fullname="Adon Hwang" initials="A." surname="Hwang">
            <organization>Harvard</organization>

            <address>
              <postal>
                <street />

                <city />

                <region />

                <code />

                <country />
              </postal>

              <phone />

              <facsimile />

              <email />

              <uri />
            </address>
          </author>

          <author fullname="David Molnar" initials="D." surname="Molnar">
            <organization />

            <address>
              <postal>
                <street />

                <city />

                <region />

                <code />

                <country />
              </postal>

              <phone />

              <facsimile />

              <email />

              <uri />
            </address>
          </author>

          <date day="9" month="December" year="1999" />
        </front>
          <seriesInfo name="MIT" value="6.857 Final Project" />

      </reference>

      <reference anchor="SHRED"
                 target="http://www.research.att.com/~bala/papers/shred-ext.ps">
        <front>
          <title>SHRED: Spam Harassment Reduction via Economic
          Disincentives</title>

          <author fullname="Balachander Krishnamurthy" initials="B."
                  surname="Krishnamurthy">
            <organization>AT&amp;T Labs - Research</organization>
          </author>

          <author fullname="Ed Blackmond" initials="E." surname="Blackmond">
            <organization>Eureka! Computing Solutions, Inc.</organization>

            <address>
              <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date year="2003" />
        </front>
      </reference>
    </references>

    <section anchor="participants" title="Participants in the workshop">
      <t>Bernard Aboba (IAB)<vspace blankLines="0" /> Loa Andersson
      (IAB)<vspace blankLines="0" /> Ganesha Bhaskara (scribe)<vspace
      blankLines="0" />Bryan Burns <vspace blankLines="0" /> Leslie Daigle
      (IAB chair) <vspace blankLines="0" /> Sean Donelan <vspace
      blankLines="0" /> Rich Draves (IAB Executive Director)<vspace
      blankLines="0" /> Aaron Falk (IAB, IRTF chair)<vspace blankLines="0" />
      Robert Geigle<vspace blankLines="0" />Minas Gjoka (scribe)<vspace
      blankLines="0" />Barry Greene <vspace blankLines="0" /> Sam Hartman
      (IESG, Security Area Director)<vspace blankLines="0" /> Bob Hinden (IAB)
      <vspace blankLines="0" /> Russ Housely (IESG, Security Area
      Director)<vspace blankLines="0" /> Craig Huegen <vspace
      blankLines="0" /> Cullen Jennings <vspace blankLines="0" /> Rodney Joffe
      <vspace blankLines="0" /> Mark Kosters <vspace blankLines="0" /> Bala
      Krishnamurthy <vspace blankLines="0" /> Gregory Lebovitz <vspace
      blankLines="0" /> Ryan McDowell <vspace blankLines="0" /> Danny
      McPherson <vspace blankLines="0" /> Dave Merrill <vspace
      blankLines="0" /> David Meyer (IAB) <vspace blankLines="0" /> Alan
      Mitchell <vspace blankLines="0" /> John Morris <vspace blankLines="0" />
      Eric Osterweil (scribe)<vspace blankLines="0" /> Eric Rescorla
      (IAB)<vspace blankLines="0" /> Pete Resnick (IAB)<vspace
      blankLines="0" /> Stefan Savage <vspace blankLines="0" /> Joe St Sauver
      <vspace blankLines="0" />Michael Sirivianos (scribe)<vspace
      blankLines="0" />Rob Thomas <vspace blankLines="0" /> Helen Wang <vspace
      blankLines="0" /> Lixia Zhang (IAB)</t>
    </section>

    <section anchor="agenda" title="Workshop agenda">
      <figure>
        <artwork><![CDATA[

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?

          ]]></artwork>
      </figure>
    </section>

    <section anchor="Slides" title="Slides">
      <t>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 <eref
      target="http://utgard.ietf.org/iab/about/workshops/unwantedtraffic/index.html"></eref>.
      As mentioned in <xref target="intro"></xref>, 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.</t>
    </section>
  </back>
</rfc>
