[171139] in North American Network Operators' Group
Re: Requirements for IPv6 Firewalls
daemon@ATHENA.MIT.EDU (Glen Turner)
Fri Apr 18 20:45:26 2014
From: Glen Turner <gdt@gdt.id.au>
In-Reply-To: <534FAD41.8040604@gont.com.ar>
Date: Sat, 19 Apr 2014 09:54:23 +0930
To: Fernando Gont <fernando@gont.com.ar>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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:" =85 "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=
