In message <[EMAIL PROTECTED]>, Luigi Rizzo writes:
>> I think the general syntax would be if you could say "for one of my
>> own IP#" that would be very powerful:
>>
>> add allow tcp from any to me 22
>> add deny tcp from any to not me 22
>
>the 'me' thing is relatively simple to impl
> I think the general syntax would be if you could say "for one of my
> own IP#" that would be very powerful:
>
> add allow tcp from any to me 22
> add deny tcp from any to not me 22
the 'me' thing is relatively simple to implement, it suffices to scan
the list of IP associated with
In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
:
>handle packets as they traverse ip_forward? I know Poul's or someone
>elses drawing of the H style firewall could be implemented if we had
>a way to apply rules as they traverse the ip_forward code and an easy
>way to expand your scheme
> > clnsrv "allow" tcp "" 43 "${tcp_nicname_c}""${tcp_nicname_s}"
> > clnsrv "allow" tcp "" 53 "${tcp_domain_c}" "${tcp_domain_s}"
> ...
> > ... on and on up to the 1024 and then a few splattered after that.
>
> looks like the search path can become extremely long!.
Yes,
> clnsrv "allow" tcp "" 43 "${tcp_nicname_c}""${tcp_nicname_s}"
> clnsrv "allow" tcp "" 53 "${tcp_domain_c}" "${tcp_domain_s}"
...
> ... on and on up to the 1024 and then a few splattered after that.
looks like the search path can become extremely long!.
> The single larg
> > No, this is completly reasonable now that I understand what it is your
> > proposing. Even the memory footprint is minimal if pointers to the
> > actual rules is all we store in the per interface list, my largest set
> > duplicated over 8 interfaces would only be 3200 rules. Stored as
>
> I
> No, this is completly reasonable now that I understand what it is your
> proposing. Even the memory footprint is minimal if pointers to the
> actual rules is all we store in the per interface list, my largest set
> duplicated over 8 interfaces would only be 3200 rules. Stored as
I'd be curiou
> No, this is completly reasonable now that I understand what it is your
> proposing. Even the memory footprint is minimal if pointers to the
> actual rules is all we store in the per interface list, my largest set
> duplicated over 8 interfaces would only be 3200 rules. Stored as
> pointers to
...
>
>
> Yes I agree, I love ipfw functionality. You were asking for ideas on how to
> optimize ipfw. What I suggested is that in its INTERNAL representation of
> the rules, ipfw could split the rules on a per interface/direction basis.
> This means that you will not look at the rules that are
(don't you love all that quoting...)
> > > > I agree that having a `switch' type of rule for selecting interfaces
> > > > would be a reasonable gain of efficiency (but then again.. how
> > > > many interfaces is one using!)
> > >
> > > It doesn't matter, it has to do the lookup on a per-interface
> > > I agree that having a `switch' type of rule for selecting interfaces
> > > would be a reasonable gain of efficiency (but then again.. how
> > > many interfaces is one using!)
> >
> > It doesn't matter, it has to do the lookup on a per-interface basis. On
> > my firewall box, I have 11 int
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi,
>
> > > One of the things I would do to optimize ipfw is:
> > > - instead of keeping one list with all the rules, split the list (the
> > > internal one) by interface and by direction (one list for ed1
> incoming,
> > > one list fo
Something else I would like to see someday [assuming I haven't missed it
and it already exists], is TOS optimizations in much the same way that
Linux's ipchains utility can optimize protocols such as nntp, telnet, etc.
Since the thread is entitled ipfw optimizations - I thought I would add my
t
On Fri, Jan 07, 2000 at 11:37:02AM -0700, Nate Williams wrote:
> > > One of the things I would do to optimize ipfw is:
> > > - instead of keeping one list with all the rules, split the list (the
> > > internal one) by interface and by direction (one list for ed1 incoming,
> > > one list for ed
Hi,
> > One of the things I would do to optimize ipfw is:
> > - instead of keeping one list with all the rules, split the list (the
> > internal one) by interface and by direction (one list for ed1
incoming,
> > one list for ed1 outgoing, etc.).
>
> I often do this manually in long rule sets
> In message <[EMAIL PROTECTED]>, Luigi Rizzo writes:
> >> One of the things I would do to optimize ipfw is:
> >> - instead of keeping one list with all the rules, split the list (the
> >> internal one) by interface and by direction (one list for ed1 incoming,
> >> one list for ed1 outgoing, e
> > One of the things I would do to optimize ipfw is:
> > - instead of keeping one list with all the rules, split the list (the
> > internal one) by interface and by direction (one list for ed1 incoming,
> > one list for ed1 outgoing, etc.).
>
> one skipto rule is enough to switch between two
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi Luigi,
>
>
> > i am looking at (minor) optimizations of the ipfw code in order to reduce
> > the running time in the common cases.
> >
> > I have a few ideas (mostly along the lines of optimizing for the
> > most commonly-used rules).
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes:
>> I still think we should split the current "one huge list of rules"
>> into several lists:
>
>> Two lists per interface:
>> one list of rules for inbound packets
>> one list of rules for outbound packets
>>
>>
> I still think we should split the current "one huge list of rules"
> into several lists:
> Two lists per interface:
> one list of rules for inbound packets
> one list of rules for outbound packets
>
> Two lists for the IP stack:
> one list
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes:
>> One of the things I would do to optimize ipfw is:
>> - instead of keeping one list with all the rules, split the list (the
>> internal one) by interface and by direction (one list for ed1 incoming,
>> one list for ed1 outgoing, etc.).
>
>o
> One of the things I would do to optimize ipfw is:
> - instead of keeping one list with all the rules, split the list (the
> internal one) by interface and by direction (one list for ed1 incoming,
> one list for ed1 outgoing, etc.).
one skipto rule is enough to switch between two rulesets de
Hi Luigi,
> i am looking at (minor) optimizations of the ipfw code in order to reduce
> the running time in the common cases.
>
> I have a few ideas (mostly along the lines of optimizing for the
> most commonly-used rules). An obvious candidate is the 'match all'
> rule (all from any to any), bu
23 matches
Mail list logo
