Fernando, Perhaps the document should have opened with a disclaimer that it is impossible to describe the full customer requirements for a firewall and thus a customer can reasonably add additional requirements. Then everyone knows where they stand and we avoid stupid (perhaps contractual) arguments that a firewall is acceptable solely because it meets this IETF publication. The document varies between specification and advice. My view is that it that as it stands the document is too specific to a particular type of firewall in a particular type of network to be anything other than advice, and should remove words such as "specify". My view is that there is scope for a different document -- or a much later revision of this document -- which actually specifies the minimum acceptable behaviour of a IPv6 network boundary firewall. You need an copyeditor. Expressions such as "but at times has also meant that a number of important/basic features have remained unimplemented by major firewall vendors, or that aforementioned features have not behaved as expected." are simply a poor use of the language. REQ GEN-5. Benchmarking is far too vague. Replace with a list of tests. REQ GEN-10 This is a requirement for the author of this specification. You should take that requirement and implement it throughout the document, and have a corresponding SNMP MIB which SHOULD be implemented. Counters we can't retrieve are pointless. REQ GEN-20 Define "basic access control list". Is that drop-and-count on destination address prefix? That would be the understanding based on the use of that term in Cisco IOS for IPv4. REQ GEN-30 Which transport layers are required for stateless inspection? TCP? UDP? OSPF? REQ GEN-50 This should not be a general requirement at all. There are good reasons not to use TCP proxying, not the least of which is the load on the firewall. REQ GEN-70 Doesn't allowing ACLs meet the uRPF requirement for non-routers? Is a vendor which supports ACLs automatically compliant? If not, state so. REQ GEN-80 Redirection of HTTPS traffic independent of other traffic is a specific feature for content providers not justifying a MUST for all firewalls. REQ SPC-10 This requirement squibs the most important single statement you can make about a IPv6 firewall: defining ICMP types which SHOULD be forwarded and those which SHOULD NOT when crossing a network boundary. This was a major issue for IPv4 and requires greater depth for IPv6 then is given here. REQ SPC-20 List the extension headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-30: List the routing headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-40 List the options which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-50 This requirement need much more work, as the specification is handwaving. REQ SPC-70 Cannot be implemented in anything but a simplistic network. ICMPv6 errors can come from anywhere on the forwarding path between the firewall and the host. The firewall cannot tell if a ICMPv6 from an unknown address is on the forwarding path for a connection. All it can do is validate uRPF, which is already a requirement. REQ SPC-80 Duplicate requirement REQ SPC-90 Poorly expressed. Rephrase in terms of packet parsing. REQ SPC-100 Rewriting Hop Limit? If you are going to proceed with the requirement then *reducing* Hop Limit is the only safe behaviour, and the only which a firewall SHOULD be required to support. If you are doing this to hide topology then the firewall manufacturer can reduce Hop Limit to the next lowest in a predefined set of values. Setting Hop Limit to an arbitrary value MAY be possible, and that should be accompanied by a note pointing out that this can lead to network failure unless all topologies containing the firewall are loop-free at all times. Why should a firewall support VPNs at all? Maybe you need to be clearer about the applicability of each section to a product. Do you mean that if a firewall implemented VPNs it must do so meeting these requirements? REQ VPN-20 is dynamic multipoint VPNs really a MUST for all VPN servers? You are saying that is it not possible for their to be a valid VPN design which does not include dynamic multipoint VPN. You'll excuse my doubt on that point. REQ VPN-60 needs more work. Some environments require certificates and keys to be manually altered. DOS. There are a lot of "must be able to protect against" which is handwaving. REQ DoS-70. This introduces a new requirement for filtering on VLAN or MPLS. That requirement needs to be higher in the document, not hidden. REQ DoS-80. I contest the MUST participate in blackhole infrastructure. There seems to be an assumption in this document that all valid IP firewalls designs are for use on Internet-connected networks. Ditto REQ DoS-85. REQ DoS-100. Underspecified. Or is "detected" the limit of the behaviour the firewall needs to implement to be compliant? (ie, it need not be able to drop). REQ DoS-110. "The minimum actions required are the following:" … "send an email/SMS/pager text to the firewall administrator". No, this is not the IETF network management architecture. I'll refer you to SNMP Traps. Operators have already set up whatever escalation they see as necessary based on the IETF's standard (ie, international standard) network management architecture. REQ APP-10. Underspecified, "such as" is far too broad for a MUST requirement. REQ APP-20. So a device aimed at application filtering for VoIP calls must also implement spam filtering? The MUST says so. REQ SOC-10 Once again, there is a IETF network management architecture. The requirement is overbroad -- when I add a user to a directory service, which is then exposed via RADIUS so networking equipment can validate administrators, how can the firewall meet the MUST log for "new or removed administrators". Logging *all* added and removed "devices in a group" is asking for trouble. Network operators are more than familiar with the ability of routing protocols to make neighbours come and go at a rate which will defeat a logger which records *all* neighbour changes. In any case, the inconsistency between this "all" and the later log rate limiting is unresolved. REQ SOC-20 MUST provide: "Local log storage", "Real time log viewer", "Automatic log file compression", "Log file rotation". Again operators already have logging architectures which do all of this. It's a perfectly fine design choice for a firewall vendor to punt messages into that existing facility. REQ SOC-30 "all the logins, logouts and failed login attempts from firewall administrators", "any modifications or disabling of the firewall rules". If you are going to MUST that then also MUST the disabling of that. Leaving that much forensic material on a device an attacker might gain access to isn't a pretty thought. REQ SOC-60 "Full payload" is asking too much for a SHOULD. REQ SOC-80 "The firewall MUST be able to send logs in multiple ways and formats" It is a valid design choice for a vendor to implement one method of logging, especially if that method is the one which suits their customers. You are making a design choice (general market or specific market) best left to the vendor. REQ CON-10 Delete. Yet again -- encourage people to use the IETF's network management architecture, where facilities like "dashboards" already exist. Better still that integrate all of a customers networking and account information, not just their firewall. REQ CON-20 Delete REQ CON-30 Delete REQ CON-40 Delete REQ CON-50 Delete REQ REP-20 Delete. See previous comments about logging. In general this document seems to be overreach -- it is considering desirable attributes for a specific type of firewall in a specific type of network, but claims to be setting a minimum for all IPv6 firewalls. It could do with a considerable pruning to get to the core of what are the base requirements for a network boundary IPv6 firewall. -glen