BGP FlowSpec Payload
MatchingJuniper Networks, Inc.2251 Corporate Park DriveHerndonVirginia20171USanuragk@juniper.netJuniper Networks, Inc.1133 Innovation WaySunnyvaleCA94089USjgs@juniper.netVerizonluay.jalil@one.verizon.comVerizonmichael.gallagher@verizon.com
RTG
Internet Engineering Task ForceBGPFlowspecThe rise in frequency, volume, and pernicious effects of DDoS attacks
has elevated them from fare for the 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 (RFC 5575, "Dissemination of Flow Specification Rules")
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.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, or the burgeoning
variety of tunneled traffic.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 .BGP FlowSpec couples both the advertisement of NLRI-specific match
conditions, as well as the forwarding instance to which the filter is
attached. This makes sense since BGP FlowSpec advertisements are most
commonly generated, or at least verified, by human operators. The
operator finds it intuitive to configure match conditions as
human-readable values, native to each address family.It is much friendlier, for instance, to define a filter that matches
a source address of 192.168.1.1/32, than it is to work with the
equivalent binary representation of that IPv4 address. Further, it is
easier to use field names such as 'IPv4 source address' as part of the
match condition, than it is to demarc that field using byte and bit
offsets.However, there are a number of use cases that benefit from the
latter, more machine-readable approach.Launching a DDoS is easier and more cost-effective than ever. The
will to attack matters more than wherewithal. Those with the
inclination can initiate one from the comfort of
their homes, or even buy DDoS-as-a-Service,
complete with 24x7 support and flexible payment plans.Despite their effectiveness, such attacks are easily thwarted -
once identified. The challenge lies in fishing out a generally
unvarying attack signature from a data stream. Machine analysis may
prove superior here, given the size of input involved. The resulting
pattern may not lie within a well-defined field; even if it happens
to, it may be a more straight-forward workflow to have machine
analysis result in a machine-readable filter.Tunnels continue to proliferate due to the benefits they provide.
They can help reduce state in the underlay network. Tunnels allow
bypassing routing decisions of the transit network. Traffic that is
tunneled is often done so to obscure or secure. Common tunnel types
include IPsec , Generic Routing Encapsulation
(GRE) , Virtual eXtensible Local Area Network
(VXLAN) , GPRS Tunneling Protocol (GTP) , et al.By definition, transit nodes that are not the endpoints of the
tunnel hold no attendant control or management plane state. These very
qualities make it challenging to filter tunneled traffic at
non-endpoints. Often though, the forwarding hardware at these
transit-only nodes is capable of reading the byte stream that
comprises the protocol being tunneled. Despite this capability, it is
usually infeasible to filter based on the content of this passenger
protocol's header since BGP FlowSpec does not provide the operator a
way to address arbitrary locations within a packet.Not all traffic is forwarded as IP packets. Layer 2 services
abound, including flavors of BGP-signaled Ethernet VPNs such as
BGP-EVPN, BGP-VPLS, FEC 129 VPWS (LDP-signaled VPWS with BGP
Auto-Discovery).Ongoing efforts such as offer one approach, which is to
add layer 2 fields as additional match conditions. This may suffice if
a filter needs to be applied only to layer 2, or only to layer 3
header fields.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.ValueSymbolic NameMatch start0dLayer 2 (d)ata-link layer Ethernet header1iLayer 3 (I)Pv4/IPv6 header2tLayer 4 TCP/UDP (t)ransport header3pLayer 4-specific (p)rotocol-specific payloadReserved. 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 valueMatch startdOuter Ethernet HeaderiOuter IPv4/IPv6 HeadertOuter UDP HeaderpVXLAN HeaderMalicious, 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 ValueNameReferenceTBDFlexible Match Conditionsthis documentThanks to Rafal Jan Szarecki, Sudipto Nandi, Ron Bonica, and Jeff
Haas for their valuable comments and suggestions on this document.