I think you're underestimating the limit to how fast DPI is or can get. The computations aren't complicated and like many kinds of algorithms you can trade space with time.
This statement might be correct (although I've never seen any evidence to support it), but it's still misleading because "forward the packet" is always going to require fewer resources than "read the packet, parse it using this set of algos, use the parse results to search your DB of shit you want to fuck with, optionally fuck with the packet, optionally forward the packet". An exception to this would be if you have big iron on the edge that protects resource-poor interior nodes. This situation is unavoidable sometimes (DDOS), but it's not what anyone should aim for.
They don't necessarily need to do anything with the packet then -- they could always pass a copy to cold storage, and then crunch the bits at their leisure in a massive data center.
A) this is probably true to an extent.
B) slurping everything to disk is impractical, and no one has that much storage, so you're back to parsing and deciding at the boundary. This "leisure" time doesn't ever happen when you save everything all the time.
C) this point seems to contradict the various claims of reasonable network maintenance I've seen; if it's trash you want to drop, you want to drop it on the floor not on your disk. If you're keeping actual traffic rather than just summaries of traffic, you're not doing reasonable network maintenance.
I think you're underestimating how much traffic can be out there.
DPI requires decoding application-layer protocols. This requires many layers of decoding. That's all well and good for one client (feature phones happily load web pages, after all), but to do it inline at the router means the router needs to be as powerful as the sum of all of the networking hardware of the hosts it routes to.
Source: at my last job, we were working on fixes for security holes that could cost billions of dollars of damages per incident, and the fixes were solvable in software, but we couldn't persuade customers of the value of buying beefy enough network equipment to actual block the attacks. Mind you, I didn't run any numbers myself on the cost of the hardware; that's just what my colleagues said.
Oh, it's obviously possible. Reading a little about Narus does not give me the impression that it's cost-effective, for any non-NSA sense of the word "cost". In any case, in my opinion our customers were not taking their problems very seriously, and their price sensitivity reflected that.
If you have any trustworthy source of ballpark pricing for a 10Gb/s DPI solution, Narus or otherwise, I'm curious. I'm talking BALLPARK here.
I looked up some of Narus's whitepapers, and what I'm seeing looks like Grade A Bullshit. That doesn't mean they ARE bullshit -- their whitepapers would look like this in either case. But I would like to point out that it is absolutely possible to build a company like this without actually delivering the goods, because many of your potential customers are largely incapable of understanding whether or not the goods have really been delivered.
ALSO, I guess I should remember that DPI for stopping malware, and DPI for spying on citizens, are really different things. When you're spying on citizens, 90% effectiveness is good enough. When you're trying to block malware (versus e.g. commited cyberterrorism), 90% is a little better than 0%, but not much, because your adversary can try many times and they only have to succeed once. So in that sense, the DPI being discussed here is a much easier problem than the DPI that we were trying to tackle.
well, i think you can look up the pricing for gateway nodes for cellular wireless equipment vendors (hspa/umts/lte/cdma etc.). my guess is that it should somewhere around 200-400k range. a sufficiently capable box can handle approx. 7 - 10m subscribers simultaneously doing data.
any cellular network that you send data on, already does this. standardization only levels the playing field.
