BGP FlowSpec

Danny McPherson danny at
Mon May 2 12:30:14 UTC 2016

On 2016-04-28 02:31 AM, Martin Bacher wrote:

>> Literally the only people who were interested in it at the time was 
>> one
>> of the spec's co-authors.  :-)
> That’s how it usually starts. ;)

Given that I may be the guilty one here, I thought it might be worth 
chiming in.

Inter-AS FlowSpec largely met the same fate as inter-AS source-based 
RTBH, where upstreams would only want to permit you to block sources 
destined for your address blocks (i.e.,. not others, so you would have 
to specify extended drop rule sets -- at least source and destination).  
As a result, with inter-AS FlowSpec, to appropriately scope things 
ingress policy specification is more complicated and hardware support 
was pretty limited at the time as well.  Additionally, there was also 
only one vendor implementation at the time but now there are many and 
the IETF's IDR working group is continuing to enhance the capabilities 
and options available with FlowSpec.

There are a large number of intra-AS and multi-AS single administrative 
domains that use FlowSpec today (my $dayjob included, for an array of 
things, not just DDoS mitigation).  And as you point out Martin, it's 
simply another option available in the toolkit.

One of the nicest things about it is that unlike destination-based RTBH, 
where you effectively completed the attack, if you can identify the 
primitives, namely at the network and transport layer, you can squelch a 
large number of attack vectors in an automated manner with minimal 
action required by the operator.

We use it effectively in a layered model where "Principle of Minimal 
Intervention" applies, allowing attack mitigation and traffic diversion 
in the most optimal place (e.g., at network ingress), and only scrubbing 
or diverting traffic when necessary.  Just like destination and 
source-based RTBH, FlowSpec is simply another evolution of automating 
forwarding path configuration, where NFV/SDN are the newest incarnation 
and can allows badness such as DDoS to be dropped implicitly rather than 
explicitly, even...


More information about the NANOG mailing list