A DoS-limiting Network Architecture

Download Report

Transcript A DoS-limiting Network Architecture

A DoS-limiting Network
Architecture
CSCE 715: Fall’06
Presentation by:
Amit Jain
Shantnu Chaturvedi
DoS (Denial of Service)
Attacks
DoS (Denial of Service)
Attacks
 Goal: To prevent legitimate users from using some service


Usually accomplished by exhausting some resources (ie, bandwidth, CPU,
memory)
Intrinsic problem of Internet: any hosts can send packets to any other hosts
without first acquiring permission
 Effects




2001 study shows 4000 attacks a week
Can bring down DNS root servers
Lost of business estimation are in the billions
Online extortion
Possible Defenses
 Ingress Filtering - Source address filtering



To prevent spoofing IP address
Need widespread deployment
Ineffective with more sophisticated attack, ie DDoS
 Traceback


Locate the source of the disrupting packets
Does not prevent DoS since an attacker can still use a short TTL
 Pushback


Signal upstream nodes to rate limit misbehaving nodes
How do you distinguish good from bad traffic?
Possible Defenses
SIFF (Stateless Internet Flow Filter)





Privileges & Unprivileged packet
Routers Mark every packet
Backward compatibility
Marking space in the IP header.
Routers mark every packet.
SIFF Packet Identifier Design
 Flags field (3-bits).


SF: Packet is non-legacy
CU: Capability reply present or not
 Capability: Marks modified by routers
 Capability-Reply: recipients to signal to sender a capability
Possible Defenses
 Capabilities

Senders obtain authorization from the receiver before sending the traffic
 Anomaly detection


Automated classification of “bad” flows
Traffic flow and type information used
Problems with current approaches
 Each solution addresses an aspect of problem and not the
overall issue.
 Do not provide a complete solution, either

Lack scalability

Require substantial change in hardware
Goal
 Provide a “comprehensive” solution to DoS
 Receiver should also be able to control traffic
directed towards it
 Two legitimate nodes should be able to effectively
communicate even during attacks
 Bounded computation and memory
 Incrementally deployable
 Focus on lower-layer attacks (bandwidth, router
memory)
TVA






Traffic Validation Architecture
Packet Capabilities
Cut to the heart of DoS problems
Destination control received packets
Counters a broader set of attacks
Automated validation of senders
Practical use of TVA
 Can operate at Gigabit speed on inexpensive
hardware
 Incremental deployment.
 Backward Compatibility.
 Mix of spectrum of solutions.
 Fine-Grained access control.
Traffic Validation Architecture
1.
2.
3.
4.
5.
6.
7.
8.
9.
Packets with Capabilities.
Bootstrapping Issues.
Destination Policies.
Unforgeable Capabilities.
Fine-Grained Capabilities.
Bounded Router State.
Efficient Capabilities.
Balancing Authorized Traffic.
Short, Slow and Asymmetric Flows.
1. Packets with Capabilities
 Capability information present in each packets used by routers to
provide preferential service.
 Capabilities:





Granted by destination .
Unforgeable.
Routers can trust packet capabilities without host authentication.
Must be byte & time limited for destination cutoff.
Add little overhead in computation and bandwidth.
2. Bootstrapping Issues
 To avoid the attacks on request messages itself
 Tags each request with a 16 bit value derived from the incoming
hardware interface
 Tags are used to queue the requests.
 Connection request packets do not contain capabilities and are rate
limited (5%) at all network locations.
 Fair queuing of requests combined with path identifiers helps counter
attacks from legitimate users.
3. Destination Policies
 Client has only outgoing request. It accepts requests only if it relates to
the previous request made by it.
 Server grants the requests with initial number of bytes (N) and timeout
(T).
 Weak authentication of source address, so misbehaving senders are
quickly contained by server.
 Destination determines how to authorize request depending on role of
destination in the network.
4. Unforgeable Capabilities
 Should not be forgeable or usable if stolen.
 Each Router generates own pre-capability and attaches it to the
forwarded packet.
 Each router changes it’s secret at twice the rate of timestamp rollover.
 The destination receives a set of pre-capabilities that correspond to a
specific network path with fixed source and destination addresses.
 Once authorized, the destination sends a list of capabilities to the sender.
5. Fine Grained Capabilities




Routers perform the pre-capability hash check and capability hash check
Check if their local time > original time stamp + T
Check if N bytes have already been used for this connection
To tackle this problem, limit the data flow rate (N) as well as the period
of validity (T) by returning these values to the sender.
 Router State is used to count the bytes sent so far.
6. Bounded Router State
 The router state could be exhausted as it would be counting the number
of bytes sent
 Router state is only maintained for flows that send faster than N/T
 When new packets arrive, a new state is created and a byte counter is
initialized along with a time-to-live field that is decremented.
6. Bounded Router State
 Consider the router creates a capability valid for t + T, then it allows data
till the ttl field is decremented to zero, after which the router state is
reclaimed
7. Efficient Capabilities
 Capabilities should be efficient (Less overhead) as well as secure (long key
length).
 Long capabilities (64-bits) are used for security and then cached at routers for
efficiency.
 When a router receives a packet with a valid capability, it caches the
capability relevant information and the flow nonce.
 Subsequent packets then carry the flow nonce only and omit the list of
capabilities.
 Routers check the packets without capabilities using source & destination IP
address and compare the cached nonce with the packet nonce.
 Legacy packets are demoted by changing a bit in the capability header
8. Balancing Authorized Traffic
 Authorized flows between attacker and colluder may be malicious.
 Simply give each capability a reasonable share of the network bandwidth.
 Users get decreasing share of network bandwidth as the network becomes
busier.
 A fair queuing policy is used where the queues are limited by a bounded
policy. Queue only the flows that send faster then N/T.
 The low rate flows are limited by FIFO service with drops depending on
timing of arrivals.
9. Short, Slow and Asymmetric Flows
 TVA experiences reduced efficiency only when the flows near the host are
short; this can be countered by increasing the bandwidth
 Effects on aggregate efficiency are small given that most bytes belong to long
flows.
 No overheads in exchanging handshakes.
 All TCP connections between a pair of hosts are using a single capability. So,
short flows are less likely.
The TVA protocol – Design Elements
 Three Elements in protocol:



Packets with capability information.
Hosts as senders & destinations.
Routers processing capability.
The TVA protocol
Packets with capability information:


IP packet header extended with capability header.
Request packets:



Regular packets:


Packets that carry flow nonce and list of valid capabilities.
Packets that carry only the nonce.
Renewal packets:


Carry blank list of capabilities.
Contain path identifiers filled by routers.
Share an identifying pre-capability header.
A regular packet, used to establish new capabilities.
Demoted packets:

A packet that does not pass the capability test, treated as legacy packet
The TVA protocol
Packets with capability information:

Type field bits used to identify the type and format



Type and capability.
Return information.
Demoted packet.
The TVA protocol
Packets with capability information:
The TVA protocol
Hosts as senders & destinations:
 Sender sends request as part of TCP SYN.
 If destination chooses to authorize, it sends response with
TCP SYN/ACK.
 To refuse transfer, destination sends empty capability list
with TCP RST.
The TVA protocol
Routers processing capability:
 Processing of packets by capability information.
 Sharing capacity of outgoing link between three classes of
traffic:



Request packets.
Regular packets.
Legacy traffic.
The TVA protocol
Routers processing capability:
 Request packets – processed after router adds path identifier
and pre-capabilities.
 Regular packets – forwarded after checking authorization
information, updating cached information (Nonce and
capability).
 The packet is demoted to be a legacy packet if neither its
capability nor it’s nonce is valid.
Simulation Results
 Use of ns (network simulator) to simulate TVA, SIFF, pushback and
legacy internet.
 TVA is changed to rate limit the capability requests to 1% of link
capacity.
 Fixed length transfers between destination and legitimate users and
destination under various attacks.


Measure average fraction of completed transfers.
Measure average time of transfers that complete.
 Change in attack intensity – Vary number of attackers.
 Timeouts of TCP SYN’s is fixed at 1 sec with up to 8 transmissions
being performed.
 TCP aborts connection if retransmission timeout > 64 sec for regular
packet or packet transmitted > 10 times.
Simulation Results
 Based on Dumb bell topology.
Simulation Results - Legacy packet floods
 TVA: Legacy packets have lower priority than request traffic. So,
average completion time remains small with attack intensity.
 SIFF: Equal priority to legacy and request packets. When intensity of
traffic exceeds the bottleneck bandwidth, it suffers losses.
 Pushback: Performs well until large number of attackers distribute traffic
on all links and attacks are harder to identify.
 Legacy internet: Here the legitimate and attack traffic are treated alike
and the probability of completed transfers approaches 0 as the number of
attackers increase.
Simulation Results - Legacy packet floods
Simulation Results - Request packet floods
 TVA: Request packets are rate limited and don’t reduce capacity for
authorized packets. Packets separately queued.
 SIFF: Both request and authorized packets are low priority. Results same
as for legacy packets.
 Pushback: Results same as for legacy packets.
 Legacy internet: Results same as for legacy packets.
Simulation Results - Request packet floods
Simulation Results - Authorized packet floods
 TVA: Destinations use fine grained capability to allocate bandwidth to
senders. So, bandwidth between colluder and destination is rate limited.
 SIFF: Request packets are dropped against authorized packets. So,
request completion rate drops sharply when attack reaches bottleneck
bandwidth.
 Pushback: Treat request and authorized traffic as regular traffic. Results
same as for legacy packets.
 Legacy internet: Treat request and authorized traffic as regular traffic.
Results same as for legacy packets.
Simulation Results - Authorized packet
floods
Simulation Results – Imprecise authorization
 TVA: Implements capabilities that expire after timeout and can be
revoked by destination after finding misbehaving destinations.
 SIFF: The expiration of a capability depends on changing the router
secret, leaving the destination powerless in case of a misbehaving
sender.
Simulation Results – Imprecise
authorization
Implementation
 TVA prototype using Linux netfilter on commodity hardware.
 Legacy applications run without modification.
 Router capability as kernel module, using:


AES = first hash function.
SHA-1 = second hash function.
 Kernel packet generator to generate different types of packets.
 Recording of the average number of instruction cycles for the router to
process each type of packet.
 Testing of Linux router forwarding speed for capability packets.
 Implementation handles 100Mbps interface with off-the-shelf hardware.
Implementation
Processing overhead for different packet
types
Security Analysis
 Security based on inability of attacker to gain capabilities for routers
along path to destination.
 Hashing scheme uses a sufficiently small key that changes every 128 sec.
Breaking the key is practically impossible.
 Attacker may observe pre-capabilities in requests by routers.
 Stolen capabilities belonging to sender cannot be reused as this is
included in the hashed value.
 Masquerade as a receiver.
 Attacker and colluder spoof the authorized traffic as sent by different
sender S. This is thwarted by the fact that the per-destination queuing is
used. Per-source queuing is not used as the sources cannot be trusted.
Deployment
 Needs routers and hosts to be upgraded.
 Incremental deployment.
 Routers up gradation:





At trust boundaries.
At locations of congestion.
Placement of inline processing box next to legacy router.
No inter-router arrangements and alteration of routing.
Deployment working back from destination for better attack localization.
 Host up gradation:


Occurring with proxies at edges of customer networks in form of NAT
boxes.
Not needed to upgrade individual hosts separately.
Conclusion
 TVA limits DoS despite a large number of attackers.
 Architecture is based on capabilities that enable destinations to authorize
senders, in combination with routers to send authorized traffic.
 Complete design to handle packet capabilities, initial request exchanges,
destination policies, computation state requirements and router states.
 With the TVA architecture; Legacy, Request and other authorized
packets have little or limited impact on the performance of the legitimate
users.
 Practical design that runs at Gigabit speeds on commodity PC’s.
 Design with easy transition and deployment on legacy network.
Thank you !!!!