idnits 2.17.1 draft-baker-opsawg-firewalls-00.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 date (January 21, 2012) is 4451 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) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-22 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 January 21, 2012 5 Expires: July 24, 2012 7 On Firewalls in Internet Security 8 draft-baker-opsawg-firewalls-00 10 Abstract 12 There is an ongoing discussion regarding the place of firewalls in 13 security. This note is intended to capture and try to make sense out 14 of it. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in [RFC2119]. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 24, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Common kinds of firewalls . . . . . . . . . . . . . . . . . . 3 58 2.1. Perimeter security: Protection from aliens and 59 intruders . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Pervasive access control . . . . . . . . . . . . . . . . . 5 61 2.3. Intrusion Management: Contract and Reputation filters . . 5 62 3. Reasoning about Firewalls . . . . . . . . . . . . . . . . . . 7 63 3.1. The End-to-End Principle . . . . . . . . . . . . . . . . . 7 64 3.2. Building a communication . . . . . . . . . . . . . . . . . 8 65 3.3. The middle way . . . . . . . . . . . . . . . . . . . . . . 8 66 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 There is an ongoing discussion regarding the place of firewalls in 78 security. This note is intended to capture and try to make sense out 79 of it. 81 The IETF has a long and fractured discussion on security. Many early 82 RFCs simply didn't address the topic - and said as much. When the 83 IESG started complaining about that, it was told that there was no 84 market interest in the topic that was measurable in money spent. 85 Those who *were* interested in the topic set forth frameworks, rules, 86 and procedures without necessarily explaining how they would be 87 useful in deployment, and dismissed questions as "from those who 88 don't understand." In many cases, as a result, deployments have been 89 underwhelming in both quantity and quality, and the Internet is noted 90 for its problems with security. What is clear is that people need to 91 think clearly about security, their own and that of others. What is 92 not clear is how to do so in a coherent and scalable manner. 94 Prophylactic perimeter security in the form of firewalls, and the 95 proper use of them, have been a fractious sub-topic in this area. 96 One could compare them to the human skin. The service that the skin 97 performs for the rest of the body is to keep common crud out, and as 98 a result prevent much damage and infection that could otherwise 99 occur. The body supplies prophylactic perimeter security for itself 100 and then presumes that the security perimeter has been breached; real 101 defenses against attacks on the body include powerful systems that 102 detect changes (anomalies) counterproductive to human health, and 103 recognizable attack syndromes such as common or recently-seen 104 diseases. One might well ask, in view of those superior defenses, 105 whether there is any value in the skin at all; the value is easily 106 stated, however. It is not in preventing the need for the stronger 107 solutions, but in making their expensive invocation less needful and 108 more focused. 110 This note will address common kinds of firewalls and the claims made 111 for them. It will suggest a line of reasoning about the use of 112 firewalls. It will attempt to end the bickering on the topic, which 113 is, for the most part, of little value in illuminating the 114 discussion. 116 2. Common kinds of firewalls 118 There are at least three common kinds of firewalls: 120 o Context or Zone-based firewalls, that protect systems within a 121 perimeter from systems outside it, 123 o Pervasive routing-based measures, which protect intermingled 124 systems from each other by enforcing role-based policies, and 126 o Systems that analyze application behavior and trigger on events 127 that are unusual, match a signature, or involve an untrusted peer. 129 2.1. Perimeter security: Protection from aliens and intruders 131 As discussed in [RFC6092], the most common kind of firewall is used 132 at the perimeter of a network. Perimeter security assumes two 133 things: that applications and equipment inside the perimeter are 134 under the control of the local administration and are therefore 135 probably doing reasonable things, and that applications and equipment 136 outside the perimeter are unknown. It may make simple permission 137 rules, such as that external web clients are permitted to access a 138 specific web server or that SMTP peers are permitted to access 139 internal SMTP MTAs. Apart from those rules, a session may be 140 initiated from inside the perimeter, and responses from outside will 141 be allowed through the firewall, but sessions may never be initiated 142 from outside. 144 In addition, perimeter firewalls often perform some level of testing, 145 either as application proxies or through deep packet inspection, to 146 verify that the protocol claimed to be being passed is in fact the 147 protocol being passed. 149 The existence and definition of zone-based perimeter defenses is 150 arguably a side-effect of the deployment of Network Address 151 Translation [RFC2993]; applications frequently make the mistake of 152 coupling application identities to network layer addresses, and in so 153 doing make two other coupling assumptions: that an address useful to 154 and understood by one application is useful to and understood by 155 another, and that addresses are unlikely to change within a time 156 frame useful to the application. Network Address Translation forces 157 the translator to interpret packet payloads and change addresses 158 where used by applications. If the transport or application headers 159 are not understood by the translator, this has the effect of damaging 160 or preventing communication. Detection of such issues can be sold as 161 a security feature, although it is really a side-effect of a failure. 163 While this can have useful side-effects, such as preventing the 164 passage of attack traffic that masquerades as some well-known 165 protocol, it also has the nasty side-effect of making innovation 166 difficult. For example, One of the issues in the deployment of 167 Explicit Congestion Notification [RFC3168], for example, has been 168 that common firewalls often test unused bits and require them to be 169 set to zero to close covert channels. A similar problem has slowed 170 the deployment of SCTP [RFC4960], in that a firewall will often not 171 permit a protocol it doesn't know even if a user behind it opens the 172 session. When a new protocol or feature is defined, the firewall 173 needs to stop applying that rule, and that can be difficult to make 174 happen. 176 2.2. Pervasive access control 178 Another access control model, often called "Role-based", tries to 179 control traffic in flight regardless of the perimeter. Given a rule 180 that equipment located in a given routing domain or with a specific 181 characteristic (such as "student dorms") should not be able to access 182 equipment in another domain or with a specific characteristic (such 183 as "academic records"), it might prevent routing from announcing the 184 second route in the domain of the first, or it might tag individual 185 packets ("I'm from the student dorm") and filter on those tags at 186 enforcement points throughout network. Such rules can be applied to 187 individuals are well as equipment; in that case, the host needs to 188 tag the traffic, or there must be a reliable correlation between 189 equipment and its user. 191 One common use of this model is in data centers, in which physical or 192 virtual machines from one tenant (which is not necessarily an "owner" 193 as much as it is a context in which the system is used) might be co- 194 resident with physical or virtual machines from another. Inter- 195 tenant attacks, espionage, and fraud are prevented by enforcing a 196 rule that traffic from systems used by any given tenant is only 197 delivered to other systems used by the same tenant. This might, of 198 course have nuances; under stated circumstances, identified systems 199 or identified users might be able to cross such a boundary. 201 The major impediment in deployment is complexity. The administration 202 has the option to assign policies for individuals on the basis of 203 their current location (e.g. as the cross-product of people, 204 equipment, and topology), meaning that policies can multiply wildly. 205 The administrator that applies a complex role-based access policy is 206 probably most justly condemned to live in the world he or she has 207 created. 209 2.3. Intrusion Management: Contract and Reputation filters 211 The model proposed in Advanced Security for IPv6 CPE 212 [I-D.vyncke-advanced-ipv6-security] could be compared to purchasing 213 an anti-virus software package for one's computer. The proposal is 214 to install a set of filters, perhaps automatically updated, that 215 identify "bad stuff" and make it inaccessible, while not impeding 216 anything else. 218 It depends on four basic features: 220 o A frequently-updated signature-based Intrusion Prevention System 221 which inspects a pre-defined set of protocols at all layers (from 222 layer-3 to layer-7) and uses a vast set of heuristics to detect 223 attacks within one or several flow. Upon detection, the flow is 224 terminated and an event is logged for further optional auditing. 226 o A centralized reputation database that scores prefixes for degree 227 of trust. This is unlikely to be on addresses per se, as Privacy 228 Addresses change regularly and frequently. 230 o Local correlation of attack-related information, and 232 o Global correlation of attacks seen, in a reputation database 234 The proposal doesn't mention anomaly-based intrusion detection, which 235 could be used to detect day-zero attacks and new applications or 236 attacks. This would be an obvious extension. 238 The comparison to anti-virus software is real; anti-virus software 239 uses similar algorithms, but on API calls or on data exchanged rather 240 than on network traffic, and for identified threats is often 241 effective. 243 The proposal also has weaknesses: 245 o People don't generally maintain anti-virus packages very well, 246 letting contracts expire, 248 o Reputation databases have a bad reputation for distributing 249 information which is incorrect or out of date, 251 o Anomaly-based analysis identifies changes but is often ineffective 252 in determining whether new application or application behaviors 253 are pernicious (false positives). Someone therefore has to 254 actively decide - a workload the average homeowner might have 255 little patience for, and 257 o Signature-based analysis applies to attacks that have been 258 previously identified, and must be updated as new attacks develop. 259 As a result, in a world in which new attacks literally arise 260 daily, the administrative workload and be intense, and reflexive 261 responses like accepting https certificates that are out of date 262 or the download and installation of unsigned software on the 263 assumption that the site admin is behind are themselves vectors 264 for attack. 266 Security has to be maintained to be useful, because attacks are 267 maintained. 269 3. Reasoning about Firewalls 271 3.1. The End-to-End Principle 273 One common complaint about firewalls in general is that they violate 274 the End-to-End Principle [Saltzer]. The End-to-End Principle is 275 often incorrectly stated as requiring that "application specific 276 functions ought to reside in the end hosts of a network rather than 277 in intermediary nodes, provided they can be implemented 'completely 278 and correctly' in the end hosts" or that "there should be no state in 279 the network." What it actually says is heavily nuanced, and is a 280 line of reasoning applicable when considering any two communication 281 layers. 283 [Saltzer] "presents a design principle that helps guide placement 284 of functions among the modules of a distributed computer system. 285 The principle, called the end-to-end argument, suggests that 286 functions placed at low levels of a system may be redundant or of 287 little value when compared with the cost of providing them at that 288 low level." 290 In other words, the End-to-End Argument is not a prohibition against 291 lower layer retries of transmissions, which can be important in 292 certain LAN technologies, nor of the maintenance of state, nor of 293 consistent policies imposed for security reasons. It is, however, a 294 plea for simplicity. Any behavior of a lower communication layer, 295 whether found in the same system as the higher layer (and especially 296 application) functionality or in a different one, that from the 297 perspective of a higher layer introduces inconsistency, complexity, 298 or coupling extracts a cost. That cost may be in user satisfaction, 299 difficulty of management or fault diagnosis, difficulty of future 300 innovation, reduced performance, or other forms. Such costs need to 301 be clearly and honestly weighed against the benefits expected, and 302 used only if the benefit outweighs the cost. 304 From that perspective, introduction of a policy that prevents 305 communication under an understood set of circumstances, whether it is 306 to prevent access to pornographic sites or prevents traffic that can 307 be characterized as an attack, does not fail the end to end argument; 308 there are any number of possible sites on the network that are 309 inaccessible at any given time, and the presence of such a policy is 310 easily explained and understood. 312 What does fail the end-to-end argument is behavior that is 313 intermittent, difficult to explain, or unpredictable. If I can 314 sometimes reach a site and not at other times, or reach it using this 315 host or application but not another, I wonder why that is true, and 316 may not even know where to look for the issue. 318 3.2. Building a communication 320 Any communication requires at least three components: 322 o a sender, someone or some thing that sends a message, 324 o a receiver, someone or some thing that receives the message, and 326 o a channel, which is a medium by which the message is communicated. 328 In the Internet, the IP network is the channel; it may traverse 329 something as simple as a directly connected cable or as complex as a 330 sequence of ISPs, but it is the means of communication. In normal 331 communications, a sender sends a message via the channel to the 332 receiver, who is willing to receive and operate on it. In contrast, 333 attacks are a form of harassment. A receiver exists, but is 334 unwilling to receive the message, has no application to operate on 335 it, or is by policy unwilling to. Attacks on infrastructure occur 336 when message volume overwhelms infrastructure or uses infrastructure 337 but has no obvious receiver. 339 By that line of reasoning, a firewall primarily protects 340 infrastructure, by preventing traffic that would attack it from it. 341 The best prophylactic might use a procedure for the dissemination of 342 Flow Specification Rules [RFC5575] to drop traffic sent by an 343 unauthorized or inappropriate sender or which has no host or 344 application willing to receive it as close as possible to the sender. 346 In other words, as discussed in Section 1, a firewall compares to the 347 human skin, and has as its primary purpose the prophylactic defense 348 of a network. By extension, the firewall also protects a set of 349 hosts and applications, and the bandwidth that serves them, as part 350 of a strategy of defense in depth. A firewall is not itself a 351 security strategy; the analogy to the skin would say that a body 352 protected only by the skin has an immune system deficiency and cannot 353 be expected to long survive. That said, every security solution has 354 a set of vulnerabilities; the vulnerabilities of a layered defense is 355 the intersection of the vulnerabilities of the various layers (e.g., 356 a successful attack has to thread each layer of defense). 358 3.3. The middle way 360 There is therefore no one way to prevent attacks; as noted in 361 Section 2, there are different kinds of firewalls, and they address 362 different views of the network. A zone-based firewall (Section 2.1) 363 views the network as containing zones of trust, and deems 364 applications inside its zone of protection to be trustworthy. A 365 role-based firewall (Section 2.2) identifies parties on the basis of 366 membership in groups, and prevents unauthorized communication between 367 groups. A reputation, anomaly, or signature-based intrusion 368 management system depends on active administration, and permits known 369 applications to communicate while excluding unknown or known-evil 370 applications. In each case, the host or application is its own final 371 bastion of defense, but preventing a host from accepting incoming 372 traffic (so-called "host firewalls") does not defend infrastructure. 373 Each type of prophylactic has a purpose, and none of them is a 374 complete prophylactic defense. 376 Each type of defense, however, can be assisted by enabling an 377 application running in a host to inform the network of what it is 378 willing to receive. As noted in Section 2.1, a zone-based firewall, 379 generally denies all incoming sessions and permits responses to 380 sessions initiated outbound from the zone, but can in some cases be 381 configured to also permit specific classes of incoming session 382 requests, such as WWW or SMTP to an appropriate server. A simple way 383 to enable a zone-based firewall to prevent attacks on infrastructure 384 (traffic to an un instantiated address or to an application that is 385 off) while not impeding traffic that has a willing host and 386 application would be for the application to inform the firewall of 387 that willingness to receive. The Port Control Protocol 388 [I-D.ietf-pcp-base], or PCP, is an example of a protocol designed for 389 that purpose. 391 4. Recommendations 393 A general recommendation for the IETF: the IETF should not seek to 394 standardize something that is not being requested by consumers or 395 industry. 397 Zone-based firewalls, when used, SHOULD exclude all session 398 initiation from outside the zone regardless of attributes such as the 399 use of IPsec. They SHOULD also facilitate the use of a protocol such 400 as PCP by hosts to identify traffic (IPsec AH, IPsec ESP, transports 401 in general, or transports using specified destination port ranges) 402 that they are willing to receive, and interpret that into rules 403 permitting specified traffic to those specific systems. Being fully 404 automated and easily understood, such firewalls are appropriate for 405 networks with passive administration. 407 Role-based firewalls can be implemented using routing technology. 408 For example, if Alice should not be able to send a message to Bob, 409 Alice might not be able to obtain Bob's address from DNS, Alice's 410 routing system might not have a route to Bob, or Bob's routing system 411 might not have a route to Alice. Role-based firewalls can also be 412 implemented using filtering technology; Alice, Alice's router, Bob's 413 router, or Bob may have a filter that prevents communication between 414 them. While there can be issues in specific cases, a routing 415 implementation is generally more scalable and more easily managed. 417 Reputation, anomaly, or signature-based intrusion management is 418 generally proprietary; a service maintains the list of exclusions, 419 which must be updated as new kinds of attacks are developed. 420 Implementations SHOULD be designed for frequent and scalable 421 updating. 423 As further discussed in Section 2.1, firewalls of any type SHOULD NOT 424 attempt to perform the kind of deep packet inspection and surgery 425 that is common with Network Address Translators [RFC2993]. There is 426 marginal value in detecting the spoofing of applications by attack 427 traffic, but the side-effects of preventing protocol improvement and 428 application innovation are destructive and unnecessary. 430 Apart from routing protocols and infrastructure protocols intended to 431 manage network configuration and use of addresses such as DNS or 432 DHCP, applications MUST NOT expect a peer to be able to interpret 433 network layer addresses carried in their payload. Network layer 434 addresses carried for documentation purposes, such as in an SMTP 435 envelope or a syslog message, have other value and don't violate this 436 recommendation. 438 5. IANA Considerations 440 This memo asks the IANA for no new parameters. 442 Note to RFC Editor: This section will have served its purpose if it 443 correctly tells IANA that no new assignments or registries are 444 required, or if those assignments or registries are created during 445 the RFC publication process. From the author"s perspective, it may 446 therefore be removed upon publication as an RFC at the RFC Editor"s 447 discretion. 449 6. Security Considerations 451 This note reasons about security considerations. It introduces no 452 new ones. 454 7. Acknowledgements 455 8. References 457 8.1. Normative References 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, March 1997. 462 8.2. Informative References 464 [I-D.ietf-pcp-base] 465 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 466 Selkirk, "Port Control Protocol (PCP)", 467 draft-ietf-pcp-base-22 (work in progress), January 2012. 469 [I-D.vyncke-advanced-ipv6-security] 470 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 471 Security for IPv6 CPE", 472 draft-vyncke-advanced-ipv6-security-03 (work in progress), 473 October 2011. 475 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 476 November 2000. 478 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 479 of Explicit Congestion Notification (ECN) to IP", 480 RFC 3168, September 2001. 482 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 483 RFC 4960, September 2007. 485 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 486 and D. McPherson, "Dissemination of Flow Specification 487 Rules", RFC 5575, August 2009. 489 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 490 Customer Premises Equipment (CPE) for Providing 491 Residential IPv6 Internet Service", RFC 6092, 492 January 2011. 494 [Saltzer] Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end 495 arguments in system design", ACM Transactions on Computer 496 Systems (TOCS) v.2 n.4, p277-288, Nov 1984. 498 Author's Address 500 Fred Baker 501 Cisco Systems 502 Santa Barbara, California 93117 503 USA 505 Email: fred@cisco.com