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... -danny