nanog mailing list archives
Re: DDOS, IDS, RTBH, and Rate limiting
From: Denys Fedoryshchenko <denys () visp net lb>
Date: Fri, 21 Nov 2014 16:42:40 +0200
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.
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.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.
Use case of fastnetmon is not largest networks. Sampled netflow is useless for per-traffic billing purpose for example.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.
While i can pay $1500 for a server, and get netflow and ~3second BGP blackholing with fastnetmon.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.
In hosting case mirroring usually done for uplink port, but i have to agree, it might be a problem.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.
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.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).
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 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'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'.
So much arrogance. But on something i have to agree, again, it is perfect idea to stop this useless flamewar.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.
--- Best regards, Denys
Current thread:
- Re: DDOS, IDS, RTBH, and Rate limiting, (continued)
- Re: DDOS, IDS, RTBH, and Rate limiting Denys Fedoryshchenko (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Roland Dobbins (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Robert Duffy (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Roland Dobbins (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Tim Jackson (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Robert Duffy (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Paul S. (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Roland Dobbins (Nov 20)
- Re: DDOS, IDS, RTBH, and Rate limiting Denys Fedoryshchenko (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Roland Dobbins (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Denys Fedoryshchenko (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Denys Fedoryshchenko (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Peter Phaal (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Denys Fedoryshchenko (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Tim Jackson (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Denys Fedoryshchenko (Nov 21)
- Re: DDOS, IDS, RTBH, and Rate limiting Denys Fedoryshchenko (Nov 22)