RFC 3871           Operational Security Requirements      September 2004

2.7.6.  Ability to Specify Filter Actions

   Requirement.

      The device MUST provide a mechanism to allow the specification of

      the action to be taken when a filter rule matches.  Actions MUST

      include "permit" (allow the traffic), "reject" (drop with

      appropriate notification to sender), and "drop" (drop with no

      notification to sender).  Also see Section 2.7.7 and Section 2.9

   Justification.

      This capability is essential to the use of filters to enforce

      policy.

   Examples.

      Assume that you have a small DMZ network connected to the

      Internet.  You want to allow management using SSH coming from your

      corporate office.  In this case, you might "permit" all traffic to

      port 22 in the DMZ from your corporate network, "rejecting" all

      others.  Port 22 traffic from the corporate network is allowed

      through.  Port 22 traffic from all other addresses results in an

      ICMP message to the sender.  For those who are slightly more

      paranoid, you might choose to "drop" instead of "reject" traffic

      from unauthorized addresses, with the result being that *nothing*

      is sent back to the source.

   Warnings.

      While silently dropping traffic without sending notification may

      be the correct action in security terms, consideration should be

      given to operational implications.  See [RFC3360] for

      consideration of potential problems caused by sending

      inappropriate TCP Resets.

2.7.7.  Ability to Log Filter Actions

   Requirement.

      It MUST be possible to log all filter actions.  The logging

      capability MUST be able to capture at least the following data:

      *  permit/deny/drop status,

      *  source and destination IP address,

      *  source and destination ports (if applicable to the protocol),

Jones                        Informational                     [Page 40]