Subject: Re: [Idr] flowspec enhancements

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Oct 2015 15:11:28 -0400

Wes,

On Tue, Sep 15, 2015 at 01:39:29PM -0400, Wesley Eddy wrote:
> Hello, we've been working on a few enhancements to the BGP flowspec
> capabilities that may be of interest:
> 
> https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00
> 
> There are several ideas described in the document that could be
> factored out from one another, but the basic idea is to increase
> the power of flowspec, mainly for its DDoS mitigation purposes.

This I-D serves as an interesting melange of ideas.  I suspect at some later
point you might find it useful to separate the individual changes into
distinct I-Ds.

> Specifically, the suggested enhancements include:
> - add packet rate limitations as an action (not just bitrate)

This one is generally useful and would be a pretty trivial extension.

> - add support for filtering of tunneled traffic (unencrypted)

This is problematic in several interesting ways, some of them implementation
specific.  But perhaps that really suggests a widening of the deployment
domain.

BGP Flowspec is typically deployed in scenarios to effectively program
firewall filtering on BGP speakers.  Pragmatically, this has meant some
level of restricting the operations to filters that can be applied at near
wire-rate and thus we're not always getting a full set of potential
filtering operations that may be available on devices that work at different
scale.  

There's also the second issue in that such directly indexed forms of
filtering may limit the deployment to cases where flowspec routes are
directly advertised and not propagated to other BGP speakers.  This is likey
because when tunneling technologies may change encap/decap on a hop-by-hop
basis, it becomes difficult to adjust the filters to be fully generic using
distribution via a Route Reflector - a common deployment scenario for
Flowspec.  

Of course, these constraints become different once we're talking about
non-traditional BGP speakers such as IPS systems, etc.

> - identifying flow specifications for tracking and communication
>   between providers

You may be aware that some tools vendors already permit DDoS mitigation
signature distribution.  I'd suggest speaking to some of them about the
popularity of the service.

> - cryptographically signing flowspecs

You note the major problems with using BGPSEC for securing Flowspec.  Your
second biggest challenge would be to get some sort of changes in BGPSEC for
covering flowspec.  

> - supporting a more surgical re-route to scrubbing centers
> - providing feedback about flowspecs to the source
> 
> If any of these are interesting to folks, we'll appreciate your
> feedback, comments, questions, etc.  Some are more difficult than
> others.

Lots of interesting ideas, and some that probably should be peeled off and
submitted individually.

-- Jeff

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 14 Oct 2015 20:21:45 -0400

Hi Jeff, I had a couple comments to your message inline below:

> point you might find it useful to separate the individual changes into

Splitting out any good ideas, and leaving the bad or more difficult
ones behind, is definitely the plan.

> This one is generally useful and would be a pretty trivial extension.

Everyone that we've talked to has seemed to agree on this, so I think
it looks like we should pull it out into its own document.  We aren't
an equipment vendor with an implementation that could do packet rate
limiting, so I'd think it would be great if we could get a co-editor
from some vendor who could actually implement this ... if you or
someone else might be interested.

> non-traditional BGP speakers such as IPS systems, etc.

Agreed on all counts.  I think it motivates having a discussion "up one
level" first, to see what the community believe the future of flowspec
is, in terms of what types of devices in the near future are envisioned
to be utilizing flowspec routes, whether everyone only intends to use
them intra-domain or across one or more AS hops, etc.

Maybe everyone already implicitly agrees on these, and I just haven't
understood, but I think it would help to be explicit.

-- 
Wes Eddy
MTI Systems