idnits 2.17.1 draft-ietf-opsawg-firewalls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 18, 2012) is 4201 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Area Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: BCP P. Hoffman 5 Expires: April 21, 2013 VPN Consortium 6 October 18, 2012 8 On Firewalls in Internet Security 9 draft-ietf-opsawg-firewalls-01 11 Abstract 13 This document discusses the most important operational and security 14 implications of using modern firewalls in networks. It makes 15 recommendations for operators of firewalls, as well as for firewall 16 vendors. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 21, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Modern Firewall Features That Should Not Be Confused 54 with Firewalling . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. High-Level Firewall Concepts . . . . . . . . . . . . . . . . . 4 57 2.1. The End-to-End Principle . . . . . . . . . . . . . . . . . 4 58 2.2. Building a Communication . . . . . . . . . . . . . . . . . 5 59 3. Firewalling Strategies . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Blocking Traffic Unless It Is Explicitly Allowed . . . . . 7 61 3.2. Typical Firewall Categories . . . . . . . . . . . . . . . 7 62 3.3. Newer categories of firewalling . . . . . . . . . . . . . 8 63 4. Recommendations for Operators . . . . . . . . . . . . . . . . 8 64 5. Recommendations for Firewall Vendors . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Appendix A. IPv4 NATs Are Not Security Devices . . . . . . . . . 10 72 Appendix B. Origin Reputation and Firewalls . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 In this document, a firewall is defined as a device or software that 78 imposes a policy whose effect is "a stated type of packets may or may 79 not pass from A to B". All modern firewalls allow an administrator 80 to change the policies in the firewall, although the ease of 81 administration for making those changes, and the granularity of the 82 policies, vary widely between firewalls and vendors. 84 Given this definition, it is easy to see that there is a perimeter 85 (the position between A and B) in which the specific security policy 86 applies. In typical deployed networks, there are usually some easy- 87 to-define perimeters. If two or more networks that are connected by 88 a single device, the perimeter is inside the device. If that device 89 is a firewall, it can impose a security policy at the shared 90 perimeters of those networks. 92 Many firewalls also employ some perimeters that are not as easy to 93 define. Some of these perimeters in modern firewalls include: 95 o An application-layer gateway (ALG) in front of a server creates a 96 perimeter between that server and the network it is connected to. 97 The ALG blocks some of the flows in the application protocol based 98 on policies such as "do not all traffic from this network" and "do 99 not allow the client to send a message of this type". 101 o Routing domains that are controlled with role-based administration 102 create perimeters in a routed network. Role-based administration 103 makes rules such as "Domain X cannot see Domain Y in its routing 104 table"; this prevents any host in Domain X from sending traffic to 105 any host in Domain Y. 107 o [[[ MORE HERE with other interesting perimeters ]]] 109 Modern firewalls apply perimeters at three layers: 111 Layer 3: Most firewalls can filter based on source and destination 112 IPv4 addresses. Many (but, frustratingly, not all) firewalls can 113 filter based on IPv6 addresses. 115 Layer 4: Most firewalls can filter based on TCP and UDP ports. 116 Many (but, frustratingly, not all) firewalls can also filter based 117 on transports other than TCP and UDP. 119 Layer 7: Modern firewalls can filter based on the application 120 protocol contents, such as to allow or block certain types of 121 protocol-defined messages, or based on the contents of those 122 messages. 124 Note that many firewall devices can only create policies at one or 125 two of the layers. 127 Hardware-based firewalls by their nature inspect traffic flowing 128 through them, sometimes using proprietary mechanisms to make traffic 129 analysis as fast as possible on the given hardware. Some firewalls 130 use network visibility protocols such as NetFlow and sFlow to help 131 capture and analyze traffic. [[ References needed ]] 133 1.1. Modern Firewall Features That Should Not Be Confused with 134 Firewalling 136 There are a few features that appear in any firewall devices that 137 have become associated with firewalls but in fact are not used for 138 firewalling. Those non-firewalling features include: 140 Network Address Translation (NAT) [RFC2993], which is not used for 141 security policy 143 IPsec [RFC4301], which is used for virtual private networks 144 (VPNs). Although the core IPsec protocol has firewalling in it, 145 when IPsec appears in a firewall device, it is normally only 146 associated with the application of authenticated encryption and 147 integrity protection of traffic. 149 "SSL VPN" is a set of technologies that rely on tunneling traffic 150 through the TLS [RFC5246] protocol running on port 443. Some 151 firewalls offer SSL VPNs as an alternative to IPsec. 153 Traffic prioritization is a feature common in firewalls, but does 154 not meet the definition of firewalling at all. 156 1.2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 Some terms which have specific meanings in this document (such as 163 "firewall") are defined earlier in this section. 165 2. High-Level Firewall Concepts 167 2.1. The End-to-End Principle 169 One common complaint about firewalls in general is that they violate 170 the End-to-End Principle [EndToEnd]. The End-to-End Principle is 171 often incorrectly stated as requiring that "application specific 172 functions ought to reside in the end hosts of a network rather than 173 in intermediary nodes, provided they can be implemented 'completely 174 and correctly' in the end hosts" or that "there should be no state in 175 the network." 177 What it actually says is heavily nuanced, and is a line of reasoning 178 applicable when considering any two communication layers. The 179 document says that it "presents a design principle that helps guide 180 placement of functions among the modules of a distributed computer 181 system. The principle, called the end-to-end argument, suggests that 182 functions placed at low levels of a system may be redundant or of 183 little value when compared with the cost of providing them at that 184 low level." 186 In other words, the End-to-End Argument is not a prohibition against 187 lower layer retries of transmissions, which can be important in 188 certain LAN technologies, nor of the maintenance of state, nor of 189 consistent policies imposed for security reasons. It is, however, a 190 plea for simplicity. Any behavior of a lower communication layer, 191 whether found in the same system as the higher layer (and especially 192 application) functionality or in a different one, that from the 193 perspective of a higher layer introduces inconsistency, complexity, 194 or coupling extracts a cost. That cost may be in user satisfaction, 195 difficulty of management or fault diagnosis, difficulty of future 196 innovation, reduced performance, or other forms. Such costs need to 197 be clearly and honestly weighed against the benefits expected, and 198 used only if the benefit outweighs the cost. 200 From that perspective, introduction of a policy that prevents 201 communication under an understood set of circumstances, whether it is 202 to prevent access to pornographic sites or prevents traffic that can 203 be characterized as an attack, does not fail the end to end argument; 204 there are any number of possible sites on the network that are 205 inaccessible at any given time, and the presence of such a policy is 206 easily explained and understood. 208 What does fail the end-to-end argument is behavior that is 209 intermittent, difficult to explain, or unpredictable. If I can 210 sometimes reach a site and not at other times, or reach it using this 211 host or application but not another, I wonder why that is true, and 212 may not even know where to look for the issue. 214 2.2. Building a Communication 216 Any communication requires at least three components: 218 o a sender, someone or some thing that sends a message, 220 o a receiver, someone or some thing that receives the message, and 222 o a channel, which is a medium by which the message is communicated. 224 In the Internet, the IP network is the channel; it may traverse 225 something as simple as a directly connected cable or as complex as a 226 sequence of ISPs, but it is the means of communication. In normal 227 communications, a sender sends a message via the channel to the 228 receiver, who is willing to receive and operate on it. In contrast, 229 attacks are a form of harassment. A receiver exists, but is 230 unwilling to receive the message, has no application to operate on 231 it, or is by policy unwilling to. Attacks on infrastructure occur 232 when message volume overwhelms infrastructure or uses infrastructure 233 but has no obvious receiver. 235 By that line of reasoning, a firewall primarily protects 236 infrastructure, by preventing traffic that would attack it from it. 237 The best prophylactic might use a procedure for the dissemination of 238 flow specification rules from [RFC5575] to drop traffic sent by an 239 unauthorized or inappropriate sender or which has no host or 240 application willing to receive it as close as possible to the sender. 242 In other words, as discussed in Section 1, a firewall compares to the 243 human skin, and has as its primary purpose the prophylactic defense 244 of a network. By extension, the firewall also protects a set of 245 hosts and applications, and the bandwidth that serves them, as part 246 of a strategy of defense in depth. A firewall is not itself a 247 security strategy; the analogy to the skin would say that a body 248 protected only by the skin has an immune system deficiency and cannot 249 be expected to long survive. That said, every security solution has 250 a set of vulnerabilities; the vulnerabilities of a layered defense is 251 the intersection of the vulnerabilities of the various layers (e.g., 252 a successful attack has to thread each layer of defense). 254 3. Firewalling Strategies 256 There is a great deal of tension in firewall policies between two 257 primary goals of networking: the security goal of "block traffic 258 unless it is explicitly allowed" and the networking goal of "trust 259 hosts with new protocols". The two inherently cannot coexist easily 260 in a set of policies for a firewall. 262 3.1. Blocking Traffic Unless It Is Explicitly Allowed 264 The security goal of "block traffic unless it is explicitly allowed" 265 prevents useful new applications. This problem has been seen 266 repeatedly over the past decade: a new and useful application 267 protocol is deployed, but it cannot get wide adoption because it is 268 blocked by firewalls. The result has been a tendency to try to run 269 new protocols over established applications, particularly over HTTP 270 [RFC3205]. The result is protocols that do not work as well they 271 might if they were designed from scratch. 273 Worse, the same goal prevents the deployment of useful transports 274 other than TCP, UDP, and ICMP. A conservative firewall that only 275 knows those three transports will block new transports such as SCTP 276 [RFC4960]; this in turn causes the Internet to not be able to grow in 277 a healthy fashion. Many firewalls will also block TCP and UDP 278 options they don't understand, and this has the same unfortunate 279 result. 281 [[[ MORE HERE about forcing more costly and error-prone layer 7 282 inspection ]]] 284 3.2. Typical Firewall Categories 286 Most IPv4 firewalls have pre-configured security policies that fall 287 into one of the following categories: 289 I: Block all outside-initiated traffic, allow all inside-initiated 290 traffic 292 II: Same as I, but allow outside-initiated traffic to some 293 specific inside hosts. The specified hosts are often added by IP 294 address (or sometimes by DNS host name), and the host may be 295 limited to particular transport and application protocols. For 296 example, a rule might allow traffic destined to 203.0.113.226 on 297 TCP ports 80 and 443. 299 III: Same as I or II, but allow some outside-initiated traffic 300 over some protocols to all hosts. For example, a firewall 301 protecting a farm of web servers might want to allow traffic using 302 TCP ports 80 and 443 to all addresses protected by the firewall so 303 that new servers can be deployed without having to update the 304 firewall rules. 306 Firewalls that understand IPv6 may have a fourth category: 308 IV: Allow nearly all outside-initiated traffic. [[[ MORE HERE 309 about why this is considered a good idea by some and a bad idea by 310 others ]]]] 312 3.3. Newer categories of firewalling 314 [[[ MORE HERE on blocking traffic based on dynamic origin reputation 315 such as the long-expired vyncke-advanced-ipv6-security ]]] 317 4. Recommendations for Operators 319 [[[ MORE HERE with the following outline ]]] 321 Firewalling strategies 322 None. This is really the operator's choice. 323 Be aware that deep packet inspection causes varying amounts of 324 delay in firewalls, particularly for long-lived flows 325 Don't enforce protocol semantics in the firewall 326 Applications are easier to change than firewalls 327 Avoid using application-layer gateways for firewalling 328 Use the security in the applications servers instead 329 Servers are easier to change than firewalls 330 However, ALGs are useful for IPv4-IPv6 conversion and proxying 331 in some protocols 332 Allow fragments 333 Except in specific protocols where layer 7 content filtering is 334 deemed crucial 335 Document your intended firewall strategy and settings 336 Be sure that other operators of the firewall are able to see it 337 Don't rely on a NAT for security (see Appendix A) 338 If using IPsec or SSL VPN, test whether the filtering rules for the 339 rest of the firewall apply 341 5. Recommendations for Firewall Vendors 343 [[[ MORE HERE with the following outline ]]] 345 Make a set of NAT-like rules for IPv6 easily choosable 346 Interface for pinholing of IPv4 NATs needs clearly identify security 347 issues 348 Follow the BEHAVE RFC rules for binding timeouts on NATs 349 Keep a summary log of non-normal events to aid reviewing 350 Make leaving notes about the firewalling rules easy and useful 351 Implement draft-ietf-pcp-base and probably the follow-on protocols 352 from that WG 354 6. IANA Considerations 356 None. 358 7. Security Considerations 360 This document is all about security considerations. It introduces no 361 new ones. 363 8. Acknowledgements 365 Warren Kumari commented on this document. 367 9. References 369 9.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 9.2. Informative References 376 [EndToEnd] 377 Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end 378 arguments in system design", ACM Transactions on Computer 379 Systems (TOCS) v.2 n.4, p277-288, Nov 1984. 381 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 382 November 2000. 384 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 385 RFC 3205, February 2002. 387 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 388 Internet Protocol", RFC 4301, December 2005. 390 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 391 RFC 4960, September 2007. 393 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 394 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 396 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 397 and D. McPherson, "Dissemination of Flow Specification 398 Rules", RFC 5575, August 2009. 400 Appendix A. IPv4 NATs Are Not Security Devices 402 Their security is a side-effect of their design. [[[ MORE HERE about 403 the history and why some operators mistake the security policy of 404 NATs with firewalls. ]]] 406 [[[ MORE HERE about how pinholes mess badly that security policy. ]]] 408 [[[ MORE HERE about PCP and how to integrate it with a firewall 409 security policy. ]]] 411 Recommendations for deploying NATs in firewalls include: 413 o NATs should only be used when more IPv4 addresses are needed 415 o Operators should not pinhole to addresses that are unpredictably 416 assigned by DHCP 418 Appendix B. Origin Reputation and Firewalls 420 [[[ MORE HERE with the following outline ]]] 422 Letting someone else curate your security policy 423 Different types of reputation for different layers 424 draft-ietf-repute-model 425 draft-vyncke-advanced-ipv6-security 426 draft-hallambaker-omnibroker 427 Recommendations 428 Check logs to be sure updates are happening 429 Check vendors' policies 431 Authors' Addresses 433 Fred Baker 434 Cisco Systems 436 Email: fred@cisco.com 438 Paul Hoffman 439 VPN Consortium 441 Email: paul.hoffman@vpnc.org