Summary

  • The 2 November draft-ietf-idr-fsv2-content-filter-00 proposes a fixed packet-content match for BGP FlowSpec v1 and v2. It is an IDR working-group Internet-Draft, not an RFC.
  • A rule specifies a starting point, offset, content bytes and a mask. In FSv2 the content component is mandatory; a device that cannot implement it must refuse local installation of the whole route.
  • The safeguard matters because silently dropping the byte condition would leave a broader traffic filter. The draft places peer trust, rule authorization, scope, resource limits and rollback with the operator.

A small string can cast a large shadow

FlowSpec distributes traffic-filter rules over BGP. Until now its basic IP families mostly matched header fields: addresses, ports and related signals. The new IDR working-group draft gives the rule a way to name fixed bytes in packet content. A filter can say where to start, how far to skip and which bits must match. For a known attack signature, that is useful precision. For a mistaken offset, it is a very efficient way to make innocent traffic look suspicious.

The proposed component uses OType to choose an IP header, IP payload, UDP payload or TCP payload as the starting point, then an Offset, a nonzero Content Length, bytes and a mask. The mask marks which bits count. This is a fixed-pattern test, not a claim that BGP understands the meaning of an application message. The draft's example targets a two-byte value at the start of a TCP payload, alongside a destination prefix.

The crucial sentence is in the FSv2 encoding. Its packet-content component is mandatory. If a device cannot inspect the specified pattern, perhaps because the valid encoded length exceeds its local hardware capacity, it must treat the entire FlowSpec route as ineligible for local installation. It may not throw away that one component and install the rest. Without the byte test, a rule intended to catch one pattern could match a much wider set of packets and apply a drop, redirect or rate limit under local policy.

The offset itself is not a universal coordinate. For IPv6, the IP-payload base begins after the fixed header, so extension headers sit inside the counted region; changes in those headers along a path can move the intended bytes. With a tunnel, inspecting the outer packet can make the base ambiguous. The draft tells operators to use the decapsulated inner IP packet where appropriate, or establish an unambiguous base. A device that cannot locate a UDP or TCP payload simply does not match it.

The authors recommend controlled filtering points, combinations with narrower header conditions, trusted BGP peers, restricted propagation and resource limits. Packet inspection consumes finite ACL, UDF or TCAM capacity. The draft reports tests with OpenBGPD, FRRouting and programmable switches, but gives no production adoption or incident count. The public decision now on the table is precise: a network may distribute a sharper instruction, yet a device that cannot execute its essential condition has no licence to execute a blunter one.

Original sources