opsec F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Intended status: Informational M. Ermini
Expires: August 19, 2014 ResMed
W. Liu
Huawei Technologies
February 15, 2014
Requirements for IPv6 Firewalls
draft-gont-opsec-ipv6-firewall-reqs-00
Abstract
While there are a large number of documents discussing IP and IPv6
packet filtering, requirements for IPv6 firewalls have never been
specified in the RFC series. When it comes to IPv6, the more limited
experience with the protocols, and reduced variety of products has
made it rather difficult to specify what are reasonable features to
be expected from 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, marked as
"mandatory", "recommended", or "optional".
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gont, et al. Expires August 19, 2014 [Page 1]
Internet-Draft IPv6 Firewalls February 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. General Security Features . . . . . . . . . . . . . . . . . . 3
5. IPv6-Specific Features . . . . . . . . . . . . . . . . . . . 4
6. VPN Security Requirements . . . . . . . . . . . . . . . . . . 5
7. Denial of Service (DoS) Protection . . . . . . . . . . . . . 6
8. Application Layer Firewall . . . . . . . . . . . . . . . . . 7
9. Logging, Auditing and Group Security Operation Centre (GSOC)
requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Console and Events Visualisation requirements . . . . . . . . 9
11. Reporting requirements . . . . . . . . . . . . . . . . . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
13. Security Considerations . . . . . . . . . . . . . . . . . . . 10
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
15.1. Normative References . . . . . . . . . . . . . . . . . . 10
15.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. DISCLAIMER
This initial version of the document is based on a typical IPv6
firewall RFP, and is mostly meant to trigger discussion in the
community, and define a direction for the document. Future versions
of this document may content all, more, or a subset of the
requirements present in the current version of this document.
Additionally, the current version DOES NOT yet properly separate
requirements among MUST/REQUIRED, SHOULD/RECOMMENDED, and MAY/
OPTIONAL.
Additionally, this version is meant to provide requirements, rather
than implementation guidelines.
Gont, et al. Expires August 19, 2014 [Page 2]
Internet-Draft IPv6 Firewalls February 2014
2. Introduction
While the IETF has published a large number of documents discussing
IP and IPv6 packet filtering (see e.g. [RFC7126], requirements for
firewalls have never been specified in the RFC series. 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 IPv6 firewall. This has typically been a problem for
network operators (who typically have typically had to produce a
"Request for Proposal" from scratch), but also for vendors (who lack
a well defined set of requirements to comply to).
This situation has not only made the process of purchasing an IPv6
firewall harder, but at times has also meant that a number of
important/basic features have remained unimplemented by major
firewall vendors, or the aforementioned features have been found to
contain bugs.
This document aims to provide a ser of requirements for firewall
vendors, which are specified as "MUST", "SHOULD", or "MAY". An IPv6
firewall product is said to be "fully-compliant" with this
specification provided it implements all requirements marked as
"MUST" and "SHOULD". An IPv6 firewall product is said to be
"conditionally-compliant" with this specification provided it
implements all requirements marked as "MUST", but fails to implement
one or more of the requirements marked as "SHOULD".
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. General Security Features
REQ GEN-1:
MUST support basic Access Control Lists (ACLs).
REQ GEN-2:
MUST support both stateless and stateful packet inspection and
filtering at transport layer.
REQ GEN-3:
Gont, et al. Expires August 19, 2014 [Page 3]
Internet-Draft IPv6 Firewalls February 2014
MUST support full-proxy for the TCP [RFC0793] connections (the
handshake is validated on the firewall before reaching the target
system).
REQ GEN-4:
MUST be able to enforce timeouts on TCP connections based on
specific protocols (e.g. enforce DNS timeout to a specific number
of seconds, or FIN-WAIT, etc.). In general, it MUST have
different kind of timeout values and thresholds to be used to
prevent idle established connections to saturate resources on both
the device and the service that is defended.
REQ GEN-5:
MUST be able to provide anti-spoofing features (e.g. uRPF ).
REQ GEN-6:
MUST be able to redirect specific traffic to a proxy server e.g.
for HTTP/S protocols.
REQ GEN-7:
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.
5. IPv6-Specific Features
REQ SPC-1:
MUST be able to filter ICMPv6 [RFC4443] traffic at a message type/
code granularity.
REQ SPC-2:
MUST be able to block IPv6 packets that employ a Routing Header
(both at the granaularity of Extension Header Type and Routing
Header Type).
REQ SPC-3:
MUST be able to detect IPv6 tunnels such as SIT, 6to4, 6in4,
ISATAP and Teredo (please see [RFC7123], and must be able to
selectively block or allow them for specific sources,
destinations, routes or interfaces.
REQ SPC-4:
MUST be able to filter ICMPv6 traffic at a message type/code
granularity.
REQ SPC-5:
Gont, et al. Expires August 19, 2014 [Page 4]
Internet-Draft IPv6 Firewalls February 2014
MUST be able to validate IPv6 Neighbor Discovery [RFC4861] packets
(RS, RA, NS, NA, Redirect) according to
[I-D.ietf-opsec-ipv6-nd-security].
REQ SPC-6:
MUST be able to statefully match ICMPv6 errors to TCP [RFC0793],
UDP [RFC0768], and ICMPv6 [RFC4443] communication instances.
REQ SPC-7:
MUST be able to find the upper-layer protocol in an IPv6 header
chain (see [RFC7112].
6. VPN Security Requirements
REQ VPN-1:
MUST implement IPsec-based [RFC4301] VPN technology.
REQ VPN-2:
MUST implement "hub-and-spoke" Dynamic Multipoint VPN-like
technology, allowing creation of dynamic-meshed VPN without having
to preconfigure all of possible tunnels.
REQ VPN-3:
MUST implement SSL/TLS-based [SSL-VPNs] VPN technology.
REQ VPN-4:
MUST be able to use digital certificates, including CRL and OCSP
revocation checking methods, to mutually authenticate VPN peers.
REQ VPN-5:
MUST be able to disable or enable split-tunnelling feature on VPN
as required.
REQ VPN-5:
MUST support the enrollment of the system in a PKI infrastructure
for the regular renewal of certificates.
REQ VPN-6:
MUST be able to work indifferently on IPv4 and IPv6, and also
offer both protocol in dual-stack in the same VPN connection.
REQ VPN-7:
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.
Gont, et al. Expires August 19, 2014 [Page 5]
Internet-Draft IPv6 Firewalls February 2014
7. Denial of Service (DoS) Protection
REQ DoS-1:
MUST be able to protect against OS-specific attacks: nuke, ping-
of-death (NOTE: this list should be expanded, and references
added).
REQ DoS-2:
MUST be able to protect against IPv6 resource exhaustion attacks
(e.g., fragment flooding attacks).
REQ DoS-3:
MUST be able to protect against TCP flooding attacks: connection-
flooding, FIN-WAIT-1 flooding, etc. (see e.g. [CPNI-TCP])
REQ DoS-4:
MUST be able to protect against TCP resource exhaustion attacks:
zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP])
REQ DoS-5:
MUST be able to detect and drop malformed IPv6 packets (incorrect
header/option lengths, etc.).
REQ DoS-6:
MUST be able to detect and drop malformed TCP packets (incorrect
segment/options lengths, etc.).
REQ DoS-7:
MUST be able to provide bandwidth management (QoS or anti-
flooding) policies customisable for specific source and
destination networks, or by VLAN or MPLS ID.
REQ DoS-8:
MUST be able to participate to a blackhole/sync hole routing
infrastructure as per [RFC5635].
REQ DoS-9:
MUST be able to set up a maximum session setup rate, and detect
hosts or networks exceeding it.
REQ DoS-10:
MUST be able to set up a maximum IPv6 source and/or destination
session limit, and detect when they are exceeded.
REQ DoS-11:
For each of the previous detection controls, different
configurable reactions SHOULD be possible by IPv6 address and
Gont, et al. Expires August 19, 2014 [Page 6]
Internet-Draft IPv6 Firewalls February 2014
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 administrator
7. send TCP reset to source only
8. send TCP reset to destination only
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)
8. Application Layer Firewall
REQ APP-1:
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.
REQ APP-2:
MUST be able to provide email filtering features, such as
mitigating spam, phishing and email harvesting, and enforce email
policies.
Gont, et al. Expires August 19, 2014 [Page 7]
Internet-Draft IPv6 Firewalls February 2014
9. Logging, Auditing and Group Security Operation Centre (GSOC)
requirements
REQ GSOC-1:
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 GSOC-2:
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
REQ GSOC-3:
MUST be able to generate a log for:
1. all the logins, logouts and failed login attempts from
administrators
2. any modifications or disabling of the firewall rules
REQ GSOC-4:
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 GSOC-5:
There MUST be a mechanism to prevent log flooding from the device
against the management system, such as aggregation of like events.
REQ GSOC-6:
The amount of information in the alerts MUST be configurable; it
SHOULD possible to have the date/time and type of event and the
Gont, et al. Expires August 19, 2014 [Page 8]
Internet-Draft IPv6 Firewalls February 2014
full payload of the traffic that has triggered the signature/
event.
REQ GSOC-7:
The firewall MUST minimise 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 GSOC-8:
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.
10. Console and Events Visualisation requirements
REQ CON-1:
MUST provide a dashboard view, which must be customisable by user
and users' group.
REQ CON-2:
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
REQ CON-3:
MUST have the possibility to select a particular piece of data or
individual alert, and visualise the policy that has triggered the
event.
REQ CON-4:
Gont, et al. Expires August 19, 2014 [Page 9]
Internet-Draft IPv6 Firewalls February 2014
MUST be able to create exception filters that will suppress
visualisation of a specific alert (e.g. from specific sources, or
specific events), without actually affecting the detection and log
retention.
11. Reporting requirements
REQ REP-1:
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 utilisations, and so on.
REQ REP-2:
MUST allow to run reporting over historical and archived logs,
automatically restoring and rearchiving them.
12. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
13. Security Considerations
[TBD]
14. Acknowledgements
This initial version is based on an earier document authored by Marco
Ermini.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
Gont, et al. Expires August 19, 2014 [Page 10]
Internet-Draft IPv6 Firewalls February 2014
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112, January 2014.
15.2. Informative References
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on
IPv4 Networks", RFC 7123, February 2014.
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
on Filtering of IPv4 Packets Containing IPv4 Options", BCP
186, RFC 7126, February 2014.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
Filtering with Unicast Reverse Path Forwarding (uRPF)",
RFC 5635, August 2009.
[I-D.ietf-opsec-ipv6-nd-security]
Gont, F., Bonica, R., and W. Will, "Security Assessment of
Neighbor Discovery (ND) for IPv6", draft-ietf-opsec-ipv6
-nd-security-00 (work in progress), October 2013.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Version 4", RFC 6274, July 2011.
[CPNI-TCP]
CPNI, , "Security Assessment of the Transmission Control
Protocol (TCP)", http://www.gont.com.ar/papers/
tn-03-09-security-assessment-TCP.pdf, 2009.
[SSL-VPNs]
Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72,
SAAG Meeting., 2008,
<http://www.ietf.org/proceedings/72/slides/saag-4.pdf>.
Gont, et al. Expires August 19, 2014 [Page 11]
Internet-Draft IPv6 Firewalls February 2014
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Marco Ermini
ResMed
Fraunhoferstrasse 16
Munich, Bayern 82152
Deutschland
Phone: +49 175 4395642
Email: marco.ermini@resmed.com
URI: http://www.resmed.com
Will Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Gont, et al. Expires August 19, 2014 [Page 12]