"Paul D. Robertson" wrote:
>
>
> Firewalls aren't the optimum solution for bandwidth control, and it's
> fairly easy to do QoS to a gateway using internal network equipment, or
> pacing using older multiplexing technologies. Using a firewall to
> artificially limit bandwidth is an interesting application of a firewall,
> but it's not really the best way to do it. In fact, it's a lot easier to
> rip into something like IPFilter and add latency, or do policy based
> routing under Linux than it is to reliably count on most firewalls[1] to
> do bandwidth management.
But can these tools control usage based on users (strongly authenticated
by signed challenges) in a dynamic IP environment? That's what our
clients often want. Not so much traffic shaping as being able to do
internal billing and accounting based on bandwidth usage, and to be able
to do this within a dynamic IP environment.
> > That's not to say that current products do these things. But as the
> > attacks evolve and become more commonplace, so will the defenses.
>
> If we're constantly playing catch-up as an industry it's a bad thing[tm].
Well, obviously it's good to try to anticipate weaknesses and address
them before they get exploited. But for something like applying random
perturbations to image files to attempt to defeat steganography, the
cost involved (both in development and in the probable performance hit)
make it unlikely that such a technique will be deployed until such time
as customers ask for it - and most customers base what they ask for on
whatever the latest publicised vulnerabilities and attacks are. Some
will be sufficiently well-informed that they may anticipate needing a
feature like this, but most aren't.
The fact is that most people know very little when it comes to security,
and so the perceived value of features is tied very much to the mileage
that marketeers and the press can make of them. The recent Love Bug
furore is going to make customers far more likely to demand viruswalling
with their firewall than they did before. Those vendors who don't
support that will be playing catch up. On the other hand, it can be hard
to make much marketing mileage out of features that are anticipatory -
if there is no publicity about something being a common exploit, then
most people don't care.
Recently here in South Africa, some large pieces of space debris (I
think they were parts of a Jupiter rocket?) can crashing down to ground.
Now, if I had a car that could withstand having a piece of a Jupiter
rocket fall on it, prior to the actual event people would have laughed
at me. After the event, some people might think that this is a desirable
feature. If any of the rocket pieces had actually landed on a car and
killed the occupants, then I might even be able to make some good
marketing mileage about the fact that my car would have saved them. And
some other car manufacturers may play catch up.
It's a frivolous example, I know. The point is, the cost-benefit
analysis of security features is heaviliy skewed by what the perceived
threats are. Defending against an attack that the masses know about is a
much easier thing to market than defending against an attack that
no-one's ever heard of. So as long as companies are driven by sales and
marketing, playing catch-up is going to be commonplace. I agree (from an
engineering perspective) that that's a Bad Thing.
> Sure you can, you can count on flames on Firewalls :)
Ah, but I could have been saved by a DoS on the list. So even that is
not 100% certain ;-)
This discussion has got really off-topic, and being in different time
zones has overextended its useful life, so I'll shut up now.
--
Dr Graham Wheeler E-mail: [EMAIL PROTECTED]
Director, Research and Development WWW: http://www.cequrux.com
CEQURUX Technologies Phone: +27(21)423-6065
Firewalls/VPN Specialists Fax: +27(21)424-3656
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
