ACLs

[Emir Arslanagic <emir@cw.net>]

Hi all,

Regarding ACLs, it is absolutely must for the backbone equipment to be able
to filter passing through traffic in line speed, traffic to the box it-self
is little bit less strict but that is why we have rate limiting and QoS.

BTW many vendors do that this days in ASICS any way, it is not that
difficult.

This could be described with two stamens:
- Network equipment must provide a means of allowing and denying data flow
based on a
security policy.

- Network equipment must provide a means of segregating data flow between
networks, which
does not share same security paradigm.

Thanks,

--Emir
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Emir Arslanagic, CISSP
Cable and Wireless
Director of Network Security
Engineering and Infrastructure
Desk:   +49 89 9269 9115
Mobile: +49 172 898 6797
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com]On Behalf Of Neal
> Ziring
> Sent: Tuesday, July 22, 2003 4:03 PM
> Cc: opsec@ops.ietf.org
> Subject: Re: Ability to withstand well known attacks
>
>
> Dan and everybody,
>













> >
> > ACLs often have undesirable and significantly negative
> performance impact.
> >
>
> Well, according to one of the other rules in the
> -00 draft, ACLs shouldn't have any performance
> impact.  In some respects, I think some of the
> requirements that give both functional and
> performance criteria may also be difficult for
> some vendors to satisfy.  (Also, what consistitutes
> 'no impact'?   If I have a 1000-rule ACL, and it
> imposes a 3% throughput penalty, is that good enough?
> How about 200 rules and 5%?   There's no free lunch -
> on a fast enough link, I suspect some performance
> impact is inevitable for complex ACLs.)
>
> Also, I'm worried about the definition of 'known
> vulnerabilities' in the requirement.  Known to whom?
> How long do they have to be known.  I agree with the
> spirit of the requirement, but I just can't think of
> any good way to express it that will be objectively
> testable (same for 'no impact on performance').
>
> BTW, I very much enjoyed Chris's description of
> hitting Cisco devices with Nessus.
>
> ...nz
>
>
>