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

[chip]

>> 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?

In IOSXR I believe you can specify which interfaces are subject to FlowSpec
rules:

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-2/routing/configuration/guide/b_routing_cg52xasr9k/b_routing_cg52xasr9k_chapter_011.html#task_A5FC3160B5F346D5A28389B78AFB9EFB

I do not believe there's a method to define some set of received flow rules
only apply to a specific set of interfaces.

With regards to the ordering of policies, its defined in the RFC how they
are implemented.
https://tools.ietf.org/html/rfc5575#section-5.1

--chip








On Wed, May 18, 2016 at 7:35 PM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
wrote:

> > Saku Ytti
> > Sent: Monday, May 16, 2016 10:33 AM
> > To: Nathan Ward
> > Cc: Gert Doering; Cisco Network Service Providers
> > Subject: Re: [c-nsp] BGP flowspec S/RTBH for large DDoS
> >
> > On 16 May 2016 at 12:29, Nathan Ward <cisco-nsp at daork.net> wrote:
> >
> > > I see what you’re getting at, and the behaviour to prevent attacks I
> suspect
> > that you’re thinking of is the default.
> > >
> > > https://tools.ietf.org/html/rfc5575#section-6
> > >
> > > Roughly, you only use flowspec routes from external networks if they
> are
> > the best path for that prefix.
> > >
> > > There’s an I-D that updates this to relax it a little so it can be
> used if you
> > have multiple eBGP peers between two ASNs (which is obviously quite
> > common).
> >
> > Alas this effort is overlooking actions. RFC should have two category of
> > actions, actions which are externally OK and which are internally OK. By
> > default, this policy should reject all updates with internal action from
> external
> > customer.
> >
> > Right now, without manually limiting the action communities, customer can
> > inject traffic to arbitrary VRF and arbitrary next-hop. Then you'll need
> > another vector to get forward traffic to VRF (Such as OptB without label
> > checking) to completely pwn VRF.
> >
> >
> >
> 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?
>
> 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....