[189033] in North American Network Operators' Group
Re: BGP FlowSpec
daemon@ATHENA.MIT.EDU (Martin Bacher)
Mon May 2 09:16:52 2016
X-Original-To: nanog@nanog.org
From: Martin Bacher <ti14m028@technikum-wien.at>
In-Reply-To: <4548ef76bafd6f33e098c93f90a46c7c@tcb.net>
Date: Mon, 2 May 2016 15:16:44 +0200
To: Danny McPherson <danny@tcb.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> Am 02.05.2016 um 14:30 schrieb Danny McPherson <danny@tcb.net>:
>=20
>=20
>=20
> On 2016-04-28 02:31 AM, Martin Bacher wrote:
>=20
>>> Literally the only people who were interested in it at the time was =
one
>>> of the spec's co-authors. :-)
>> That=E2=80=99s how it usually starts. ;)
>=20
>=20
> Given that I may be the guilty one here, I thought it might be worth =
chiming in.
>=20
> 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). =20=
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=E2=80=99s 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.=20
>=20
> 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?
>=20
> 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.
>=20
> 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=E2=80=A6
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.=20
@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
>=20
>=20
> -danny
>=20
