DDOS, IDS, RTBH, and Rate limiting

Fri Nov 21 14:42:40 UTC 2014

On 2014-11-21 14:50, Roland Dobbins wrote:
> On 21 Nov 2014, at 15:17, Denys Fedoryshchenko wrote:
> 
>> Word stateful has nothing common with stateful firewall.Stateful 
>> protocol. "a protocol which requires keeping of the internal state on 
>> the server is known as a stateful protocol."
> 
> Correct - and NetFlow is not stateful, by this definition.
Not stateful, if you pick on "server" word.
To be able to make bytes/packets accounting for a flow, you need to keep 
this specific flow previous state. To be able to differentiate between 
flows with same src/dst ip+ports (if one is ended, next is started with 
same data) you need to track it's state, again. And just to keep track 
of _flows_ in packet switched network you need states. Surprising lack 
of knowledge.

> 
>> And sure unidirectional/bidirectional is totally unrelated.
> 
> On the contrary, it is quite relevant.
> 
>> Cisco 65xx (yes, they are obsolete, but they run stuff wirespeed)
> 
> They are not obsolete - they perform very well with Sup2T and
> EARL8-based linecards.
Seems yes, i'm wrong on that point, i was not successful to run netflow 
reliable way , but it was before CSCul90377 and CSCui17732 fixed.

> 
>> Others, for example Juniper, are using sampling (read - missing data),
> 
> The largest networks in the world use sampled NetFlow every hour of
> every day for many purposes, including DDoS
> detection/classification/traceback.  It works quite well for all those
> purposes.
Use case of fastnetmon is not largest networks. Sampled netflow is 
useless for per-traffic billing purpose for example.

> 
>> just to not overflow resources, and has various limitations, such as 
>> RE-DPC communication pps limit, licensing limit.
>> For example MS-DPC is pretty good one, few million flows in hardware, 
>> 7-8Gbps of traffic, and... cost $120000.
> 
> You get what you pay for.
While i can pay $1500 for a server, and get netflow and ~3second BGP 
blackholing with fastnetmon.

> 
>> But still they can run fine mirroring, and fastnetmon will do it's 
>> job.
> 
> On the contrary - SPAN nee port mirroring cuts into the
> frames-per-second budget of linecards, as the traffic is in essence
> being duplicated.  It is not 'free', and it has a profound impact on
> the the switch's data-plane traffic forwarding capacity.
> 
> Unlike NetFlow.
In hosting case mirroring usually done for uplink port, but i have to 
agree, it might be a problem.

> Yes, it does - they are far less popular that NetFlow, because they do
> not scale on networks of any size, nor do they provide traceback
> (given your lack of comments on traceback elsewhere in this thread, it
> appears that you aren't familiar with this concept).
> You make my point very well, thank you.  There is overwhelming
> evidence that NetFlow and similar forms of flow telemetry scale well
> and provide real, measurable, actionable operational value on networks
> of all types and sizes.  The reason for the popularity of flow
> telemetry is that it is low-opex (no probes to deply); low-capex (no
> probes to deploy); scales to tb/sec speeds; is practicable for large
> networks (no probes to deploy); provides instantaneous traceback
> (probes can't do this); and provides statistics on dropped traffic
> (probes can't do this, either).
And again and again we are going to tb/s. I don't need TB/s, i dont need 
traceback,nor on relatively small ISP nor on VDS provider i dont need 
all that above. I just need inexpensive way to block attacked ip and/or 
announce it from different location within minimal timeframe, to 
minimize impact on other customers.
You might be highly professional with large scale operators, but small 
guys needs and capabilities are very different.
I had developed tool similar to fastnetmon for almost same purpose, 
detecting attacks and switching affected network by BGP to "protected" 
backbone. After calculating "OPEX/CAPEX", capable server turned to be 
much cheaper alternative in short and long term than buying netflow 
capable hardware (and support for it) just for netflow purposes, and 
buying hardware for netflow collector.
Let's talk numbers.
My case is small hosting, 4G, C4948-10G, one 10G uplink, one 10G port is 
free. Switch is not capable to run sFlow or Netflow.
Decent server is available already, since it is hosting company, so the 
only expenses are 10G 82599 card, which is around $500. Even in case 
server is not available, based on data from fastnetmon author still 
total cost is within $1500. Deployment time - hours from installing 
hardware, without distrupting existing traffic.
"Major" expenses - tuning server according author recommendations, and 
writing shell script that will send to 4948 command to blackhope IP. For 
qualified sysadmin it is 2 hours of work, and $500 max as a "labor" 
cost. Thats it. What can be cheaper than $2000 in this case? I guess i 
wont get answer.

> I'm uninterested in selling anyone anything.  What I'm interested in
> doing is correcting the misinformation you are promulgating regarding
> the utility of flow telemetry coupled with open-source flow analysis
> systems.  There has been no mention of any commercial systems or
> products in my half of this 'conversation'.
I didn't meant you at all, but i meant when i'm hearing OPEX/CAPEX, 
often it is
not real detailed calculations, but some very well unrealistic mangled 
numbers,
that surprisingly looks for good marketed product, and bad for competing 
products.

> I am going to stop replying to your trolling, because you obviously do
> not have the requisite operational experience and depth/breadth of
> knowledge to even try to plausibly support your demonstrably-incorrect
> assertions.  One can only hope that such a potentially useful tool as
> FastNetMon isn't tarnished in the view of those who have read this
> thread due to such uninformed, erroneous misadvocacy.
So much arrogance. But on something i have to agree, again, it is 
perfect idea to stop this useless flamewar.

---
Best regards,
Denys