Re: Flowspec IPv6

[Eric Dugas via NANOG]

Turns out the apply-group isn't working for v6 rules.

ATAC made me replicate the same rule directly under routing-options and
inet6flow.0 appeared and I can see my rule populated now.

FYI I'm running vRR 20.4R1-S1.2

On Sun, May 23, 2021 at 4:55 AM Zbyněk Pospíchal 
wrote:

> Hi Eric,
>
> with no v6 fs rules, the table inet6flow.0 stay hidden. Try to make any.
>
> --
> S pozdravem/Best Regards,
> Zbyněk
>
>
>
> Dne 21.05.21 v 20:10 Eric Dugas via NANOG napsal(a):
> > Hello,
> >
> > I've been fiddling with JunOS to enable Flowspec IPv6. According to the
> > docs, it was implemented in 16.x. I've tried to set it up in vRR and vMX
> > in the 20.x train. Everything commit just fine, I get the inetflow.0 for
> > IPv4 but inet6flow.0 is not appearing.
> >
> > I already have a JTAC case (now escalated to ATAC) but I am looking for
> > plan B.
> >
> > Has anyone implemented Flowspec v6? I was thinking about FRRouting but I
> > wanted to get some feedback from the community before spending more
> > hours into this.
> >
> > Thanks
> > Eric
>
>

Re: Flowspec IPv6

[Trond Hastad via NANOG]

Hi,

I just configured this a few days ago on a mx960 running 18.4R3.
This was traffic redirection into a routing-instances so i do not know 
if it matches your setup.

But i can confirm that it is working in my setup.

Regards
Trond




Hello,

I've been fiddling with JunOS to enable Flowspec IPv6. According to
the docs, it was implemented in 16.x. I've tried to set it up in vRR
and vMX in the 20.x train. Everything commit just fine, I get the
inetflow.0 for IPv4 but inet6flow.0 is not appearing.

I already have a JTAC case (now escalated to ATAC) but I am looking
for plan B.

Has anyone implemented Flowspec v6? I was thinking about FRRouting but
I wanted to get some feedback from the community before spending more
hours into this.

Thanks
Eric

Re: Flowspec IPv6

[Zbyněk Pospíchal]

Hi Eric,

with no v6 fs rules, the table inet6flow.0 stay hidden. Try to make any.

-- 
S pozdravem/Best Regards,
Zbyněk



Dne 21.05.21 v 20:10 Eric Dugas via NANOG napsal(a):
> Hello,
> 
> I've been fiddling with JunOS to enable Flowspec IPv6. According to the
> docs, it was implemented in 16.x. I've tried to set it up in vRR and vMX
> in the 20.x train. Everything commit just fine, I get the inetflow.0 for
> IPv4 but inet6flow.0 is not appearing.
> 
> I already have a JTAC case (now escalated to ATAC) but I am looking for
> plan B.
> 
> Has anyone implemented Flowspec v6? I was thinking about FRRouting but I
> wanted to get some feedback from the community before spending more
> hours into this.
> 
> Thanks
> Eric

RE: [EXTERNAL] Re: FlowSpec

[Nikos Leontsinis]

If you can impose a limit on the amount of flowspec rules the customer can send 
you (I assume you are the Service provider) where is the problem
 with offering  flowspec services? Seems more of a vendor challenge.

The tcam issue is relatively addressed with proper dimensioning (throw money to 
the problem)
 and you have created a service revenue opportunity so it is a win win for both
 customer, provider and the entire community.
We cannot go very far with blackholing as a community.


-Original Message-
From: NANOG  On Behalf Of Denys Fedoryshchenko
Sent: 23 April 2020 16:58
To: Colton Conor 
Cc: NANOG 
Subject: [EXTERNAL] Re: FlowSpec

On 2020-04-23 18:13, Colton Conor wrote:
> Do any of the large transit providers support FlowSpec to transit
> customers / other carriers, or is that not a thing since they want to
> sell DDoS protection services? FlowSpec sounds much better than RTBH
> (remotely triggered blackhole), but I am not sure if  FlowSpec is
> widely implemented. I see the large router manufacturers support it.

RETN

They have extended blackholing, and FlowSpec, sure its all have costs.
I'm using both services from them and quite satisfied.

In general operators don't like flowspec, because it is not easy to implement 
it right, there is bugs and most important its "eating" TCAM.
For example:
https://urldefense.com/v3/__https://blog.cloudflare.com/todays-outage-post-mortem-82515/__;!!PcPv50trKLWG!jJCV6iVdjh9kx3oiFfxOwO6BdJfkVq6eY8iqqerUChY1t8qUVWITa00EAx1J1zloDMvF1WX9$
This email is from Equinix (EMEA) B.V. or one of its associated companies in 
the territory from where this email has been sent. This email, and any files 
transmitted with it, contains information which is confidential, is solely for 
the use of the intended recipient and may be legally privileged. If you have 
received this email in error, please notify the sender and delete this email 
immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA 
Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889.

Re: FlowSpec

[Denys Fedoryshchenko]

On 2020-04-23 19:12, Roland Dobbins wrote:

On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:


In general operators don't like flowspec


Its increasing popularity tens to belie this assertion.

Yes, you're right that avoiding overflowing the TCAM is very
important.  But as Rich notes, a growing number of operators are in
fact using flowspec within their own networks, when it's appropriate.

One of operators told me why they dont provide flowspec anymore:
customers are installing rules by scripts, stacking them,
and not removing then when they dont need them anymore.
RETN solved that by limiting number of rules customer can install.



Smart network operators tend to do quite a bit of lab testing,
prototyping, PoCs, et. al. against the very specific combinations of
platforms/linecards/ASICs/OSes/trains/revisions before generally
deploying new features and functionality; this helps ameliorate many
concerns.
Definitely, and i know some hosting operators who provide Flowspec 
functionality
different way - over their own web interface/API. This way they can do 
unit tests,

and do additional verifications.

But if there is direct BGP, things like 
https://dyn.com/blog/longer-is-not-better/
might happen, if customer is using some exotic, "nightly-build" BGP 
implementation.

Re: FlowSpec

[Roland Dobbins]

On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote:


In general operators don't like flowspec


Its increasing popularity tens to belie this assertion.

Yes, you're right that avoiding overflowing the TCAM is very important.  
But as Rich notes, a growing number of operators are in fact using 
flowspec within their own networks, when it's appropriate.


Smart network operators tend to do quite a bit of lab testing, 
prototyping, PoCs, et. al. against the very specific combinations of 
platforms/linecards/ASICs/OSes/trains/revisions before generally 
deploying new features and functionality; this helps ameliorate many 
concerns.


Also, don't forget about S/RTBH.  It's generally confined to within an 
operator's own span of administrative control for some of the same 
reasons as flowspec (not generally TCAM, per se, but concerns about 
giving Customer A the ability to interfere with Customer B's traffic, 
and the difficulty of implementing such constraints).  It can be an 
option worth exploring, in many circumstances.



Roland Dobbins 

Re: FlowSpec

[Denys Fedoryshchenko]

On 2020-04-23 18:13, Colton Conor wrote:

Do any of the large transit providers support FlowSpec to transit
customers / other carriers, or is that not a thing since they want to
sell DDoS protection services? FlowSpec sounds much better than RTBH
(remotely triggered blackhole), but I am not sure if  FlowSpec is
widely implemented. I see the large router manufacturers support it.


RETN

They have extended blackholing, and FlowSpec, sure its all have costs.
I'm using both services from them and quite satisfied.

In general operators don't like flowspec, because it is not easy to 
implement it right,

there is bugs and most important its "eating" TCAM.
For example: 
https://blog.cloudflare.com/todays-outage-post-mortem-82515/

Re: FlowSpec

[Denys Fedoryshchenko]

On 2020-04-23 18:13, Colton Conor wrote:

Do any of the large transit providers support FlowSpec to transit
customers / other carriers, or is that not a thing since they want to
sell DDoS protection services? FlowSpec sounds much better than RTBH
(remotely triggered blackhole), but I am not sure if  FlowSpec is
widely implemented. I see the large router manufacturers support it.

RETN considered Tier-2?
They offer it, but it is more expensive than

Re: FlowSpec

[Compton, Rich A]

Hi Colton,
It is fairly common to use flowspec internally at an ISP for mitigation of DDoS 
attacks.  eBGP flowspec is not very common though.  I know of only a couple of 
ISPs that allow flowspec rules to be advertised by their customers.  The 
biggest issue with this is that other providers are very hesitant to allow an 
external party to reach into their routers and modify the configuration (add a 
flowspec rule).  I (with others at my company) had attempted to work on this to 
provide a validation mechanism that would be performed on the advertised rules 
before adding them to the router.  We didn’t see much interest at that time on 
this.  https://www.youtube.com/watch?v=rKEz8mXcC7o
From conversations I have had with a couple of large ISPs recently it seems 
like there is an increased interest in this topic.
Here is a document on flowspec best practices that I worked on for M3AAWG that 
may be of interest: 
https://www.m3aawg.org/sites/default/files/m3aawg-flowspec-bp-2019-02.pdf

-Rich

From: NANOG Email List  on behalf of Colton Conor 

Date: Thursday, April 23, 2020 at 9:15 AM
To: NANOG list 
Subject: FlowSpec

Do any of the large transit providers support FlowSpec to transit customers / 
other carriers, or is that not a thing since they want to sell DDoS protection 
services? FlowSpec sounds much better than RTBH (remotely triggered blackhole), 
but I am not sure if  FlowSpec is widely implemented. I see the large router 
manufacturers support it.





E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: FlowSpec Support

[Mike Hammett]

I read that discussion (and several others going back about two or three years) 
before I posted this. 

As an occasional OP on here, I've noticed I get a lot of off-list responses so 
I obviously wouldn't have seen any of those from other people's threads. 

I didn't take that observation away from that thread, but maybe I'm dense. ;-) 
I know it was suggested that they wanted to bill for that sued capacity, but 
that was debunked. I know DDoS services were mentioned, but I didn't see a 
clear line drawn to that's why it isn't happening... nor confirmed. 

Also, what's big? Listed on the Baker's Dozen? Wide-spread POPs on six 
continents? Showing up on 50 IXPs? 1k IPv4 adjacencies? 

A medium sized network that does FlowSpec could be vastly more useful to you 
than a large network that doesn't. 





- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Josh Reynolds" <j...@kyneticwifi.com> 
To: "Mike Hammett" <na...@ics-il.net> 
Cc: "NANOG" <nanog@nanog.org> 
Sent: Saturday, May 28, 2016 5:41:38 PM 
Subject: Re: FlowSpec Support 


There was just a recent discussion about this. 
None of the big upstreams support it because they are all too busy selling 
their own DDoS mitigation services :) 
On May 28, 2016 5:38 PM, "Mike Hammett" < na...@ics-il.net > wrote: 


I know support (from customers) is limited among networks. I know it isn't on 
all hardware, but does appear to be on at least a couple platforms from the 
major router vendors. It is supported on an increasing number of DDoS 
appliances and software packages. 

What all networks support receiving BGP FlowSpec information from customers and 
acting upon it? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

Re: FlowSpec Support

[Josh Reynolds]

There was just a recent discussion about this.

None of the big upstreams support it because they are all too busy selling
their own DDoS mitigation services :)
On May 28, 2016 5:38 PM, "Mike Hammett"  wrote:

> I know support (from customers) is limited among networks. I know it isn't
> on all hardware, but does appear to be on at least a couple platforms from
> the major router vendors. It is supported on an increasing number of DDoS
> appliances and software packages.
>
> What all networks support receiving BGP FlowSpec information from
> customers and acting upon it?
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>