RFC 4948

Report from the IAB workshop on Unwanted Traffic March 9-10, 2006

📅 published August 2007, from ietf

Okay bestie, RFC 4948 is giving "the IAB threw a workshop about the bad stuff on the internet" 🦋

The title block is the vibe check first ✨ This is an Informational RFC (so it's a report, not an Internet standard, no cap 🫶). It's from August 2007 and was written by L. Andersson (Acreo AB), E. Davies (Folly Consulting), and L. Zhang (UCLA). Its title is Report from the IAB workshop on Unwanted Traffic March 9-10, 2006. It doesn't obsolete or update anything, so no drama there 💅

Status of This Memo 🌸

This memo gives information to the Internet community, and it does not specify an Internet standard of any kind. Distribution is unlimited, so share away 💖

Copyright Notice 🎀

Abstract 🔥

Okay so the IAB held a workshop on Unwanted Internet Traffic on March 9-10, 2006 at USC/ISI in Marina del Rey, CA 🌴 The whole point was to get the operator, standards, and research folks in one room to talk about unwanted traffic, like DDoS attacks, spam, and phishing 😭 They wanted to figure out where this junk actually comes from, how much damage it does, and whether today's fixes even work. They also wanted to spot engineering and research topics that the IAB, the IETF, the IRTF, and the wider research community could tackle to build real countermeasures. Iconic goal, honestly 👑

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  The Root of All Evils: An Underground Economy  . . . . . . . .  4
  2.1.  The Underground Economy  . . . . . . . . . . . . . . . . .  5
  2.2.  Our Enemy Using Our Networks, Our Tools  . . . . . . . . .  6
  2.3.  Compromised Systems Being a Major Source of Problems . . .  7
  2.4.  Lack of Meaningful Deterrence  . . . . . . . . . . . . . .  8
  2.5.  Consequences . . . . . . . . . . . . . . . . . . . . . . . 10
3.  How Bad Is The Problem?  . . . . . . . . . . . . . . . . . . . 10
  3.1.  Backbone Providers . . . . . . . . . . . . . . . . . . . . 10
    3.1.1.  DDoS Traffic . . . . . . . . . . . . . . . . . . . . . 10
    3.1.2.  Problem Mitigation . . . . . . . . . . . . . . . . . . 11
  3.2.  Access Providers . . . . . . . . . . . . . . . . . . . . . 12
  3.3.  Enterprise Networks: Perspective from a Large
        Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 13
  3.4.  Domain Name Services . . . . . . . . . . . . . . . . . . . 14
4.  Current Vulnerabilities and Existing Solutions . . . . . . . . 15
  4.1.  Internet Vulnerabilities . . . . . . . . . . . . . . . . . 15
  4.2.  Existing Solutions . . . . . . . . . . . . . . . . . . . . 16
    4.2.1.  Existing Solutions for Backbone Providers  . . . . . . 16
    4.2.2.  Existing Solutions for Enterprise Networks . . . . . . 17
  4.3.  Shortfalls in the Existing Network Protection  . . . . . . 18
    4.3.1.  Inadequate Tools . . . . . . . . . . . . . . . . . . . 18
    4.3.2.  Inadequate Deployments . . . . . . . . . . . . . . . . 18
    4.3.3.  Inadequate Education . . . . . . . . . . . . . . . . . 19
    4.3.4.  Is Closing Down Open Internet Access Necessary?  . . . 19
5.  Active and Potential Solutions in the Pipeline . . . . . . . . 20
  5.1.  Central Policy Repository  . . . . . . . . . . . . . . . . 20
  5.2.  Flow Based Tools . . . . . . . . . . . . . . . . . . . . . 21
  5.3.  Internet Motion Sensor (IMS) . . . . . . . . . . . . . . . 21
  5.4.  BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  5.5.  Layer 5 to 7 Awareness . . . . . . . . . . . . . . . . . . 22
  5.6.  How To's . . . . . . . . . . . . . . . . . . . . . . . . . 22
  5.7.  SHRED  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.  Research in Progress . . . . . . . . . . . . . . . . . . . . . 23
  6.1.  Ongoing Research . . . . . . . . . . . . . . . . . . . . . 23
    6.1.1.  Exploited Hosts  . . . . . . . . . . . . . . . . . . . 23
    6.1.2.  Distributed Denial of Service (DDoS) Attacks . . . . . 25
    6.1.3.  Spyware  . . . . . . . . . . . . . . . . . . . . . . . 26
    6.1.4.  Forensic Aids  . . . . . . . . . . . . . . . . . . . . 26
    6.1.5.  Measurements . . . . . . . . . . . . . . . . . . . . . 27
    6.1.6.  Traffic Analysis . . . . . . . . . . . . . . . . . . . 27
    6.1.7.  Protocol and Software Security . . . . . . . . . . . . 27
  6.2.  Research on the Internet . . . . . . . . . . . . . . . . . 27
    6.2.1.  Research and Standards . . . . . . . . . . . . . . . . 28
    6.2.2.  Research and the Bad Guys  . . . . . . . . . . . . . . 29
7.  Aladdin's Lamp . . . . . . . . . . . . . . . . . . . . . . . . 30
  7.1.  Security Improvements  . . . . . . . . . . . . . . . . . . 30
  7.2.  Unwanted Traffic . . . . . . . . . . . . . . . . . . . . . 31
8.  Workshop Summary . . . . . . . . . . . . . . . . . . . . . . . 31
  8.1.  Hard Questions . . . . . . . . . . . . . . . . . . . . . . 31
  8.2.  Medium or Long Term Steps  . . . . . . . . . . . . . . . . 32
  8.3.  Immediately Actionable Steps . . . . . . . . . . . . . . . 33
9.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations  . . . . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
12. Informative References . . . . . . . . . . . . . . . . . . . . 39
Appendix A.  Participants in the Workshop  . . . . . . . . . . . . 40
Appendix B.  Workshop Agenda . . . . . . . . . . . . . . . . . . . 41
Appendix C.  Slides  . . . . . . . . . . . . . . . . . . . . . . . 41

1. Introduction 💖

The Internet is absolutely overflowing with unwanted traffic right now 😩 To understand what's driving it and whether our current countermeasures are any good, the IAB put together an "Unwanted Internet Traffic" workshop and invited experts from operator, vendor, and research communities. The goal was to swap experiences, views, and ideas across fields, and to really dig into the technical details. They focused on five big questions:

the kinds of unwanted traffic that show up on the Internet,
how bad the picture actually looks,
who and where the main sources of the problem are,
which solutions work and which don't, and
what needs to be done.

The workshop was a total success 🎉 Over one and a half days of intense discussion, they pinned down the main sources of unwanted traffic and critically assessed the mitigation tools people already use. Time was limited though, so they couldn't cover the whole topic, and some of the important issues only got a quick glance. The workshop was mostly about collecting and sharing what's happening right now, so deriving actual solutions is the next step. That work will happen partly inside the IAB, the IETF, and the IRTF 🦋

Lots of product and company names came up during the workshop and show up in the report to some degree. Just because a product is mentioned doesn't mean it's been endorsed, btw. There are probably other equally good or effective options out there 💅

This report summarizes what the workshop participants contributed, so it's not an IAB document. The views and positions in it don't necessarily match the IAB's views and positions 🫶

The participant list is in Appendix A, and the agenda is in Appendix B. Links to some of the presentations are in Appendix C, but the rest are sensitive, so they agreed not to make those public 🙈 Definitions for the jargon used around unwanted traffic are in Section 9.

2. The Root of All Evils: An Underground Economy 💀

The very first big message the workshop wanted the Internet community to hear is that there's an underground economy running this whole mess 🔥 It produces a huge amount of money that fuels the generation of unwanted traffic. That economic incentive feeds on an Internet that's pretty much wide open. The openness is a big part of why the Internet is so innovative, but it offers basically zero defense against abuse 😭 It connects to millions of mostly unprotected hosts owned by millions of mostly naive users. These users are exploring all the amazing stuff in the new cyberspace, but they don't really get how vulnerable they are to abuse, or how dangerous it is when their computers get compromised.

Also, the Internet was built without any built-in auditing trails. That was a fine choice back then, but now the lack of traceability makes it really hard to track down malicious activity 🕵️ Pair that with a legal system that's still figuring out how to regulate cyberspace, and the Internet today has no real deterrent for bad actors. The loose design and freedom from regulation are a huge reason the Internet has been so successful. At the same time, those same factors have led to a growing volume of unwanted traffic. The rest of this section goes deeper into each of these factors 🧚

That's the first chunk, bestie 🎀 More parts are coming, so stay tuned for part 2 💜

2.1. The Underground Economy 💸

okay so, like any economy, the underground one runs on a supply and demand chain 📈 it started out as pure barter, and now it's basically a giant shopping mall 🛍️ that usually lives on IRC (Internet Relay Chat) servers. those servers have stores selling stolen credit card and bank account info, malware, bot code, botnets, root access to compromised hosts and web servers, and so much more 💀 there are DDoS attack stores, credit card stores, PayPal and bank account stores, plus Cisco and Juniper router stores that sell access to compromised routers 🫢 not every server carries everything, but the most common tools for working the underground economy show up on almost all of them ✨

so how do miscreants turn attack tools and hacked machines into actual money? ngl the simplest move is moving money out of stolen bank accounts straight into an account they control, often in another country 🏦 a fancier version is using stolen credit cards or PayPal accounts to buy stuff online 🛒 to cover their tracks, they often find remailers who receive the goods, repackage them, and send them on to the miscreants for a fee 📦 they might also resell the goods on online marketplaces like eBay 🙈 for payment, they ask for cashier checks or money orders sent to people who do money laundering for them, receiving the payments and forwarding them to banks in a different country, again for a fee 💅 either way, the destination bank accounts only get used for a short time and get closed as soon as the miscreants withdraw the money 🧹

the miscreants grab private and financial info from compromised hosts and install bots (a.k.a. zombies) on them 🧟 they can also get that info through phishing attacks 🎣 spam messages trick naive users into visiting spoofed web sites run by the miscreants, where their financial info gets pulled out and collected 😭

the miscreants in general aren't skilled programmers, but money fixes that 💰 they can hire professional writers for spam that actually reads well, and hire coders to build new viruses, worms, spyware, and botnet control packages 🤖 that means new tools get pumped back into the underground market, creating even more unwanted traffic on the Internet ✨

that new traffic looks like spam messages spreading phishing attacks, botnets launching DDoS attacks, click fraud that "earns" income by deceiving online commercial advertisers, and new viruses and worms that compromise even more hosts and steal extra financial info, system passwords, and personal identity info 💔

the income from all this illegal activity lets miscreants hire spammers, coders, and IRC server providers 💼 spammers use botnets 🤖 direct marketing companies set up dirty affiliate programs 🙃 and some less than scrupulous banks get involved to earn transaction fees from moving the dirty money around 🏦 in the underground market, everything can be traded and everything has a value 🏷️ and that's how all kinds of unwanted traffic get spawned 🌪️

the underground economy has evolved super fast over the past few years 🚀 back in the early days of bots and botnets, their activity was mostly DDoS attacks and was fairly easy to detect 👀 but as the underground economy grew up, so did the botnets 📈 they moved from easy-to-spot behavior to blending in with normal user network activity to get their goals done, which makes detection really hard, even for vigilant system administrators 🕵️‍♀️

the big reason for this rapid evolution is that the intention behind miscreant activity changed 🔄 early virus attacks and botnets were mostly anarchic chaos 🌀 a lot of them came from "script kiddies" who wanted to disrupt systems for no real purpose or to show off their skills, like breaking into systems that were touted as "secure" 😤 now that the Internet has been commercialized and used more and more for e-business, miscreant activity is mostly about conventional criminal stuff 💼 systems get quietly subverted to make illicit money later, instead of causing loud, visible disruptions like the early hackers liked to do 🤫

2.2. Our Enemy Using Our Networks, Our Tools 🕸️

IRC servers are commonly used as the command and control channel for the underground market 🎮 these servers are paid for by miscreants and professionally supported 💅 they're advertised widely to attract potential customers, so they're super easy to find 🔍 the miscreants first chat with each other on the servers to figure out who's selling what, then swap encrypted private messages to close the deals 🔐

the miscreants aren't scared of network operators seeing what they're doing 👁️ if their activities get interrupted, they just move to another venue 🏃‍♀️ when ISPs take action to protect their customers, revenge attacks are uncommon as long as the miscreants' cash flow isn't disturbed 💸 when a botnet gets taken down, they just move on to the next one, because there's a plentiful supply 🧺 but if an IRC server gets taken out and that actually disturbs their cash flow, miscreants can get ruthless and severe attacks may follow 😬 they have no fear right now, because they know the chances of getting caught are minimal 🙃

our enemies make great use of the Internet's global connectivity and all the tools the Internet has developed 🌍 IRC servers give miscreants a job market and a shopping mall full of attack tools 🛒 networking research has produced loads of results that make it easier to build large scale distributed systems, and miscreants have adopted those to build big, well-controlled botnets 🧠 powerful search engines also make it super quick to find ready-made tools and resources 🔎 attacks have gotten more sophisticated over time, while the skills needed to launch effective ones have become minimal 📉 attackers can be hiding anywhere on the Internet while attacks get launched on a global scale 🌐

2.3. Compromised Systems Being a Major Source of Problems 🧟‍♀️

the current Internet is basically a field ripe for exploitation 🌾 most end hosts run vulnerable platforms 😩 people from all walks of life eagerly jump into the newly discovered online world 🥳 but they don't have the proper training to understand the full implications 📚 a big part of that is that most users never think about how such a great invention can be easily abused 🙈 so the Internet has ended up with a huge number of compromised hosts, and their owners have no idea it happened 💀

unprotected hosts can get compromised in multiple ways 🚪 viruses and worms can get in by exploiting bugs in existing operating systems or applications, sometimes even in anti-virus programs 🦠 a phishing site can also take the chance to install malware on a victim's computer when a user gets lured there 🎣 more recently, viruses have started spreading through popular peer-to-peer file sharing applications 📂 with all these channels, malware has gotten super widespread 🌊 infected machines include home PCs (which make up a large percentage, to be fair), but also corporate servers, and even government firewalls 😱

news about new exploits of vulnerabilities in 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 reason Windows gets exploited so often is its popularity in the marketplace, so a miscreant's investment in each exploit can pay off big by infecting millions of machines 💸 as a result, each incident is also likely to make headlines 🗞️ in reality, all other platforms, like Linux, Solaris, and MAC OS for example, are vulnerable to compromise too 🐧 routers aren't exempt from 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 🚀

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 sadly, it appears they are being all too successful 😔 bots and the functions they perform are often hard to detect, and most of the time their existence isn't known to system operators or owners (hence the alternative name for hosts infected with miscreant-controlled bots: zombies 🧟); by the time anyone notices, it might very well be too late, because they've already carried out the intended (mal-)function ⏰

a large number of compromised hosts is a particularly challenging problem for the Internet's security 🛡️ the stolen financial info leads to enormous economic losses, and there's been no quick fix ☹️ as noted above, in many cases the owners of compromised computers don't know about the problem 🙃 even after being notified, some owners still don't care about fixing it as long as their own interests, like playing online games, aren't affected 🎮 meanwhile the public interest is endangered 🚨 large botnets can use multi-millions of these compromised hosts to launch DDoS attacks, with each host sending an insignificant amount of traffic, but the aggregate exceeding the capacity of the best engineered systems 🌊💥

2.4. Lack of Meaningful Deterrence ✨

okay bestie, so the Internet's superpower is that it lets basically an unlimited number of parties talk to each other 🌐💖 but the flip side is that when something goes wrong, nobody really knows whose job it is to fix it 😭 take DDoS attacks: a bunch of compromised hosts launch the attack, the traffic crosses the Internet backbone, and then it lands on the access networks linking to the victims. so there are a bunch of independent stakeholders involved, and it's not clear which one should take responsibility for sorting it out 🫠

and tracking down an attack is genuinely so hard 💀 the Internet architecture lets any IP host talk to any other host, and there are no audit trails. so not only is there no limit to what a host can do, there's also no trace afterwards of what it actually did 🙈 right now there's basically no effective tool for problem diagnosis or packet trace back. so tracing an attack is labor intensive and needs seriously sophisticated skills 🧠 and as we'll see in the next section, there's also a lack of incentive to report security attacks lowkey the whole thing is giving "nobody's accountable" 💅 with the high cost on top of all that, forensically tracing an attack back to its root is a rare event 🦋

in human society, legal systems protect us from criminals 👮‍♀️ but in cyberspace, the legal systems are lagging behind when it comes to making regulations 😤 laws and regulations punish conduct after the fact, and if the likelihood of detection is low, the deterrence is minimal 📉 lots of national jurisdictions have rules about computer fraud and abuse, and they often carry serious criminal penalties ⚖️ in the US (and plenty of other places), it's illegal to access government computers without authorization, illegal to damage protected government computers, and illegal to access confidential information on protected computers 🚫 but the definition of "access" can be genuinely hard to pin down 🤔 for example, is sending an ICMP (Internet Control Messaging Protocol) packet to a protected computer considered illegal access? 👀 there's a lack of technical understanding among lawmakers that they'd need to write laws precisely and target only the undesirable acts 📜 computer fraud and liability laws give us a forum to address illegal access and let prosecutors go after cybercriminals 🎀 however, one difficulty in prosecuting affiliate programs using bot infrastructure is that they're either borderline legal, or there's little evidence 🥴 there's also the mentality of only taking legal action when the measurable monetary damage passes a high threshold, even though it's often hard to quantify the money lost in individual cyberspace crimes 💸

there's a coalition between countries collecting cybercriminal evidence around the world, but there's no rigorous way to trace across borders 🌍 laws and rules are mostly local to each country, and policies (when they exist) are mostly enacted and enforced locally 🏳️ meanwhile the Internet, which carries the unwanted traffic, respects no borders at all 🌊 one estimate suggests most players in the underground economy are outside the US, yet most IRC servers supporting the underground market may be running in US network providers 🤯 because they enjoy the reliable service and wide connectivity to the rest of the world that the networks provide 🌸

also, what counts as "unwanted" traffic varies between countries 🧐 for example, China bans certain types of network traffic that are considered legitimate elsewhere 🙅‍♀️ and yet another major difficulty is the trade-off and blurry line between having audit trails for forensic analysis and using them to enforce censorship 👁️ the more control we build into the network over traffic, the stronger the monitoring requirements from legislators will be 🫣

it needs to be emphasized that a legal system is necessary to create effective deterrence and sanctions against miscreants, but it is by no means sufficient on its own ✋ it must be accompanied by technical solutions for unwanted traffic detection and damage recovery 🛠️ it's also by no means a substitute for user education 📚 only a well informed user community can collectively establish an effective defense in cyberspace 🫶

2.5. Consequences 💥

what we have today is not a rosy picture, babe 🥀 there are:

big economic incentives and a rich environment to exploit 💰
no specific party to carry responsibility 🙃
no auditing system to trace back to the sources of attacks 🕵️‍♀️
no well established legal regulations to punish offenders 🚔

the combination of these factors inevitably leads to ever increasing types and volume of unwanted traffic 📈 but honestly, our real threats aren't the bots or DDoS attacks, it's the criminals behind them 😤 unwanted traffic is no longer only aiming for maximal disruption; in many cases it's a means to illicit ends, specifically to generate financial gains for the miscreants 🤑 their crimes cause huge economic losses, counted in multiple billions of dollars and still climbing 💀

How Bad Is The Problem? 🔍

there are quite a number of different kinds of unwanted traffic on the Internet today, and the discussions at this workshop were mainly about DDoS traffic and spam 📨 the impact of DDoS and spam differs across different parts of the network, so below we break down the impact on backbone providers, access providers, and enterprise customers, respectively 🧩

3.1. Backbone Providers 🏗️

since backbone providers' main line of business is packet forwarding, the impact of unwanted traffic is mainly measured by whether DDoS traffic affects network availability 📡 spam or malware isn't a major concern, because backbone networks don't directly support end users 🙌 router compromises may exist, but they're rare events right now 🤏

3.1.1. DDoS Traffic 🌪️

observation shows that, in the majority of DDoS attacks, attack traffic can originate from almost anywhere on the Internet 🗺️ especially regions with high speed user connectivity but poorly managed end hosts, which are often where DDoS attacks originate 😬 the miscreants tend to find targets that offer maximal returns with minimal effort 🎯

backbone networks in general are well-provisioned for traffic capacity 💪 so core routers and backbone link capacity don't get affected much by most DDoS attacks; a 5Gbps attack could be easily absorbed without causing noticeable impact on backbone performance ✨ however, DDoS attacks often saturate access networks and make a significant impact on customers 😩 multihomed customers, who have multiple well-provisioned connections for high throughput and performance, may suffer from aggregated DDoS traffic coming in from all directions 🌀

3.1.2. Problem Mitigation 🧯

currently, backbone networks don't 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 💅 so any expenditure tends to require a clearly identified return-on-investment (ROI) 🧾 even when new security solutions become available, providers don't necessarily upgrade their infrastructure to deploy them, since security solutions are often prevention mechanisms that may not have an easily quantifiable ROI 🤷‍♀️ to survive the competition, backbone providers also try to recruit more customers, so 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's not in a provider's best interest to report all observed attacks 🙈 instead, the provider's first concern is to minimize the number of publicized security incidents 🤫 for example, a "trouble ticket" acknowledging the problem is only issued after a customer complains 🎫 an informal estimate suggested that only about 10% of DDoS attacks are actually reported (some other estimates have put the figure as low as 2%) 📉 in short, there's a lack of incentives to either report problems or deploy solutions 💀

partly as a consequence of the lack of incentive and lack of funding, there are 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 don't require coordination across administrative domains 🙌 when done at, or near, DDoS victims, these simple tools can have an immediate effect in reducing DDoS traffic volume ⚡

however, these tools are rather rudimentary and inadequate, as we will elaborate in Section 4.2.1 🥲💖

3.2. Access Providers 🏠

Okay so access providers have a problem that's lowkey the same as the one backbone providers have: nobody has the incentive or the funding to actually deploy security solutions. 💸 And just like on the backbone, the number of security incidents access providers report is estimated to be way lower than the number that actually happened. 🙈

But access providers are directly connected to end customers, so they've got their own drama too. 🎀 From their point of view, the most severe impact of unwanted traffic isn't bandwidth exhaustion. It's the customer support load it creates. 😭 The primary impact lands on end users, and access providers have to respond to incident reports from their customers. Honestly, access providers are playing IT help desk for a lot of people, 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. ⏰ Staffing help desks is so expensive that it's believed that if a customer calls just once, the provider would lose the profit they would otherwise have otherwise made over the lifetime of that customer account. 💀

To cut down on the high customer service cost caused by security breaches, most access providers offer free security software to their customers. 🧚 It's way cheaper to hand out "free" security software in the hope of preventing compromises than to deal with the break-ins after the fact. However, perhaps because customers don't understand the possible security problems they might face, many of them fail to install the software even with the free offer. And even when they do install it, they may lack the skill needed to configure a complex system correctly. 🤷‍♀️

So what factors influence how quickly customers get their security breaches fixed? Past experience suggests the following observations: 👀

Notification has little impact on end user repair behavior.
There is no significant difference in terms of repair behavior between different industries or between business and home users.
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. 🥲
There is a general lack of user understanding: after being compromised, unmanaged computers may get replaced rather than repaired, and this often results in infections occurring during the installation process on the replacement. 🫠

3.3. Enterprise Networks: Perspective from a Large Enterprise 🏢

The operators of one big enterprise network shared their experience with unwanted traffic at the workshop. 🎤 Enterprises see so 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, so most operators prefer false negatives to false positives. 🙃 In general, enterprises prefer prevention solutions to detection solutions. 🛡️

Now, 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. 📧 Workshop participants had different opinions on whether P2P traffic should, or should not, be considered unwanted traffic. Still, enterprise network operators are concerned that P2P traffic represents a significant share of the total network load. They're also sensitive to potential copyright infringement issues that could lead to significant financial and legal impacts on the company as a whole. ⚖️ On top of that, P2P file sharing applications have also become a popular channel for malware propagation. 😬

The second category is labeled "Malicious," which includes the traffic that spreads malware. ☠️ This class of traffic can be small in volume, but the cost of the resulting damage can be high. The clean up after an incident also requires highly skilled operators. 🧑‍💻

The third category is "Unknown." It's known that there's a class of traffic in the network that's best described this way, since nobody knows its purpose or where its sources are. 🕵️ Malicious traffic can be obscured by encryption, encapsulation, or covered up as legitimate traffic. The existing detection tools are ineffective against this type. Noisy worms are easy to spot, but stealth worms can open a backdoor on hosts and stay dormant for a long time without causing any noticeable detrimental effect. 🥷 This type of bad traffic has the potential to make the greatest impact on an enterprise from a threat perspective. 😱

There are more mitigation tools available for enterprise networks than for backbone and access network providers. One explanation might be that solutions are more affordable for enterprise networks. 💰 The costs of damage from a security breach can also have a very significant impact on an enterprise's profits. At the same time, though, workshop participants expressed concerns about 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." That reactive mode hasn't only created a big security market. It also doesn't let us get ahead of attackers. 🏃‍♀️💨

3.4. Domain Name Services 🌐

Different from backbone and access providers, there's also a class of Internet service infrastructure providers. ✨ Provision of Domain Name System (DNS) services is a great example. As reported by operators from a major DNS hosting company, there have been increasingly significant DDoS attacks on .com, .net and root servers over time. 📈

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 from these attacks is bandwidth and resource exhaustion, which led to disruption of critical services. 🚨 The peak rate of daily DNS transactions has been growing much faster than the number of Internet users, and this trend is expected to continue. The heavy load on DNS servers has made providing the services increasingly complex. 🤯

Besides 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 these issues have been addressed in the DNS operational guidelines drafted by the IETF DNS Operations Working Group. Still, many DNS operators have not taken appropriate actions. 😤

Right now, the only effective and viable mitigation approach is over-engineering the DNS service infrastructure. That means increasing link bandwidth, the number of servers, and the server processing power, as well as deploying network anycast. 🏗️ There's a concern about whether the safety margin gained from over-engineering is, or is not, adequate to sustain DNS services over future attacks. 🤞 Looking forward, a few new issues are also looming. Two imminent ones are the expected widespread deployment of IPv6, whose new DNS software would inevitably contain new bugs, and the DNS Security Extensions (DNSSEC), which could potentially be abused to generate DDoS attacks. 👻

4. Current Vulnerabilities and Existing Solutions ✨

This section summarizes three aspects of the workshop discussions. 📋 First, we collected the major vulnerabilities mentioned in the workshop. Then we summarized the existing solutions, and finally we examined how effective those solutions are, or whether they're effective at all. 🔍

4.1. Internet Vulnerabilities 🕵️‍♀️

okay so bestie, here's the list of known Internet vulnerabilities and the unwanted traffic issues that come with them 💅

Packet source address spoofing: there's been speculation that attacks using spoofed source addresses are decreasing, because of the proliferation of botnets. Botnets can launch various attacks without spoofing source addresses, so it's giving "why bother faking it." It is certainly true that not all attacks use spoofed addresses 🙄 but many attacks, especially reflection attacks, still do use spoofed source addresses 💀
BGP route hijacking: in a survey conducted by Arbor Networks, route hijacking and source address spoofing were listed as the two most critical vulnerabilities on the Internet 🚨 It has been observed that miscreants hijack bogon prefixes for spam message injections. Like, these hijacks don't affect normal packet delivery, so they have a low chance of being noticed 🫣
Everything over HTTP: port scan attacks happen all the time on today's Internet, looking for open TCP or UDP ports to gain access to computers 👀 So system management's reaction has been to close down all the unused ports, especially in firewalls. The result? Application designers moved to transporting all their data communications over HTTP to dodge firewall traversal issues 🏃‍♀️ "Everything over HTTP" doesn't block attacks, it just moved the vulnerability from one place to another 🫠
Everyone comes from Everywhere: in the earlier life of the Internet, you could 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 operator's network, since the sender will "always" set the TTL to the same value. So if the TTL changed without a matching change in routing, you could conclude it was potential unwanted traffic. BUT hosts are mobile now 📱 They can roam within an operator's network, and the path changes may put more (or fewer) hops between source and destination. So it's no longer possible to read a TTL change, even one without any corresponding routing change, as proof the traffic has been subverted 😭
Complex Network Authentication: network authentication as it's used today is way too complex for users to use effectively 🤯 It will also be difficult to make it work with new wireless access technologies 📶

picture this: a customer's handset starts out on a corporate wireless network 💼 They step out of the corporate building and the handset may get connected to the corporate network through a GPRS network 📡 Then it may roam to a wireless LAN network when the user walks into a public area with a hotspot ☕ Consequently, we need authentication tools for cases where the underlying data link layer technology changes quickly, possibly during a single application session 🌀

Unused Security Tools: vendors and standards have produced quite a number of useful security tools 🛠️ However, not all of them, or even most of them, get used extensively. Its giving "the toolbox is full and nobody's opening it" 🧰

4.2. Existing Solutions ✨

4.2.1. Existing Solutions for Backbone Providers 🌐

Several engineering solutions exist that operators can deploy to defend the network against unwanted traffic 🛡️ Adequate provisioning is one commonly used approach that can diminish the impact of DDoS on the Internet backbone 💪 The solution that got the 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 🙌 Right now, Access Control List (ACL) and BGP null routing are the two tools network operators use most often to mitigate DDoS attacks. They're effective at blocking DDoS attacks, especially when applied at or near a victim's site 🎯

Unfortunately, BCP 38 is not widely deployed today 😩 It may require device upgrades, and it's considered tedious to configure and maintain. Like, widespread deployment of BCP 38 could benefit the Internet as a whole, but deployment by individual sites costs that site something, and it doesn't give them a direct and tangible benefit back 💸 In other words, BCP 38 suffers from a lack of deployment incentives 🥲

Both BGP null routing and ACL rely on manual configuration, which makes them labor intensive 🥱 They also suffer from blocking both attack and legitimate packets 🙃 There's also a potential that some tools could back-fire. For example, an overly long ACL list might significantly slow down packet forwarding in a router 🐢

Unicast Reverse Path Filtering (uRPF), which is available on some routers, provides a means of implementing a restricted form of BCP 38 ingress filtering without the effort of maintaining ACLs 🦋 uRPF uses the routing table to check that a valid path back to the source exists. However, its effectiveness depends on the specificity of the routes that source addresses are compared against 🔍 Asymmetric routing is prevalent, which means the strict uRPF test (where the route to the source must leave from the same interface the tested packet arrived on) 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, so it may still be necessary to maintain an ACL to deal with exceptions 📝

4.2.2. Existing Solutions for Enterprise Networks 🏢

A wide variety of commercial products is available for enterprise network protection 🛍️ Three popular types of protection mechanisms are:

Firewalls: firewalls are perhaps the most widely deployed protection products 🧱 However, their effectiveness in protecting enterprise confidential information can be weakened by spyware installed internally, and they're ineffective against attacks carried out from inside the perimeter the firewalls establish 😬 Too often, spyware installation is a byproduct of installing other applications that end users permitted 🦠
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 🙅‍♀️
Anti-spam software: anti-spam measures consume significant human resources 🫠 Current spam mitigation tools include blacklists and content filters 📧 The more recent "learning" filters may help significantly reduce the human effort needed, and decrease the number of both false positives and negatives 🤖

A more recent development is computer admission control, where a computer is granted network access if and only if it belongs to a valid user and appears to have the most recent set of security patches installed 🔐 It is however a more expensive solution 💸 A major remaining issue facing enterprise network operators is how to solve the user vulnerability problem and reduce reliance on users' understanding of the need for security maintenance 🫶

4.3. Shortfalls in the Existing Network Protection 🥀

4.3.1. Inadequate Tools 🧰

Generally speaking, network and service operators don't have adequate tools for network problem diagnosis 🩺 The current approaches largely rely on the experience and skills of the operators, and on time-consuming manual operations 🕰️ The same is true for mitigation tools against attacks 🛡️

4.3.2. Inadequate Deployments 🚧

The limited number of existing Internet protection measures hasn't been widely deployed 😤 Deployment of security solutions requires resources that may not be available 💸 It also requires education in 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 its deployment 🎁 Effective protection also requires coordination between competing network providers 🤝 For the time being, it's often difficult to even find the contact information for operators of other networks 📞

A number of workshop participants shared the view that, if all the known engineering approaches and bug fixes were universally deployed, the Internet could have been enjoying a substantially reduced number of security problems today ✨ In particular, the need for, and lack of, BCP 38 deployment came up numerous times during the workshop 🔁 There's 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 they're also likely to bring their own set of problems 🌪️

4.3.3. Inadequate Education 📚

There's an educational challenge in disseminating 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 shipped with a default password cisco, and that attackers used it to break into routers. In reality, operators often configure Cisco routers with that password, perhaps because of the difficulty of disseminating passwords to multiple maintainers 🤦‍♀️ A similar problem exists for Juniper routers and other vendors' products 🫣

How to provide effective education to the Internet user community at large remains a great challenge 🌍 As mentioned earlier in this report, the existence of a large number of compromised hosts is one major source of the unwanted traffic problem, and the ultimate solution to this problem is a well-informed, vigilant user community 🦸‍♀️💖

4.3.4. Is Closing Down Open Internet Access Necessary? 🔒

okay so this one is a big debate, bestie 😭. One position at the workshop was that, with millions of vulnerable computers and basically no effective deterrence, protecting the Internet might need a fundamental change to the current Internet architecture, by replacing unconstrained open access to the Internet with strictly controlled access. 💀 The participants did NOT agree on this, but there was a rough consensus that, looking at the whole picture, enforcing controlled access doesn't seem like the best solution to Internet protection. ✨ Instead, the workshop identified a few needs to move towards a well protected Internet:

the need for risk assessment for service providers; at this time, we lack a commonly agreed bar for security assurance;
the need to add traceability to allow tracking of abnormal behavior in the network, and
the need for liability if someone fails to follow recommended practices.

Adding traceability has been kinda hard because the Internet is so distributed 🌐. Collaboration among operators is a total necessity if we want to fight cybercrime 🫶. We also have to prep for the next cycle of miscreant activity, and not put ALL our energy into fixing the existing problems. As discussed above, the current reactive approach to security problems is not a winning strategy 🙅‍♀️.

5. Active and Potential Solutions in the Pipeline 🚀

This section covers the issues that vendors recognized as important and for which there will be solutions available in the near future. 🔮

There are a bunch of potential solutions that vendors are working on, but they aren't offering them as part of their product portfolio yet 👀. They will allegedly remedy or diagnose the problems described in Section 4.1.

Here's the tea: when vendors have made a decision (or are about to) on new features but haven't announced anything, they aren't willing to talk about those features openly 🤐, so this section can only say so much.

5.1. Central Policy Repository 📚

One idea is 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 info on which neighbor router or AS is doing proper ingress address filtering. It could also hold the configurations that operators use to upgrade the configurations on their routers 🎀.

If the repository is going to be a shared resource used by multiple operators, it will necessarily need validation and authentication of the stored policies, so the repository doesn't become the cause of vulnerabilities 😬. Inevitably, 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 💸.

5.2. Flow Based Tools 🌊

A set of tools based on flow data is widely used to extract information from both the network and data link layers 🔍. Tools have been built that can find the sources of almost any type of traffic, including certain unwanted traffic. These flow-based tools make it possible to do things like DDoS traceback, traffic/peering analyses, and detection of botnets, worms, and spyware 🕵️‍♀️.

These tools monitor flows on the network and build baselines for what "normal" behavior looks like 📊. Once the baseline is available, it's possible to detect anomalous activity. It's easy to detect variations over time and decide if the variation is legit or not 🤔. You can take this approach further, typically by identifying signatures of particular types of traffic ✨.

These flow-based tools are basically the "sonar" that navies use to listen for submarines 🚢. Once a particular submarine is identified, they can record its sonar signature and use it for rapid identification the next time that same submarine shows up 🫡.

Examples of existing tools include Cisco IOS NetFlow <http://www.cisco.com/en/US/products/ps6601/products_ios_protocol_group_home.html>, sFlow <http://www.sflow.org/>, and NeTraMet <http://www.caida.org/tools/measurement/netramet/> based on the IETF RTFM and IPFIX standards 🧁.

There are also tools for working with the output of NetFlow, such as jFlow <http://www.net-track.ch/opensource/jflow/> and Arbor Networks' Peakflow <http://www.arbor.net/products_platform.php> 💜.

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

5.3. Internet Motion Sensor (IMS) 👁️

The Internet Motion Sensor (IMS) [IMS] may be used to watch traffic to or from "Darknets" (routable prefixes that don't have end hosts attached), unassigned address spaces, and unannounced address spaces 🌑. By watching activity in these types of address spaces, you can understand and detect, e.g., scanning activities, DDoS worms, worm infected hosts, and misconfigured hosts 🧐.

Right now, the IMS is used to monitor approximately 17 million prefixes, about 1.2% of the IPv4 address space 📡. Its use has highlighted two major characteristics of attacks. First, malicious attacks are more targeted than one might have assumed 🎯. Second, 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 😤. Be careful out there, babe 💅.

This form of passive data collection is also known as a "Network Telescope" 🔭. Links to similar tools can be found on the CAIDA web site at <http://www.caida.org/data/passive/network_telescope.xml>.

5.4. BCP 38 🧱

In the year 2000, the IETF developed a set of recommendations to limit DOS attacks and Address Spoofing, published as BCP 38 [RFC2827], "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" 🛑. However, BCP 38 capabilities still haven't been widely deployed, perhaps due to the incentive issue discussed earlier 😮‍💨.

The IETF has also developed an additional set of recommendations extending BCP 38 to multihomed networks. These recommendations are published as BCP 84 [RFC3704] 🧩.

5.5. Layer 5 to 7 Awareness 🔬

Tools are being developed that will make it possible to perform deep packet inspection at high speed 🏎️. Some companies are working on hardware implementations to inspect all layers from 2 to 7 (e.g., EZchip <http://www.ezchip.com/t_npu_whpaper.htm>). A number of other companies, including Cisco and Juniper, offer tools capable of analyzing packets at the transport layer and above 🧠.

5.6. How To's 📝

One idea 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 📣.

This type of initiative needs a "sponsor" or "champion" who takes the lead and starts collecting a set of "How To's" that could be freely distributed 🏆. The workshop did not discuss this further 🤷‍♀️.

5.7. SHRED 🍝

Methods to discourage the spread of spam by punishing the spammers were discussed, such as Spam Harassment Reduction via Economic Disincentive (SHRED) [SHRED] 🚫📧. The idea is to make it increasingly expensive for spammers to use the email system, while normal users keep the normal service they've come to expect 💌. There was no agreement on how effective this type of system would be 🤨.

6. Research in Progress 🧪

In preparation for this session, several researchers active in Internet Research were asked two pretty open-ended questions: "Where is the focus on Internet research today?" and "Where should it be?" 💭

A summary of the answers is given below. Section 6.2.2 covers part of the relationship between research and miscreants. For example, research activities in each area (please refer to the slide set for Workshop Session 8, which can be found at the link referred to in Appendix C) 📎.

6.1. Ongoing Research 🔎

Section 6.1 briefly discusses areas where we see active research on unwanted traffic today 👩‍🔬.

6.1.1. Exploited Hosts 🦠

One area where researchers are super 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 can be divided into three categories: prevention, detection, and defense 🛡️.

6.1.1.1. Prevention 🚧

Code quality is crucial when it comes to preventing exploitation of Internet hosts 🧼. Quite a bit of research effort has therefore gone into improving code quality. Researchers are looking into automated methods for finding bugs and, maybe in the end, fixes for any bugs detected 🪲.

A second approach designed to stop hosts from becoming compromised is to reduce the "attack surface" 🎯. Researchers are thinking about changes or extensions to the Internet architecture. The idea is to create a strict client/server architecture, where clients are only allowed to initiate connections, and servers may only accept connections 🔐.

Researchers have put a lot of effort into better scaling honey pots and honey farms, to better understand and neutralize the methods miscreants use to exploit hosts 🍯. Research also goes into developing honey monkeys, in order to understand how hosts are vulnerable 🐵. Both honey pots/farms and honey monkeys are aimed at taking measures that prevent further (mis-)use of possible exploits 🙅‍♀️.

6.1.1.2. Detection 🕵️

When an attack is launched against a computer system, the attack typically leaves evidence of the intrusion in the system logs 🪵. Each type of intrusion leaves a specific kind of footprint or signature. The signature can be evidence that certain software has been executed, that logins have failed, that administrative privileges have been misused, or that particular files and directories have been accessed 👀. Administrators can document these attack signatures and use them to detect the same type of attack in the future. This process can be automated 🤖.

Because each signature is different, system administrators can determine, by looking at the intrusion signature, what the intrusion was, how and when it was carried out, and even how skilled the intruder is 🧠.

Once an attack signature is available, it can be used to create a vulnerability filter, i.e., the stored attack signature is compared to actual events in real time, and an alarm is raised when this pattern is repeated 🚨.

A further step may be taken with automated vulnerability signatures, i.e., when a new type of attack is found, a vulnerability filter is created automatically 🪄. This vulnerability filter can be made available for nodes to defend themselves against this new type of attack 🫶. The automated vulnerability signatures may be part of an Intrusion Detection System (IDS) 🌈.

6.1.1.3. Defense

okay so an IDS can totally be part of the defense against actual attacks 🛡️, like by using vulnerability filters ✨. An Intrusion Detection System (IDS) inspects inbound and outbound network activities and detects signatures that show a system is under attack from someone trying to break in or compromise it 👀. Lowkey the whole "watching the door" energy 🚪💅.

6.1.2. Distributed Denial of Service (DDoS) Attacks

bestie, research on DDoS attacks goes down two separate paths 💖. One path has the application as its focus, and the other focuses on the network 🌐. Both are iconic in their own way 👑.

6.1.2.1. Application Oriented DDoS Research

the key issue here is telling legitimate activities apart from attacks 🤔. Today, several tools exist that can do this, and research has moved on to more advanced stuff 🚀.

Research today is looking into tools that can detect and filter activities generated by bots and botnets 🤖. It's giving detective era 🕵️‍♀️✨.

One approach is to set up a tool that sends challenges to senders who want to send traffic to a certain node 🧩. The potential sender then has to respond correctly to that challenge, otherwise the traffic gets filtered out 🚫. Not me being picky, but that's the whole vibe 💅.

The other option is to get more capacity between sender and receiver 📈. This is mainly done through some form of peer-to-peer technology 🔗.

Ngl there is serious "peer-to-peer hype" in the research community right now 🫠. A sure way to make yourself known as a researcher is to publish something that solves old problems with some peer-to-peer technology 🏆. Proposals now exist for peer-to-peer DNS, peer-to-peer backup solutions, peer-to-peer web-cast, and more 🌸. Whether these proposals can actually live up to the hype remains to be seen 👀✨.

6.1.2.2. Network Oriented DDoS Research

research on DDoS attacks with a network oriented focus can be described by the following oversimplified three steps 📝. Lowkey very cute and very simple 🎀.

Find the bad stuff
Set the "evil bit" on those packets
Filter out the packets with the "evil bit" set

this rather uncomplicated scheme has to run on high-speed links and interfaces ⚡. Automation is the only way to pull it off 🤖💜.

One way of indirectly setting the "evil bit" is to use a normalized TTL 🧠. The logic goes like this: the TTL for traffic from this sender has always been "x", but now it has suddenly become "y", with no matching change in routing 🗺️. The conclusion is that someone is masquerading as the legitimate sender 🎭. So traffic with the "y" TTL gets filtered out 🗑️. It's giving detective work fr fr 🔍🍓.

Another idea is to give traffic received from ISPs that are known to do source address validation the "red carpet treatment" 🏆🧚, i.e., to set the "good bit". When an attack is detected, traffic from everyone who doesn't have the "good bit" gets filtered out 🚫. Apart from reacting to the attack, this also gives ISPs an incentive to do source address validation 💰. If they don't do it, their peers won't set the "good bit", and the ISP's customers will suffer, dragging down the ISP's reputation 😭💀.

Overlay networks can also be used to stop a DDoS attack 🌈. The idea here is that traffic isn't routed directly to the destination. Instead, it's hidden behind some entry points in the overlay 🫥. The entry points make sure the sender is the host they claim to be, and if so, they mark the packet with a "magic bit" ✨🪄. Packets lacking the "magic bit" are not forwarded on the overlay 🙅‍♀️. This has really good scaling properties, because you only need enough capacity to tag the amount of traffic you want to receive, not the amount you actually receive 📊💖.

6.1.3. Spyware

current research on spyware, and measurements of spyware, are aiming to find ways to understand when certain activities associated with spyware happen, and to understand the impact of that activity 🔎. There are a number of research activities around spyware, e.g., looking into threats caused by spyware 🕷️. Ngl these were only briefly touched on at the workshop 🙈.

6.1.4. Forensic Aids

lately, research has started looking into tools and support that answer the "What happened here?" question 🕵️‍♀️🔎. These tools are called "forensic aids", and they can be used to "recreate" an illegal activity, just like the police do at a crime scene 🚨🎀.

The techniques these forensic aids start from involve identifying a process or program that shouldn't be present on a computer 👾. The effort goes into building tools and methods that can trace the intruder back to its origin 🧵. Methods for understanding how a specific output depends on a particular input also exist 🧩✨.

6.1.5. Measurements

measurements are always interesting to the research community, because they generate new data 📈💜. Consequently, lots of effort goes into specifying how measurements should be performed and into developing measurement tools 🛠️. Measurements have been useful in creating effective counter-measures against worms 🐛. Before measurements gave actual data on how worms behave, actions taken against worms were generally ineffective 😤.

6.1.6. Traffic Analysis

one aspect of research that closely relates to measurements is analysis 🧠. Earlier, it was common to look at the amount of traffic going through certain transport ports 🚪. Lately, it has become common to tunnel "everything" over something else, so there's been a shift towards looking for behavior and/or content 👀🦋. When you see a certain behavior or content over a protocol that isn't supposed to behave that way, it's likely that something bad is going on 🚩.

Since this is an arms race, the miscreants who use tunneling protocols have started to mimic the pattern of something that's acceptable 🥷💅.

6.1.7. Protocol and Software Security

the general IETF design guidelines for robust Internet protocols say: "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 isn't ready yet, but it will be offered as input to a BCP in due course ⏳.

An area with potential overlap between standards people and researchers is protocol analysis languages 🤝. Protocol analysis languages could be used, for example, to look for vulnerabilities 🔍🌈.

6.2. Research on the Internet

the workshop discussed the interface between people working in standardization organizations in general, and the IETF in particular, on 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" 😈🍿.

6.2.1. Research and Standards

the workshop discussed how research and standardization could mutually support each other 🤝💖. Quite often there's a commonality of interest between the two groups 👯‍♀️. The IAB supports the Internet Research Task Force (IRTF) as a venue for Internet research 🏛️. The delta between what is done and what could be is still substantial 📏. The discussion focused on how standardization in general, and the IETF in particular, can get help from researchers 🧑‍🔬.

Since standardization organizations don't have the economic strength to simply finance the research they need or want, other means have to be used 💸. One is to correctly and clearly communicate problems, and another is to supply adequate and relevant information 📣✨.

To attract the research community to work with standardization organizations, it's necessary to identify the real problems and state them in a way that makes them amenable to solution 🎯. General unspecified problems are of no use, e.g., "This is an impossible problem!" or "All the problems are because my users behave badly!" 🙄💀.

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

The potential research problem should also be communicated publicly 📢. A researcher who wants to take on a problem is helped if they can point at a slide from NANOG or RIPE that identifies this problem 🪧💜.

The way researchers go about solving problems is basically to identify all the existing constraints, and then relax one of the constraints and see what happens 🧪. Therefore, rock solid constraints are a show stopper, e.g., "We can't do that, because it has to go into an ASIC!" 🚫🧱. Real constraints have to be clearly communicated to, and understood by, the researcher 🫶.

One reasonable way to foster cooperation is to entice two or three people and have them write a paper on the problem 📝🥰. What happens then is that this paper gets incrementally improved by other researchers 📈. The vast majority of all research goes into improving on someone else's paper 🌟.

A second important factor is supplying sufficient relevant information 📚. New information that suggests possible ways to address new problems, or to improve on old or partial solutions to previously investigated problems, is attractive 💅. Often, understanding of important problems comes from the operator community, so when trying to initiate research from a standards perspective, keeping operators in the loop may be beneficial 🫂🌷.

Today, the research community is largely left on its own, and consequently tends to generate essentially random, untargeted results 😵‍💫. If the right people in the standards community say the right things to the right people in the research community, it can literally focus hundreds of graduate students on a single problem 🎓🔥🔥. Problem statements and data are needed 💖📊.

6.2.2. Research and the Bad Guys ✨

okay so here's the tea 🫖: basically all research has a dark side bestie. whatever can be used can also be misused, and sometimes miscreants get help from research that nobody ever meant to give them 💀

there are a few examples of Free Nets, which are networks built so end-users can participate without revealing their identity or how and where they're connected to the network 🦋 they're based on tech like onion routing or mix networks. Free Nets create anonymity so people can share opinions without exposing their real identity, which means they can be used to promote free speech 🗣️ but these same tools can also work just as well to hide illegal activities in democracies. iconic dual energy, not gonna lie.

mix networks create hard-to-trace communications by using a chain of proxy servers 🔗 a message goes from a sender to a receiver and passes through that chain of proxies. the message gets wrapped in layered encryption, where each layer can only be read by one of the proxies in the chain, and the actual message is the innermost layer 🪆 a mix network can still achieve untraceable communication even if all but one of the proxies get compromised by a potential tracer. that's the kind of main character energy I'm obsessed with 😭

onion routing is a technique for anonymous communication over a computer network 🧅 it encodes routing information in a set of encrypted layers, and it's a further development of mix networks. the layers are literally the onion, periodt 💜

research projects have also given us methods for distributed command and control, like Distributed Hash Tables (DHT) and gossip protocols 🌈 this of course has legitimate uses, for example in security and reliability applications, but it's also extremely useful for DDoS attacks and unwanted traffic in general. so yeah, double-edged sword, ngl 🗡️

then there's worms 🪱 a lot of effort has gone into researching them, and the result is that we have a very good understanding of their characteristics and how they behave ✨ that's a great basis when we want to protect against worms 🫶 the downside is that researchers also understand how to build future worms, including how to design faster worms that won't leave a footprint. not me going "wait, that's a plot hole" 🙈

7. Aladdin's Lamp 🧞

okay imagine we had an Aladdin's Lamp 🪔 and could be granted anything we wanted for dealing with unwanted traffic or its effects. what would we wish for? the whole point of this session was wishes, which means loosening the constraints that depend on what we have right now and focusing on what we really want 💖

there are lots of "wishes" floating around, and making things simpler and safer is definitely at the top of the list ✨ on the flip side, very few of these wishes are clearly stated 🤔 one comment on this lack of clarity was that we're way too busy putting out today's fires to have time to think ahead 🔥

7.1. Security Improvements

the operators at the workshop shared a bunch of wishes that, if fulfilled, would help improve and simplify security 💅 the list below has examples of actions that ought to improve security. the content is still at the "wish-level," so nobody has put in effort to figure out whether these wishes are actually feasible 🌸

Wish: Reliable point of contact in each administrative domain for security coordination 📞 First and foremost, operators would love correct and complete contact information for coordinating security problems across operators 🫶

the "whois" database of registration details for IP addresses and Autonomous System numbers, held by Regional Internet Registries (e.g., ARIN, RIPE, APNIC), was meant to be the directory for this type of info 📒 and RFC 2142 [RFC2142] set up common mailbox names for certain roles and services. there are several reasons these tools are largely unused, including unwanted traffic 😩

Wish: Organized testing for security 🧪 right now, new hardware and software get tested extensively for performance, but there's almost no testing of that hardware and software for security 👀 big mood.

Wish: Infrastructure or test bed for security 🛠️ it would be super good to have an organized infrastructure or test bed for testing the security of new products 🧚

Wish: Defaults for security 🔐 equipment and software should come with a simple and effective default setting for security 💜

Wish: Shared information regarding attacks 📣 it would be useful to have an automated sharing mechanism for attacks, vulnerabilities, and sources of threats between network users and providers, so attacks can be met in a more timely and efficient manner ⚡

7.2. Unwanted Traffic

Wish: Automatic filtering of unwanted traffic 🚫 it would be useful, especially for enterprises, to have mechanisms that automatically filter out unwanted traffic 🍓

some filtering of spam, viruses, and malware sent by email is already practicable, but it's inevitably imperfect because it mainly relies on "heuristics" to spot unwanted traffic 🙃 this is another example of the "arms race" between filtering and the ingenuity of spammers trying to dodge the filters 🥊 this "wish" needs more discussion and development before it can become practical ideas.

Wish: Fix Spam 📧 a large fraction of the email coming into enterprises today is spam, so any fixes to the spam problem are very high on their priority list 🫠

8. Workshop Summary 🌈

the workshop spent its last two hours on this 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 summed up into three classes.

8.1. Hard Questions 🧠

this concluding section raised a bunch of questions that touched on the overall network architecture designs 🏗️

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? 🔍
To add effective protection to the Internet, how far are we willing to go in
- curtailing its openness, and
- increasing the system complexity?

and what architectural principles do we need to preserve as we go along these paths? 🛤️

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 🫣
Can we, and how do we, change the economic substructure? A special workshop was suggested as a next step to better understand the question 💸

8.2. Medium or Long Term Steps 🗓️

answering the hard questions above may take some time and effort, but several specific steps were suggested as medium or long term efforts to add protection to the Internet 🛡️

Tightening the security of the core routing infrastructure 🔒
Cleaning up the Internet Routing Registry repository [IRR], and securing both the database and the access, so it can be used for routing verifications 🧹
Take down botnets 🤖
Although we don't have a magic wand to wave all the unwanted traffic off the Internet, we should be able to develop effective measures to reduce unwanted traffic to a tiny fraction of its current volume and keep it under control ✨
Community education, to try to ensure people use updated host, router, and ingress filtering BCPs 📚

8.3. Immediately Actionable Steps 🚨

the IETF is recommended to take steps to carry out the following actions for enhancing network protection 💪

Update the host requirements RFC. The Internet host requirements ([RFC1122], [RFC1123]) were developed in 1989. The Internet has gone through fundamental changes since then, including pervasive security threats. so a new set of requirements is overdue 📅
Update the router requirements. The original router requirements [RFC1812] were developed in 1995. Like the host requirements, it's also overdue for an update 🧭
Update ingress filtering (BCP 38 [RFC2827] and BCP 84 [RFC3704]) 🚪

one immediate action the IAB should carry out is to inform the community about the existence of the underground economy 🕵️‍♀️

the IRTF is recommended to take further steps toward understanding the Underground Economy and to start research on developing effective countermeasures 🔬

overall, the workshop attendees want to raise the community's awareness of the underground economy 📢 the community as a whole should undertake a systematic examination of the current situation and develop both near- and long-term plans 🗺️🫶

9. Terminology ✨

okay bestie, this section is a quick glossary of the key words that keep popping up in the doc 📖 it's not the full list, just a cute cheat sheet so you can keep up 💅

ACL

okay so an ACL (Access Control List) is basically a list of IP addresses or routing prefixes (layer 3, the Internet layer 🌐), sometimes paired with transport port numbers (layer 4, the transport layer 🚪). packets in a flow coming in or going out of a device get checked against the ACL entries to decide if they're allowed or denied access to some resources. so the ACL is literally a filter on a flow of packets 🔍 it's giving bouncer energy 💅

BGP route hijacking

this one is so not it 💀 it's an attack where someone shoves a bad route into the global routing system to steal traffic from its real recipient. the traffic either gets just dropped (a DoS attack, see below 👀) or it's part of a bigger attack on the victim. fun fact: injecting fake routes for bogon addresses can give email systems fake proof that spam is coming from legit addresses 🙈

Bogon

a bogon is an IP packet whose source address comes from a range that hasn't been given out to real users yet, or is a private [RFC1918] or reserved address [RFC3330] 🚫

Bogon prefix

a bogon prefix is a route that should never show up in the Internet routing table, like one from private or unallocated address blocks 🙅‍♀️

Bot

a bot is internet slang for a software program that acts as a software agent 🤖 it talks to network services meant for people like it's a real person 💬 bots are often used to gather info. the name comes from "robot", which is about that autonomous, "virtual robot" vibe 🧚

the most common bots are the sneaky ones that secretly install themselves on people's computers for shady reasons. they're basically remote attack tools 😬 and they're sometimes called "zombies" 🧟

Botnet

a botnet is jargon for a bunch of bots running autonomously 🕸️ it can also mean the network of computers running distributed computing software. technically "botnet" can mean any group of bots (like IRC bots), but people usually use it for a pile of compromised machines running worms, Trojan horses, or backdoors, all under one common command and control setup 👑

Click fraud

click fraud happens in pay per click (PPC) advertising when a person, a script, or a program pretends to be a real user clicking an ad just to rack up an improper charge per click 💸 PPC works like this: site operators act as publishers and show clickable links from advertisers in exchange for a charge per click 🖱️

Darknet

a darknet (also called a Network Telescope, a Blackhole, or an Internet Sink) 🕳️ is a globally routed network with no "real" machines on it, and it only carries a tiny amount of specially crafted legit traffic. that makes it super easy to pull out and study the unwanted traffic, which can come from things like a human mistyping an IP address, hackers scanning for vulnerable targets, backscatter from random source DoS attacks, and the automated spread of Internet worms 🔬

Dirty affiliate program

okay so affiliate programs are marketing setups that recruit agents to promote a product or service 📣 affiliates get paid for each sale tied to their unique 'affiliate ID' 💰 they're usually told not to break any laws while promoting, and if they spam or break the program's rules they get sanctioned (usually losing unpaid commissions or getting kicked out) 🚫

dirty affiliate programs are the messy ones 🗑️ they either allow spamming, or they say they don't allow it but never actually punish anyone. they often push illegal or deceptive stuff (like prescription drugs sold without normal dispensing rules, or body part enlargement products, etc.), use anonymous or untraceable affiliates, take payment through anonymous online financial channels, and may skip normal tax withholding and reporting 😤

DoS attack

a DoS attack (Denial-Of-Service) is an attack designed to bring a network to its knees 🦵 by flooding it with useless traffic or blocking the resources needed for normal traffic flow 🌊

DDoS attack

a DDoS attack (Distributed Denial of Service) is when multiple compromised systems team up to target a single system, causing a Denial of Service (DoS) attack 🤝

Honey farm

a honey farm is just a set of honey pots working together 🍯🌾

Honey monkey

a honey monkey is a honey pot in reverse 🐒 instead of sitting around waiting for miscreants, it actively mimics a user surfing the Web. it runs on virtual machines so it can detect exploit sites 🕵️‍♀️

Honey pot

a honey pot is a server on the Internet that acts as a decoy 🪤 it attracts potential miscreants so people can study what they're doing and monitor how they break into a system. honey pots mimic systems an intruder would want to break into, but they keep the intruder from getting access to the whole network 🔒

IRC

IRC (Internet Relay Chat) is a form of instant communication over the Internet 💬 it's mainly built for group (many-to-many) chats in discussion forums called channels, but it also allows one-to-one messages. it was originally standardized by RFC 1459 [RFC1459], and it's been much improved and extended since 🌱 IRC clients meet up and swap messages through IRC servers, and lots of organizations run those servers for both benign and nefarious purposes 👀

Malware

malware is software designed to infiltrate or damage a computer system without the owner's informed consent 🦠 people debate where the word comes from. is it a portmanteau of "malicious" and "software", or is it just the prefix "mal-" plus the morpheme "ware"? 🤓 malware is about the creator's intent, not any particular features. it includes computer viruses, worms, Trojan horses, spyware, adware, and other malicious and unwanted software. in law, it's sometimes called a computer contaminant 📜

Mix networks

mix networks create hard-to-trace communications by bouncing messages through a chain of proxy servers [MIX] 🌀 each message gets encrypted for each proxy, and the layers stack up like a Russian doll with the message as the innermost layer 🪆 even if all but one of the proxies get compromised by a tracer, untraceability is still achieved 🙌 more info is at <http://www.adastral.ucl.ac.uk/~helger/crypto/link/protocols/mix.php>.

Onion routing

onion routing is a technique for anonymous communication over a computer network 🧅 it encodes routing information in a set of encrypted layers. it's based on mix cascades (see mix networks, q.v.). more info is at <http://www.onion-router.net/>.

Phishing

phishing is a form of criminal activity that uses social engineering techniques 🎣 it's all about fraudulently grabbing sensitive info, like passwords and credit card details, by pretending to be a trustworthy person or business in what looks like an official electronic message. it's typically done with spoofed websites, email, or instant messages 📧 the name comes from password harvesting and the use of increasingly sophisticated lures to "fish" for people's financial info and passwords 🐟

Root access

root access means full administrative privileges that get around any security restrictions placed on normal users 👑 the name comes from the 'superuser' name traditionally used on Unix systems 🐧

Script kiddy

a script kiddy is a derogatory term for an inexperienced hacker who mindlessly uses scripts and programs other people made, to compromise computers or generate DoS attacks 🙄 not a flex, bestie 💀

Spam

spam is the abuse of electronic messaging systems to send unsolicited, undesired bulk messages 📨 the individual messages are referred to as spam, and the term is often used specifically for the email form of spam 📬

Spoofing

(IP) spoofing is when the illegitimate source of IP packets gets hidden by using IP addresses the receiver recognizes as legit 🎭 it's often used to sneak into computers or trick filtering mechanisms. the intruder sends packets into the network with a source address that makes it look like they're coming from a legit host. to pull it off, a hacker first has to use a bunch of techniques to find the IP address of a valid host, then modify the packet headers so the packets look like they came from that host 🕶️

Spyware

spyware is any software that covertly gathers user info through the user's Internet connection without them knowing, e.g., for spam purposes 👁️ absolutely not iconic 😤

UBE

UBE (Unsolicited Bulk Email) is an official term for spam 📋

UCE

UCE (Unsolicited Commercial Email) is an official term for spam 📋

Virus

a virus is a program or piece of code that gets loaded onto a computer without the owner's knowledge and runs without their consent 🧫 it's self-replicating code that spreads by inserting copies of itself into other executable code or documents, which then get transferred to other machines 📂 usually the virus has a payload that harms the infected machine when the virus code runs ☠️

Worm

a worm is a self-replicating computer program 🪱 it uses a network to send copies of itself to other systems, and it may do that without any user doing anything 😱 unlike a virus, it doesn't need to attach itself to an existing program. worms always harm the network (even if it's just by eating up bandwidth), whereas viruses always infect or corrupt files on a targeted computer 💥

Zombie

zombie is just another name for a bot 🧟‍♀️

10. Security Considerations 🔐

this document doesn't specify any protocol or "bits on the wire" 🫶 so there's no protocol mechanism here to secure, and nothing on the wire to check, but the security stakes of everything above are still very real 😭

11. Acknowledgements 🌸

the IAB would like to thank the University of Southern California Information Sciences Institute (ISI) 🏫 for hosting the workshop, and all the people at ISI and elsewhere who helped out with the organization and logistics of the workshop there 🙌

the IAB would also like to thank the scribes listed in Appendix A, who diligently recorded the proceedings during the workshop 📝✨

a special thanks to all the workshop participants 🌈 who took the time, came to the workshop to take part in the discussions, and put in the effort to make it a success 💜 the IAB especially appreciates everyone who prepared and gave presentations at the workshop 🎤👑

12. Informative References ✨

okay so this is the reading list bit 📚 every source the document leans on lives here, and I'm keeping every single detail so nobody gets lost chasing a link 🔍

[IMS]      University of Michigan, "Internet Motion Sensor", 2006,
           <http://ims.eecs.umich.edu/>.

[IRR]      Merit Network Inc, "Internet Routing Registry Routing
           Assets Database", 2006, <http://www.irr.net/>.

[MIX]      Hill, R., Hwang, A., and D. Molnar, "Approaches to Mix
           Nets", MIT 6.857 Final Project, December 1999, <http://
           www.mit.edu/afs/athena/course/6/6.857/OldStuff/Fall99/
           papers/mixnet.ps.gz>.

[RFC1122]  Braden, R., "Requirements for Internet Hosts -
           Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
           and Support", STD 3, RFC 1123, October 1989.

[RFC1459]  Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
           RFC 1459, May 1993.

[RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
           RFC 1812, June 1995.

[RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
           E. Lear, "Address Allocation for Private Internets",
           BCP 5, RFC 1918, February 1996.

[RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
           FUNCTIONS", RFC 2142, May 1997.

[RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
           Defeating Denial of Service Attacks which employ IP Source
           Address Spoofing", BCP 38, RFC 2827, May 2000.

[RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
           September 2002.

[RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
           Networks", BCP 84, RFC 3704, March 2004.

[SHRED]    Krishnamurthy, B. and E. Blackmond, "SHRED: Spam
           Harassment Reduction via Economic Disincentives", 2003,
           <http://www.research.att.com/~bala/papers/shred-ext.ps>.

Appendix A. Participants in the Workshop 🎀

the whole squad who showed up to the workshop, roles included 🫶

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

Appendix B. Workshop Agenda 🗓️

here's how the day was laid out, session by session 💅

Session 1:
How bad is the problem? What are the most important symptoms?

Session 2:
What are the sources of the problem?

Lunch session (session 3):
Solutions in regulatory and societal space

Session 4:
The underground economy

Session 5:
Current countermeasures, what works, what doesn't

Session 6:
If all our wishes could be granted, what would they be?

Session 7:
What's in the pipeline, or should be in the pipeline

Session 8:
What is being actively researched on?

Session 9:
What are the engineering (immediate and longer term) and
research issues that might be pursued within the IETF/IAB/IRTF?

Appendix C. Slides 🦋

so the slides. the IAB workshops page has links to some of the talks given by the participants at <http://utgard.ietf.org/iab/about/workshops/unwantedtraffic/index.html>, but it's <pink>not</pink> the full set. Section 1 already mentioned why: a few presentations were sensitive, so sharing them publicly right now wouldn't be appropriate 🙈

Authors' Addresses 📮

Loa Andersson
Acreo AB

EMail: loa@pi.se


Elwyn Davies
Folly Consulting

EMail: elwynd@dial.pipex.com


Lixia Zhang
UCLA

EMail: lixia@cs.ucla.edu

Full Copyright Statement ⚖️

bestie, the legal bit 🫠 but the vibe is simple: the IETF Trust owns the copyright on this one, and it's (C) The IETF Trust (2007). this document falls under the rights, licenses and restrictions in BCP 78, and aside from what that says, the authors keep all their rights 💜

also the disclaimer is giving full "as is" energy. the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust and the Internet Engineering Task Force all DISCLAIM ALL WARRANTIES, express or implied. that includes no promise that using the info here won't infringe any rights, and no implied warranties of merchantability or fitness for a particular purpose 🙃

Intellectual Property 🔐

the IETF takes no position on whether any IP rights claimed for the tech in this document are valid or how far they reach, and it doesn't say whether licenses for them are available. it also hasn't independently checked for any such rights 👀 the rules on rights in RFC documents live in BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users are all on the IETF online IPR repository at http://www.ietf.org/ipr.

and the IETF wants to hear from you 💖 if you know of any copyrights, patents, patent applications or other proprietary rights that might cover tech needed to implement this standard, tell the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

funding for the RFC Editor function is currently coming from the Internet Society. thank u, next 🫶✨

📦 where this page comes from

ietf: rfc4948 2007-08
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms