TVA:A DoS-limiting Network ArchitectureSoonho [email protected] November 2010Xiaowei Yang, David Wetherall, and Tom AndersonIn IEEE/ACM Transactions on Networking (ToN), vol 16, no. 6, Dec. 2008.*Presented by1Problem, Goal, and Key IdeaProblem:DoS(Denial of Service) AttackAttackerUserServerGoal:Effectively Communicate!AttackerUserServerIdea: CapabilityShort-term authorizations Senders obtain from receiversStamp on their packetsIdea: CapabilityRequestSenderReceiverRequest1 Request CapabilitiesIdea: CapabilitySenderReceiver2 Send CapabilitiesIdea: CapabilitySenderReceiver3 Send Packets with CapabilitiesIdea: CapabilitySenderReceiverAttacker4 Filter Traffic without Capabilities2Key Challenges and Their SolutionsChallenge:Request FloodReceiverSenderRequestRequestRequestChallenge:Request FloodReceiverSenderAttackerAttackerRequestRequestRequestRequestRequestRequestRequestChallenge:Request FloodReceiverSenderAttackerAttackerRequestRequestRequestRequestRequestRequestRequestDoS Attack!Solution:Rate-limiting Request + per-identifier Fair-QueuingReceiverSenderAttackerAttackerRequestRequestRequestRequestRequestSolution:Rate-limiting Request + per-identifier Fair-QueuingReceiverSenderAttackerAttackerRequestRequestRequestRequestRequestRate-limitingSolution:Rate-limiting Request + per-identifier Fair-QueuingReceiverSenderAttackerAttackerRequestRequestRequestRequestRequestRequestRequestRate-limitingSolution:Rate-limiting Request + per-identifier Fair-QueuingReceiverSenderAttackerAttackerRequestRequestRequestRequestRequestRequestRequestper-IDFair-QueuingRate-limitingChallenge:Secure CapabilitiesAttackerReceiverForged/CopiedSenderForged/CopiedForged/CopiedDoS Attack!Solution:Cryptographic HashReceiverSenderRequestSolution:Cryptographic HashReceiverSenderRequestRequest3dest(2)responserequest(1)sender routerrouterFig. 1. A sender obtaining initial capabilities by (1) sending arequest to the destination, to which routers add pre-capabilities;and (2) receiving a response, to which the destination addedcapabilities.A. Packets with CapabilitiesTo prevent a destination from losing connectivity becauseof a flood of unwanted packets, the network must discardthose packets before they reach a congested link. Otherwise thedamage has already been done. This in turn requires that routershave a means of identifying wanted packets and providing themwith preferential service. To cleanly accomplish this, we requirethat each packet carry information that each router can check todetermine whether the packet is wanted by the destination. Werefer to this explicit information as a capability [3].Capabilities have significant potential benefits compared toother schemes that describe unwanted packets using implicitfeatures [16], [21]. They do not require a difficult inferenceproblem to be solved, are precise since attackers cannot spoofthem, and are not foiled by end-to-end encryption. However, tobe viable as a solution, capabilities must meet several impliedrequirements. First, they must be granted by the destinationtothe sender, so that they can be stamped on packets. This raisesan obvious bootstrap issue, which we address shortly. Second,capabilities must be unforgeable and not readily transferableacross senders or destinations. This is to prevent attackersfromstealing or sharing valid capabilities. Third, routers mustbeable to verify capabilities without trusting hosts. This ensuresmalicious hosts cannot spoof capabilities. Fourth, capabilitiesmust expire so that a destination can cut off a sender from whomit no longer wants to receive packets. Finally, to be practical,capabilities must add little overhead in the common case. Therest of our design is geared towards meeting these requirements.B. Bootstrapping CapabilitiesIn our design, capabilities are initially obtained using requestpackets that do not have capabilities. These requests are sentfrom a sender to a destination, e.g., as part of a TCP SYNpacket. The destination then returns capabilities to the senderif it chooses to authorize the sender for further packets, e.g.,piggybacked on the TCP SYN/ACK response. This is shownin Figure 1 for a single direction of transfer; each directionishandled independently, though requests and responses in differ-ent directions can be combined in one packet. Once the senderhas capabilities, the communication is bootstrapped in the sensethat the sender can send further packets with capabilities thatrouters can validate.Ignoring legacy issues for the moment, we expect the numberof packets without associated capabilities to be small in mostsettings. This is because one capability covers all connectionsbetween two hosts, and new capabilities for a long transfercan be obtained using the current capability before it expires.capability checkingregular packets yeslegacy packetsnolow priority queueHierarchical path!identifier queuerequests per!destination queueFig. 2. Queue management at a capability router. There are three typesof traffic: requests that are rate-limited; regular packets with associatedcapabilities that receive preferential forwarding; and legacy traffic thatcompetes for any remaining bandwidth.Pre!Capability (routers)timestamp (8 bits)Capability (hosts)hash(pre!capability, N, T) (56 bits)timestamp (8 bits)hash(src IP, dest IP, in iface, out iface,time, secret) (56 bits)Fig. 3. Format of capabilities.Nonetheless, it is crucial that the initial request channel notopen an avenue for DoS attacks, either by flooding a destinationor blocking the requests of legitimate senders. The first issue isstraightforward to address: we rate-limit requests at all networklocations so that they cannot consume all of the bandwidth.Request packets should comprise only a small fraction ofbandwidth. Even with 250 bytes of request for a 10KB flow,request traffic is 2.5% of the bandwidth. This allows us to rate-limit request traffic to be no more than 5% of the capacity ofeach link, with the added margin for bursts.It is more challenging to prevent requests from attackersfrom overwhelming requests from legitimate clients. Ideally,we would like to use per-source fair queuing to ensure that nosource can overwhelm others, regardless of how many differentdestinations it contacts. However, this is problematic becausesource addresses may be spoofed, but per-source fair queuingrequires an authenticated source identifier. One possibility isingress filtering, but we discarded it as too fragile
View Full Document
Unlocking...