>Which is immaterial to the subsequent discussion of technical features
>which ensued.
I made my point specifically because the marketing aspects of the
discussion were not, IMO, fully discussed. Much of Fred's document
attempts to persuade the reader about a particular technology based on
marketing information, not solely on technology (quoting IDC for
example). Denver Systems did this and everyone railed at them, but
because Fred is Fred we should just bow our heads and forget marketing
rhetoric? I didn't think so, hence my comments.
FWIW, I did send Fred, privately, my comments on how I thought his
market-speak was ill-stated. An attempt to appease the trigger-happy
flamers from repeating their inferno on me. Once Fred's replied, I'll
happily restate them in public (see that's the difference that Fred
deserves vs. Denver Systems).
>Which doesn't mean that a number of people haven't done such tests. I
>think your predicates may hold true for 'most customers', but that
>different predicates, and resultant answers should apply for security
>professionals. Just because you, or your customers, or your company
>(genericly, not personally) can't do valid tests doesn't make valid
tests
>any less relevent.
I, my customers, and my company can do valid tests. While your
parenthetic disclaimer "(generically, not personally)" may be have been
enough in your mind, the wording comes off sounding too much like a
personal reproach for my liking.
I never said that the tests weren't valid, but no test results exist in
the public realm that can reliably be used by anyone who chooses not to
do the tests themselves (or cannot). Therefore no valid test results
exist for the vast majority of customers wishing to implement Firewall
solutions, hence my point that the marketing of the products/technology
is a very large factor in the decision process.
An example of this is any test done in any magazine/publication, since
the test criteria is not specific to the person reading the results, the
results come down to being marketing material rather than valid
technical data. Who cares, for example, how much traffic can be pumped
through a FW if the traffic is not representative of your own traffic?
- What effect does, say, doubling the amount of SMTP traffic and halving
the amount of HTTP traffic (in a given test mix) have on the overall
performance of FWs? Obviously such changes are likely to have more
impact on AGs than on SPFs, but who can say for sure?
- What about encrypted traffic, how does that affect the performance of
the various boxes, or more complex protocols like NBT or even FTP, do
both technologies handle them equally well, if not, what's the
difference?
- If I run each Proxy in a different user context, how much of a
performance hit do I see vs. using a single context for all Proxies?
- Does a FW-FW VPN create the same load as a Client-FW VPN?
The list goes on and on, and is very valid for all customers, but unless
they do the tests themselves any reported values are near worthless
(read: marketing information). Since much of the rhetoric that is thrown
around, both by the vendors and by the security professionals, is based
solely on their own tests/experience, or a few controlled tests done by
vendors, or generic tests done by publications, none of which that I've
seen can be reliably used by anyone whom the tests weren't designed for,
I put it to you that much of what "professionals" say about the
technology is based on what I call "marketing information".
FWIW, I would like to see protocol-by-protocol comparisons for security
gateways. They should present a list of threats tested, as well as the
performance during those tests. They should be done unencrypted and
encrypted. Then a rough mix of traffic can be thrown at the boxes to
give an idea of overhead of mixing protocols. A comprehensive table like
this would, IMO, put an end to much of the discussion. NCSA/DataComms,
can you here me??
[Paul's description of his personal abilities snipped]
>While I'm aware of the marketing issues, I
>don't think they are relevent to the technical discussion which this
>bloomed into. I don't known why we're vectoring back to the marketing
>stuff here, since the first couple of notes pretty much covered that
ground.
The first sentence explains the second. You don't think marketing is
relevant to the technical discussion, hence you don't understand why I
made my points about marketing being important. Rather than trying to
blow off my opinions, why not instead ask me why I think their relevant
next time, maybe you'll learn something (boy do I wish I had a "clue
hammer")...;-]
Cheers,
Russ
Follow-Ups:
|
|
