[OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs

["Fred Baker (fred)" <[e-mail]>]

I thought I might take a crack at a few comments on this draft.

First comment: I’d appreciate it if we had a framework for the discussion of this, RFC 6092, draft-hutton-rtcweb-nat-firewall-considerations, draft-jab-host-firewalls, draft-ietf-v6ops-balanced-ipv6-security, draft-vyncke-advanced-ipv6-security, and a long list of other drafts with the name “firewall” in them.

Second comment: I think this draft is not about an IPv6 firewall, and as currently structured is likely to take approximately forever to discuss, and will then be wrong. Let me throw out a thought experiment: consider REQ SPC-70. This is listed as an “IPv6” firewall feature, but it requires “stateful” association of ICMPv6 replies to TCP, UDP, and ICMPv6 sessions - it doesn’t mention IPv6, and apart from the ICMPv6 part, would be substantively the same if we were to suddenly decide to deploy CATNIP or TUBA. Why are these not a separate document that such a deployment could refer to? I can build that product on an enterprise scale if you can afford it, but you’re talking about some serious state in the network, far beyond what firewalls do today. You want to specify the user interface for a firewall? Care to say exactly which firewall you can buy today incorporates both the firewall features and the user interface, and what market that is targeted at?

I’m join to suggest that this be broken up into a number of separately-discussable documents, each of which defines a test target. If I build a product and claim that it firewalls IPv6, what are the requirements of that product? If I build a product (perhaps the same product) that claims to firewall TCP sessions, what are the requirements for that product? There are a variety of ways that user interfaces can be built, and they generally target different markets. What the IETF does NOT want to do is get in the way of vendor innovation in design of user interfaces. However, whatever UI a vendor provides, what are the requirements that it must address?

>    While there has been some work in the area of firewalls, concrete
>    requirements for IPv6 firewalls have never been specified in the RFC
>    series.

Except in RFC 6092.

> The more limited experience with the IPv6 protocols and the
>    more reduced number of firewalls that support IPv6 has made it rather
>    difficult to infer what are reasonable features to expect in an IPv6
>    firewall.  This has typically been a problem for network operators,
>    who typically have to produce a "Request for Proposal" from scratch
>    that describes such features.  This document specifies a set of
>    requirements for IPv6 firewalls, in order to establish some common-
>    ground in terms of what features can be expected in them.

> 2.  Introduction
> 
>    While the IETF has published a large number of documents discussing
>    IP and IPv6 packet filtering (see e.g. [RFC7126] and some documents
>    on the topic of IP firewalls (see e.g. [RFC2979] and [RFC3511]),
>    concrete requirements for IP firewalls have never been specified in
>    the RFC series.

Except in RFC 6092.

> When it comes to IPv4, a number of features have
>    become common over the years, and firewall requirements have somehow
>    become operational wisdom.  When it comes to IPv6 [RFC2460], the more
>    limited experience with the protocols, and the reduced variety of
>    IPv6 firewalls has made it rather difficult to specify what are
>    reasonable features to be expected of an IPv6 firewall.  This has
>    proven to be a problem for network operators (who have typically had
>    to produce a "Request for Proposal" from scratch), but also for
>    vendors (who lack a well defined set of requirements that can serve
>    as a roadmap for implementation).

I’m not sure that is actually true. IPv4 firewalls are far from standardized; they all supply some basic functions, such as being able to block traffic, but the mechanisms on which they operate differ a great deal. My company has at least two broad classes of firewall products, based on topological zones and the roles of actors, and somewhere in my head I think we have a third. Juniper, Checkpoint, Barracuda, and others have other technologies that are based on anomaly-based and signature-based intrusion detection, and other technologies. You can consider a proxy to be a firewall, in that it can observe sessions and prevent them. The features available in various firewalls differ quite a bit, and that is the basis on which those vendors compete.

And at first blush, I’ll bet the requirements for an IPv6 firewall are almost identical to those of an IPv4 firewall. Reason? The attacks are the same, and the security policies are the same. If a smurf can run on IPv4, it can run on IPv6. Amplification attacks, spoofed source address issues, and so on and so forth, are likely to be identical, because in a certain sense IPv6 is IPv4 with bigger addresses, and the transports and applications use the two interchangeably.

The one place that the IETF would *like* security policy to differ is that a to of security practitioners bought, hook line and sinker, the circa-1995 marketing that a NAT was a security technology; it’s not, it’s an address multiplexing technology, and produces a certain kind of firewall-like capability as an accidental side-effect, but a lot of corporate security policies star with “you put your NAT here”, and then stop.

That’s not to say that we shouldn’t document a set of requirements for a firewall. But let’s not be silly about it.

> 4.  General Security Features
> 
>    REQ GEN-5:
>       The firewall MUST include performance benchmarking documentation.
>       Such documentation MUST include information that reflects firewall
>       performance with respect to IPv6 packet, but also regarding how
>       IPv6 traffic may affect the performance of IPv4 traffic.  The
>       aforementioned documentation MUST be, at the very least,
>       conditionally-compliant with both [RFC3511] and [RFC5180] (that
>       is, it MUST support all "MUST" requirements in such documents, and
>       may also support the "SHOULD" requirements in such documents).
> 
>          NOTE: This is for operators to spot be able to identify cases
>          where a devices may under-perform in the presence of IPv6
>          traffic (see e.g. [FW-Benchmark]).  XXX: This note may be
>          removed before publication if deemed appropriate.

I’m OK with basic benchmark information, but, well, there’s lies, damn lies, and benchmarks. 

>    REQ GEN-10:
>       All features of the firewall MUST be able to be individually
>       configured (at least ON or OFF, with other configurable parameters
>       as applicable).  A well-documented default initial setting must be
>       provided for each feature.

>    REQ GEN-20:
>       MUST support basic Access Control Lists (ACLs).

Define a “basic” access list? 

>    REQ GEN-30:
>       MUST support stateless packet inspection and filtering at
>       transport layer.

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-40:
>       MUST support stateful packet inspection and filtering at transport
>       layer.

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-50:
>       SHOULD support full-proxy for the TCP [RFC0793] connections (the
>       handshake is validated on the firewall before reaching the target
>       system).
> 
>          Some products identify this feature with terms such as "TCP
>          Intercept and Limiting Embryonic Connections".

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-60:
>       MUST be able to enforce timeouts on protocol sessions based on the
>       upper-layer protocol (e.g. enforce a timeout on the FIN-WAIT state
>       for TCP connections, a timeout for DNS query/respose pair, etc.).
>       In general, it MUST have different timeout parameters and
>       thresholds to be used to prevent idle sessions from exhausting
>       resources on the device and/or the service that is defended.  For
>       sessions composed of multiple packets (such as TCP connections),
>       the exchange of valid packets MUST refresh the timers employed for
>       enforcing the aforementioned timeouts.
> 
>          NOTE: This is to avoid the known and buggy behavior where
>          firewalls enforce a maximum lifetime for the protocol session
>          (e.g. TCP connection) regardless of whether there is ongoing
>          exchange of legitimate packets for such session.

This also forces certain behaviors, such as TCP keep-alives, to be used, which means that host applications that don’t currently use them to be changed before they can be used in the context of this firewall.

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-70:
>       MUST be able to provide anti-spoofing features (e.g. uRPF ).

I’d actually suggest that this is general to routers. You might take a look at RFC 3704. An important behavior in uRPF is that it actually depend on the RIB rather than the FIB, and should have the ability to have external information added to it such as “I know this address is <there>, but it is not being advertised to me in routing (it is a static route or aggregated into some other route), so I can’t automagically know that.”

>    REQ GEN-80:
>       MUST be able to redirect specific traffic to a proxy server e.g.
>       for HTTP/S protocols.
> 
>          NOTE: "Redirection means that the firewall should be able to
>          divert the traffic to a proxy - i.e., take the traffic, send it
>          to an inspection engine, receive it back and forward it (all
>          this completely transparent to the users).

This can be complicated. if I am redirecting DNS to a local server, for example, I need the server to be able to accept a packet as “to it” regardless of its destination address, and respond as if it were that system. If it is http/https, I’d actually rather have this built into routing somehow - instead of all of the traffic going through the firewall to the proxy, and routing deliver it to the proxy in the first place.

>    REQ GEN-90:
>       MUST be able to detect and reject invalid source or destination
>       addresses (e.g. local-link addresses that try to traverse the
>       firewall) with a single policy.

Again, a general router requirement. Any router needs to be able to generate an ICMP Destination Unreachable for any of the seven valid codes if appropriate. That includes validating source address scope.

> 5.  IPv6-Specific Features
> 
>    REQ SPC-10:
>       MUST be able to filter ICMPv6 [RFC4443] traffic at a message type/
>       code granularity.  [RFC4890] MUST be employed for the default
>       filtering configuration.

ICMPv6 is not IPv6. This belongs in an ICMPv6-specific firewall specification. It’s OK to make a requirement of the IPv6 firewall specification that it also implement the ICMPv6 specification.

>    REQ SPC-20:
>       MUST be able to block packets containing any specified extension
>       header type (based on its Next Header value), on a specified
>       number of instances of a specified extension header type, and on a
>       specified overall number of IPv6 extension headers.
> 
>    REQ SPC-30:
>       MUST be able to block IPv6 packets that employ a Routing Header
>       both at the granularity of Extension Header Type (as required in
>       SPC-20) and Routing Header Type.

I’d actually generalize that. Any of the extension headers that can handle a sub-option (of which the Routing Header and Destination Header are examples) should be able to filter on the presence, absence, or content of the various sub-options.

>    REQ SPC-40:
>       SHOULD be able to drop packets based on IPv6 option types.

Is that the same as SPC-30?

>    REQ SPC-50:
>       MUST be able to detect IPv6 tunnels such as SIIT [RFC6145], 6to4
>       [RFC3056], 6in4 [RFC4213], ISATAP [RFC5214] and Teredo [RFC4380]
>       (please see [RFC7123], and MUST be able to selectively block or
>       allow them for specific sources, destinations, routes or
>       interfaces.

Why is this not “must implement an ACL that can permit or deny traffic based on any combination of source and destination prefixes or port numbers, or next header (e.g. protocol) values”?

>    REQ SPC-60:
>       MUST be able to validate IPv6 Neighbor Discovery [RFC4861] packets
>       (RS, RA, NS, NA, Redirect) according to
>       [I-D.ietf-opsec-ipv6-nd-security].

Why is this not a requirement of any IPv6 node? What makes it specific to a firewall?

>    REQ SPC-70:
>       MUST be able to statefully match ICMPv6 errors to TCP [RFC0793],
>       UDP [RFC0768], and ICMPv6 [RFC4443] communication instances (see
>       [RFC5927]).

So, it not only keeps source/destination pair state, as a NA(P)T might, but tracks send and acknowledge sequence numbers, last message sent (SYN vs data vs ack vs FIN/RST), and where the conversation is in its state machine. This precludes loa-sharing among firewalls, as the most recent message will by definition have passed one and not both.

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ SPC-80:
>       MUST be able to parse all defined extension headers according to
>       [RFC7045], and SHOULD filter packets containing IPv6 Extension
>       Headers as recommended in [draft-gont-opsec-ipv6-eh-filtering].

How does this differ from SPC-20?

>    REQ SPC-90:
>       MUST be able to find the upper-layer protocol in an IPv6 header
>       chain (see [RFC7112].

How does this differ from SPC-80?

>    REQ SPC-100:
>       SHOULD be able to normalize (rewrite) the following IPv6 header
>       fields on a per-interface basis:
> 
>       *  Hop Limit

DANGER! DANGER WILL ROBINSON! Do you *really* want to do that?

> 6.  VPN Security Requirements
> 
>    REQ VPN-10:
>       MUST implement IPsec-based [RFC4301] VPN technology.

What, precisely, does that mean? Does it mean “must implement ESP”? "must implement IPsec/UDP”? What types of crypto algorithms? Algorithms like DMVPN go quite a way beyond that; are you also looking at PKI solutions, VPN Routing, and the like?

>    REQ VPN-20:
>       MUST implement "hub-and-spoke" Dynamic Multipoint VPN-like
>       technology, allowing creation of dynamic-meshed VPN without having
>       to pre-configure all of possible tunnels.

“Must reverse-engineer Cisco proprietary technology” 
http://www.cisco.com/c/en/us/products/security/dynamic-multipoint-vpn-dmvpn/index.html

>    REQ VPN-30:
>       MUST implement SSL/TLS-based [SSL-VPNs] VPN technology.

Must fix Heartbleed?

>    REQ VPN-40:
>       MUST be able to use digital certificates, including CRL and OCSP
>       revocation checking methods, to mutually authenticate VPN peers.

Is that part of VPN-30?

>    REQ VPN-50:
>       MUST be able to disable or enable split-tunnelling feature on VPN
>       as required.

Not sure what you mean. Does that become “must support ACLs” for who it may or may not connect to, and diverting traffic among various peers?

>    REQ VPN-60:
>       MUST support the enrollment of the system in a PKI infrastructure
>       for the regular renewal of certificates.

Should we specify the technology this implies? I think there are several options.

>    REQ VPN-70:
>       MUST be able to transit IPv4 and IPv6 packets providing full
>       parity for services, and also offer both protocols in dual-stack
>       in the same VPN connection.

IPv4 is not IPv6. I certainly don’t object to calling for feature parity given that one implements IPv4, but I don’t think you want to make an IPv6-only product non-compliant.
 
>    REQ VPN-80:
>       MUST be able to apply to the tunnelled content that is terminated
>       on the device, the same inspection policies that are possible in
>       the non tunnelled traffic.

earlier, I started to write "To my way of thinking, any tunnel, including a VPN tunnel, can be an external interface just like a physical interface - it just has to connect to someone deemed “untrusted”. Do you want to say something about filtering traffic passed to/through VPN tunnels?”. I’m glad you put this here.

DMVPN, which you referred to, has the ability to emulate a n NBMA network similar to ATM or Frame Relay - the header is the same, but it is used as an encapsulation rather than as a static tunnel. Thinking about this requirement in that context makes my head hurt; do I want to have different policies for the various neighbors on an NBMA interface, or is it OK to have one policy for all of the neighbors on the “interface”?

>    REQ VPN-90:
>       MUST perform a full validation of the certificates' chains when
>       verifying the validity of the OCSP/CLR responses.  Caching of
>       responses SHOULD be configurable by end users, and the default
>       response SHOULD be not to accept a non-valid certificate.  The
>       default response MAY be overridden by the administrators, but it
>       MUST be configurable on a per-domain basis (e.g. accept incomplete
>       certificate chains for "intranet_of_internal_corp.example.org",
>       but refuse it for all of the other domains).
> 
> 7.  Denial of Service (DoS) Protection
> 
>    REQ DoS-10:
>       MUST be able to protect against implementation-specific attacks,
>       including:
> 
>       *  Winnuke [Myst1997]
> 
>       *  ping-of-death [Kenney1996]
> 
>       *  Smurf [CERT1998a]
> 
>       *  LAND Attack [Meltman1997]
> 
>       *  Teardrop Attack [CERT1997] [Junos-Teardrop]

So, just checking on the implications here. Nobody has thought of a new DDOS attack since 1998?

>    REQ DoS-20:
>       MUST be able to protect against IPv6 resource exhaustion attacks,
>       including:
> 
>       *  fragment flooding attacks

Protect what against such attacks? Itself, hosts behind it? If hosts behind it, are you asking for the stateful firewall to also include reassembly and re-transmission of incoming traffic to prevent the host from needing to do so?

>       *  Neighbor Cache Exhaustion attacks, whether launched from a
>          local network (see [I-D.ietf-opsec-ipv6-nd-security] or from
>          remote networks (see [RFC6583]

It certainly needs to protect itself. It can’t protect hosts behind it, especially if they are on a different LAN. why is this not a general host requirement?

>    REQ DoS-30:
>       MUST be able to protect against TCP flooding attacks: connection-
>       flooding, FIN-WAIT-1 flooding, etc. (see e.g. [CPNI-TCP])

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ DoS-40:
>       MUST be able to protect against TCP resource exhaustion attacks:
>       zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP])

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

SYN-flood is generally best solved using good table design in a TCP implementation. TCP Cookies, LRU lists of TCBs that enable you to re-use a TCB that received a SYN and nothing since, and so on.

>    REQ DoS-50:
>       MUST be able to detect and drop malformed IPv6 packets (incorrect
>       header/option lengths, etc.).

Hey! This is great! This IPv6 firewall actually does something with IPv6!

Is a side-effect of this that we can’t deploy a new feature like we had with ECN?

>    REQ DoS-60:
>       MUST be able to detect and drop malformed TCP packets (incorrect
>       segment/options lengths, etc.).

The transport layer is not IPv6. This belongs in a transport-layer-specific firewall specification, as it will be portable to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ DoS-70:
>       MUST be able to provide bandwidth management (QoS or anti-
>       flooding) policies customizable for specific source and
>       destination networks, or by VLAN or MPLS ID.

Hmm. That kind of thing is usually found in higher-end equipment. Are you saying that a residential firewall that one purchases for peanuts needs to do this? Do you have a market requirement?

>    REQ DoS-80:
>       MUST be able to participate to a blackhole/synkhole routing
>       infrastructure as per [RFC5635].

This is a general router requirement.

>    REQ DoS-85:
>       MUST be able to fetch and use third party "reputational" IP white-
>       and black-lists (e.g. download them via RSS feeds or query via
>       them DNS record) and use them in policy constructs/ACLs.  In
>       general, it MUST be able to provide some form of reputational
>       service for IP addresses which must include IPv6 networks.

In an IPv6 specification, you have to say that this also applies to IPv6?

When it comes to things like this, addresses fall broadly into two sets - the addresses we forward from, and the rest. The firewall won’t take a 20%-trustworthy address and forward 20% of its packets. I think you’re going to have to specify further what is meant here. Operators will usually download white lists or black lists and use a default for the other, and if there is a numeric value in the record, we’ll need to be able to specify a threshold of some sort.

>    REQ DoS-90:
>       MUST be able to set up a maximum session setup rate, and detect
>       hosts or networks exceeding it.

Easier said than done. If I access a site that has hundreds of thumbnail images, and the images all are on different hosts or what appear to be different hosts, I can set up sessions at a very high rate for a short amount of time. If that exceeds a firewall configuration, am I blacklisted forever? Or until my privacy address changes?

This sounds like one of those “in theory...” things...

>    REQ DoS-100:
>       MUST be able to set up a maximum IPv6 source and/or destination
>       session limit, and detect when they are exceeded.

Is this to protect the firewall (table abuse), the host, or the organization maintaining it? TCP sessions now commonly don’t close - they just fade away. In my zillion-thumbnail example, it would be pretty easy to imagine the TCBs being re-used without going through FIN/FIN-ACK, just grabbing it and opening a new session using it, knowing that IF the peer ever sends a packet he’ll get an RST. How does this interact with this requirement?

>    REQ DoS-110:
>       For each of the previous detection controls, different
>       configurable reactions SHOULD be possible by IPv6 address and
>       network sources and/or destinations.  The minimum actions required
>       are the following:
> 
>       1.   allow the traffic ("ignore" or "whitelist")
> 
>       2.   allow the traffic but log ("bypass" or "detection only" mode)
> 
>       3.   drop the packet (only the offending packet but do not reset
>            the connection)
> 
>       4.   drop session (drop the entire connection, but do not send a
>            reset back)
> 
>       5.   "greylist" - put it in a list of blocked addresses, but
>            remove it from the list after a configurable amount of time
> 
>       6.   send an email/SMS/pager text to the firewall administrator
> 
>       7.   send TCP reset to source only
> 
>       8.   send TCP reset to destination only
> 
> 
> 
> 
> Gont, et al.            Expires October 18, 2014               [Page 10]
> Internet-Draft               IPv6 Firewalls                   April 2014
> 
> 
>       9.   send TCP reset to both source and destination
> 
>       10.  perform a specific, preconfigured change on the firewall
>            policy
> 
>       11.  feed a third party source such as a switch/NAC/NAP or RADIUS
>            system, to isolate/quarantine the offending port/MAC address/
>            user
> 
>       12.  quarantine the specific traffic or source (block them for a
>            configurable amount of time, e.g. 5 minutes, and then allow
>            them again; eventually, the quarantine time may get longer if
>            the offense is repeated)

Sure there isn’t a 13th option? If a vendor added a 13th option, would s/he be in violation of the specification?

> 8.  Application Layer Firewall
> 
>    REQ APP-10:
>       MUST be able to provide web filtering features, such as enforcing
>       access to allowed web content and filtering high risk URLs such as
>       anonymizers and known hostile addresses.

What, specifically, does this have to do with IPv6? The rules would presumably be the same whether it runs on TCP/IPv4, TCP/IPv6, QUIC/IPv4, QUIC/IPv6, SCTP/IPv4, SCTP/IPv6, COAP/IPv6, or anything else. This belongs in an application-specific document.

>    REQ APP-20:
>       MUST be able to provide email filtering features, such as
>       mitigating spam, phishing and email harvesting, and enforce email
>       policies.

What, specifically, does this have to do with IPv6? The rules would presumably be the same whether it runs on TCP/IPv4, TCP/IPv6, QUIC/IPv4, QUIC/IPv6, SCTP/IPv4, SCTP/IPv6, COAP/IPv6, or anything else. This belongs in an application-specific document.

> 9.  Logging, Auditing and Security Operation Centre (SOC) requirements
> 
>    REQ SOC-10:
>       MUST generate log for all the changes performed to the system,
>       including change of group membership for a device, new or removed
>       devices in a group, new or removed administrators.
> 
>    REQ SOC-20:
>       MUST provide the following features:
> 
>       1.  Connection logs
> 
>       2.  Local log storage
> 
>       3.  Network logging
> 
>       4.  Real time log viewer
> 
>       5.  Attack detected
> 
>       6.  Per rule logging
> 
>       7.  Automatic log file compression
> 
>       8.  Log file rotation

No port logging? Your government is pretty interested in port logging. So is mine.

>    REQ SOC-30:
>       MUST be able to generate a log for:
> 
>       1.  all the logins, logouts and failed login attempts from
>           firewall administrators
> 
>       2.  any modifications or disabling of the firewall rules
> 
>    REQ SOC-40:
>       Any security event detected - malicious traffic, hit of a policy,
>       policy violation, termination of a session and so on - MUST be
>       able to generate a log, and be configurable to do that or not by
>       administrators.

>    REQ SOC-50:
>       There MUST be a mechanism to prevent log flooding from the device
>       against the management system, such as aggregation of like events.
> 
>    REQ SOC-60:
>       The amount of information in the alerts MUST be configurable; it
>       SHOULD possible to have the date/time and type of event and the
>       full payload of the traffic that has triggered the signature/
>       event.

How about the protocol? For example, syslog is common, but IPFIX can also be useful on high-rate systems.

>    REQ SOC-70:
>       The firewall MUST minimize the number of log entries generated for
>       a single event - e.g. when repeated similar events for a short
>       period of time are detected, they are aggregated and the
>       cumulative number of events is reported.
> 
>    REQ SOC-80:
>       The firewall MUST be able to send logs in multiple ways and
>       formats, for instance UDP syslog, TCP syslog, SMTP, SNMP and so
>       on.  It must be possible to configure different ways and formats
>       for different policies and configure some ways and formats as a
>       "backup" in the case that the main way fails.  Please describe the
>       different possibilities.
> 
>    REQ SOC-90:
>       The firewall SHOULD alert the firewall administrator when the
>       policy to be enforced does not follow the advice in [RFC4890] --
>       particularly if the filtering policy would block/drop ICMPv6
>       Packet Too Big error messages.

> 10.  Console and Events Visualization requirements

Why is this a *firewall* requirement?

>    REQ CON-10:
>       MUST provide a dashboard view, which must be customizable by end-
>       user and end-users' group (e.g. their Microsoft Active Directory
>       or LDAP group).

So, vendors like Cisco need not apply, because we don’t ship terminals with our equipment.

>    REQ CON-20:
>       The dashboard must be able to include system health monitoring
>       information, such as the following:
> 
>       1.  CPU idle
> 
>       2.  Real and Swap memory usage
> 
>       3.  Disk usage
> 
>       4.  Number of accepted and dropped packets
> 
>       5.  Operating status for all supported facilities (HA, QoS, VPN)
> 
>       6.  VPN tunnels status
> 
>       7.  NIC link state

But you can get that information from a Cisco product. It’s just not in a fancy GUI on a built-in screen display. Why not say what information you want to access without specifying how it is accessed?

>    REQ CON-30:
>       MUST have the possibility to select a particular piece of data or
>       individual alert, and visualize the policy that has triggered the
>       event.

Define “visualize”? Is that anything like “display”?

>    REQ CON-40:
>       MUST be able to create exception filters that will suppress
>       visualization of a specific alert (e.g. from specific sources, or
>       specific events), without actually affecting the detection and log
>       retention.
> 
>    REQ CON-50:
>       MUST provide a remote access method to obtain all current
>       operational data on demand, in a documented format, covering items
>       such as those listed in REQ CON-20.
> 
>          Note: This is to be able to integrate firewall operations in an
>          existing NMS.

It is common to make suggestions. SSH, NetConf, SNMP, and other solutions come to mind.

> 11.  Reporting requirements
> 
>    REQ REP-10:
>       Built in reports MUST be provided by default, such as protocol
>       distribution, policy and rule matched, top attacks, top sources/
>       destinations, top targets, top geographical sources, device status
>       including utilizations, and so on.

Reports to whom, with what authorization requirements? 

>    REQ REP-20:
>       SHOULD allow to run reporting over historical and archived logs,
>       automatically restoring and re-archiving them.

So - is the firewall required to support rotating media? Is there any chance that the medium might be in network-attached storage, and access to the media from a different system?