[c-nsp] BGP flowspec S/RTBH for large DDoS

[chip]

Some folks at Juniper have recently commented that work is ongoing to
devise a method of configuring "groups" of interfaces and an extra field in
the flowspec rule be tied to the group.  In this manner some rules may be
tied a group of interfaces while other rules can be tied to other
interfaces.  No idea when it will be implemented however.

--chip

On Thu, May 19, 2016 at 7:40 AM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
wrote:

> > From: Saku Ytti [mailto:saku at ytti.fi]
> > Sent: Thursday, May 19, 2016 11:15 AM
> >
> > On 19 May 2016 at 02:35, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> > wrote:
> > > Is there a support for selection of interface to which the policy
> should be
> > applied as well as support to select order in which the policies are
> applied
> > please?
> >
> > I don't think I understand the question. The RFC limit applies to all
> external
> > BGP. The limit I'm talking about is simply about matching communities and
> > dropping updates with bad action communities.
> >
> I'm sorry I wasn't necessarily commenting on your worries, where if i
> understand it correctly you mentioned that if customer advertises a rule
> with set next hop to other VRF the rule gets installed allowing him to
> inject traffic to that VRF -and thus this type of action should be rejected
> when received via CP-PE eBGP session.
> -did I get it right?
>
> In my question I was trying to ask whether the below shortcoming of
> current flowspec implementations are being addressed.
> My understanding (from flowspec implementation in junos) is that the
> received route is applied in from of a filter at vrf level so all
> interfaces in the vrf are subject to the filtering in both inbound and
> outbound direction so one can't select which interfaces will actually
> install the filter.
> Also if multiple routes are received the order at which the terms are
> installed/evaluated (if you enable the correct behaviour) is from the
> longest (most detailed) match down -and there's no way how a user can
> influence that.
>
>
> adam
>
>
>
>
>
>
>
>
>
>
>
>         Adam Vitkovsky
>         IP Engineer
>
> T:      0333 006 5936
> E:      Adam.Vitkovsky at gamma.co.uk
> W:      www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or
> forward all or any of it in any form (unless otherwise notified). If you
> receive this email in error, please accept our apologies, we would be
> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> email postmaster at gamma.co.uk
>
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
Just my $.02, your mileage may vary,  batteries not included, etc....