[188974] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: BGP FlowSpec

daemon@ATHENA.MIT.EDU (Martin Bacher)
Thu Apr 28 02:32:05 2016

X-Original-To: nanog@nanog.org
From: Martin Bacher <ti14m028@technikum-wien.at>
In-Reply-To: <20160427105823.12639135@localhost>
Date: Thu, 28 Apr 2016 08:31:57 +0200
To: John Kristoff <jtk@cymru.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org


> Am 27.04.2016 um 17:58 schrieb John Kristoff <jtk@cymru.com>:
>=20
> On Thu, 21 Apr 2016 09:46:13 +0200
> Martin Bacher <ti14m028@technikum-wien.at> wrote:
>=20
>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
>> of attacks are you using it? Are you only dropping or rate-limiting
>> certain traffic or are you also using the redirect/remark
>> capabilities? What are the limitations from your perspective? Are you
>> facing any operational issues? How are you injecting the FlowSpec
>> routes?
>=20
> Unless you received a number of private responses, perhaps the lack of
> public responses is telling.
>=20
> I've heard of a few networks doing this and there is some public =
record
> of it being used, including one instance where a bad rule was behind a
> serious outage:
>=20
>  =
<https://support.cloudflare.com/hc/en-us/articles/200172446-CloudFlare-Pos=
t-Mortem-from-Outage-on-March-3-2013>

Thanks for that information.  I didn=E2=80=99t know about that outage =
and this is definitely something which is very important and worth =
mentioning in the paper. But i would rather say that this is a general =
risk. A fat fingers issue can always disconnect you from the internet as =
well as a software bug in a homogenous environment.

>=20
>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
>> your experience? Are there any concerns regarding Inter-AS
>> deployments? Has anyone done interop tests?
>=20
> You might mine public, archived BGP data and see if there are any
> traffic filtering rules present (they are encoded in extended
> communities, which are optional, transitive).

I don=E2=80=99t think that I will find anything there because it is a =
dedicated SAFI. Only traffic filtering actions are encoded as extended =
communities.
>=20
> We once tried to coordinate an Inter-AS flow-spec project, but it
> failed miserably due to lack of interest.  For posterity, here is the
> project page:
>=20
>  <https://www.cymru.com/jtk/misc/community-fs.html>

I already came across your project but didn=E2=80=99t recognize that =
there is/was also some FlowSpec initiative.

>=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
> Since then, we have tried a more modest approach using the well known
> BGP RTBH technique:
>=20
>  <https://www.cymru.com/jtk/misc/utrs.html>
>=20
> This has been much more successful and since we've started we've
> probably had about a dozen networks express interest in flow-spec
> rules.  Verification of rules is potentially tricky, but
> widespread interest still lags in my estimation.
Yes, RTBH is quite common and really helpful in the inter AS world. But =
eBGP FlowSpec is just offered by very few ISPs. I think that intra AS =
deployments are more common, but one wouldn=E2=80=99t be able to detect =
that unless somebody tells you that they are using it.

>=20
>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
>> and which applications are you using for the analysis (Peakflow,
>> Open-Source tools, ..?)
>=20
> Not speaking for anyone in particular, but don't forget about user
> complaints.  In some cases a network may not notice (or care) if an
> attack is below a certain threshold for their network, but above a
> stress point downstream.
That=E2=80=99s true. They are selling IP-Transit and more traffic means =
more money. Upstream providers may only care if other customers are also =
affected or unless you pay them for protection.

Thanks for your comments!

Cheers,
Martin

>=20
> John


home help back first fref pref prev next nref lref last post