One document matched: draft-baker-opsawg-firewalls-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="bcp" docName="draft-baker-opsawg-firewalls-00"
ipr="trust200902">
<front>
<title abbrev="">On Firewalls in Internet Security</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2012" />
<area>Operations and Management</area>
<workgroup>Operations Area Working Group</workgroup>
<abstract>
<t>There is an ongoing discussion regarding the place of firewalls in
security. This note is intended to capture and try to make sense out of
it.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</note>
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Introduction">
<t>There is an ongoing discussion regarding the place of firewalls in
security. This note is intended to capture and try to make sense out of
it.</t>
<t>The IETF has a long and fractured discussion on security. Many early
RFCs simply didn't address the topic - and said as much. When the 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.</t>
<t>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. </t>
<t>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.</t>
</section>
<section anchor="kinds" title="Common kinds of firewalls">
<t>There are at least three common kinds of firewalls: <list
style="symbols">
<t>Context or Zone-based firewalls, that protect systems within a
perimeter from systems outside it,</t>
<t>Pervasive routing-based measures, which protect intermingled
systems from each other by enforcing role-based policies, and</t>
<t>Systems that analyze application behavior and trigger on events
that are unusual, match a signature, or involve an untrusted
peer.</t>
</list></t>
<section anchor="zbac"
title="Perimeter security: Protection from aliens and intruders">
<t>As discussed in <xref target="RFC6092"></xref>, 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.</t>
<t>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.</t>
<t>The existence and definition of zone-based perimeter defenses is arguably a side-effect of the deployment of Network Address
Translation <xref target="RFC2993"></xref>; 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.</t>
<t>While this can have useful side-effects, such as preventing the
passage of attack traffic that masquerades as some well-known
protocol, it also has the nasty side-effect of making innovation
difficult. For example, One of the issues in the deployment of <xref
target="RFC3168">Explicit Congestion Notification</xref>, for example,
has been that common firewalls often test unused bits and require them
to be set to zero to close covert channels. A similar problem has
slowed the deployment of <xref target="RFC4960">SCTP</xref>, 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.</t>
</section>
<section anchor="rbac" title="Pervasive access control">
<t>Another access control model, often called "Role-based", tries to
control traffic in flight regardless of the perimeter. Given a rule
that equipment located in a given routing domain or with a specific characteristic (such as "student
dorms") should not be able to access equipment in another domain or with a specific characteristic (such
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.</t>
<t>One common use of this model is in data centers, in which physical
or virtual machines from one tenant (which is not necessarily an
"owner" as much as it is a context in which the system is used) might
be co-resident with physical or virtual machines from another.
Inter-tenant attacks, espionage, and fraud are prevented by enforcing
a 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.</t>
<t>The major impediment in deployment is complexity. The
administration 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.</t>
</section>
<section anchor="norton"
title="Intrusion Management: Contract and Reputation filters">
<t>The model proposed in <xref
target="I-D.vyncke-advanced-ipv6-security">Advanced Security for IPv6
CPE</xref> could be compared to purchasing an anti-virus software
package for one's computer. The proposal is to install a set of
filters, perhaps automatically updated, that identify "bad stuff" and
make it inaccessible, while not impeding anything else.</t>
<t>It depends on four basic features: <list style="symbols">
<t>A frequently-updated signature-based Intrusion Prevention
System which inspects a pre-defined set of protocols at all layers
(from layer-3 to layer-7) and uses a vast set of heuristics to
detect attacks within one or several flow. Upon detection, the
flow is terminated and an event is logged for further optional
auditing.</t>
<t>A centralized reputation database that scores prefixes for
degree of trust. This is unlikely to be on addresses per se, as
Privacy Addresses change regularly and frequently.</t>
<t>Local correlation of attack-related information, and</t>
<t>Global correlation of attacks seen, in a reputation
database</t>
</list></t>
<t>The proposal doesn't mention anomaly-based intrusion detection,
which could be used to detect day-zero attacks and new applications or
attacks. This would be an obvious extension.</t>
<t>The comparison to anti-virus software is real; anti-virus software
uses similar algorithms, but on API calls or on data exchanged rather
than on network traffic, and for identified threats is often
effective.</t>
<t>The proposal also has weaknesses:<list style="symbols">
<t>People don't generally maintain anti-virus packages very well,
letting contracts expire,</t>
<t>Reputation databases have a bad reputation for distributing
information which is incorrect or out of date, </t>
<t>Anomaly-based analysis identifies changes but is often
ineffective 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</t>
<t>Signature-based analysis applies to attacks that have been
previously identified, and must be updated as new attacks develop.
As a result, in a world in which new attacks literally arise
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.</t>
</list></t>
<t>Security has to be maintained to be useful, because attacks are
maintained.</t>
</section>
</section>
<section anchor="reasoning" title="Reasoning about Firewalls">
<t></t>
<section anchor="e2e" title="The End-to-End Principle">
<t>One common complaint about firewalls in general is that they
violate the <xref target="Saltzer">End-to-End Principle</xref>. The
End-to-End Principle is often incorrectly stated as requiring that
"application specific functions ought to reside in the end hosts of a
network rather than in intermediary nodes, provided they can be
implemented 'completely 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 line of reasoning applicable when
considering any two communication layers. <list style="empty">
<t><xref target="Saltzer"></xref> "presents a design principle
that helps guide placement of functions among the modules of a
distributed computer system. The principle, called the end-to-end
argument, suggests that 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."</t>
</list></t>
<t>In other words, the End-to-End Argument is not a prohibition
against lower layer retries of transmissions, which can be important
in certain LAN technologies, nor of the maintenance of state, nor of
consistent policies imposed for security reasons. It is, however, a
plea for simplicity. Any behavior of a lower communication layer,
whether found in the same system as the higher layer (and especially
application) functionality or in a different one, that from the
perspective of a higher layer introduces inconsistency, complexity, or
coupling extracts a cost. That cost may be in user satisfaction,
difficulty of management or fault diagnosis, difficulty of future
innovation, reduced performance, or other forms. Such costs need to be
clearly and honestly weighed against the benefits expected, and used
only if the benefit outweighs the cost.</t>
<t>From that perspective, introduction of a policy that prevents
communication under an understood set of circumstances, whether it is
to prevent access to pornographic sites or prevents traffic that can
be characterized as an attack, does not fail the end to end argument;
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
easily explained and understood.</t>
<t>What does fail the end-to-end argument is behavior that is
intermittent, difficult to explain, or unpredictable. If I can
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
may not even know where to look for the issue.</t>
</section>
<section anchor="parts" title="Building a communication">
<t>Any communication requires at least three components: <list
style="symbols">
<t>a sender, someone or some thing that sends a message,</t>
<t>a receiver, someone or some thing that receives the message,
and</t>
<t>a channel, which is a medium by which the message is
communicated.</t>
</list></t>
<t>In the Internet, the IP network is the channel; it may traverse
something as simple as a directly connected cable or as complex as a
sequence of ISPs, but it is the means of communication. In normal
communications, a sender sends a message via the channel to the
receiver, who is willing to receive and operate on it. In contrast,
attacks are a form of harassment. A receiver exists, but is unwilling
to receive the message, has no application to operate on it, or is by
policy unwilling to. Attacks on infrastructure occur when message
volume overwhelms infrastructure or uses infrastructure but has no
obvious receiver.</t>
<t>By that line of reasoning, a firewall primarily protects
infrastructure, by preventing traffic that would attack it from it.
The best prophylactic might use a procedure for the dissemination of
<xref target="RFC5575">Flow Specification Rules</xref> to drop traffic
sent by an unauthorized or inappropriate sender or which has no host
or application willing to receive it as close as possible to the
sender.</t>
<t>In other words, as discussed in <xref target="intro"></xref>, a
firewall compares to the human skin, and has as its primary purpose
the prophylactic defense of a network. By extension, the firewall also
protects a set of hosts and applications, and the bandwidth that
serves them, as part 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 protected only by the skin has an immune system deficiency and
cannot be expected to long survive. That said, every security solution
has a set of vulnerabilities; the vulnerabilities of a layered defense
is the intersection of the vulnerabilities of the various layers
(e.g., a successful attack has to thread each layer of defense).</t>
</section>
<section anchor="howto" title="The middle way">
<t>There is therefore no one way to prevent attacks; as noted in <xref
target="kinds"></xref>, there are different kinds of firewalls, and
they address different views of the network. A zone-based firewall
(<xref target="zbac"></xref>) views the network as containing zones of
trust, and deems applications inside its zone of protection to be
trustworthy. A role-based firewall (<xref target="rbac"></xref>)
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.</t>
<t>Each type of defense, however, can be assisted by enabling an
application running in a host to inform the network of what it is
willing to receive. As noted in <xref target="zbac"></xref>, 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 <xref
target="I-D.ietf-pcp-base">Port Control Protocol</xref>, or PCP, is an
example of a protocol designed for that purpose.</t>
</section>
</section>
<section anchor="recommendation" title="Recommendations">
<t>A general recommendation for the IETF: the IETF should not seek to
standardize something that is not being requested by consumers or
industry.</t>
<t>Zone-based firewalls, when used, SHOULD exclude all session
initiation from outside the zone regardless of attributes such as the
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.</t>
<t>Role-based firewalls can be implemented using routing technology. 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.</t>
<t>Reputation, anomaly, or signature-based intrusion management is
generally proprietary; a service maintains the list of exclusions, which
must be updated as new kinds of attacks are developed. Implementations
SHOULD be designed for frequent and scalable updating.</t>
<t>As further discussed in <xref target="zbac"></xref>, firewalls of any
type SHOULD NOT attempt to perform the kind of deep packet inspection
and surgery that is common with Network Address Translators <xref
target="RFC2993"></xref>. 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.</t>
<t>Apart from routing protocols and infrastructure protocols intended to
manage network configuration and use of addresses such as DNS or DHCP,
applications MUST NOT expect a peer to be able to interpret network
layer addresses carried in their payload. Network layer addresses
carried for documentation purposes, such as in an SMTP envelope or a
syslog message, have other value and don't violate this
recommendation.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during 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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This note reasons about security considerations. It introduces no new
ones.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<?rfc needLines="5"?>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<?rfc needLines="5"?>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-pcp-base" ?>
<?rfc include="reference.I-D.vyncke-advanced-ipv6-security" ?>
<?rfc include="reference.RFC.2993"?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5575" ?>
<?rfc include="reference.RFC.6092" ?>
<reference anchor="Saltzer">
<front>
<title>End-to-end arguments in system design</title>
<author initials="JH" surname="Saltzer">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<author initials="DP" surname="Reed">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<author initials="DD" surname="Clark">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<date month="Nov" year="1984" />
</front>
<seriesInfo name="ACM Transactions on Computer Systems (TOCS)"
value="v.2 n.4, p277-288" />
<format target="http://mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf"
type="PDF" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:51 |