Re: Ability to withstand well known attacks

[ericb@digitaljunkyard.net]

 "nz" == Neal Ziring <nziring@thecouch.ncsc.mil> writes:

nz> Dan and everybody,
>> ACLs often have undesirable and significantly negative performance
>> impact.

This is a historical fact, and not state of the art.  It's certainly
not BCP.

nz> Well, according to one of the other rules in the
nz> -00 draft, ACLs shouldn't have any performance
nz> impact.  In some respects, I think some of the
nz> requirements that give both functional and
nz> performance criteria may also be difficult for
nz> some vendors to satisfy.  (Also, what consistitutes
nz> 'no impact'?   If I have a 1000-rule ACL, and it
nz> imposes a 3% throughput penalty, is that good enough?
nz> How about 200 rules and 5%?   There's no free lunch -
nz> on a fast enough link, I suspect some performance
nz> impact is inevitable for complex ACLs.)

Again, I hold up the example of Juniper.  Or Cloudshield.  They have 0
latency ACLs, in effect.  They are implemented in ASICs, perform
regardless of ACL length (seriously, we had a 1500 line Juniper
filter, no additional latency), and Just Work.  So not every vendor
can accomplish this this year.  But every vendor that makes it a
design goal will have hardware under test within 18 months that does.

The old ways don't work.  There are new ways.  Adopt them.

You scale up your filtering abilities as you scale up your bandwidth.
If this is a design goal, then it will be met.  If you try to retrofit
it to existing ASICs, then you are sunk.

Anyway, you have to differentiate TO vs. THROUGH.  Filtering THROUGH a
device is nice, but you HAVE to filter TO the device.  This is a very
different job, and is much more attainable.

nz> Also, I'm worried about the definition of 'known
nz> vulnerabilities' in the requirement.  Known to whom?

George has a first cut list of who qualifies as "well known".  Suggest
edits to that list.  I think CERT/CVE/BugTraq covers most of it.

Most importantly, known to miscreants, but that's much harder to
quantify.  I think the list above is a subset of the miscreant sploit
list, so it's all of concern to us.

nz> How long do they have to be known.  I agree with the
nz> spirit of the requirement, but I just can't think of
nz> any good way to express it that will be objectively
nz> testable (same for 'no impact on performance').

We can agree on some compromise length of "known".  

As for objectively testing, you run every sploit that you get from the
known list, and the box keeps ticking, or the box falls over.  Every
sploit comes with sample code, sometimes multiple versions.  Try it
out. If a new version comes to light, try it too.  Eventually, you
will have a library of exploits.  Try them all against every device
you either release as a vendor, or buy as a customer.  This SHOULD be
BCP.

ericb