Summary
The FlowSpec-netfilter add-on container currently documents only match-criteria generation.
RFC 5575 / RFC 8955 define four action extended communities, and operators using FlowSpec for DDoS mitigation commonly need more than discard, i.e., policing an attack flow rather than blackholing it keeps legitimate traffic to the same destination alive. This request asks for support for traffic-rate and traffic-marking, and for an evaluation of the redirect.
Currently, the container generates rules for: destination prefix, source prefix, protocol, destination-port, source-port, icmp-type, icmp-code, packet-length, and dscp. Port, tcp-flags, and fragment are unchecked, with a TODO for TCP flags and fragmentation.
Requested
| Ext. community | Action | Request |
| 0x8006 | traffic-rate | Emit a rate-limiting rule instead of an unconditional drop |
| 0x8009 | traffic-marking | Set DSCP on matching packets |
| 0x8008 | redirect (RT → VRF) | Evaluate feasibility; see notes |
- traffic-rate. nftables supports byte-granular token-bucket limits natively, so the generated rule is of the form <existing match> limit rate over <N> bytes/second burst <B> bytes drop, inside the existing flowspec table and chain. Burst needs a sane default and probably an env var (e.g., NFT_RATE_BURST). Named limits are an option if per-rule counters are wanted in the nft list table ip flowspec.
- traffic-marking. The container already parses DSCP on the match side, so this is an IP DSCP set <value> statement on an otherwise-accepting rule.
- redirect. nftables can mark packets (meta mark set), but moving them into a VRF requires an ip rule and an l3mdev VRF device. It also needs a mapping from the received route target to a locally configured VRF.