Today's data centers may contain tens of thousands of computers with significant aggregate bandwidth requirements. The network architecture typically consists of a tree of routing and switching elements with progressively more specialized and expensive equipment moving up the network hierarchy. Unfortunately, even when deploying the highest-end IP switches/routers, resulting topologies may only support 50% of the aggregate bandwidth available at the edge of the network, while still incurring tremendous cost. Non-uniform bandwidth among data center nodes complicates application design and limits overall system performance.In this paper, we show how to leverage largely commodity Ethernet switches to support the full aggregate bandwidth of clusters consisting of tens of thousands of elements. Similar to how clusters of commodity computers have largely replaced more specialized SMPs and MPPs, we argue that appropriately architected and interconnected commodity switches may deliver more performance at less cost than available from today's higher-end solutions. Our approach requires no modifications to the end host network interface, operating system, or applications; critically, it is fully backward compatible with Ethernet, IP, and TCP.

/pdf/a-scalable-commodity-data-center-network-architecture-5evikm9tu4.pdf

A scalable, commodity data center network architecture

Distributed Denial of Service (DDoS) flooding attacks are one of the biggest concerns for security professionals. DDoS flooding attacks are typically explicit attempts to disrupt legitimate users' access to services. Attackers usually gain access to a large number of computers by exploiting their vulnerabilities to set up attack armies (i.e., Botnets). Once an attack army has been set up, an attacker can invoke a coordinated, large-scale attack against one or more targets. Developing a comprehensive defense mechanism against identified and anticipated DDoS flooding attacks is a desired goal of the intrusion detection and prevention research community. However, the development of such a mechanism requires a comprehensive understanding of the problem and the techniques that have been used thus far in preventing, detecting, and responding to various DDoS flooding attacks. In this paper, we explore the scope of the DDoS flooding attack problem and attempts to combat it. We categorize the DDoS flooding attacks and classify existing countermeasures based on where and when they prevent, detect, and respond to the DDoS flooding attacks. Moreover, we highlight the need for a comprehensive distributed and collaborative defense approach. Our primary intention for this work is to stimulate the research community into developing creative, effective, efficient, and comprehensive prevention, detection, and response mechanisms that address the DDoS flooding problem before, during and after an actual attack.

/pdf/a-survey-of-defense-mechanisms-against-distributed-denial-of-36i5dbdzy6.pdf

A Survey of Defense Mechanisms Against Distributed Denial of Service (DDoS) Flooding Attacks

Modern networks provide a variety of interrelated services including routing, traffic monitoring, load balancing, and access control. Unfortunately, the languages used to program today's networks lack modern features - they are usually defined at the low level of abstraction supplied by the underlying hardware and they fail to provide even rudimentary support for modular programming. As a result, network programs tend to be complicated, error-prone, and difficult to maintain.This paper presents Frenetic, a high-level language for programming distributed collections of network switches. Frenetic provides a declarative query language for classifying and aggregating network traffic as well as a functional reactive combinator library for describing high-level packet-forwarding policies. Unlike prior work in this domain, these constructs are - by design - fully compositional, which facilitates modular reasoning and enables code reuse. This important property is enabled by Frenetic's novel run-time system which manages all of the details related to installing, uninstalling, and querying low-level packet-processing rules on physical switches.Overall, this paper makes three main contributions: (1) We analyze the state-of-the art in languages for programming networks and identify the key limitations; (2) We present a language design that addresses these limitations, using a series of examples to motivate and validate our choices; (3) We describe an implementation of the language and evaluate its performance on several benchmarks.

/pdf/frenetic-a-network-programming-language-xza0s2pb9i.pdf

Frenetic: a network programming language

An empirical comparison of botnet detection methods

This document specifies the IP Flow Information Export (IPFIX)
protocol that serves for transmitting IP Traffic Flow information over
the network. In order to transmit IP Traffic Flow information from an
Exporting Process to an information Collecting Process, a common
representation of flow data and a standard means of communicating them
is required. This document describes how the IPFIX Data and Template
Records are carried over a number of transport protocols from an IPFIX
Exporting Process to an IPFIX Collecting Process. [STANDARDS-TRACK]

/pdf/specification-of-the-ip-flow-information-export-ipfix-4ofmputj6q.pdf

Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information

A method of managing routing of data elements, each having a plurality of characteristics having a respective attribute, in a data communications network, comprises: creating a flow record of data elements having common attributes for one or more tracked characteristics. The method further comprises defining said flow record as a trackable object; tracking a state change of said trackable an object; and performing a routing management step upon occurrence of a tracked state change.

Method and apparatus for managing routing of data elements

This document specifies the export of packet information from a Packet
SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process. For
export of packet information, the IP Flow Information eXport (IPFIX)
protocol is used, as both the IPFIX and PSAMP architecture match very
well, and the means provided by the IPFIX protocol are sufficient. The
document specifies in detail how the IPFIX protocol is used for PSAMP
export of packet information. [STANDARDS-TRACK]

Packet Sampling (PSAMP) Protocol Specifications

Packet delay variation metrics appear in many different standards
documents. The metric definition in RFC 3393 has considerable
flexibility, and it allows multiple formulations of delay variation
through the specification of different packet selection functions.
Although flexibility provides wide coverage and room for new ideas, it
can make comparisons of independent implementations more difficult.
Two different formulations of delay variation have come into wide use
in the context of active measurements. This memo examines a range of
circumstances for active measurements of delay variation and their
uses, and recommends which of the two forms is best matched to
particular conditions and tasks.

Packet Delay Variation Applicability Statement

This document provides a common implementation-independent basis for
the interoperable application of the IP Flow Information Export
(IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX
Flows representing packets from multiple Original Flows sharing some
set of common properties. It does this through a detailed terminology
and a descriptive Intermediate Aggregation Process architecture,
including a specification of methods for Original Flow counting and
counter distribution across intervals.

/pdf/flow-aggregation-for-the-ip-flow-information-export-ipfix-2pjt5i8l3w.pdf

Benoit Claise

Papers

Method and apparatus for managing routing of data elements

Packet Sampling (PSAMP) Protocol Specifications

Packet Delay Variation Applicability Statement

Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol

Requirements for {IP} Flow Information Export