Protecting transit networks that carry traffic to multiple end-user networks is different from protecting the end-user networks themselves.

• The throughput of a transit network can suffer from DDoS attacks aimed directly at it, as well as from attacks aimed at any of the transit networks.

  That said, transit network owners need to keep resources available on all end-user networks as much as possible, even during an attack on some of them.

• Protection of a transit network must rely only on traffic analysis at the network and transport layers, since the end-user networks may use different higher-layer protocols.

Qrator Labs provides ingress filtering to secure transit networks. It allows responding effectively to attacks, either by keeping the resource fully available for each end-user network or by limiting the availability of only specific networks under attack.

To use ingress filtering, the transit network owner specifies prefixes corresponding to the protected subnets and configures it in the Qrator Labs dashboard. See Connection: Ingress filtering. This process is transparent to end-user networks, no settings need to be made on their side.

Differences from end-user network protectionDifferences from end-user network protection

The key difference between DDoS attack protection for end-user networks and for transit networks is that threats for transit networks are detected only at the network and transport layers (L3, L4 according to the OSI model) and does not require analysis of outbound traffic.

In many cases, this saves resources and avoids analyzing traffic whose source is known and legitimate. In particular, when serving streaming and other multimedia services, where outbound network traffic can be dozens of times greater than inbound traffic, it often makes sense to pass inbound and outbound traffic through different networks and enable ingress filtering only for the network through which inbound traffic passes.

Traffic accountingTraffic accounting

The Qrator Labs network counts and filters incoming traffic for prefix sets configured by the customer. All traffic within one prefix set is divided into three categories, whose traffic is counted independently.

• TCP segments SYN and ACK, which are used to establish new sessions, are counted as TCP Unverified. Incorrect segments and segments within unknown sessions fall into this same category.

• TCP segments sent within already established sessions are counted as TCP Verified.

• Any other segments, including UDP and ICMP traffic, are counted as Other.

When configuring filter policies, you can set arbitrary limits on each of these traffic categories separately, as well as set a limit on the total traffic volume.

The Qrator Labs network also keeps statistics on distribution of traffic by destination network IP address. This is not related to any limits per se, but plays a role in blocking busy IP addresses.

The segment counter of each category and the total traffic counter are reset once every few seconds (the exact size of the interval may vary depending on load). If any of the counters have exceeded or are approaching the corresponding limit before this period expires, the Qrator Labs network blocks busy IP addresses or applies the [SYN cookies] mechanism(#syn-cookies) in order to protect the transit network.

Blocking busy IP addressesBlocking busy IP addresses

This attack-blocking method is applied when the TCP Verified, Other or total traffic limit is reached (see Traffic Accounting).

Using traffic distribution statistics for IP addresses on the end-user network, the Qrator Labs network blacklists those IP addresses that have received the most traffic in the last few seconds. The number of temporarily blacklisted addresses is calculated in such a way that when the traffic to these addresses is no longer delivered, the remaining traffic is again no higher than the limit.

This solution reduces the load on the transit network during an attack by temporarily blocking the minimum possible number of IP addresses on end-user networks.

SYN cookiesSYN cookies

The SYN cookies mechanism is used when a SYN flood attack is launched against the server and the TCP Unverified traffic limit has been reached (see Traffic Accounting).

In a SYN flood attack, the attacker sends multiple TCP segments to the server, specifying a foreign IP address as the source. The server tries to continue the TCP handshake with this address and never gets a reply. This causes half-opened connection data to remain in the queue for a long time, causing it to overflow and making it impossible to establish a session with legitimate users.

The task of ingress filtering at the moment of such an attack is to deliver TCP segments to the transit network only from legitimate users with real IP addresses. TCP segments from unverified IP addresses are responded to by the Qrator Labs network itself, thus trying to continue the handshake. This response TCP segment is chosen so that the next segment from the user within this handshake can be unambiguously determined whether it received a segment from the Qrator Labs network. IP addresses that pass this check are added to the whitelist. The SYN cookie algorithm is described more fully in RFC 6013.

This process does not use the half-open connection queue, so the volume of traffic from the attacker does not affect the ability of a legitimate user to receive a response TCP segment and complete the handshake.

Upon successful completion of the check, the Qrator Labs network immediately resets the session. Most modern applications are resistant to TCP session resets and they attempt again to establish connection automatically. Since the user's IP address is already on the whitelist, all new segments are sent to the transit network without restriction.

Filtering policiesFiltering policies

The customer can define one or more ingress filtering policies in his Qrator Labs dashboard. The customer can set the created policy for any set of prefixes within his network or for his entire network.

It is possible to set multiple policies for the same prefix. In this case, once one of the limits in one of the policies is reached, restrictions can be imposed on the IP addresses from the prefix even if limits in the other policies have not yet been reached.

Each policy is a set of traffic accounting limits. The policy can include separate limits for TCP Verified, TCP Unverified, Other traffic categories, as well as an overall Total counter for all traffic. Some of the limits can be left unset by the customer.

Limits can be set both in bits per second and in packets per second. Bits-per-second limits help protect against bandwidth-exhaustion attacks, while packets-per-second limits help defend against those attacks that occupy network hardware with many small segments, e.g., from a TCP SYN flood attack.