Requirements for IPv6 Firewalls

Sat Apr 19 00:24:23 UTC 2014

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