BGP FlowSpec Payload Matching

The rise in frequency, volume, and pernicious effects of distributed denial of service ("DDoS") attacks has elevated them from fare for specialist to generalist press. Numerous reports detail the taxonomy of DDoS types, the varying motivations of their attackers, as well as the resulting business and reputation loss of their targets. BGP FlowSpec can be used to rapidly disseminate filters that thwart attacks, being particularly effective against the volumetric type. Operators can use existing FlowSpec components to match on pre-defined packet header fields. However recent enhancements to forwarding plane filter implementations allow matches at arbitary locations within the packet header and, to some extent, the payload. This capability can be used to detect highly amplified attacks, whose attack signature remains relatively constant. We define a new FlowSpec component, "Flexible Match Conditions", with similar matching semantics to those of existing components. This component will allow the operator to define bounded match conditions using offsets and bitmasks.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

We define a new FlowSpec component, Type TBD, named "Flexible Match Conditions". Encoding: <type (1 octet), op, value> It contains a single {operator, value} tuple that is used to match packets according to the rules given below.

The operator field is encoded as:

Type of value being matched, string comparison if this bit is set, and numeric range if unset. Anchor. A 2-bit unsigned integer whose value indicates where in the packet the match should start. To avoid ambiguity with tunneled packets, the match SHOULD be anchored at the outermost header. An example is given below . Value Symbolic Name Match start 0 d Layer 2 (d)ata-link layer Ethernet header 1 i Layer 3 (I)Pv4/IPv6 header 2 t Layer 4 TCP/UDP (t)ransport header 3 p Layer 4-specific (p)rotocol-specific payload Reserved. MUST be set to 0. MUST be ignored on receipt. A 3-bit unsigned integer indicating how many bits to ignore, following the byte offset. An 8-bit unsigned integer indicating how many bytes to ignore, after the match start as determined by the first selected anchor bit.

The operator field indicates where to start matching; by contrast, the value operand indicates what to match and where to stop matching. The value operand MUST be of the type indicated by the 'v' bit, as signaled in the operator. As a result it can take on one of two forms - string vs. numeric range comparison. The length of the numeric range is constant. It uses two 64-bit fields. A string comparison uses two 128-bit fields. Its length field indicates the extent of how much of the prefix and mask fields to use in the AND operation. This is deemed sufficient for stateless inspection and practical for efficient hardware forwarding plane implementations.

Indicates the number of corresponding bits in the prefix and mask fields to read. This length field is interpreted as (len + 1 << 1). This allows even unsigned values ranging from 2-128. Provides a bit string to be matched. The prefix and mask fields are bitwise AND'ed to create a resulting pattern. The number of bits used in the AND operation are indicated by the preceding length field. Paired with the prefix field to create a bit string match. An unset bit is treated as a 'do not care' bit in the corresponding position in the prefix field. When a bit is set in the mask, the value of the bit in the corresponding location in the prefix field must match exactly. Implementations MUST only extract the number of bits from the prefix and mask fields as indicated by the preceding length field.

The low value of the desired inclusive numeric range. This value MUST be numerically lower than the high value. The high value of the desired inclusive numeric range. This value MUST be numerically higher than the low value.

As an example, consider that the canonical Virtual eXtensible Local Area Network (VXLAN) packet has the following headers: Outer Ethernet Header: Source MAC address of the originating VXLAN Tunnel End Point (VTEP). Outer IPv4/IPv6 Header: Source IP address of the originating VXLAN Tunnel End Point (VTEP). Outer UDP Header: Random source port used to generate entropy for load balancing, and destined to the IANA-assigned VXLAN port 4789. VXLAN Header: Used to identify a specific VXLAN overlay network. Inner Ethernet Header and payload: Original MAC frame being encapsulated. The following table outlines where the match would start based on the anchor setting: Anchor value Match start d Outer Ethernet Header i Outer IPv4/IPv6 Header t Outer UDP Header p VXLAN Header

Malicious, misbehaving, or misunderstanding implementations could advertise semantically incorrect values. Care must be taken to minimize fallout from attempting to parse such data. Any well-behaved implementation SHOULD verify that the minimum packet length undergoing a match equals (match start header length + byte offset + bit offset + value length).

This document introduces no additional security considerations beyond those already covered in .

IANA is requested to assign a type from the First Come First Served range of the "Flow Spec Component Types" registry: Type Value Name Reference TBD Flexible Match Conditions this document

Thanks to Rafal Jan Szarecki, Sudipto Nandi, and Jeff Haas for their valuable comments and suggestions on this document.