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
