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

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 18 Apr 2014 23:38:44 +0000

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?

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sat, 19 Apr 2014 04:30:58 +0000

On Apr 19, 2014, at 6:38 AM, Fred Baker (fred) <[email-masked]> wrote:

> I’m join to suggest that this be broken up into a number of separately-discussable documents, each of which defines a test target. 

Concur 100% - and with everything else Fred noted, along with my previous comments.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton

---

From: "Lukasz Bromirski (lbromirs)" <[email-masked]>
Date: Sat, 19 Apr 2014 14:25:12 +0000

> On 19 kwi 2014, at 06:32, "Dobbins, Roland" <[email-masked]> wrote:

Yes, the doc is pretty lenghty and deals with all bells and whistles you can imagine. But only small percentage is IPv6 related, some points ask for unnecessary bloating of firewall code (BGP blackholing, MPLS, e-mail/url filtering), and some seems to be inspired by some specific products.

-- 
Łukasz Bromirski
CCIE R&S/SP #15929, CCDE 2012::17

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Apr 2014 06:36:20 -0300

Hi, Fred,

Thanks so much for your feedback! (and thanks for taking the time to
write down such a detailed review!) -- Please find (some of) my
comments in-line...

On 04/18/2014 08:38 PM, Fred Baker (fred) wrote:
> 
> 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.

Could you elaborate what (specifically) you have in mind?

> 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.

Not sure what you mean. Clearly, an IPv6 firewall does not deal only
with IPv6, but with whatever is on top of it 8at least the transport
layer). In this particular case, the intent is that, if you allow,
say, outgoing tcp segments destined to port 80, you should also allow
the corresponding (ICMPv6) control messages.

> Why are these not a separate document that such a deployment could
> refer to?

You mean e.g., a document that just focuses on the IPv6 packet
filtering details? -- If so, I can agree with you.

> 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.

FWIW, here we're assuming that you're doing stateful filtering -- so
the state is already there.

> 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?

I'd have no issues with that. I'd say that it makes perfect sense to
move "how to filter X protocol" into a different document.. although
I'm not sure if I'd do "one protocol per document" (me, I wouldn't
mind, but then there are folks that claim about multiple small
documents..)

>> 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.

[fwiw, point noted]

[....]
> 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.

I agree that the functional requirements will be very similar to those
of IPv4. But the problem is that it is not unusual to find that there
is no such parity of features between the two protocols (given the
same device).

> 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.

Agreed.

>> 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).
> 

Will do.

>> 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.

Sort of. There's interaction between e.g. ICMPv6 and the transport
layer. -- for instance, if you require the fw to perform e.g. TCP
checksum validation, it won't be "IP-agnostic".

I'd also say that basic packet filtering capabilities imply the
ability to do this sort of stateful filtering.

>> 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.
>> 
> 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.

Agreed.

>> REQ GEN-80: MUST be able to redirect specific traffic to a proxy 
>> server e.g. for HTTP/S protocols.
>> 
> 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.

FWIW, this req is based on a commonly supported firewall feature.

>> 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.

Agreed. Question: are you implying that we should remove this
requirement? Something else?

>> 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.

I'm fine with, say, putting the filtering details in separate
documents. But I'd disagree that ICMPv6 is not IPv6. Or, well.. that
depends on what what means by "IPv6". If one means "IPv6 protocol
suite", then ICMPv6 is definitely a part of it (that's what we mean here).

>> 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.

Good point. Will do.

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

No. Here we mean that you should be able to filter based on the
*options* (i.e., this is finer-grained than 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”?

Would do. Maybe it would be valuable to avoid requiring the admin to
craft the aforementioned rules from cratch?

>> REQ SPC-60: MUST be able to validate IPv6 Neighbor Discovery 
>> [RFC4861] packets (RS, RA, NS, NA, Redirect) according to 

It's certainly not... But some validation checks are not (yet)
required for all nodes, and [I-D.ietf-opsec-ipv6-nd-security] will not
formally achieve this, since it's on the Informational track....

>> 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.

Note: here we're requiring the ability of doing so... not the
enforcement of the policy.

>> 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].
> 

I agree this one wasn't clear. But here's the intent: SPC-20 requires
that the device has the capability to filter EHs on a per-type
granularity, etc. SPC-80 is meant to provide a default ruleset via
[draft-gont-opsec-ipv6-eh-filtering].

(yes, this is not clear... and the reference to RFC7045 is probably
superflous).

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

SPC-80 specifies default filtering rules based on EHs. SPC-90 requires
the fw to be able to process the entire IPv6 header chain (such that
e.g. the fw cannot be bypassed via inclusion of IPv6 EHs and the like).

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

As with many of the previous ones, here we're specifying feature,
rather than enforcement of a policy. (the device must be able to do
that... but that doesn't mean that e.g. the feature must be enabled by
default).

That said, normalizing the Hop Limit to something like, say, 64, will
prevent external nodes from discovering your network topology (yes,
you can also filter the corresponding ICMPv6 errors), and, most
importantly, will prevent an attacker from evading a NIDS by playing
with the Hop Limit field (such that the sensor sees the packet, but
the target doesn't).

>> REQ DoS-10: MUST be able to protect against
>> implementation-specific attacks, including:
>> 
>> *  Winnuke [Myst1997]
>> 

FWIW, these are not really DDOS, but rather common implementation
errors. The references are certainly about the IPv4 incarnation of
these vulnerabilities.. but some of them have reincarnated in IPv6
implementations. See e.g.:

*
<http://gcn.com/blogs/cybereye/2013/08/microsoft-patch-ping-of-death-ipv6.aspx>

* <http://tools.ietf.org/id/draft-gont-6man-ipv6-smurf-amplifier-01.txt>

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

Why should it be? ECN had trouble being deployed because fw's were
dropping packets that had a *Reserved* bit set. Here we're talking
about *malformed* packet -- a packet with a reserved bit set does not
qualify as such.

>> REQ DoS-70: MUST be able to provide bandwidth management (QoS or 
>> anti- flooding) policies customizable for specific source and 
> 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?

We're certainly not talking about "residential firewalls" here. That
said, the idea is that if you have a residential firewall that somehow
wanted to "comply" with this document, you could simply state that it
e.g. "does not comply with the 'requirements for dos mitigation' in
this document", or e.g., that "it is conditionally compliant to the
'requirements for DoS mitigation' in this document".

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

do you mean "a formal router requirement" (as say, per RFC1812)?

P.S.: More responses in the pipeline...

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492