Reference Architecture: Hybrid On-Premise with rCloud

Introduction

Comprehensive defense against Distributed Denial of Service attacks requires both sophisticated mitigation and the ability to sink large volumes of traffic. A hybrid architecture can achieve both of these goals in a cost-effective manner while maintaining low latency and high visibility. This document describes a reference architecture for deploying Riorey products in a Hybrid On-Premise with Scrubbing Center configuration.

The highest quality of Distributed Denial of Service mitigation comes from locally controlled in-line appliances. Appliances can make decisions packet-by-packet to allow good traffic and drop attack traffic. However, they are limited by the bandwidth of the local site to receive attack traffic. Very large attacks can cause downtime even if the filtering is perfect.

rCloud offers the same high quality of mitigation and visibility available with RIOS while adding capacity for terabit-scale attacks. A hybrid architecture maximizes the benefits of inline on-premise mitigation while relying on the scrubbing center for exceptional attacks. On-premise resources will always provide the most cost-effective mitigation, as well as allowing the greatest level of control and lowest latency. Inline remains the best tool for mitigating sophisticated low-rate attacks and the bulk of medium scale attacks. Furthermore, deploying inline provides instant protection for routers and other network security hardware. rCloud is the best tool for mitigating high-rate attacks that would overwhelm local infrastructure or require otherwise unnecessary scaling to mitigate.

Combining rCloud and local mitigation gives the best of both worlds for both larger and smaller networks. A smaller network can be fully covered with inline scrubbing, and can utilize rCloud to handle exceptional attacks instead of over-investing in scaling up resources. For larger networks, rCloud provides instant flexibility to manage attacks, while on-premise mitigation can be deployed where it has the highest impact.

Basic Design

In this architecture, an rCloud Enabled VM or hardware RIOS is deployed inline along upstream links. The primary defense against DDoS attacks is still RIOS. Riorey Director monitors the volume of traffic passing through RIOS and takes action if the upstream link starts becoming congested. As traffic reaches unacceptable levels, Director identifies the specific destinations under attack. Director then issues global BGP announcements to redirect the highest volume destinations through rCloud. The rCloud scrubbing centers filter out the attack and return the clean traffic through a dedicated connection.

Components

rWeb

An rWeb appliance is deployed as the main interface for on-premise configuration, reporting, and coordination. rWeb manages both the RIOS and Director components. Network prefixes are defined centrally in rWeb, and then used for traffic configuration, reporting, and limiting of Director actions.

RIOS

RIOS can be deployed inline either as a VM or as a Hardware appliance. With the scrubbing center for backup mitigation, RIOS and upstream link capacity can be scaled to appropriate production levels instead of being oversized to sink attack traffic.

RIOS should be configured to provide IPFIX/PSAMP flow data to Director. This gives Director visibility into the health of the upstream link.

Director

Director consumes IPFIX/PSAMP data from RIOS and issues BGP announcements to steer traffic through the scrubbing center when appropriate.

An Interface Workflow is used to monitor traffic and take action based on traffic entering the RIOS WAN interface. This workflow should be configured to trigger at the point where incoming traffic reaches an abnormal level, and where RIOS and the network approach their limit to mitigate locally.

Once traffic redirection becomes necessary, Director automatically detects the minimal set of destinations that are under attack. If the attacker pivots to new destinations, those are automatically redirected as well.

Traffic redirection should be persisted for a reasonable time, usually 8-48 hours. Director should maintain the announcements for the full length of the attack, but will lose visibility once the attack has been successfully redirected. A long redirection also prevents announcements from flapping back and forth if the attacker starts and stops or rotates through destination addresses.

rCloud

The Riorey rCloud Scrubbing Center provides large volumes of intelligent mitigation, plus emergency rate limiting and black-holing. Administrators have access to a Scrubbing Center rWeb with capabilities similar to the on-premise rWeb.

Clean traffic is returned along a dedicated connection from the closest scrubbing center node. BGP announcements to begin redirection are also issued through the tunnel.

This architecture is compatible with other forms of cloud mitigation as well.

Example Configuration

Director

In this example, all upstream links from the network are provisioned at 40 Gbps, and protected with RIOS. Attacks up to ~35 Gbps will be mitigated on-site, but if the link utilization goes above 35 Gbps, then traffic will start being moved to the scrubbing center.

Destination traffic will be measured and redirected at the /24 (or /48 for IPv6) prefix size. It is necessary for these announcements to take priority over the standard outgoing announcements. The simplest way to do this is to make sure that the prefix size is smaller for scrubbing center announcements. Other techniques can be used to prioritize announcements including AS-Path prepending or communities provided by a BGP peer.

# Monitor all RIOS interfaces with a the same basic rule
[interface-sets.RIOS]
interfaces = [{agent = "any", interface-id = "any"}]
interface-workflows = ["40GB-Link-Scrubbing"]

# Sample workflow to protect a link provisioned at 40 Gbps
[interface-workflows.40GB-Link-Scrubbing]
actions = [
	"Scrubbing-Center-Redirect-v4",
  "Scrubbing-Center-Redirect-v6",
]
min-action-time = "12 hours"

# High bit rate should cause redirection
[[interface-workflows.40GB-Link-Scrubbing.top-dest-trigger]]
type = "bits-per-second"
limit = "35 G"
ipv4-prefix-length = 24
ipv6-prefix-length = 48

# When the workflow triggers, issue BGP announcements through the return tunnel. 
[actions.Scrubbing-Center-Redirect-v4]
type = "bgp-v4"
destination = "detected"
next-hop = "192.0.2.100"

[actions.Scrubbing-Center-Redirect-v6]
type = "bgp-v6"
destination = "detected"
next-hop = "2001:db8::100"