4. In computing, a denial-of-service attack (DoS attack) is a cyber-attack where the perpetrator seeks to
make a machine or network resource unavailable to its intended users by temporarily or indefinitely
disrupting services of a host connected to the Internet. Denial of service is typically accomplished by
flooding the targeted machine or resource with superfluous requests in an attempt to overload systems and
prevent some or all legitimate requests from being fulfilled
Let’s start
with DDoS 43%
7. BUT it is a everyday headache
• It burns money and kills
business
• It consumes valuable
bandwidth
• When DDos kills your
uplink, it is a nightmare
for IDC cause
everybody dies
• Blocking/unblocking IP
also takes money and
time
8. It takes a lot to detect and
m i t i g a t e
• Attacking cost is low (even lower
with cloud)
• Nowhere to be traced (IP
spoofing)
• Random victims
• We need to find the
attack/attackers without hurting
good ones and it is expensive
13. • No mirroring/bypassing traffic is
needed so no delay expected
• Simple P4 lines(less than 100 lines
for SYN-flood)
• Detect and drop/mitigate, quick
response
• With INT/big data, a lot things can
happen in the same time
• Great performance (6.4Tbps line
rate)
What’s changed?
14. E x a m p l e : S y n - C o o k i e
Detect normal vs.
suspicious traffic inside
network in 6.4Tbps
instead of statically
mirroring lots of traffic
to DDoS mitigation boxes
15. Non-attack scenario
Initiator Tofino switch Listener
SYN
SYN+ACK with cookie
ACK with cookie + 1
RST
SYN
SYN+ACK
ACK
Add to
whitelist
Not on
whitelist
16. Attack scenario
Initiator Tofino switch Listener
SYN
SYN+ACK with cookie
Not on
whitelist
SYN
SYN+ACK with cookie
Not on
whitelist
SYN
SYN+ACK with cookie
Not on
whitelist
.
.
.
.
Shielded
from the
attack
17. Control flow
Receive SYN
SIP in
whitelist
?
Compute SYN
cookie
Send SYN+ACK with
cookie in seq#
and timestamp
fields
Forward
packet
Yes
No
Receive ACK
ACK#-1 ==
cookie?
Add SIP to
whitelist
Send RST
Forward
packet
No
Yes
Compute SYN
cookie
ACK#-1 ==
timestamp?
No
22. DDoS Detection
• Challenges:
1. Large traffic → must be in data-plane
2. Many connections from many sources with low traffic → heavy hitter
detection
• Solution steps:
1. Count number of sources per service/destination in data plane
• Limited memory in data plane → Use an approximation data structure with
guaranteed accuracy (Hyper loglog sketch)
2. Estimate the number of flows and compare against a threshold
• Periodically in control-plane
• Or per packet in data-plane
3. Possible reactions
• Mark packets
• Forward to DDoS mitigation
• Zoom in destination IP range to find which server is under attack
• Zoom in source IP range to find the attacker
22
23. Hyper LogLog Sketch
• Motivation: Estimate the number of source IPs in many packets
• Intuition: To see a rare pattern in random numbers, we need to
see many values
1. If I say I got 100 straight heads in coin tossing, I was either
lucky or tossed the coin many times
• Algorithm:
1. Hash source IPs to a uniformly random number
2. Count the number of consecutive 0s in the beginning of hash
3. Keep track of the maximum number of zeros we saw till now
• More zeros indicate we saw more source IPs
• 10 zeros → 2^11 IPs in average
4. Do this for 1000s of times per packet and track separate numbers to
get an accurate estimate (avoid lucky cases)
• Updating only 1 of 1000s randomly has the same accuracy
5. Read 1000s of counters and use average
23
24. Hyper LogLog Sketch
• Motivation: Estimate the number of source IPs
in many packets
• Intuition: To see a rare pattern in random
numbers, we need to see many values
1. If I say I got 100 straight heads in coin
tossing, I was either lucky or tossed the coin
many times
• Algorithm:
1. Hash source IPs to a uniformly random number
2. Count consecutive 0s in the beginning of hash
3. Keep track of total number of zeros till now
• More zeros indicate we saw more source IPs
• 10 zeros → 2^11 IPs in average
4. Do this for 1000s of times per packet and track
separate numbers to get an accurate estimate
(avoid lucky cases)
• Updating only 1 of 1000s randomly has the
same accuracy
5. Read 1000s of counters and use average 24
25. Implementation: Count in data-plane, compare in control-plane
Hash
Count #
zeros
Track
max
zeros
Periodically
1. fetch counters from data-plane
2. estimate and compare against
threshold
3. reset counters
Control-plane
Data-plane
Watchlist
25
table count_zeros {
reads {
hll_md.hash : ternary;
}
actions {
count_zeros_do;
}
size : 64;
}
action count_zeros_do(zeros) {
modify_field(hll_md.zeros, zeros);
}
26. Results
# counters (SRAM bytes for Track max zeros table)
● Detection Latency:
○ Control-plane: ~5ms to fetch counters and estimate
○ Data-plane: 0 (it is per packet)
● Estimation error:
26
If threshold is 1B, we
may report a destination
with >0.985B or ignore
one with <1.15B source
IPs
27. Summary
27
Benefits of In-Network DDoS detection
•A Tofino implementation guarantees high scalability and line-rate
performance under any type of attack with minimal consumption of on-
chip memory and resources.
•In-network DDoS detection can be implemented in Tofino with high
accuracy and negligible probability for false positives.
•P4 programmability allows customers flexibility and customization
of the DDoS detection methods and mitigation actions.
•Granular statistics allow customers to quickly identify which
applications and services are under attack.
•When compared with a DDoS solution using NetFlow, a Tofino-based
approach is multiple orders of magnitude faster in detecting a DDoS
attack (tens of milliseconds vs. tens of seconds).
28. Summary
28
In-Network DDoS detection with programmable chipset like Tofino:
• High scalability & line-rate with minimal memory consumption
• High accuracy vs. negligible probability for false positives
• P4 programmability: flexible customization of detection methods and
mitigation actions
• Granular statistics: quick identify apps & services under attack
• Multiple orders of magnitude faster than NetFlow based solutions
(tens of milliseconds vs. tens of seconds)
