> > > > > Yes, when there are better solutions to the problem at hand.
> > > >
> > > > Please enlighten me.
> > >
> > > Intercept and inspect IRC packets. If they join a botnet channel, turn on
> > > a flag in the user's account. Place them in a garden (no IRC, no nothing,
> > > except McAfee or your favorite AV/patch set).
> > Pleaes do this at 1Gbps, really 2Gbps today and 20gbps shortly, in a cost
> > effective manner.
> Mmmmm... okay. Would you like solution #1 or solution #2? (You can pay
> for solutions above and beyond that)
I tried to be nice and non-sarcastic. I outlined requirements from a real
network security professional on a large transit IP network. You
completely glossed over most of it and assumed a host of things that
weren't in the requirements. I'm sorry that i didn't get my point across
to you, please have a nice day.
As far as "Please enlighten me" followed by "Please do this at 1Gbps,
really 2Gbps today and 20gbps shortly, in a cost effective manner" goes,
I don't consider that to be non-sarcastic. I consider it to be either
very rude, or perhaps a challenge. I attempted to reply in an
approximately equivalent tone.
But, now, what exactly did I gloss over? And what things did I assume
that weren't in the requirements?
It's already been demonstrated that it doesn't need to handle 1Gbps,
2Gbps, or 20Gbps, so those "requirements" are irrelevant.
You then said:
Please also do this on encrypted control channels or
channels not 'irc', also please stay 'cost effective'.
But I'm not about to be trapped into building a solution that does WAY
MORE than what Cox was trying to do. That it was a requirement from a
"real network security professional" is not relevant, as we're discussing
ways to accomplish what Cox was trying, without the related breakage.
You further said:
please do NOT require in-line placement unless you can do complete
end-to-end telco-level testing (loops, bit pattern testing, etc),
To which I said: "Ok.", because my solution meets that measure. It does
not require in-line placement, condition met.
You went on to say:
it'd be a good idea to have a sensible management interface for these
devices (serial port 9600 8n1 at least along with a scriptable
And again I said: "Ok.", because my solution can be built on a FreeBSD
or Linux box, and as a result, you gain those features too. Condition
And finally, you say:
Looking at DPI (which is required for your solution to work) you are still
talking about paying about 500k/edge-device for a carrier-grade DPI
solution that can reliably do +2gbps line-rate inspection and actions.
And I finally said: "Yeah, I see that. Not."
Because I don't fundamentally believe that you need to do deep packet
inspection of all packets in order to accomplish what Cox was doing.
So what exactly did I assume that wasn't in the requirements (and by
that, I mean the requirements to do what Cox was attempting to do, not
the requirements of some random "real network security professional")?
If you really think I glossed over something that was important, then
by all means, point it out and call me on it. Don't just say HAND.
Part of network engineering is being a little bit clever. Brute force
is great when you really need to move 20Gbps of traffic. Any idiot
can buy big iron to move traffic. However, putting your face in front
of the firehose is a bad way to take a sip of water. With that in mind,
I will once again point out that doing the equivalent what Cox was
trying to do did not /require/ the ability to do deep packet inspection
at 20 gigabits per second, and as a result, I'm exercising my option of
being a clever network engineer, rather than one who simply throws
money and big iron at the problem.
You asked for enlightenment.