FlowSpec
This document is an informative description of the standard Inter.link FlowSpec service. The applicable service order, Service Level Agreement (SLA), and Master Services Agreement (MSA) prevail in the event of any conflict.
Service overview
Section titled “Service overview”Inter.link FlowSpec is a separately ordered, customer-managed BGP FlowSpec filtering service. The customer advertises rules over existing BGP sessions. Rules that pass Inter.link validation are distributed to AS5405 edge routers, where they can drop, rate-limit, or accept matching customer-bound traffic.
FlowSpec does not include attack detection or managed mitigation. The customer is responsible for monitoring traffic, constructing and advertising rules, validating their effect, and withdrawing them when no longer required. DDoS Protection is a separate service with its own detection, diversion, and mitigation model.
FlowSpec is ordered through Sales and billed as a flat monthly add-on once per customer. It can be used across all of that customer’s eligible IP Transit and FlexTunnel services. The current package and active-rule entitlement must be confirmed with Sales.
Eligible services and BGP delivery
Section titled “Eligible services and BGP delivery”| Underlying service | FlowSpec delivery |
|---|---|
| IP Transit | Uses the service’s existing IPv4 and IPv6 BGP sessions; available at every Inter.link point of presence (PoP) |
| FlexTunnel | Uses the tunnel’s existing IPv4 and IPv6 BGP sessions; termination is limited to selected Inter.link routers |
At least 10 Gbps of aggregate customer commitment is required within each underlying service type on which FlowSpec is used. IP Transit and FlexTunnel commitments are calculated separately.
FlowSpec uses MP-BGP on the underlying service’s existing directly connected eBGP sessions. IPv4 rules are exchanged over the IPv4 session and IPv6 rules over the IPv6 session. No separate FlowSpec session is created, and ordinary unicast routes are not exchanged in the FlowSpec address families.
| Attribute | Standard behaviour |
|---|---|
| Provider ASN | AS5405 |
| IPv4 FlowSpec | AFI 1, SAFI 133, following RFC 8955 |
| IPv6 FlowSpec | AFI 2, SAFI 133, following RFC 8956 |
| Advertisement direction | Customer to Inter.link |
| External export | Customer rules are not exported outside AS5405 |
| BGP settings | Inherited from the underlying IP Transit or FlexTunnel service |
TCP MD5, GTSM and BFD follow the underlying service.
Rule construction
Section titled “Rule construction”One FlowSpec NLRI matches the intersection of all components it contains. Components must be unique and encoded in ascending component-type order. Every rule must contain a destination prefix; source-only rules are silently filtered.
IPv4 match components
Section titled “IPv4 match components”| Component | Support and limitations |
|---|---|
| Destination prefix | Mandatory and subject to customer authorization |
| Source prefix | Supported |
| IP protocol | Supported |
| Source or destination port | Supported, except with a positive IsF condition |
| Destination port | Supported, except with a positive IsF condition |
| Source port | Supported, except with a positive IsF condition |
| ICMP type and code | Supported |
| TCP flags | Supported except ECE, CWR, and NS |
| IP packet length | Supported |
| DSCP | Supported |
| Fragment state | Only IsF is supported |
IsF matches only non-first IPv4 fragments, for which the transport-layer
header is unavailable. A rule combining a positive IsF condition with Port,
Destination Port, or Source Port is therefore silently filtered.
IPv6 match components
Section titled “IPv6 match components”| Component | Support and limitations |
|---|---|
| Destination IPv6 prefix | Mandatory and subject to customer authorization |
| Source IPv6 prefix | Supported |
| Next Header or upper-layer protocol | Supported |
| Source or destination port | Supported |
| Destination port | Supported |
| Source port | Supported |
| ICMPv6 type and code | Supported |
| TCP flags | Supported except ECE, CWR, and NS |
| IPv6 packet length | Not supported |
| DSCP | Supported |
| IPv6 fragment state | Not supported |
| IPv6 Flow Label | Not supported |
Non-zero source-prefix or destination-prefix offsets are not supported. Rules containing them are silently filtered and not installed.
Actions and rate limiting
Section titled “Actions and rate limiting”| Action | Standard behaviour |
|---|---|
| Rate limit | Supported in bytes per second, encoded as an IEEE-754 value |
| Drop | Supported by setting the byte rate to zero |
| Accept | Supported; traffic continues through normal forwarding and later policy stages |
| Packet-rate limit | Not supported |
| Redirect, DSCP rewrite, sampling, or logging | Not supported |
| Multiple actions in one rule | Not supported |
A positive byte rate is hard-policed independently at each edge router rather than as an aggregate network-wide allowance. Unsupported actions, combinations, or rules are silently filtered and are not installed.
Authorization and validation
Section titled “Authorization and validation”FlowSpec rule authorization and validation follow the separate Routing Policies document.
Enforcement and precedence
Section titled “Enforcement and precedence”Accepted rules are propagated to every AS5405 edge router and applied as ACLs to customer-bound traffic entering the network. Separate overlapping rules use standard RFC 8955 precedence. Customer rules are not exported outside AS5405.
Packet handling follows this order:
- Apply any matching FlowSpec rule at the receiving edge.
- Evaluate an applicable DDoS diversion.
- Apply routing.
A terminating result at an earlier stage prevents the packet from reaching a later stage. Rule installation and withdrawal are best effort.
Identical rules received over multiple service sessions remain effective while at least one session continues to advertise them. The customer must withdraw a rule when it is no longer required. Rules rejected because an entitlement was exceeded are not automatically reconsidered and must be advertised again.
Entitlement, acceptable use, and visibility
Section titled “Entitlement, acceptable use, and visibility”The rule entitlement applies customer-wide across all eligible IP Transit and FlexTunnel services. When the entitlement is exceeded, no additional rules are installed; existing rules and the BGP session remain active. There is no product-defined update-rate or numerical rule-size limit, but rule complexity must be kept low and service use remains subject to available platform resources.
FlowSpec is intended for temporary filtering of unwanted or attack traffic. Rules do not expire automatically, but continued use is subject to acceptable use and review by Inter.link.
Rules are created and withdrawn exclusively through BGP. No FlowSpec-specific state is exposed through the customer portal or API. Inter.link Support can inspect the internal installation date, but traffic counters are unavailable. Customers should provide the affected NLRI, timestamps, expected behaviour, and relevant traffic evidence.
The charge is independent of filtered traffic volume and ordinary variation in rule use within the ordered package. Unless otherwise agreed, billing starts when FlowSpec is provisioned and not before an associated new IP Transit or FlexTunnel service has also started billing.
Responsibilities
Section titled “Responsibilities”| Activity | Inter.link | Customer |
|---|---|---|
| BGP service | Operates the provider BGP endpoint and distributes valid rules | Operates and secures the customer BGP endpoint |
| Rule authorization | Applies supported syntax, action, prefix, and entitlement policy | Advertises rules only for authorized prefixes |
| Rule lifecycle | Applies accepted advertisements and withdrawals on a best-effort basis | Monitors traffic and withdraws rules when no longer required |
| Rate limiting | Enforces accepted limits independently at each edge | Selects limits and assesses application and capacity impact |
| Validation | Can provide the internal installation date; traffic counters are unavailable | Verifies intended traffic behaviour and supplies evidence for troubleshooting |
| Security impact | May reject or withdraw rules to protect the service or platform | Remains responsible for rule correctness and false-positive impact |
Service levels and support
Section titled “Service levels and support”Availability and performance commitments, incident priorities, response and restoration targets, maintenance rules, exclusions, remedies, and service credits are defined exclusively in the applicable SLA. FlowSpec rule installation and withdrawal are best effort. Nothing in this informative specification changes those terms.