flowspec ddos mitigation

FlowSpec and DDoS Mitigation with ExaBGP

Overview

ExaBGP pioneered open-source FlowSpec support (first implementation, now also in GoBGP, FRRouting, BIRD) and remains the most API-friendly for automated DDoS mitigation.

Key Concepts

What is FlowSpec?

BGP FlowSpec (RFC 5575) allows network operators to distribute traffic flow specifications throughout their network via BGP. It enables precise traffic filtering based on multiple criteria without requiring individual /32 host route announcements.

ExaBGP's Role

• FlowSpec Controller: ExaBGP acts as the FlowSpec server/controller
• Rule Injection: Dynamically injects FlowSpec rules to edge routers (FlowSpec clients)
• Automation: Integrates with detection systems for automated response

Use Cases

1. Automated DDoS Response

Integration with detection systems like Arbor SP/TMS:

• Listens for syslog messages from DDoS detection appliances
• Automatically generates FlowSpec rules for high-severity attacks
• Makes API calls to ExaBGP for rule injection
• Withdraws rules when attack is complete

2. Machine Learning Integration

• ElastiFlow + Elasticsearch ML for threat detection
• Automatic FlowSpec rule generation based on ML analysis
• Dynamic traffic shaping rather than outright blocking
• Precise mitigation around specific ports and IP addresses

3. Upstream Provider Mitigation

• FlowSpec uses BGP to carry DDoS mitigation policies
• Enforcement happens at upstream provider's edge network
• Offloads DDoS traffic before it reaches your infrastructure
• Rate limiting via extended communities

Configuration Patterns

Basic FlowSpec Structure

ExaBGP configured as FlowSpec controller:

• Establishes BGP peering with edge routers (FlowSpec clients)
• Routers install FlowSpec rules via their FlowSpec manager
• Policy manager applies rules based on matching traffic

Dynamic Rule Injection

ExaBGP leverages multithreading:

• One process for BGP peering establishment
• Separate forked process for dynamic rule injection
• No peering disruption when injecting new rules

Rate Limiting Example

Use "rate-limit" extended community to create packet policer directly in forwarding plane:

flow route {
    match {
        source 192.0.2.0/24;
        destination-port =80;
    }
    then {
        rate-limit 9600;  # bits per second
    }
}

Real-World Implementations

Cisco IOS-XR Integration

• ExaBGP as FlowSpec server
• Cisco IOS-XR routers as FlowSpec clients
• Rules propagated via BGP
• Installed in hardware forwarding plane

Vendor Appliance Integration

• Arbor SP/TMS with built-in FlowSpec support
• Automated trigger based on attack detection
• Previously required hundreds/thousands of /32 routes
• Now single FlowSpec rule handles complex patterns

Third-Party Controllers

Many companies use ExaBGP or GoBGP-based solutions for FlowSpec validation before passing rules into production networks.

Advantages Over Traditional Methods

vs. Remote Triggered Black Hole (RTBH)

• Precision: Match on multiple fields (ports, protocols, packet lengths)
• Granularity: Shape traffic instead of complete blackhole
• Efficiency: Single FlowSpec rule vs. many /32 routes
• Flexibility: Rate limiting, redirects, and other actions

vs. On-Premises Scrubbing

• Upstream Filtering: Traffic blocked at provider edge
• Bandwidth Savings: Attack traffic never reaches your network
• Scalability: Leverage provider's high-capacity infrastructure
• Speed: BGP convergence for rapid deployment

Match Conditions (RFC 5575)

FlowSpec rules can match on:

• Source/destination prefix
• IP protocol
• Source/destination ports
• ICMP type/code
• TCP flags
• Packet length
• DSCP (DiffServ)
• Fragment encoding

Actions (Extended Communities)

Available actions include:

• Traffic-rate: Rate limit to specific bps
• Traffic-action: Sample or terminal action
• Redirect: Redirect to VRF
• Traffic-marking: Set DSCP value
• Discard: Drop matching packets

Best Practices

1. Validation Layer: Implement validation before accepting FlowSpec rules
2. Logging: Track all rule injections and withdrawals
3. Automation: Integrate with monitoring/detection systems
4. Testing: Verify rules in lab before production deployment
5. TTL Management: Automatically withdraw rules after attack ends
6. Specificity: Make rules as specific as possible to avoid collateral impact

Integration Patterns

With SIEM/Monitoring

Detection System → Syslog/API → ExaBGP Controller → BGP → Edge Routers

With Machine Learning

NetFlow → ElastiFlow → Elasticsearch ML → ExaBGP API → FlowSpec Rules

With Scrubbing Centers

FlowSpec Detection → Redirect to Scrubbing → Clean Traffic Return

Example Scenarios

HTTP Flood Protection

Match: destination-port=80, source 10.0.0.0/8
Action: rate-limit 1000000 (1 Mbps per source)

DNS Amplification

Match: source-port=53, packet-length >512
Action: discard

SYN Flood

Match: destination-port=443, tcp-flags syn
Action: rate-limit 100000

Performance Considerations

• FlowSpec rules installed in hardware forwarding plane
• Near-zero performance impact on router
• Scales to thousands of simultaneous rules
• BGP convergence typically <5 seconds

References

• RFC 5575: Dissemination of Flow Specification Rules
• RFC 7674: Clarification of Default BGP NEXT_HOP Attribute
• RIPE presentations on FlowSpec deployment
• Vendor-specific FlowSpec implementation guides