per-interface packet filters, design approach

From: Andre Oppermann (andre_at_freebsd.org)
Date: 12/14/04

  • Next message: Luigi Rizzo: "Re: per-interface packet filters [summary]"
    Date: Tue, 14 Dec 2004 15:03:27 +0100
    To: freebsd-net@freebsd.org
    
    

    Let's take a high level view of the issue at hand and the consider
    some alternative approaches to the situation.

    Current situation:

     a1. There is a need to have per-interface specific firewall rules.
     a2. We have multiple firewall packages which have multiple way to
         specify interface specific rules.
     a3. With large numbers of interface specific rules the rulesets get
         complex and hard to manage.
     a4. This seems to be mainly a problem with ipfw and it's skipto
         actions.

    Request:

     b1. Users request a less complicated way of doing interface specific
         firewall rules.

    Analysis:

     c1. This is primarily a USER interface/syntax/semantics issue.
     c2. The different user interface approaches of the different firewall
         packages we have require different changes to their USER interfaces
         to make it easier for per-interface rule sets.
     c3. The firewall packages we have can only deal with one global rule
         set per protocol family and direction currently. They can't be
         loaded multiple times and can't have multiple rule set heads (only
         one entry point).

    Implementation approaches:

     d1. The PFIL_HOOKS API has one hook per direction per protocol and
         passes the interface information to the firewall package.
     d2. Should the PFIL_HOOKS API be changed and be per interface instead
         of per protocol? All firewall packages need to be modified and
         we are no longer compatible with the PFIL_HOOKS API.
     d3. Should the interface specific rules sets be per firewall package
         in the way that best suits the package? No kernel API is changed.
     d4. What is the user interface syntax and semantics for each firewall
         package that someone wants to be modified? Provide examples for
         those you are interested in.
     d5. Should it be a replica of Cisco|Juniper approaches or can we do
         better in syntax or semantics? Think outside of the box.

    Lets continue the discussion from here.

    -- 
    Andre
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    

  • Next message: Luigi Rizzo: "Re: per-interface packet filters [summary]"

    Relevant Pages

    • Re: per-interface packet filters, design approach
      ... With large numbers of interface specific rules the rulesets get ... > to make it easier for per-interface rule sets. ... The firewall packages we have can only deal with one global rule ... Should the PFIL_HOOKS API be changed and be per interface instead ...
      (freebsd-net)
    • Re: CA to IBM TCP Conversion
      ... If a name is to be associated with a node and the node has multiple interfaces, necessarily the name, indirectly, is associated with the multiple IP addresses, each one of which is primarily associated with an interface. ... Also we need to assume he has multiple LPARs ready to benefit from the wandering dynamic VIPA. ... An OSA can be shared by multiple TCPIP stacks. ...
      (bit.listserv.ibm-main)
    • Re: Examples of good UI
      ... REQUIRE A USER INTERFACE. ... hit icons or menus, as in SolidWorks. ... For SolidWorks is there a Hidden Interface Element that has been ... become more of a part of the User Interface in a number of ways. ...
      (comp.cad.solidworks)
    • Re: [PATCH] ata: ahci: power off unused ports
      ... The user interface in this case, a module option, is ... create the same user interface in each driver, ... hotplug and power instead of forcing a generic policy on everyone. ...
      (Linux-Kernel)
    • Re: Examples of good UI
      ... REQUIRE A USER INTERFACE. ... For SolidWorks is there a Hidden Interface Element that has been ... become more of a part of the User Interface in a number of ways. ... using the wrong screen (1900 pixel laptop screens), ...
      (comp.cad.solidworks)