The Evil Bit Revisited: Blocking DDoS Attacks with AS-Based Accountability

Dan Simon Sharad Agarwal Dave MaltzTrustworthy ComputingApril 8, 2006

The Solution to DoS is Already Here!Paraphrasing the rest of the RFC:Malicious applications MUST set the evil bit to 1Routers/firewalls SHOULD preferentially drop pakcets with the evil bit setFirewalls ... and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. The problem is that making such determinations is hard. To solve this problem, we define a security flag, known as the "evil" bit, in the IPv4 header. Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1. Network Working Group S. BellovinRequest for Comments: 3514 AT&T Labs ResearchCategory: Informational 1 April 2003The Security Flag in the IPv4 Header

Approaches to DoS on One SlideIngress filteringWorthless until deployed everywhere, hence undeployablePushback filteringRequires PKI to authenticate requestsRequires router hardware changesReflection attacks render pushback uselessCapabilitiesCapability server vulnerable to DoSRequires changing router HW and host SWOur solution: Leverage AS relationships and the evil bit for incrementally-deployable ingress filtering and pushback without router changes or a PKI

OutlineThe Problem of DoSInternet AccountabilityAchieving accountability among a club of members with pair-wise trustDealing with the world outside the clubDetermining if a member of the club has gone badEconomics of Dos and Accountability

Understanding (D)DoSBasic structure: the attacker tries to get the target to use up resources (memory, CPU, bandwidth, etc.) dealing with DoS trafficSucceeds when the targets remaining resources are insufficient to handle everyone elses trafficThe targets only strategies are:Increasing resources enough to handle it allDistinguishing DoS traffic, and reducing the resources expended on itE.g., identify sources of DoS traffic, and block them

DoS and the InternetCompany running a websitewebserveraccess linkYou are hereYour customers are hereSome of them want to hurt you

Levels of DoSCan hit the application layer or the network layerApp-layer DoS attack and defense are highly application-dependentThe attacker can exploit bugs or costly high-level operations The defender can try to spot subtle distinguishing cues in application-level traffic

Levels of DoSNetwork-layer DoS can attack any applicationWebsite serving a peak load of 100,000 hits/second, @5KBytes/hit, needs a 4Gbps access link ($25-$50K/month) . .Which is completely saturated by 4,000 1Mbps broadband clients (about $400/week on the botnet market)

Levels of DoSObservations:If new attackers appear faster than they can be classified, then all is lost (IP spoofing/DHCP exacerbates)Need to shed all load from attacker once identifiedASes have long-lived relationships with each otherASes generally have non-transient relationships with their customers (e.g., billing information)

Sidebar: Isnt End-Host Security the Real Problem?True, compromised end hosts (botnets) are a major source of unwanted trafficBut.suppose end hosts were bullet-proofE.g., you could run SETI@home completely safelyIntroducing DDoS@home....Does something nice for the user (use your imagination)Borrows spare cycles and bandwidth in return, with which to launch DDoS attacksThe user may or may not even know or care what it does, because.The users computer and data are completely safeConclusion: End hosts arent the whole problemThe solution needs to involve the network, as well

OutlineThe Problem of DoSInternet AccountabilityAchieving accountability among a club of members with pair-wise trustDealing with the world outside the clubDetermining if a member of the club has gone badEconomics of Dos and Accountability

What Is Accountability?Two components:Identification: Receivers of traffic can distinguish it by source Must be based on some persistent attributeI.e., difficult/expensive for the originator to changeThink IP addressbut something more durable is neededDefensibility: Receivers can choose to avoid (block) traffic from a source with a particular persistent attributeRequires identification, but doesnt automatically follow from itAllows a DoS target to distinguish DoS traffic sources (not just IP address), and block all traffic from them

OutlineThe Problem of DoSInternet AccountabilityAchieving accountability among a club of members with pair-wise trustDealing with the world outside the clubDetermining if a member of the club has gone badEconomics of Dos and Accountability

Implementing Accountability on the Internet(Among a Club with Pair-wise Trust)Total Ingress FilteringEvery packet is required to have an honest source addressCovers all traffic (e.g., DNS spoofing eliminated!)Filtering on request by source-destination pairRequestor identifies source by (IP address, port, time)Too many filters against a source leads to other measuresRate-limiting, offers for support upgrades, warnings, charging

`

Implementing Accountability on the Internet(Among a Club with Pair-wise Trust)

Both measures are best implemented at the source ISPCan identify, distinguish and filter an individual offending machine/user at the ingress point (even assuming DHCP, NAT, etc.)Downstream ASes are spared the trafficMultiple paths arent a problemHabitual offenders are more easily recognized

`

Secure Relay of Filtering RequestsAssume for now:Peer ISPs cooperateincluding ingress filteringBasic Design:Every AS/ISP has a Filter Request Server (FRS)Requestor sends a request to its local ISPs FRS FRS forwards the request along a chain of FRSs to the sources ISP: filter all traffic from source to requestor Request does not need to follow the same path as the offending trafficSources ISP identifies the source and applies the filter

How FRSs Work

`

Attacks on the FRS SystemCustomer asks FRS to filter traffic to another customerCant happen FRS only allows filters on traffic to requestorIngress filtering prevents spoofing and crypto is easyAn ISP injects spoofed Filter RequestsMeans an ISP is breaking its peering agreementsPresumably a rare, serious eventHeavy-duty investigation using sampling, logs, cooperationDoS on FRSsFRS can filter traffic to itself!ISP can charge for right to send filter requests, and scale FRS accordingly

Attacks on the FRS SystemFraming attacks (false, non-spoofed complaints)Only relevant when they accumulate, hurting a sources reputationA single framer can block anyone he/she wants (and who cares?) Solution: delay punitive measures to allow resolutionGives the customer a chance to complain of framingOverwhelm a routers ability to filter a customerApply many useless filters against a bot, so real filters dont takeSolution: evict the customer from the club

OutlineThe Problem of DoSInternet AccountabilityAchieving accountability among a club of members with pair-wise trustDealing with the world outside the clubDetermining if a member of the club has gone badEconomics of Dos and Accountability

Incremental Deployment and the Evil BitPackets from unaccountable peers get evil bit setMarking occurs at ingress to accountable ASBit stays set as the packet travels through accountable ASesBehavior enforced by peering agreement

Incremental Deployment and the Evil BitISPs can de-prioritize evil traffic sent to their customersOn request, or when traffic to the customer is too heavyDiffServ mechanisms are already available on most routersIncentive to other ISPs to become accountableISPs can also slap an evil bit on repeat offenders trafficCheaper than filtering out a large list of destination addressesIncentive for the offender to stop attacks/remove malware

Reflection AttacksAttacker redirects attack packets through an innocent reflectorE.g., TCP SYN with (forged) source address of the attack targetresults in an ACK sent to the targetDoesnt magnify the attack, but helps disguise its source attack packets can shed their evil bitReflectors are fundamental to IP architectureIP depends on hosts/routers replying to single packetsPath MTU Discovery, TCP RST, ICMP TTL ExceededRouters, hosts all can be used as reflectorsOnly two choicesHosts/routers reply only to packets from authenticated sources breaks all connectivity to hosts using different or no authenticationHost/router software must change to reflect some characteristic of incoming packet in reply

Reflection Attacks - SolutionHosts need to preserve the evil bit setting of incoming packets when replying to themRequires changes to host network stacksBut these are necessary in any event, to protect against reflection attacksregardless of the DoS defense schemeIncremental deployment possibleAccountable ISPs probe customers for reflectionSet evil bit on hosts not reflecting evil bits properly

OutlineThe Problem of DoSInternet AccountabilityAchieving accountability among a club of members with pair-wise trustDealing with the world outside the clubDetermining if a member of the club has gone badEconomics of Dos and Accountability

What Motivates an AS to Follow the Accountablity Club Rules?Active malfeasance among ASes can be expected to be rarePeering agreements are contracts = lawyersSo long as misbehavior is observable to the world, peer pressure keeps ASes in lineDetection must be possibleNeed not be automatedFailure to behave means peer ASes will set evil bit on the offenders trafficBGP is a positive example

Detecting Fraudulent Accountable ASesEasiest case to detect: AS claims to install filters when requested, but doesntRequest forwarded and FRS ACK received, but packets still arrive and packet have evil bit clearEach AS tasks the upstream AS to determine why the filter wasnt applied, on pain of having evil bit set getting tossed out of the accountable club

UnaccountableAS7

Detecting Fraudulent Accountable ASesHardest case to detect: AS claims to perform ingress filtering, but doesntPackets with evil bit clear arrive at a hostPackets dont stop when host requests filteringCollaboration among neighbor accountable ASes shows packets not entering the fraudulent AS

UnaccountableAS7

OutlineThe Problem of DoSInternet AccountabilityAchieving accountability among a club of members with pair-wise trustDealing with the world outside the clubDetermining if a member of the club has gone badEconomics of Dos and Accountability

Economic JustificationSay you want to protect against 50,000 bots@128Kbps/bot....Roll-your-own solution:6.4 Gbps bandwidth (~10 OC-12s at $30K/month) + enough magic scrubber boxes ($110K/OC-12) = ~$10M over 3 yearsScrubbing services provided by ISP:$210K/month for 3 OC-48s worth of scrubbing = ~$7.5M over 3 yearsDeploying accountability:Hard to say how much this would costBut we have data on the cost of two huge communication infrastructure overhauls: number block pooling and local wireless number portabilityIf accountability is comparable, it would cost about $60-230M for the whole InternetBottom line: Somewhere between 6 and 30 large orgs could probably finance deployment of Internet accountability by themselves, out of their 3-year savings estimates

Deployment StrategiesThree primary types of ISPsServe end-users: Verizon, Comcast, ...Serve servers and enterprises: SAVIS, AboveNet, parts of ATT & Sprint, ...Serve other networks (transit): UUNET, ATT, Sprint, ...Deployment realitiesDeployment costs highest for ISPs serving end-usersRevenue potential greatest for ISPs serving serversBut these networks often peer directly! Now money can flow and mutual benefit arise...Who deploys first? Pairs of Server ISPs and User ISPs

Deployment Over TimeDoS on the Internet slowly goes awayA host with too many filters has evil bit setbotnets become harder to build and arent useful for as longUltimately, cost for links to DoS a server become greater than the cost of links to connect the serverDeploying accountability in transit network is cheapJust need an FRS to do pass-thruProbably not early adopters though

Related WorkIdentificationTCP handshake for identificationNo good for UDP, DNS, TCP SYN floods, transient IP addressesEnd-to-end (IPSec, HIP)Requires PKI, DNSSec or some other global identity infrastructureTraceback/packet-markingPartial, statistical information, doesnt help against transient IP addressesHighly vulnerable to reflection attacksDefensibilityEnd-host filtering (possibly with packet-marking)End hosts still have to have enough bandwidth to handle attacksCapabilitiesDont protect the capability issuer, and require state in the network to prevent capability abuseActive filteringPacket-marking + filtering scattered across the network (not just at source)

ConclusionsNetwork-level DDoS is a big problem on the Internet todayIts costing a lot of people a lot of moneySolving it will require costly changesAccountability actually solves the problemDDoS traffic can be identified and blocked at the sourceAccountability is actually deployableIngress and by-destination on-request filtering are technically straightforward to deploy The evil bit enables incremental deploymentAccountability is cheaper than living with DDoS

Questions?Thanks!

Our Solution in 1 SlideLeverage the persistence of relationships among ASes and their customers to create a working pushback packet filtering systemUse the evil bit to deal with non-participating ASes, achieve incremental deployability, and attain scalabilityProvide techniques to discover and cope with ASes that claim to be good citizens, but actually cheat or are lazyShow that our infrastructure is cheaper than alternatives

Sidebar 2: Computer Networking People, Please Cover Your EarsThere exists a large-scale, successful network today that doesnt have a DoS problem.Despite the fact that DoS attacks are breathtakingly easy on itThe reason: AccountabilityTargets know whos attacking, and can ask for the network to block all traffic from them(Okay, Computer Networking folksyou can uncover your ears now.)

AttacksPerhaps state that our scheme is targeted at end hosts (clients, servers). If a router is compromised, forget flooding style attacks, you've got more serious BGP attacks that can get rid of your legitimate traffic.

DeploymentPairings of ISPs specializing in hosting servers and ISPs specializing in serving home usersTwo tiers of filter requestorsBig servers are stable, and pay for the right to request lots of filters (theyre the DoS targets, after all)Small clients rarely if ever need to request filtersASes/ISPs can include accountability in their peering agreementsMutually agree to deploy ingress filtering and accept filtering requests from destinations (really easy for core ASes without end-host clients)

The Evil Bit In Action

add slides to talk about how companies handled?add pictureadd picture