Operations Area Working Group                                   F. Baker
Internet-Draft                                             Cisco Systems
Intended status: BCP                                       June 12, 2012                                          P. Hoffman
Expires: December 14, April 21, 2013                                   VPN Consortium
                                                        October 18, 2012

                   On Firewalls in Internet Security
                     draft-ietf-opsawg-firewalls-00
                     draft-ietf-opsawg-firewalls-01

Abstract

   There is an ongoing discussion regarding

   This document discusses the place most important operational and security
   implications of using modern firewalls in
   security.  This note is intended to capture and try to make sense out networks.  It makes
   recommendations for operators of it.

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 firewalls, as described in [RFC2119]. well as for firewall
   vendors.

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 December 14, 2012. April 21, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Common kinds of firewalls
     1.1.  Modern Firewall Features That Should Not Be Confused
           with Firewalling . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Perimeter security: Protection from aliens and
           intruders .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Pervasive access control
   2.  High-Level Firewall Concepts . . . . . . . . . . . . . . . . .  5
     2.3.  Intrusion Management: Contract and Reputation filters  4
     2.1.  The End-to-End Principle . .  5
   3.  Reasoning about Firewalls . . . . . . . . . . . . . . .  4
     2.2.  Building a Communication . . .  7
     3.1.  The End-to-End Principle . . . . . . . . . . . . . .  5
   3.  Firewalling Strategies . . .  7
     3.2.  Building a communication . . . . . . . . . . . . . . . . .  8
     3.3.  The middle way  6
     3.1.  Blocking Traffic Unless It Is Explicitly Allowed . . . . .  7
     3.2.  Typical Firewall Categories  . . . . . . . . . . . . . . .  7
     3.3.  Newer categories of firewalling  . . . . . . . . . . . . .  8
   4.  Recommendations for Operators  . . . . . . . . . . . . . . . .  8
   5.  Recommendations for Firewall Vendors . . . . . . . . .  9
   5. . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address  9
   Appendix A.  IPv4 NATs Are Not Security Devices  . . . . . . . . . 10
   Appendix B.  Origin Reputation and Firewalls . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 . 10

1.  Introduction

   There

   In this document, a firewall is an ongoing discussion regarding the place of firewalls in
   security.  This note defined as a device or software that
   imposes a policy whose effect is intended "a stated type of packets may or may
   not pass from A to capture and try B".  All modern firewalls allow an administrator
   to make sense out change the policies in the firewall, although the ease of it.

   The IETF has a long
   administration for making those changes, and fractured discussion on security.  Many early
   RFCs simply didn't address the topic - and said as much.  When granularity of the
   IESG started complaining about that,
   policies, vary widely between firewalls and vendors.

   Given this definition, it was told is easy to see 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, is a perimeter
   (the position between A and procedures without necessarily explaining how they would be
   useful B) in deployment, and dismissed questions as "from those who
   don't understand." which the specific security policy
   applies.  In many cases, as typical deployed networks, there are usually some easy-
   to-define perimeters.  If two or more networks that are connected by
   a result, deployments have been
   underwhelming in both quantity and quality, and single device, the Internet is noted
   for its problems with security.  What is clear perimeter is inside the device.  If that people need to
   think clearly about security, their own and that of others.  What device
   is a firewall, it can impose a security policy at the shared
   perimeters of those networks.

   Many firewalls also employ some perimeters that are not clear is how as easy to do so
   define.  Some of these perimeters in modern firewalls include:

   o  An application-layer gateway (ALG) in front of a server creates a coherent and scalable manner.

   Prophylactic
      perimeter security in between that server and the form network it is connected to.
      The ALG blocks some of firewalls, the flows in the application protocol based
      on policies such as "do not all traffic from this network" and "do
      not allow the
   proper use client to send a message of them, have been this type".

   o  Routing domains that are controlled with role-based administration
      create perimeters in a fractious sub-topic routed network.  Role-based administration
      makes rules such as "Domain X cannot see Domain Y in its routing
      table"; this area.
   One could compare them to the human skin.  The service that the skin
   performs for the rest of the body is prevents any host in Domain X from sending traffic to keep common crud out,
      any host in Domain Y.

   o  [[[ MORE HERE with other interesting perimeters ]]]

   Modern firewalls apply perimeters at three layers:

      Layer 3: Most firewalls can filter based on source and as
   a result prevent much damage destination
      IPv4 addresses.  Many (but, frustratingly, not all) firewalls can
      filter based on IPv6 addresses.

      Layer 4: Most firewalls can filter based on TCP and infection that could otherwise
   occur.  The body supplies prophylactic perimeter security for itself UDP ports.
      Many (but, frustratingly, not all) firewalls can also filter based
      on transports other than TCP and then presumes that the security perimeter has been breached; real
   defenses against attacks UDP.

      Layer 7: Modern firewalls can filter based on the body include powerful systems that
   detect changes (anomalies) counterproductive to human health, and
   recognizable attack syndromes application
      protocol contents, such as common to allow or recently-seen
   diseases.  One might well ask, in view block certain types of
      protocol-defined messages, or based on the contents of those superior defenses,
   whether there is any value in the skin
      messages.

   Note that many firewall devices can only create policies 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 one or
   two of reasoning about the use of
   firewalls.  It will attempt layers.

   Hardware-based firewalls by their nature inspect traffic flowing
   through them, sometimes using proprietary mechanisms to end the bickering make traffic
   analysis as fast as possible on the topic, which
   is, for the most part, of little value in illuminating the
   discussion.

2.  Common kinds of given hardware.  Some 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,
   use network visibility protocols such as NetFlow and

   o  Systems that analyze application behavior sFlow to help
   capture and trigger on events
      that analyze traffic. [[ References needed ]]

1.1.  Modern Firewall Features That Should Not Be Confused with
      Firewalling

   There are unusual, match a signature, or involve an untrusted peer.

2.1.  Perimeter security: Protection from aliens and intruders

   As discussed few features that appear in [RFC6092], the most common kind of any 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 devices 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
   have become associated with 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 but in fact the
   protocol being passed.

   The existence and definition of zone-based perimeter defenses is
   arguably a side-effect of the deployment of are not used for
   firewalling.  Those non-firewalling features include:

      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
   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
   Explicit Congestion Notification [RFC3168], 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 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

   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.

   One common use of this model is in data centers, in (NAT) [RFC2993], 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.

   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.

2.3.  Intrusion Management: Contract and Reputation filters

   The model proposed in Advanced Security for IPv6 CPE
   [I-D.vyncke-advanced-ipv6-security] 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.

   It depends on four basic features:

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

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

   o  Local correlation of attack-related information, and

   o  Global correlation of attacks seen, in a reputation database

   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.

   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.

   The proposal also has weaknesses:

   o  People don't generally maintain anti-virus packages very well,
      letting contracts expire,

   o  Reputation databases have a bad reputation for distributing
      information
      security policy

      IPsec [RFC4301], which is incorrect or out of date,

   o  Anomaly-based analysis identifies changes but is often ineffective
      in determining whether new application or application behaviors
      are pernicious (false positives).  Someone therefore used for virtual private networks
      (VPNs).  Although the core IPsec protocol has to
      actively decide - firewalling in it,
      when IPsec appears in a workload firewall device, it is normally only
      associated with the average homeowner might have
      little patience for, application of authenticated encryption and

   o  Signature-based analysis applies to attacks
      integrity protection of traffic.

      "SSL VPN" is a set of technologies that have been
      previously identified, and must be updated rely on tunneling traffic
      through the TLS [RFC5246] protocol running on port 443.  Some
      firewalls offer SSL VPNs as new attacks develop.
      As a result, in an alternative to IPsec.

      Traffic prioritization is a world feature common in which new attacks literally arise
      daily, firewalls, but does
      not meet the administrative workload and be intense, and reflexive
      responses like accepting https certificates that are out definition of date
      or the download firewalling at all.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and installation of unsigned software on the
      assumption that the site admin is behind "OPTIONAL" in this
   document are themselves vectors
      for attack.

   Security has to be maintained to be useful, because attacks interpreted as described in [RFC2119].

   Some terms which have specific meanings in this document (such as
   "firewall") are
   maintained.

3.  Reasoning about Firewalls

3.1. defined earlier in this section.

2.  High-Level Firewall Concepts

2.1.  The End-to-End Principle

   One common complaint about firewalls in general is that they violate
   the End-to-End Principle [Saltzer]. [EndToEnd].  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.

      [Saltzer]  The
   document says that it "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."

   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.

   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.

   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.

3.2.

2.2.  Building a communication Communication

   Any communication requires at least three components:

   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 channel, which is a medium by which the message is communicated.

   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.

   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
   Flow Specification Rules
   flow specification rules from [RFC5575] 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.

   In other words, as discussed in Section 1, 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).

3.3.  The middle way

3.  Firewalling Strategies

   There is therefore no one way to prevent attacks; as noted in
   Section 2, there are different kinds of firewalls, and they address
   different views of the network.  A zone-based firewall (Section 2.1)
   views the network as containing zones of trust, and deems
   applications inside its zone of protection to be trustworthy.  A
   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 great deal of defense, however, can be assisted by enabling an
   application running tension in a host to inform firewall policies between two
   primary goals of networking: the network security goal of what "block traffic
   unless it is
   willing to receive.  As noted in Section 2.1, a zone-based firewall,
   generally denies all incoming sessions explicitly allowed" and permits responses to
   sessions initiated outbound from the zone, but can networking goal of "trust
   hosts with new protocols".  The two inherently cannot coexist easily
   in some cases be
   configured to also permit specific classes a set of incoming session
   requests, such as WWW or SMTP to an appropriate server.  A simple way
   to enable policies for 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 firewall.

3.1.  Blocking Traffic Unless It Is Explicitly Allowed

   The security goal of "block traffic that unless it is explicitly allowed"
   prevents useful new applications.  This problem has been seen
   repeatedly over the past decade: a willing host new and useful application would be for the application
   protocol is deployed, but it cannot get wide adoption because it is
   blocked by firewalls.  The result has been a tendency to inform the firewall of
   that willingness try to receive. run
   new protocols over established applications, particularly over HTTP
   [RFC3205].  The Port Control Protocol
   [I-D.ietf-pcp-base], or PCP, result is an example of a protocol designed for
   that purpose.

4.  Recommendations

   A general recommendation for the IETF: the IETF should not seek to
   standardize something protocols that is do not being requested by consumers or
   industry.

   Zone-based firewalls, when used, SHOULD exclude all session
   initiation work as well they
   might if they were designed from outside scratch.

   Worse, the same goal prevents the zone regardless deployment of attributes useful transports
   other than TCP, UDP, and ICMP.  A conservative firewall that only
   knows those three transports will block new transports such as SCTP
   [RFC4960]; this in turn causes the
   use of IPsec.  They SHOULD Internet to not be able to grow in
   a healthy fashion.  Many firewalls will also facilitate block TCP and UDP
   options they don't understand, and this has the use same unfortunate
   result.

   [[[ MORE HERE about forcing more costly and error-prone layer 7
   inspection ]]]

3.2.  Typical Firewall Categories

   Most IPv4 firewalls have pre-configured security policies that fall
   into one of a protocol such the following categories:

      I: Block all outside-initiated traffic, allow all inside-initiated
      traffic

      II: Same as PCP by hosts to identify I, but allow outside-initiated traffic (IPsec AH, IPsec ESP, transports
   in general, or transports using to some
      specific inside hosts.  The specified destination port ranges)
   that they hosts are willing often added by IP
      address (or sometimes by DNS host name), and the host may be
      limited to particular transport and application protocols.  For
      example, a rule might allow traffic destined to receive, 203.0.113.226 on
      TCP ports 80 and interpret that into rules
   permitting specified 443.

      III: Same as I or II, but allow some outside-initiated traffic
      over some protocols 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. all hosts.  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 firewall
      protecting a route to Bob, or Bob's routing system farm of web servers might not have a route want to Alice.  Role-based firewalls can also be
   implemented allow traffic using filtering technology; Alice, Alice's router, Bob's
   router, or Bob may have a filter
      TCP ports 80 and 443 to all addresses protected by the firewall so
      that prevents communication between
   them.  While there new servers can be issues in specific cases, deployed without having to update the
      firewall rules.

   Firewalls that understand IPv6 may have a routing
   implementation fourth category:

      IV: Allow nearly all outside-initiated traffic. [[[ MORE HERE
      about why this is generally more scalable considered a good idea by some and more easily managed.

   Reputation, anomaly, or signature-based intrusion management is
   generally proprietary; a service maintains the list bad idea by
      others ]]]]

3.3.  Newer categories of exclusions,
   which must be updated firewalling

   [[[ MORE HERE on blocking traffic based on dynamic origin reputation
   such as new kinds of attacks are developed.
   Implementations SHOULD be designed the long-expired vyncke-advanced-ipv6-security ]]]

4.  Recommendations for frequent and scalable
   updating.

   As further discussed in Section 2.1, firewalls of any type SHOULD NOT
   attempt to perform Operators

   [[[ MORE HERE with the kind of following outline ]]]

   Firewalling strategies
      None. This is really the operator's choice.
      Be aware that deep packet inspection and surgery
   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 causes varying amounts of preventing
         delay in firewalls, particularly for long-lived flows
   Don't enforce protocol improvement and
   application innovation semantics in the firewall
      Applications are destructive and unnecessary.

   Apart from ICMP, tunnel encapsulations, routing protocols, and
   infrastructure protocols intended easier to manage network configuration and
   use of addresses such as DNS or DHCP, change than firewalls
   Avoid using application-layer gateways for firewalling
      Use the security in the applications MUST NOT expect a
   peer to be able servers instead
      Servers are easier to interpret network layer addresses carried in their
   payload.  Network layer addresses carried change than firewalls
      However, ALGs are useful for documentation purposes,
   such as IPv4-IPv6 conversion and proxying
         in an SMTP envelope or a syslog message, have other value some protocols
   Allow fragments
      Except in specific protocols where layer 7 content filtering is
         deemed crucial
   Document your intended firewall strategy and
   don't violate this recommendation.

5.  IANA Considerations

   This memo asks settings
      Be sure that other operators of the IANA for no new parameters.

   Note firewall are able to RFC Editor: This section will have served its purpose if see it
   correctly tells IANA that no new assignments or registries are
   required, or if those assignments
   Don't rely on a NAT for security (see Appendix A)
   If using IPsec or registries are created during SSL VPN, test whether the RFC publication process.  From filtering rules for the author's perspective, it may
   therefore be removed upon publication as an RFC at
      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 Editor's
   discretion. 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 note reasons document is all about security considerations.  It introduces no
   new ones.

7.

8.  Acknowledgements

   Warren Kumari commented on this note.

8. document.

9.  References

8.1.

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.

9.2.  Informative References

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R.,

   [EndToEnd]
              Saltzer, JH., Reed, DP., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-26 (work in progress), June 2012.

   [I-D.vyncke-advanced-ipv6-security]
              Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced
              Security for IPv6 CPE",
              draft-vyncke-advanced-ipv6-security-03 (work DD. Clark, "End-to-end
              arguments in progress),
              October 2011. system design", ACM Transactions on Computer
              Systems (TOCS) v.2 n.4, p277-288, Nov 1984.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3168]  Ramakrishnan,

   [RFC3205]  Moore, K., Floyd, S., and D. Black, "The Addition "On the use of Explicit Congestion Notification (ECN) to IP", HTTP as a Substrate", BCP 56,
              RFC 3168, September 2001. 3205, February 2002.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              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.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, August 2009.

   [RFC6092]  Woodyatt, J., "Recommended Simple

Appendix A.  IPv4 NATs Are Not Security Capabilities in
              Customer Premises Equipment (CPE) for Providing
              Residential IPv6 Internet Service", RFC 6092,
              January 2011.

   [Saltzer]  Saltzer, JH., Reed, DP., Devices

   Their security is a side-effect of their design. [[[ MORE HERE about
   the history and DD. Clark, "End-to-end
              arguments why some operators mistake the security policy of
   NATs with firewalls. ]]]

   [[[ 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 system design", ACM Transactions on Computer
              Systems (TOCS) v.2 n.4, p277-288, Nov 1984.

Author's Address 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
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com

   Paul Hoffman
   VPN Consortium

   Email: paul.hoffman@vpnc.org