draft-ietf-opsawg-firewalls-00.txt   draft-ietf-opsawg-firewalls-01.txt 
Operations Area Working Group F. Baker Operations Area Working Group F. Baker
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: BCP June 12, 2012 Intended status: BCP P. Hoffman
Expires: December 14, 2012 Expires: April 21, 2013 VPN Consortium
October 18, 2012
On Firewalls in Internet Security On Firewalls in Internet Security
draft-ietf-opsawg-firewalls-00 draft-ietf-opsawg-firewalls-01
Abstract Abstract
There is an ongoing discussion regarding the place of firewalls in This document discusses the most important operational and security
security. This note is intended to capture and try to make sense out implications of using modern firewalls in networks. It makes
of it. recommendations for operators of firewalls, as well as for firewall
vendors.
Requirements Language
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 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2012. This Internet-Draft will expire on April 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Common kinds of firewalls . . . . . . . . . . . . . . . . . . 3 1.1. Modern Firewall Features That Should Not Be Confused
2.1. Perimeter security: Protection from aliens and with Firewalling . . . . . . . . . . . . . . . . . . . . . 4
intruders . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pervasive access control . . . . . . . . . . . . . . . . . 5 2. High-Level Firewall Concepts . . . . . . . . . . . . . . . . . 4
2.3. Intrusion Management: Contract and Reputation filters . . 5 2.1. The End-to-End Principle . . . . . . . . . . . . . . . . . 4
3. Reasoning about Firewalls . . . . . . . . . . . . . . . . . . 7 2.2. Building a Communication . . . . . . . . . . . . . . . . . 5
3.1. The End-to-End Principle . . . . . . . . . . . . . . . . . 7 3. Firewalling Strategies . . . . . . . . . . . . . . . . . . . . 6
3.2. Building a communication . . . . . . . . . . . . . . . . . 8 3.1. Blocking Traffic Unless It Is Explicitly Allowed . . . . . 7
3.3. The middle way . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Typical Firewall Categories . . . . . . . . . . . . . . . 7
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Newer categories of firewalling . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Recommendations for Operators . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Recommendations for Firewall Vendors . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. IPv4 NATs Are Not Security Devices . . . . . . . . . 10
Appendix B. Origin Reputation and Firewalls . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
There is an ongoing discussion regarding the place of firewalls in In this document, a firewall is defined as a device or software that
security. This note is intended to capture and try to make sense out imposes a policy whose effect is "a stated type of packets may or may
of it. not pass from A to B". All modern firewalls allow an administrator
to change the policies in the firewall, although the ease of
The IETF has a long and fractured discussion on security. Many early administration for making those changes, and the granularity of the
RFCs simply didn't address the topic - and said as much. When the policies, vary widely between firewalls and vendors.
IESG started complaining about that, it was told that there was no
market interest in the topic that was measurable in money spent.
Those who *were* interested in the topic set forth frameworks, rules,
and procedures without necessarily explaining how they would be
useful in deployment, and dismissed questions as "from those who
don't understand." In many cases, as a result, deployments have been
underwhelming in both quantity and quality, and the Internet is noted
for its problems with security. What is clear is that people need to
think clearly about security, their own and that of others. What is
not clear is how to do so in a coherent and scalable manner.
Prophylactic perimeter security in the form of firewalls, and the
proper use of them, have been a fractious sub-topic in this area.
One could compare them to the human skin. The service that the skin
performs for the rest of the body is to keep common crud out, and as
a result prevent much damage and infection that could otherwise
occur. The body supplies prophylactic perimeter security for itself
and then presumes that the security perimeter has been breached; real
defenses against attacks on the body include powerful systems that
detect changes (anomalies) counterproductive to human health, and
recognizable attack syndromes such as common or recently-seen
diseases. One might well ask, in view of those superior defenses,
whether there is any value in the skin at all; the value is easily
stated, however. It is not in preventing the need for the stronger
solutions, but in making their expensive invocation less needful and
more focused.
This note will address common kinds of firewalls and the claims made
for them. It will suggest a line of reasoning about the use of
firewalls. It will attempt to end the bickering on the topic, which
is, for the most part, of little value in illuminating the
discussion.
2. Common kinds of firewalls
There are at least three common kinds of firewalls:
o Context or Zone-based firewalls, that protect systems within a
perimeter from systems outside it,
o Pervasive routing-based measures, which protect intermingled
systems from each other by enforcing role-based policies, and
o Systems that analyze application behavior and trigger on events
that are unusual, match a signature, or involve an untrusted peer.
2.1. Perimeter security: Protection from aliens and intruders
As discussed in [RFC6092], the most common kind of firewall is used
at the perimeter of a network. Perimeter security assumes two
things: that applications and equipment inside the perimeter are
under the control of the local administration and are therefore
probably doing reasonable things, and that applications and equipment
outside the perimeter are unknown. It may make simple permission
rules, such as that external web clients are permitted to access a
specific web server or that SMTP peers are permitted to access
internal SMTP MTAs. Apart from those rules, a session may be
initiated from inside the perimeter, and responses from outside will
be allowed through the firewall, but sessions may never be initiated
from outside.
In addition, perimeter firewalls often perform some level of testing,
either as application proxies or through deep packet inspection, to
verify that the protocol claimed to be being passed is in fact the
protocol being passed.
The existence and definition of zone-based perimeter defenses is
arguably a side-effect of the deployment of Network Address
Translation [RFC2993]; applications frequently make the mistake of
coupling application identities to network layer addresses, and in so
doing make two other coupling assumptions: that an address useful to
and understood by one application is useful to and understood by
another, and that addresses are unlikely to change within a time
frame useful to the application. Network Address Translation forces
the translator to interpret packet payloads and change addresses
where used by applications. If the transport or application headers
are not understood by the translator, this has the effect of damaging
or preventing communication. Detection of such issues can be sold as
a security feature, although it is really a side-effect of a failure.
While this can have useful side-effects, such as preventing the Given this definition, it is easy to see that there is a perimeter
passage of attack traffic that masquerades as some well-known (the position between A and B) in which the specific security policy
protocol, it also has the nasty side-effect of making innovation applies. In typical deployed networks, there are usually some easy-
difficult. For example, One of the issues in the deployment of to-define perimeters. If two or more networks that are connected by
Explicit Congestion Notification [RFC3168], for example, has been a single device, the perimeter is inside the device. If that device
that common firewalls often test unused bits and require them to be is a firewall, it can impose a security policy at the shared
set to zero to close covert channels. A similar problem has slowed perimeters of those networks.
the deployment of SCTP [RFC4960], in that a firewall will often not
permit a protocol it doesn't know even if a user behind it opens the
session. When a new protocol or feature is defined, the firewall
needs to stop applying that rule, and that can be difficult to make
happen.
2.2. Pervasive access control Many firewalls also employ some perimeters that are not as easy to
define. Some of these perimeters in modern firewalls include:
Another access control model, often called "Role-based", tries to o An application-layer gateway (ALG) in front of a server creates a
control traffic in flight regardless of the perimeter. Given a rule perimeter between that server and the network it is connected to.
that equipment located in a given routing domain or with a specific The ALG blocks some of the flows in the application protocol based
characteristic (such as "student dorms") should not be able to access on policies such as "do not all traffic from this network" and "do
equipment in another domain or with a specific characteristic (such not allow the client to send a message of this type".
as "academic records"), it might prevent routing from announcing the
second route in the domain of the first, or it might tag individual
packets ("I'm from the student dorm") and filter on those tags at
enforcement points throughout network. Such rules can be applied to
individuals are well as equipment; in that case, the host needs to
tag the traffic, or there must be a reliable correlation between
equipment and its user.
One common use of this model is in data centers, in which physical or o Routing domains that are controlled with role-based administration
virtual machines from one tenant (which is not necessarily an "owner" create perimeters in a routed network. Role-based administration
as much as it is a context in which the system is used) might be co- makes rules such as "Domain X cannot see Domain Y in its routing
resident with physical or virtual machines from another. Inter- table"; this prevents any host in Domain X from sending traffic to
tenant attacks, espionage, and fraud are prevented by enforcing a any host in Domain Y.
rule that traffic from systems used by any given tenant is only
delivered to other systems used by the same tenant. This might, of
course have nuances; under stated circumstances, identified systems
or identified users might be able to cross such a boundary.
The major impediment in deployment is complexity. The administration o [[[ MORE HERE with other interesting perimeters ]]]
has the option to assign policies for individuals on the basis of
their current location (e.g. as the cross-product of people,
equipment, and topology), meaning that policies can multiply wildly.
The administrator that applies a complex role-based access policy is
probably most justly condemned to live in the world he or she has
created.
2.3. Intrusion Management: Contract and Reputation filters Modern firewalls apply perimeters at three layers:
The model proposed in Advanced Security for IPv6 CPE Layer 3: Most firewalls can filter based on source and destination
[I-D.vyncke-advanced-ipv6-security] could be compared to purchasing IPv4 addresses. Many (but, frustratingly, not all) firewalls can
an anti-virus software package for one's computer. The proposal is filter based on IPv6 addresses.
to install a set of filters, perhaps automatically updated, that
identify "bad stuff" and make it inaccessible, while not impeding
anything else.
It depends on four basic features: Layer 4: Most firewalls can filter based on TCP and UDP ports.
Many (but, frustratingly, not all) firewalls can also filter based
on transports other than TCP and UDP.
o A frequently-updated signature-based Intrusion Prevention System Layer 7: Modern firewalls can filter based on the application
which inspects a pre-defined set of protocols at all layers (from protocol contents, such as to allow or block certain types of
layer-3 to layer-7) and uses a vast set of heuristics to detect protocol-defined messages, or based on the contents of those
attacks within one or several flow. Upon detection, the flow is messages.
terminated and an event is logged for further optional auditing.
o A centralized reputation database that scores prefixes for degree Note that many firewall devices can only create policies at one or
of trust. This is unlikely to be on addresses per se, as Privacy two of the layers.
Addresses change regularly and frequently.
o Local correlation of attack-related information, and Hardware-based firewalls by their nature inspect traffic flowing
through them, sometimes using proprietary mechanisms to make traffic
analysis as fast as possible on the given hardware. Some firewalls
use network visibility protocols such as NetFlow and sFlow to help
capture and analyze traffic. [[ References needed ]]
o Global correlation of attacks seen, in a reputation database 1.1. Modern Firewall Features That Should Not Be Confused with
Firewalling
The proposal doesn't mention anomaly-based intrusion detection, which There are a few features that appear in any firewall devices that
could be used to detect day-zero attacks and new applications or have become associated with firewalls but in fact are not used for
attacks. This would be an obvious extension. firewalling. Those non-firewalling features include:
The comparison to anti-virus software is real; anti-virus software Network Address Translation (NAT) [RFC2993], which is not used for
uses similar algorithms, but on API calls or on data exchanged rather security policy
than on network traffic, and for identified threats is often
effective.
The proposal also has weaknesses: IPsec [RFC4301], which is used for virtual private networks
(VPNs). Although the core IPsec protocol has firewalling in it,
when IPsec appears in a firewall device, it is normally only
associated with the application of authenticated encryption and
integrity protection of traffic.
o People don't generally maintain anti-virus packages very well, "SSL VPN" is a set of technologies that rely on tunneling traffic
letting contracts expire, through the TLS [RFC5246] protocol running on port 443. Some
firewalls offer SSL VPNs as an alternative to IPsec.
o Reputation databases have a bad reputation for distributing Traffic prioritization is a feature common in firewalls, but does
information which is incorrect or out of date, not meet the definition of firewalling at all.
o Anomaly-based analysis identifies changes but is often ineffective 1.2. Terminology
in determining whether new application or application behaviors
are pernicious (false positives). Someone therefore has to
actively decide - a workload the average homeowner might have
little patience for, and
o Signature-based analysis applies to attacks that have been The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
previously identified, and must be updated as new attacks develop. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
As a result, in a world in which new attacks literally arise document are to be interpreted as described in [RFC2119].
daily, the administrative workload and be intense, and reflexive
responses like accepting https certificates that are out of date
or the download and installation of unsigned software on the
assumption that the site admin is behind are themselves vectors
for attack.
Security has to be maintained to be useful, because attacks are Some terms which have specific meanings in this document (such as
maintained. "firewall") are defined earlier in this section.
3. Reasoning about Firewalls 2. High-Level Firewall Concepts
3.1. The End-to-End Principle 2.1. The End-to-End Principle
One common complaint about firewalls in general is that they violate One common complaint about firewalls in general is that they violate
the End-to-End Principle [Saltzer]. The End-to-End Principle is the End-to-End Principle [EndToEnd]. The End-to-End Principle is
often incorrectly stated as requiring that "application specific often incorrectly stated as requiring that "application specific
functions ought to reside in the end hosts of a network rather than functions ought to reside in the end hosts of a network rather than
in intermediary nodes, provided they can be implemented 'completely in intermediary nodes, provided they can be implemented 'completely
and correctly' in the end hosts" or that "there should be no state in and correctly' in the end hosts" or that "there should be no state in
the network." What it actually says is heavily nuanced, and is a the network."
line of reasoning applicable when considering any two communication
layers.
[Saltzer] "presents a design principle that helps guide placement What it actually says is heavily nuanced, and is a line of reasoning
of functions among the modules of a distributed computer system. applicable when considering any two communication layers. The
The principle, called the end-to-end argument, suggests that document says that it "presents a design principle that helps guide
functions placed at low levels of a system may be redundant or of placement of functions among the modules of a distributed computer
little value when compared with the cost of providing them at that system. The principle, called the end-to-end argument, suggests that
low level." functions placed at low levels of a system may be redundant or of
little value when compared with the cost of providing them at that
low level."
In other words, the End-to-End Argument is not a prohibition against In other words, the End-to-End Argument is not a prohibition against
lower layer retries of transmissions, which can be important in lower layer retries of transmissions, which can be important in
certain LAN technologies, nor of the maintenance of state, nor of certain LAN technologies, nor of the maintenance of state, nor of
consistent policies imposed for security reasons. It is, however, a consistent policies imposed for security reasons. It is, however, a
plea for simplicity. Any behavior of a lower communication layer, plea for simplicity. Any behavior of a lower communication layer,
whether found in the same system as the higher layer (and especially whether found in the same system as the higher layer (and especially
application) functionality or in a different one, that from the application) functionality or in a different one, that from the
perspective of a higher layer introduces inconsistency, complexity, perspective of a higher layer introduces inconsistency, complexity,
or coupling extracts a cost. That cost may be in user satisfaction, or coupling extracts a cost. That cost may be in user satisfaction,
skipping to change at page 8, line 5 skipping to change at page 5, line 47
there are any number of possible sites on the network that are there are any number of possible sites on the network that are
inaccessible at any given time, and the presence of such a policy is inaccessible at any given time, and the presence of such a policy is
easily explained and understood. easily explained and understood.
What does fail the end-to-end argument is behavior that is What does fail the end-to-end argument is behavior that is
intermittent, difficult to explain, or unpredictable. If I can intermittent, difficult to explain, or unpredictable. If I can
sometimes reach a site and not at other times, or reach it using this sometimes reach a site and not at other times, or reach it using this
host or application but not another, I wonder why that is true, and host or application but not another, I wonder why that is true, and
may not even know where to look for the issue. may not even know where to look for the issue.
3.2. Building a communication 2.2. Building a Communication
Any communication requires at least three components: Any communication requires at least three components:
o a sender, someone or some thing that sends a message, o a sender, someone or some thing that sends a message,
o a receiver, someone or some thing that receives the message, and o a receiver, someone or some thing that receives the message, and
o a channel, which is a medium by which the message is communicated. o a channel, which is a medium by which the message is communicated.
In the Internet, the IP network is the channel; it may traverse In the Internet, the IP network is the channel; it may traverse
skipping to change at page 8, line 29 skipping to change at page 6, line 25
receiver, who is willing to receive and operate on it. In contrast, receiver, who is willing to receive and operate on it. In contrast,
attacks are a form of harassment. A receiver exists, but is attacks are a form of harassment. A receiver exists, but is
unwilling to receive the message, has no application to operate on unwilling to receive the message, has no application to operate on
it, or is by policy unwilling to. Attacks on infrastructure occur it, or is by policy unwilling to. Attacks on infrastructure occur
when message volume overwhelms infrastructure or uses infrastructure when message volume overwhelms infrastructure or uses infrastructure
but has no obvious receiver. but has no obvious receiver.
By that line of reasoning, a firewall primarily protects By that line of reasoning, a firewall primarily protects
infrastructure, by preventing traffic that would attack it from it. infrastructure, by preventing traffic that would attack it from it.
The best prophylactic might use a procedure for the dissemination of The best prophylactic might use a procedure for the dissemination of
Flow Specification Rules [RFC5575] to drop traffic sent by an flow specification rules from [RFC5575] to drop traffic sent by an
unauthorized or inappropriate sender or which has no host or unauthorized or inappropriate sender or which has no host or
application willing to receive it as close as possible to the sender. application willing to receive it as close as possible to the sender.
In other words, as discussed in Section 1, a firewall compares to the In other words, as discussed in Section 1, a firewall compares to the
human skin, and has as its primary purpose the prophylactic defense human skin, and has as its primary purpose the prophylactic defense
of a network. By extension, the firewall also protects a set of of a network. By extension, the firewall also protects a set of
hosts and applications, and the bandwidth that serves them, as part hosts and applications, and the bandwidth that serves them, as part
of a strategy of defense in depth. A firewall is not itself a of a strategy of defense in depth. A firewall is not itself a
security strategy; the analogy to the skin would say that a body security strategy; the analogy to the skin would say that a body
protected only by the skin has an immune system deficiency and cannot protected only by the skin has an immune system deficiency and cannot
be expected to long survive. That said, every security solution has be expected to long survive. That said, every security solution has
a set of vulnerabilities; the vulnerabilities of a layered defense is a set of vulnerabilities; the vulnerabilities of a layered defense is
the intersection of the vulnerabilities of the various layers (e.g., the intersection of the vulnerabilities of the various layers (e.g.,
a successful attack has to thread each layer of defense). a successful attack has to thread each layer of defense).
3.3. The middle way 3. Firewalling Strategies
There is therefore no one way to prevent attacks; as noted in There is a great deal of tension in firewall policies between two
Section 2, there are different kinds of firewalls, and they address primary goals of networking: the security goal of "block traffic
different views of the network. A zone-based firewall (Section 2.1) unless it is explicitly allowed" and the networking goal of "trust
views the network as containing zones of trust, and deems hosts with new protocols". The two inherently cannot coexist easily
applications inside its zone of protection to be trustworthy. A in a set of policies for a firewall.
role-based firewall (Section 2.2) identifies parties on the basis of
membership in groups, and prevents unauthorized communication between
groups. A reputation, anomaly, or signature-based intrusion
management system depends on active administration, and permits known
applications to communicate while excluding unknown or known-evil
applications. In each case, the host or application is its own final
bastion of defense, but preventing a host from accepting incoming
traffic (so-called "host firewalls") does not defend infrastructure.
Each type of prophylactic has a purpose, and none of them is a
complete prophylactic defense.
Each type of defense, however, can be assisted by enabling an 3.1. Blocking Traffic Unless It Is Explicitly Allowed
application running in a host to inform the network of what it is
willing to receive. As noted in Section 2.1, a zone-based firewall,
generally denies all incoming sessions and permits responses to
sessions initiated outbound from the zone, but can in some cases be
configured to also permit specific classes of incoming session
requests, such as WWW or SMTP to an appropriate server. A simple way
to enable a zone-based firewall to prevent attacks on infrastructure
(traffic to an un instantiated address or to an application that is
off) while not impeding traffic that has a willing host and
application would be for the application to inform the firewall of
that willingness to receive. The Port Control Protocol
[I-D.ietf-pcp-base], or PCP, is an example of a protocol designed for
that purpose.
4. Recommendations The security goal of "block traffic unless it is explicitly allowed"
prevents useful new applications. This problem has been seen
repeatedly over the past decade: a new and useful application
protocol is deployed, but it cannot get wide adoption because it is
blocked by firewalls. The result has been a tendency to try to run
new protocols over established applications, particularly over HTTP
[RFC3205]. The result is protocols that do not work as well they
might if they were designed from scratch.
A general recommendation for the IETF: the IETF should not seek to Worse, the same goal prevents the deployment of useful transports
standardize something that is not being requested by consumers or other than TCP, UDP, and ICMP. A conservative firewall that only
industry. knows those three transports will block new transports such as SCTP
[RFC4960]; this in turn causes the Internet to not be able to grow in
a healthy fashion. Many firewalls will also block TCP and UDP
options they don't understand, and this has the same unfortunate
result.
Zone-based firewalls, when used, SHOULD exclude all session [[[ MORE HERE about forcing more costly and error-prone layer 7
initiation from outside the zone regardless of attributes such as the inspection ]]]
use of IPsec. They SHOULD also facilitate the use of a protocol such
as PCP by hosts to identify traffic (IPsec AH, IPsec ESP, transports
in general, or transports using specified destination port ranges)
that they are willing to receive, and interpret that into rules
permitting specified traffic to those specific systems. Being fully
automated and easily understood, such firewalls are appropriate for
networks with passive administration.
Role-based firewalls can be implemented using routing technology. 3.2. Typical Firewall Categories
For example, if Alice should not be able to send a message to Bob,
Alice might not be able to obtain Bob's address from DNS, Alice's
routing system might not have a route to Bob, or Bob's routing system
might not have a route to Alice. Role-based firewalls can also be
implemented using filtering technology; Alice, Alice's router, Bob's
router, or Bob may have a filter that prevents communication between
them. While there can be issues in specific cases, a routing
implementation is generally more scalable and more easily managed.
Reputation, anomaly, or signature-based intrusion management is Most IPv4 firewalls have pre-configured security policies that fall
generally proprietary; a service maintains the list of exclusions, into one of the following categories:
which must be updated as new kinds of attacks are developed.
Implementations SHOULD be designed for frequent and scalable
updating.
As further discussed in Section 2.1, firewalls of any type SHOULD NOT I: Block all outside-initiated traffic, allow all inside-initiated
attempt to perform the kind of deep packet inspection and surgery traffic
that is common with Network Address Translators [RFC2993]. There is
marginal value in detecting the spoofing of applications by attack
traffic, but the side-effects of preventing protocol improvement and
application innovation are destructive and unnecessary.
Apart from ICMP, tunnel encapsulations, routing protocols, and II: Same as I, but allow outside-initiated traffic to some
infrastructure protocols intended to manage network configuration and specific inside hosts. The specified hosts are often added by IP
use of addresses such as DNS or DHCP, applications MUST NOT expect a address (or sometimes by DNS host name), and the host may be
peer to be able to interpret network layer addresses carried in their limited to particular transport and application protocols. For
payload. Network layer addresses carried for documentation purposes, example, a rule might allow traffic destined to 203.0.113.226 on
such as in an SMTP envelope or a syslog message, have other value and TCP ports 80 and 443.
don't violate this recommendation.
5. IANA Considerations III: Same as I or II, but allow some outside-initiated traffic
over some protocols to all hosts. For example, a firewall
protecting a farm of web servers might want to allow traffic using
TCP ports 80 and 443 to all addresses protected by the firewall so
that new servers can be deployed without having to update the
firewall rules.
This memo asks the IANA for no new parameters. Firewalls that understand IPv6 may have a fourth category:
Note to RFC Editor: This section will have served its purpose if it IV: Allow nearly all outside-initiated traffic. [[[ MORE HERE
correctly tells IANA that no new assignments or registries are about why this is considered a good idea by some and a bad idea by
required, or if those assignments or registries are created during others ]]]]
the RFC publication process. From the author's perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
6. Security Considerations 3.3. Newer categories of firewalling
This note reasons about security considerations. It introduces no [[[ MORE HERE on blocking traffic based on dynamic origin reputation
such as the long-expired vyncke-advanced-ipv6-security ]]]
4. Recommendations for Operators
[[[ MORE HERE with the following outline ]]]
Firewalling strategies
None. This is really the operator's choice.
Be aware that deep packet inspection causes varying amounts of
delay in firewalls, particularly for long-lived flows
Don't enforce protocol semantics in the firewall
Applications are easier to change than firewalls
Avoid using application-layer gateways for firewalling
Use the security in the applications servers instead
Servers are easier to change than firewalls
However, ALGs are useful for IPv4-IPv6 conversion and proxying
in some protocols
Allow fragments
Except in specific protocols where layer 7 content filtering is
deemed crucial
Document your intended firewall strategy and settings
Be sure that other operators of the firewall are able to see it
Don't rely on a NAT for security (see Appendix A)
If using IPsec or SSL VPN, test whether the filtering rules for the
rest of the firewall apply
5. Recommendations for Firewall Vendors
[[[ MORE HERE with the following outline ]]]
Make a set of NAT-like rules for IPv6 easily choosable
Interface for pinholing of IPv4 NATs needs clearly identify security
issues
Follow the BEHAVE RFC rules for binding timeouts on NATs
Keep a summary log of non-normal events to aid reviewing
Make leaving notes about the firewalling rules easy and useful
Implement draft-ietf-pcp-base and probably the follow-on protocols
from that WG
6. IANA Considerations
None.
7. Security Considerations
This document is all about security considerations. It introduces no
new ones. new ones.
7. Acknowledgements 8. Acknowledgements
Warren Kumari commented on this note. Warren Kumari commented on this document.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 9.2. Informative References
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-26 (work in progress), June 2012.
[I-D.vyncke-advanced-ipv6-security] [EndToEnd]
Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end
Security for IPv6 CPE", arguments in system design", ACM Transactions on Computer
draft-vyncke-advanced-ipv6-security-03 (work in progress), Systems (TOCS) v.2 n.4, p277-288, Nov 1984.
October 2011.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
of Explicit Congestion Notification (ECN) to IP", RFC 3205, February 2002.
RFC 3168, September 2001.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009. Rules", RFC 5575, August 2009.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Appendix A. IPv4 NATs Are Not Security Devices
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092,
January 2011.
[Saltzer] Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end Their security is a side-effect of their design. [[[ MORE HERE about
arguments in system design", ACM Transactions on Computer the history and why some operators mistake the security policy of
Systems (TOCS) v.2 n.4, p277-288, Nov 1984. NATs with firewalls. ]]]
Author's Address [[[ MORE HERE about how pinholes mess badly that security policy. ]]]
[[[ MORE HERE about PCP and how to integrate it with a firewall
security policy. ]]]
Recommendations for deploying NATs in firewalls include:
o NATs should only be used when more IPv4 addresses are needed
o Operators should not pinhole to addresses that are unpredictably
assigned by DHCP
Appendix B. Origin Reputation and Firewalls
[[[ MORE HERE with the following outline ]]]
Letting someone else curate your security policy
Different types of reputation for different layers
draft-ietf-repute-model
draft-vyncke-advanced-ipv6-security
draft-hallambaker-omnibroker
Recommendations
Check logs to be sure updates are happening
Check vendors' policies
Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com Email: fred@cisco.com
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
 End of changes. 61 change blocks. 
323 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/