PaperlayerView exact revision on arXiv

Source-linked AI summary

NetFence: Preventing Internet Denial of Service from Inside Out

Xin Liu, Xiaowei Yang, Yong Xia

arXiv:1009.0033v1cs.NI

TL;DR

DoS defenses that use per-host queuing at flooded links face a scalability challenge when malicious sender-receiver pairs collude. NetFence uses secure congestion feedback to police senders inside the network. It guarantees legitimate senders a fair share under colluding attacks while keeping bottleneck state to at most per-AS.

  • Problem

    When malicious sender-receiver pairs collude to flood a link, existing defenses’ per-host queuing at the flooded router faces a scalability challenge.

    Source: §1 · p. 1

  • Method

    NetFence uses secure congestion policing feedback stamped at bottlenecks so access routers can police senders, with victims also able to use the feedback as capability tokens.

    Source: §1 · p. 1

  • Results

    NetFence guarantees legitimate senders a fair share under colluding attacks while bottleneck routers keep at most per-AS state instead of per-host state.

    Source: §1 · p. 1, §9 · p. 12

  • Takeaways & Limitations

    DoS victims can use the feedback as capability tokens to suppress unwanted traffic.

    Source: §1 · p. 1

    The current design trades performance for simplicity in handling multiple bottlenecks; more complicated designs could improve performance.

    Source: §6.3.2 · p. 11

Abstract

from arXiv · show

Denial of Service (DoS) attacks frequently happen on the Internet, paralyzing Internet services and causing millions of dollars of financial loss. This work presents NetFence, a scalable DoS-resistant network architecture. NetFence uses a novel mechanism, secure congestion policing feedback, to enable robust congestion policing inside the network. Bottleneck routers update the feedback in packet headers to signal congestion, and access routers use it to police senders' traffic. Targeted DoS victims can use the secure congestion policing feedback as capability tokens to suppress unwanted traffic. When compromised senders and receivers organize into pairs to congest a network link, NetFence provably guarantees a legitimate sender its fair share of network resources without keeping per-host state at the congested link. We use a Linux implementation, ns-2 simulations, and theoretical analysis to show that NetFence is an effective and scalable DoS solution: it reduces the amount of state maintained by a congested router from per-host to at most per-(Autonomous System).

1. INTRODUCTION

NetFence moves DoS defense into the network, using secure congestion feedback for access routers to police senders and help victims suppress unwanted traffic. Its analysis and evaluations report fair-share protection under colluding attacks, competitive performance, and lower state requirements at bottlenecks than per-host queuing.

1. INTRODUCTION

  • Secure congestion feedback lets access routers police senders even when malicious senders collude with compromised receivers, while victims can use the feedback as capability tokens to suppress unwanted traffic.The architecture also uses AS-level queues or rate-limiters to localize damage if access routers are compromised.Source: §1 · p. 1
  • NetFence’s simulations show performance similar to capability- or filter-plus-fair-queuing defenses, while Linux prototype benchmarks show low per-packet processing overhead.Theoretical analysis reports fair-share guarantees regardless of attackers’ strategies, and simulation results correlate well with that analysis.Source: §1 · p. 1
  • NetFence guarantees legitimate senders a fair share under colluding attacks, while bottleneck routers maintain at most per-AS state rather than per-host state.Bottleneck routers also have O(1) per-packet computational overhead; the paper says access routers can meet the required per-(sender, bottleneck link) state needs.Source: §1 · p. 1
  • NetFence’s closed-loop design places lightweight attack detection and congestion signaling at bottlenecks, while per-(sender, bottleneck link) policing state resides at access routers.This contrasts with prior open-loop approaches that use per-host queuing at bottlenecks.Source: §1 · p. 1

2. ASSUMPTIONS AND GOALS

NetFence targets network-layer flooding under a threat model that includes large-scale, strategic attackers and possible router compromise. Its goals combine fair resource sharing and victim controls with scalability, open-network operation, incremental deployment, and defense relying only on network routers.

2.1 Threat Model and Assumptions

  • NetFence targets flooding that exhausts network resources, assuming attackers may compromise end systems and routers, disguise traffic, use on-off strategies, or collude in sender-receiver pairs.It assumes network-managed routers are less likely to be compromised than end systems and treats each AS as a trust and fate-sharing unit.Source: §2.1 · p. 2

2.2 Goals

  • When victims cannot identify attack traffic or attackers collude, NetFence aims to guarantee each sufficiently demanding sender at least O(C/N) bandwidth on a link of capacity C.The goal is to make large-scale DoS cause predictable delay rather than denial of service.Source: §2.2 · p. 2
  • NetFence aims to keep the network open to new applications and avoid per-flow or per-host state and heavyweight fair queuing in the core.It also seeks low communication, computation, and memory overhead.Source: §2.2 · p. 2
  • NetFence aims to support incremental deployment through mutually beneficial overlays and to rely on network routers rather than external trusted infrastructure.Its design goals also include robustness against brute-force flooding and attempts to bypass or abuse the defense itself.Source: §2.2 · p. 2

3. ARCHITECTURE

NetFence routes congestion feedback through packets from bottleneck routers to access routers, which police senders using per-sender, per-bottleneck rate limiters. Unforgeable feedback also serves as a victim-controlled capability, and the paper proves a fair-share guarantee for single-bottleneck scenarios.

3.1 System Components

  • Each router keeps separate channels for request, regular, and legacy packets; legacy traffic receives lower forwarding priority, and request traffic is limited to 5% of link capacity.A priority-based backoff mechanism helps protect legitimate requests from request flooding.Source: §3.1 · p. 2, Figure 2 · p. 3
  • A bottleneck router can stamp monitoring feedback into request and regular packets during an attack, and the sender’s access router then polices regular packets using a per-sender, per-bottleneck rate limiter.The access router adjusts rate limits with AIMD across control intervals; when no attack is detected, NetFence remains idle and overhead is low.Source: §3.1 · p. 3

3.2 Unforgeable Congestion Policing Feedback

  • NetFence makes congestion policing feedback unforgeable by having an access router insert a changing secret that a bottleneck router uses to protect feedback and then erase.The access router knows the secret and can validate feedback returned in packets.Source: §3.2 · p. 3

3.3 Congestion Feedback as Capability

  • A victim can withhold valid feedback from a malicious sender, preventing valid regular packets; access-router policing limits the sender’s remaining request traffic.The feedback therefore also serves as a capability token when a victim can identify and wants to bar attack traffic.Source: §3.3 · p. 3

3.4 Fair Share Guarantee

  • For a single bottleneck, any sufficiently demanding legitimate sender eventually obtains a fair share scaled by ν_g and ρ, regardless of attack strategies.The proof sketch attributes convergence to robust AIMD adjustment of per-sender rate limits using unspoofable bottleneck feedback.Source: §3.4 · p. 3

4. DESIGN DETAILS

NetFence places congestion feedback and traffic policing in a closed loop: bottleneck routers signal congestion, while access routers regulate senders. Its design combines protected request access, robust rate adjustment, authenticated feedback, and measures to contain compromised routers.

4.2 Protecting the Request Channel

  • Request packets use a 5% capacity limit and priority-based rate limiting, which guarantees legitimate senders can eventually obtain requests regardless of attacker count.Access routers enforce the priority rates with per-sender token-based limiters; request forwarding also stamps nop feedback.Source: §4.2 · p. 4

4.3.1 A Monitoring Cycle

  • Routers infer attacks from high utilization or regular-packet loss above a local threshold; loss-based detection may also flag flash crowds.Monitoring ends after a sufficiently long period without attack indications, and longer monitoring periods relative to detection time reduce disruption from repeat attacks.Source: §4.3.1 · p. 4

4.3.2 Updating Congestion Policing Feedback

  • During monitoring, a bottleneck stamps L↓ on packets without overwriting upstream L↓ feedback, allowing access routers to gradually limit senders at overloaded on-path links.A router continues stamping L↓ until t1 + 2Ilim after detecting congestion between t and t1.Source: §4.3.2 · p. 4, Figure 4 · p. 5

4.3.3 Regular Packet Policing at Access Routers

  • Access routers apply per-(sender, link) rate limiters to feedback-marked regular packets; queue-based limiters absorb bursts that token buckets could permit.The access router resets feedback as packets leave, and the design uses at most one limiter per packet, so limiters can become idle when bottlenecks change.Source: §4.3.3 · p. 5

4.3.4 Robust Rate Limit Adjustment

  • Periodic AIMD adjustment uses fresh L↑ feedback to increase rates and otherwise decreases them; two control intervals of L↓ stamping prevent senders from hiding congestion feedback to avoid a reduction.Before increasing a limiter, the access router checks that its throughput exceeds half its current rate limit.Source: §4.3.4 · p. 5

4.3.5 Handling Multiple Bottlenecks

  • With multiple monitored bottlenecks, the core design may temporarily give a sender less than its fair share when bottlenecks change; proposed fixes are omitted for simplicity, while simulations suggest acceptable performance.The proposed alternatives let packets carry all bottleneck feedback or have access routers infer bottlenecks and apply multiple limiters.Source: §4.3.5 · pp. 5–6

4.4 Securing Congestion Policing Feedback

  • MAC-protected feedback uses mode, link, action, timestamp, and MAC fields; routers use shared AS keys and include the sender access router’s tokennop when stamping L↓.The MAC computation for nop feedback covers source and destination addresses to prevent reuse on another connection.Source: §4.4 · p. 6

4.5 Localizing Damage of Compromised Routers

  • For compromised routers, NetFence localizes damage to the compromised AS; implementation settings include a 2-second control interval and a 2% loss threshold.The design considers per-AS queues or rate limits and heavy-hitter detection; the stated parameter settings also include ∆ = 12 Kbps and δ = 0.1.Source: §4.5 · p. 6, §4.6 · p. 7

5. ANALYSIS

NetFence reduces state at bottleneck routers by shifting per-sender policing to access routers, and the analysis describes how it handles end-system and on-path attacks. Deployment can preserve legacy application and router operation, although enforcement requires router upgrades.

5.1 Scalability

  • NetFence replaces per-host bottleneck queues with lightweight congestion handling and AS-level policing, reducing state where DoS attacks may involve millions of hosts.The analysis contrasts the number of compromised hosts, potentially millions, with about 35K ASes.Source: §5.1 · p. 7
  • For an access router serving 10K hosts, the analysis estimates under 2 GB for up to one million rate limiters, while packet processing takes less than 1.3 µs during attacks.The processing benchmark corresponds to 770K packets per second, or more than 9 Gbps assuming 1500-byte packets and CPU-bound throughput.Source: §5.1 · p. 7

5.2.1 Malicious End Systems

  • MAC validation and robust rate adjustment prevent malicious end systems from forging feedback or gaining a higher rate by selectively presenting L↑ or hiding L↓.For loss-based attack detection, a low threshold limits evasion; monitoring cycles may also be triggered by flash crowds, which the design does not distinguish from attacks.Source: §5.2.1 · p. 7
  • Theoretical bounds and simulations show that attack traffic shape cannot reduce a legitimate sender’s guaranteed bandwidth share under NetFence’s rate limiting and robust adjustment.The analysis covers microscopic on-off attacks and the prolonged monitoring cycle addresses attackers who resume flooding after monitoring ends.Source: §5.2.1 · p. 7

5.2.2 Malicious On-path Routers

  • A downstream malicious router cannot validly remove or modify a congested router’s L↓ feedback without the tokennop value needed to recompute its MAC.NetFence does not aim to prevent other on-path attacks such as packet dropping or duplication; it aims to make them detectable, and preventing them requires Byzantine-tolerant routing.Source: §5.2.2 · p. 7

5.3 Incremental Deployment

  • Legacy applications need not change and legacy routers can forward NetFence packets, but congested-link and access routers require upgrades or inline enforcement boxes.Deployed ASes can protect each other’s legitimate traffic in a trusted overlay, while their traffic remains unprotected at undeployed networks.Source: §5.3 · pp. 7–8

6. IMPLEMENTATION AND EVALUATION

NetFence is implemented in Linux and ns-2, with header and packet-processing overhead benchmarked before simulations assess flooding defenses.

6.1 NetFence Header

  • The Linux shim carries forward congestion feedback and reverse-path information; its header is 20 bytes with nop feedback on both paths and 28 bytes with mon feedback.The return header can be omitted when the sender has already returned the latest feedback.Source: §6.1 · p. 8

6.2 Micro-benchmarking

  • During attacks, bottleneck processing takes 492ns per 92B request packet or at most 554ns per 1500B regular packet; access-router regular-packet processing averages 1267ns.The paper reports NetFence’s processing overhead as on par with TVA+’s on the same topology.Source: Figure 7 · p. 8, §6.2 · p. 8

6.3.1 Unwanted Traffic Flooding Attacks

  • StopIt has the best transfer-time performance, while TVA+ and NetFence remain short and rise slightly with sender count; FQ transfer time grows linearly.All simulated file transfers complete; NetFence’s average transfer time is about one second longer than TVA+’s because legitimate senders initially retry at a higher priority.Source: Figure 8 · p. 9, §6.3.1 · p. 9

6.3.2 Colluding Attacks

  • For long-running TCP, NetFence’s throughput ratio is close to 1; for web-like traffic it rises from 0.3 toward 1 as senders increase.With few senders, web-like traffic may not use a legitimate sender’s fair share because demand is insufficient and transfers have gaps.Source: §6.3.2 · p. 10
  • When CL1 < CL2, Group-A throughput can fall below its 80Kbps fair share; TCP can fare worse than attackers, and more complex designs could improve performance.The simulations find that the first two capacity cases, where CL1 ≥ CL2, are not significantly affected by this rate-limiter switching problem.Source: §6.3.2 · p. 11
  • With synchronized microscopic on-off attacks, legitimate throughput remains at least 100Kbps and approaches 400Kbps as off-periods near 100 seconds.The simulations use 100K senders, with on-periods of 0.5 or 4 seconds.Source: Figure 11 · p. 11, §6.3.2 · p. 11

7. DISCUSSION

NetFence’s fairness guarantee can become small under disproportionate attack, and its operation depends on practical choices about congestion detection, control intervals, and path stability. The discussion also describes quota-based throttling and limits on convergence speed.

7. DISCUSSION

  • When attackers disproportionately outnumber link capacity, NetFence’s fair-share lower bound can be small, so it mitigates large-scale DoS damage without preventing service degradation.Congestion quota is offered as an additional way to throttle persistent attackers.Source: §7 · p. 11
  • NetFence assumes relatively stable flow paths and bottleneck links; common ECMP implementations generally keep a flow on one path to avoid packet reordering.Source: §7 · p. 11
  • A congestion quota can throttle persistent attackers after they consume their allowed congestion traffic, without incidentally throttling traffic on other links.The quota is per sender and bottleneck link.Source: §7 · pp. 11–12
  • NetFence currently uses RED for congestion detection and closed-loop AIMD for rate limits; load-based detection is a future option, while max-min share signaling was rejected for its overhead.The rejected approach requires per-sender state and has higher computation and message overhead than AIMD.Source: §7 · p. 12
  • A fixed control interval is difficult to optimize: short intervals cannot accommodate heterogeneous RTTs, while long intervals slow rate-limit convergence.The authors propose exploring varied intervals, which would require changes to rate adjustment and congestion hysteresis.Source: §7 · p. 12
  • Convergence to fairness can take 100–200 seconds when a sender’s rate limit is far from its fair share; the limiter persists for hours to reduce opportunities for strategic on-off attacks during convergence.Source: §7 · p. 12
  • TCP window changes can briefly desynchronize from rate-limit adjustments, but this may occur at most once across many RTTs because the adjustment interval is much longer than a typical RTT.Source: §7 · p. 12

8. RELATED WORK

NetFence combines capability-based defenses with congestion feedback, using unspoofable signals to police traffic inside the network. The paper distinguishes this approach from request-packet defenses, filtering and pushback systems, destination-focused mitigation, and per-flow fairness schemes.

8. RELATED WORK

  • NetFence combines capability-system elements with re-ECN/re-feedback, but uses unspoofable congestion feedback to guarantee fair bottleneck bandwidth under attack.Victims can also use the feedback as capability tokens to suppress unwanted traffic.Source: §8 · p. 12
  • Unlike Portcullis, NetFence’s request protection uses rate limiting rather than proof-of-work or network-wide puzzle synchronization, and it guarantees eventual delivery of a legitimate request packet.Its priority mechanism is similar in spirit to LazySusan, but uses sender waiting time to set request priority.Source: §8 · p. 12
  • Unlike systems relying on per-host queues or hop-by-hop pushback, NetFence provides per-sender fairness at bottlenecks and does not require trusted host hardware or hop-by-hop deployment.Pushback installs per-(incoming interface, destination prefix) rate limiters; AIP uses trusted host hardware.Source: §8 · p. 12
  • NetFence addresses network-layer DoS, whereas Speakup and Kill-Bots address application-layer attacks; unlike destination-focused mitigation, it can remove traffic near its origins once deployed.The paper also places attack-traffic identification at receivers to keep the network open to new applications.Source: §8 · p. 12
  • NetFence’s scalability is inspired by CSFQ, but it supports victim suppression and per-sender rather than per-flow fairness.Source: §8 · p. 12

9. CONCLUSION

NetFence puts DoS defense inside the network using secure congestion policing feedback. Its evaluation and analysis support fair-share protection under colluding floods, victim suppression, and reduced bottleneck-router state.

9. CONCLUSION

  • NetFence uses router-stamped secure congestion policing feedback to signal congestion to access routers, which police senders’ traffic.Source: §9 · p. 12
  • When senders and receivers collude to flood a link, NetFence provides each sender its fair share of bottleneck capacity without per-host state at bottleneck routers.Source: §9 · p. 12
  • Victims can use the feedback as capability tokens to suppress unwanted traffic, while evaluation and analysis show bottleneck-router state reduced from per-host to per-AS.The evaluation combines a Linux implementation, simulations, and theoretical analysis.Source: §9 · p. 12

A. CONVERGENCE ANALYSIS

The appendix analyzes AIMD’s convergence to efficiency and fairness. Its preliminary model considers synchronous flows sharing one link and updates their rates through additive increase and multiplicative decrease.

A.1 AIMD Preliminary

  • The analysis uses AIMD rate updates for N synchronous flows with equal RTTs sharing one link.The model’s update rule applies additive increase without congestion and multiplicative decrease otherwise.Source: §A.1 · pp. 13–14
  • Efficiency convergence comes from aggregate rates oscillating around full utilization; the overshoot and undershoot depend on Nα and β, and efficiency is achieved as α approaches 0 and β approaches 1.Source: §A.1 · p. 14
  • The paper measures fairness with Jain’s fairness index; multiplicative decrease leaves the index unchanged, while additive increase raises it until equal sharing reaches the maximum index of 1.Source: §A.1 · p. 14

A.2 Capacity Share Lower Bound

The section analyzes whether NetFence can guarantee good senders a fair share when good and bad hosts share a bottleneck. Under its stated model, the theorem guarantees that each good sender with sufficient demand eventually obtains a fair share, regardless of attack strategy.

A.2 Capacity Share Lower Bound

  • The analysis assumes a simplified fluid model with fixed senders, one receiver, and no delay, so rate changes take effect immediately at the bottleneck.Each sender’s egress rate is limited by the smaller of its sending rate and access-router rate limit.Source: §A.2 · p. 14
  • For hosts with sufficient demand, AIMD drives their rate limits toward equality; hosts without sufficient demand receive no increase or may be reduced.A host with sufficient demand sends fast enough that its rate limit is not punished by the AIMD algorithm.Source: §A.2 · p. 14
  • Each good sender with sufficient demand eventually obtains a fair share of bottleneck capacity, regardless of bad senders’ attack strategy.The bound accounts for good and bad senders sharing a link of capacity C.Source: §A.2 · p. 14
  • A multi-homed host may obtain more bandwidth than a single-homed host because each access router keeps a separate rate limiter for that host and bottleneck pair.The passage notes that multi-homed hosts often have few access routers and pay for multiple access links.Source: §A.2 · p. 14

B. ALTERNATIVE DESIGNS TO HANDLE MULTIPLE BOTTLENECKS

This section introduces two possible solutions intended to improve NetFence’s performance in the multiple-bottleneck case.

B. ALTERNATIVE DESIGNS TO HANDLE MULTIPLE BOTTLENECKS

B.1 Multi-bottleneck Feedback in One Packet

One alternative carries congestion feedback from multiple bottlenecks in a packet and uses that information to police traffic against the corresponding rate limits. In simulation, Group-A senders obtain roughly their fair share of bottleneck bandwidth.

B.1 Multi-bottleneck Feedback in One Packet

  • Each Group-A sender gets roughly its fair share of bottleneck bandwidth when packets carry feedback from multiple bottleneck links.The simulation uses the same setting as Figure 10; the stated fair-share rate for each sender is 80 Kbps.Source: Figure 13 · p. 15, §B.1 · p. 15
  • This alternative requires a new header format and new feedback stamping, verification, and regular-packet policing algorithms, while leaving other core design parts unchanged.Source: §B.1 · p. 15
  • A NetFence header can carry feedback from zero or more bottleneck links, with a link and action field for each bottleneck.A single token field makes all feedback fields unforgeable, and one timestamp indicates their freshness.Source: §B.1 · p. 15
  • An access router applies the rate limiters for all on-path bottlenecks to regular packets and discards a packet that fails any limiter.This keeps a flow’s sending rate below the lowest rate limit on its path and avoids abrupt rate-limit changes.Source: §B.1 · p. 15

B.2 Inferring Rate Limiters

Rate-limiter inference is a core-compatible alternative for handling multiple bottlenecks: access routers infer on-path bottlenecks from feedback and police using their rate limiters. Simulation shows improved throughput over the baseline, but senders may remain far below their fair share.

B.2 Inferring Rate Limiters

  • The inference alternative is compatible with NetFence’s core design and lets access routers police using rate limiters for inferred on-path bottlenecks.It avoids the longer header required by the multiple-feedback-in-one-packet alternative.Source: §B.2 · p. 15
  • Access routers maintain a per-destination-prefix cache of bottleneck links, adding links when feedback arrives and removing them after limiter removal or prolonged absence of feedback.The cache has at most as many entries as a full BGP table has prefixes.Source: §B.2 · p. 15
  • A stale cache entry can unnecessarily throttle traffic toward a prefix, but it is removed after feedback stops appearing for a period.The passage says this occurs infrequently.Source: §B.2 · p. 15
  • A single-bottleneck feedback can imply whether other on-path links are congested, guiding whether their rate limits can increase or should remain unchanged.An L↑ feedback implies other on-path bottlenecks are not congested; an L↓ feedback prevents those links from stamping feedback.Source: §B.2 · p. 16
  • With inference, TCP senders and Group-A attackers have roughly the same throughput, and Group-A throughput improves over Figure 10 but may remain far below fair share.The stated limitation is that a sender’s rate limits can increase only when neither bottleneck is congested.Source: §B.2 · p. 16

C. PSEUDO CODE

  • The appendix also includes pseudocode for NetFence’s key procedures, including rate-limit adjustment.Figure 17 identifies its subject as rate-limit adjustment pseudocode.Source: C. PSEUDO CODE · p. 16, Figure 17 · p. 17
Loading 1009.0033v1…