Re: BGP FlowSpec

[Martin Bacher <ti14m028 () technikum-wien at>]

> Am 02.05.2016 um 14:30 schrieb Danny McPherson <danny () tcb net>:
>
>
>
> 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).  
I mainly agree on that. However, I have not found evidence of inter-AS S-RTBH deployments as of now. This would really 
require, at least in my understanding, a lot of hacks in order to implement it properly and avoid blackholing of the 
wrong traffic. BGP-FS is clearly doing a better job in that area. However, Tier 1s and most probably also some of the 
Tier 2s may not want to offer it to customers because they are loosing money if less traffic is sent downstream on 
IP-Transit links. What I would expect to see more often is iBGP deployments in order to protect the own infrastructure 
by remarking suspicious traffic to worst than best effort automatically. That’s again an example why BGP-FS in inter-AS 
setups may not be deployed on a large scale and things may stay worse for the Internet edge (and I still hope that I am 
wrong with that assumption).

> 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.
Yes, I have also noticed that. And the hardware support and inter-AS verification options are much better compared to 
the very beginning. 

> 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.
I personally think that it will really become standard for single administrative domains in the future as it is with 
L2VPNs and L3VPNs. Most of the AS will just deploy it and use it for DDoS mitigation and other applications. You just 
mentioned that you also used for other things. May I ask you about your use-cases?

> 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.
Could not agree more.

> 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…
Great. Thanks for sharing that. One must just make sure that the tools are used properly. High volume attacks can 
easily mitigated in many cases with BGP-FS while while other attacks like low bandwidth TCP attacks will have to be 
mitigated by scrubbing centers. 

@SDN/NFV: I am not so sure if this will really help or make things just more complicated. I have just been told that 
people are working on netconf/yang solutions for ACL deployments, which may again only work for intra-AS deployments. 
But your comment is going, at least in my understand, beyond ACL deployments, right? Could you please elaborate a bit 
further on that.

Many thanks.

Martin

> -danny