idnits 2.17.1 draft-gont-opsawg-firewalls-analysis-02.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 (February 4, 2016) is 3001 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 normative reference: RFC 3205 (Obsoleted by RFC 9205) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-02) exists of draft-gont-opsawg-firewalls-analysis-00 == Outdated reference: A later version (-04) exists of draft-gont-v6ops-ipv6-ehs-packet-drops-02 == Outdated reference: A later version (-01) exists of draft-ietf-opsawg-firewalls-00 -- Duplicate reference: draft-ietf-opsawg-firewalls, mentioned in 'I-D.ietf-opsawg-firewalls-01', was also mentioned in 'I-D.ietf-opsawg-firewalls-00'. -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Area Working Group F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Best Current Practice F. Baker 5 Expires: August 7, 2016 Cisco Systems 6 February 4, 2016 8 On Firewalls in Network Security 9 draft-gont-opsawg-firewalls-analysis-02 11 Abstract 13 This document analyzes the role of firewalls in network security, and 14 recognizes their role in the internet architecture. It suggests a 15 line of reasoning about their usage, and analyzes common kinds of 16 firewalls and the claims made for them. 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 August 7, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Reasoning about Firewalls . . . . . . . . . . . . . . . . . . 4 55 3.1. A Simple Model of Communication . . . . . . . . . . . . . 4 56 3.2. The Role of Firewalls in Internet Security . . . . . . . 5 57 3.3. Firewalls and The End-to-End Principle . . . . . . . . . 5 58 4. Common kinds of firewalls . . . . . . . . . . . . . . . . . . 6 59 4.1. Perimeter security: Protection from aliens and intruders 7 60 4.2. Pervasive access control . . . . . . . . . . . . . . . . 8 61 4.3. Intrusion Management: Contract and Reputation filters . . 9 62 5. Firewalling Strategies . . . . . . . . . . . . . . . . . . . 10 63 5.1. Blocking Traffic Unless It Is Explicitly Allowed (default 64 deny) . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.2. Allow Traffic Unless It Is Explicitly Blocked (default 66 allow) . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6. Assumptions on IP addresses and Transport Protocol Port 68 Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7. State Associated with Filtering Rules . . . . . . . . . . . . 13 70 8. Enforcing Protocol Syntax at the Firewall . . . . . . . . . . 14 71 9. Performing Deep Packet Inspection . . . . . . . . . . . . . . 14 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 77 13.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 Prophylactic perimeter security in the form of firewalls, and the 83 proper use of them, have been a fractious sub-topic in the area of 84 internet security. Firewalls have been largely seen by many in the 85 IETF as a poor approach to security, and often as unnecessary and 86 rather "evil" devices that hinder innovation and the deployment of 87 new protocols and applications. Operationally, they are also seen by 88 some as attack vectors, with state exhaustion attacks, side-effects 89 of the imposition of symmetry requirements and single points of 90 failure. This document analyzes the role of firewalls in network 91 security, and recognizes their role in the internet architecture. It 92 suggests a line of reasoning about their usage, and analyzes common 93 kinds of firewalls and the claims made for them. 95 This document has, among others, the following goals: 97 o Recognize the important role of firewalls in enterprise security 98 architecture for providing "prophylactic" security, rather than as 99 "evil" ad-hoc functionality/devices (see Section 3.2). 101 o Analyze common kinds of firewalls and claims made for them (see 102 Section 4). 104 o Analyze implicit assumptions made by firewalls, identifying where/ 105 when some of those assumptions may not apply (see e.g. 106 Section 6). 108 o Discuss trade-offs in the possible firewalling paradigms (see 109 Section 5). 111 o Provide conceptual guidance regarding the use and deployment of . 113 o Identify harmful behavior/policies commonly implemented and 114 applied by firewalls, in the hopes of improving the state of 115 affairs in that area. 117 o Possibly trigger other work in the area of firewalls, as a result 118 of the previous items. 120 2. Terminology 122 Firewall: 123 A device or software that imposes a policy whose effect is "a 124 stated type of network traffic may or may not be allowed from A to 125 B". The firewall may reside in the destination itself (a "host 126 firewall"), or in any intermediate system (a "network firewall"). 127 The firewalling functionality may be implemented in a general 128 purpose system (e.g. an ACL in a router), or in a special purpose 129 middleware device (e.g., a "firewall product"). The details of 130 the policy, the granularity with which a policy can be applied, 131 how such policy is configured, or of the firewall's implementation 132 are just that - implementation details. 134 We also note that a firewall may enforce policies at different 135 layers. Typically, the layer at which a firewall operates will 136 impact the type of policies that a firewall will be able to apply: 137 for example, a layer-3 firewall may be able to enforce simple 138 policies based on layer-3 addresses and some simple layer-4 139 parameters such as transport protocol port numbers, while an 140 "application firewall" may be able to enforce policies on higher- 141 level entities such as application-request types. We note that 142 all such firewall types essentially enforce the same role of 143 enforcing a policy of some sort on network traffic, and hence are 144 referred to with the generic term "firewall" (or "firewall device" 145 in some cases) throughout this document. 147 Perimeter: 148 The position in which the specific security policy applies. In 149 typical deployed networks, there are usually some easy- to-define 150 perimeters. A network connected with another network has a 151 perimeter where the two meet, which is defined by what equipment 152 is operated by each network. It invariably imposes a security 153 policy at that boundary, which may be as simple as "all traffic is 154 welcome" and as complex as matching arriving and departing traffic 155 to ensure specific behaviors, or inspecting traffic according to 156 various algorithms. Firewall functionality is usually implemented 157 at or close to such network perimeters. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 3. Reasoning about Firewalls 165 3.1. A Simple Model of Communication 167 Any communication requires at least three components: 169 o a sender, someone or some thing that sends a message, 171 o a receiver, someone or some thing that receives the message, and 173 o a channel, which is a medium by which the message is communicated. 175 In the Internet, the IP network is the channel; it may traverse 176 something as simple as a directly connected cable or as complex as a 177 sequence of ISPs, but it is the means of communication. In normal 178 communications, a sender sends a message via the channel to the 179 receiver, who is willing to receive and operate on it. In contrast, 180 attacks are a form of harassment. A receiver exists, but is 181 unwilling to receive the message, has no application to operate on 182 it, or is by policy unwilling to. Attacks on infrastructure occur 183 when message volume overwhelms infrastructure or uses infrastructure 184 but has no obvious receiver. 186 By that line of reasoning, a firewall operating at layer-3 primarily 187 protects infrastructure, by preventing traffic that would attack it 188 from it. The best prophylactic might use a procedure for the 189 dissemination of Flow Specification Rules [RFC5575] to drop traffic 190 sent by an unauthorized or inappropriate sender or which has no host 191 or application willing to receive it as close as possible to the 192 sender. 194 In other words, a firewall is comparable to the human skin, and has 195 as its primary purpose the prophylactic defense of a network. By 196 extension, the firewall also protects a set of hosts and 197 applications, and the bandwidth that serves them, as part of a 198 strategy of defense in depth. Since there is no one way to prevent 199 attacks, a firewall is not itself a security strategy; the analogy to 200 the skin would say that a body protected only by the skin has an 201 immune system deficiency and cannot be expected to long survive. 202 That said, every security solution has a set of vulnerabilities; the 203 vulnerabilities of a layered defense is the intersection of the 204 vulnerabilities of the various layers (e.g., a successful attack has 205 to thread each layer of defense). 207 3.2. The Role of Firewalls in Internet Security 209 One could compare the role of firewalls in prophylactic perimeter 210 security to that of the human skin: the service that the skin 211 performs for the rest of the body is to keep common crud out, and as 212 a result prevent much damage and infection that could otherwise 213 occur. The body supplies prophylactic perimeter security for itself 214 and then presumes that the security perimeter has been breached; real 215 defenses against attacks on the body include powerful systems that 216 detect changes (anomalies) counterproductive to human health, and 217 recognizable attack syndromes such as common or recently-seen 218 diseases. One might well ask, in view of those superior defenses, 219 whether there is any value in the skin at all; the value is easily 220 stated, however. It is not in preventing the need for the stronger 221 solutions, but in making their expensive invocation less needful and 222 more focused. 224 3.3. Firewalls and The End-to-End Principle 226 One common complaint about firewalls in general is that they violate 227 the End-to-End Principle [Saltzer]. The End-to-End Principle is 228 often incorrectly stated as requiring that "application specific 229 functions ought to reside in the end nodes of a network rather than 230 in intermediary nodes, provided they can be implemented 'completely 231 and correctly' in the end nodes" or that "there should be no state in 232 the network." What it actually says is heavily nuanced, and is a 233 line of reasoning applicable when considering any two communication 234 layers. 236 [Saltzer] "presents a design principle that helps guide placement 237 of functions among the modules of a distributed computer system. 238 The principle, called the end-to-end argument, suggests that 239 functions placed at low levels of a system may be redundant or of 240 little value when compared with the cost of providing them at that 241 low level." 243 In other words, the End-to-End Argument is not a prohibition against 244 lower layer retries of transmissions, which can be important in 245 certain LAN technologies, nor of the maintenance of state, nor of 246 consistent policies imposed for security reasons. It is, however, a 247 plea for simplicity. Any behavior of a lower communication layer, 248 whether found in the same system as the higher layer (and especially 249 application) functionality or in a different one, that from the 250 perspective of a higher layer introduces inconsistency, complexity, 251 or coupling, extracts a cost. That cost may be in user satisfaction, 252 difficulty of management or fault diagnosis, difficulty of future 253 innovation, reduced performance, or something else. Such costs need 254 to be clearly and honestly weighed against the benefits expected, and 255 used only if the benefit outweighs the cost. 257 From that perspective, introduction of a policy that prevents 258 communication under an understood set of circumstances, whether it is 259 to prevent access to pornographic sites or to prevent traffic that 260 can be characterized as an attack, does not fail the End-to-End 261 Argument; there are any number of possible sites on the network that 262 are inaccessible at any given time, and the presence of such a policy 263 is easily explained and understood. 265 What does fail the End-to-End Argument is behavior that is 266 intermittent, difficult to explain, or unpredictable. If a site can 267 be reached sometimes and not at other times, or can be reached using 268 this host or application but not another, one will wonder why that is 269 the case, and may not even know where to look for the issue. 271 4. Common kinds of firewalls 273 There are at least three common kinds of firewalls: 275 o Context or Zone-based firewalls, that protect systems within a 276 perimeter from systems outside it, 278 o Pervasive routing-based measures, which protect intermingled 279 systems from each other by enforcing role-based policies, and 281 o Systems that analyze network traffic behavior and trigger on 282 events that are unusual, match a signature, or involve an 283 untrusted peer. 285 Each kind of firewall addresses a different view of the network. A 286 zone-based firewall (Section 4.1) views the network as containing 287 zones of trust, and deems applications inside its zone of protection 288 to be trustworthy. A role-based firewall (Section 4.2) identifies 289 parties on the basis of membership in groups, and prevents 290 unauthorized communication between groups. A reputation, anomaly, or 291 signature-based intrusion management system (Section 4.3) depends on 292 active administration, and permits known applications to communicate 293 while excluding unknown or known-evil applications. In each case, 294 the host or application is its own final bastion of defense, but 295 having a host blocking incoming traffic (so-called "host firewalls") 296 does not defend infrastructure. That is, each type of prophylactic 297 has a purpose, and none of them is a complete prophylactic defense. 299 Each type of defense, however, can be assisted by enabling an 300 application running in a host to inform the network of what it is 301 willing to receive. As noted in Section 4.1, a zone-based firewall, 302 generally denies all incoming sessions and permits responses to 303 sessions initiated outbound from the zone, but can in some cases be 304 configured to also permit specific classes of incoming session 305 requests, such as WWW or SMTP to an appropriate server. A simple way 306 to enable a zone-based firewall to prevent attacks on infrastructure 307 (traffic to an un-instantiated address or to an application that is 308 off) while not impeding traffic that has a willing host and 309 application would be for the application to inform the firewall of 310 that willingness to receive incoming sessions. The Port Control 311 Protocol [RFC6887], or PCP, is an example of a protocol designed for 312 that purpose. 314 4.1. Perimeter security: Protection from aliens and intruders 316 As discussed in [RFC6092], the most common kind of firewall is used 317 at the perimeter of a network. Perimeter security assumes two 318 things: that applications and equipment inside the perimeter are 319 under the control of the local administration and are therefore 320 probably doing reasonable things, and that applications and equipment 321 outside the perimeter are unknown. 323 For example, it may enforce simple permission rules, such as that 324 external web clients are permitted to access a specific web server or 325 that external SMTP MTAs are permitted to access internal SMTP MTAs. 326 Apart from those rules, a session may be initiated from inside the 327 perimeter, and responses from outside will be allowed through the 328 firewall, but sessions may never be initiated from outside. 330 In addition, perimeter firewalls often perform some level of 331 inspection/analysis, either as application proxies or through deep 332 packet inspection, to verify that the protocol claimed to be being 333 passed is in fact the protocol being passed. 335 In many scenarios the existence and definition of zone-based 336 perimeter defenses is arguably a side-effect of the deployment of 337 Network Address Translation [RFC2993]. Since e.g. a single address 338 is shared among multiple systems, the NAT device needs to translate 339 both the IP addresses and the transport protocol ports in order to 340 multiplex multiple communication instances from different nodes into 341 the same external address. Thus, the NAT device must keep a state 342 table to know how to translate the IP addresses and transport 343 protocol ports of incoming packets. Packets originating from the 344 internal network will either match an existing entry in the state 345 table, or create a new one. On the other hand, packets originating 346 in the external network will either match an existing entry in the 347 state table, or be dropped. Thus, as a side effect, NATs implicitly 348 require that communication be initiated from the internal network, 349 and only allow return traffic from the external network. We note 350 that this is a side-effect of multiplexing traffic from multiple 351 nodes on a single IP address, rather than a design goal of NAT 352 devices or their associated network translation function. 354 Some applications make the mistake of coupling application identities 355 to network layer addresses, and hence employ such addresses in the 356 application protocol. Thus, Network Address Translation forces the 357 translator to interpret packet payloads and change addresses where 358 used by applications. 360 As a result, if the transport or application headers are not 361 understood by the translator, this has the effect of damaging or 362 preventing communication. Detection of such issues can be sold as a 363 security feature, although it is really a side-effect of a failure. 364 While this can have useful side-effects, such as preventing the 365 passage of attack traffic that masquerades as some well-known 366 protocol, it also has the nasty side-effect of making innovation 367 difficult. This has slowed the deployment of SCTP [RFC4960], since a 368 firewall will often not permit a protocol it does not know even if a 369 user behind it opens the session. When a new protocol or feature is 370 defined, the firewall needs to stop applying that rule, and that can 371 be difficult to make happen. 373 4.2. Pervasive access control 375 Another access control model, often called "Role-based", tries to 376 control traffic in flight regardless of the perimeter. Given a rule 377 that equipment located in a given routing domain or with a specific 378 characteristic (such as "student dorms") should not be able to access 379 equipment in another domain or with a specific characteristic (such 380 as "academic records"), it might prevent routing from announcing the 381 second route in the domain of the first, or it might tag individual 382 packets ("I'm from the student dorm") and filter on those tags at 383 enforcement points throughout network. Such rules can be applied to 384 individuals as well as equipment; in that case, the host needs to tag 385 the traffic, or there must be a reliable correlation between 386 equipment and its user. 388 One common use of this model is in data centers, in which physical or 389 virtual machines from one tenant (which is not necessarily an "owner" 390 as much as it is a context in which the system is used) might be co- 391 resident with physical or virtual machines from another. Inter- 392 tenant attacks, espionage, and fraud are prevented by enforcing a 393 rule that traffic from systems used by any given tenant is only 394 delivered to other systems used by the same tenant. This might, of 395 course have nuances; under stated circumstances, identified systems 396 or identified users might be able to cross such a boundary. 398 The major impediment in deployment is complexity. The administration 399 has the option to assign policies for individuals on the basis of 400 their current location (e.g. as the cross-product of people, 401 equipment, and topology), meaning that policies can multiply wildly. 402 The administrator that applies a complex role-based access policy is 403 probably most justly condemned to live in the world he or she has 404 created. 406 4.3. Intrusion Management: Contract and Reputation filters 408 The model proposed in Advanced Security for IPv6 CPE 409 [I-D.vyncke-advanced-ipv6-security] could be compared to purchasing 410 an anti-virus software package for one's computer. The proposal is 411 to install a set of filters, perhaps automatically updated, that 412 identify "bad stuff" and make it inaccessible, while not impeding 413 anything else. 415 It depends on four basic features: 417 o A frequently-updated signature-based Intrusion Prevention System 418 which inspects a pre-defined set of protocols at all layers (from 419 layer-3 to layer-7) and uses a vast set of heuristics to detect 420 attacks within one or several flows. Upon detection, the flow is 421 terminated and an event is logged for further optional auditing. 423 o A centralized reputation database that scores prefixes for degree 424 of trust. This is unlikely to be on addresses per se, since e.g. 425 temporary addresses [RFC4941] change regularly and frequently. 427 o Local correlation of attack-related information, and 429 o Global correlation of attacks seen, in a reputation database. 431 The proposal does not mention anomaly-based intrusion detection, 432 which could be used to detect zero-day attacks and new applications 433 or attacks. This would be an obvious extension. 435 The comparison to anti-virus software is real; anti-virus software 436 uses similar algorithms, but on API calls or on data exchanged rather 437 than on network traffic, and for identified threats is often 438 effective. 440 The proposal also has weaknesses: 442 o People do not generally maintain anti-virus packages very well, 443 letting contracts expire, 445 o Reputation databases have a bad reputation for distributing 446 information which is incorrect, out of date, or compromised by 447 attackers, 449 o Anomaly-based analysis identifies changes but is often ineffective 450 in determining whether new application or application behaviors 451 are pernicious (false positives). Someone therefore has to 452 actively decide - a workload the average homeowner might have 453 little patience for, and 455 o Signature-based analysis applies to attacks that have been 456 previously identified, and must be updated as new attacks develop. 457 As a result, in a world in which new attacks literally arise 458 daily, the administrative workload can be intense, and reflexive 459 responses like accepting https certificates that are out of date 460 or the download and installation of unsigned software on the 461 assumption that the site administrator is behind are themselves 462 vectors for attack. 464 Security has to be maintained to be useful, because attacks are 465 maintained. 467 5. Firewalling Strategies 469 There is a great deal of tension in firewall policies between two 470 primary goals of networking: the security goal of "block traffic 471 unless it is explicitly allowed" and the networking goal of "trust 472 hosts with new protocols". The two inherently cannot coexist easily 473 in a set of policies for a firewall. 475 The following subsections discuss the "default deny" and "default 476 allow" security paradigms. 478 5.1. Blocking Traffic Unless It Is Explicitly Allowed (default deny) 480 Many networks enforce the so-called "default deny" policy, in which 481 traffic is blocked unless it is explicitly allowed. The rationale 482 for such policy is that it is easier to open "holes" in a firewall to 483 allow specific protocols, than trying to block all protocols that 484 might be employed as an attack vectors; and that a network should 485 only support the protocols it has been explicitly meant to support. 487 The drawback of this approach is that the security goal of "block 488 traffic unless it is explicitly allowed" prevents useful new 489 applications. This problem has been seen repeatedly over the past 490 decade: a new and useful application protocol is specified, but it 491 cannot get wide adoption because it is blocked by firewalls. The 492 result has been a tendency to try to run new protocols over 493 established applications, particularly over HTTP [RFC3205]. The 494 result is protocols that do not work as well they might if they were 495 designed from scratch. 497 Worse, the same goal prevents the deployment of useful transports 498 other than TCP, UDP, and ICMP. A conservative firewall that only 499 knows those three transports will block new transports such as SCTP 500 [RFC4960]; this in turn causes the Internet to not be able to grow in 501 a healthy fashion. Many firewalls will also block TCP and UDP 502 options they don't understand, and this has the same unfortunate 503 result. 505 5.2. Allow Traffic Unless It Is Explicitly Blocked (default allow) 507 Some networks enforce the so-called "default allow" policy, in which 508 traffic is allowed unless it is explicitly blocked. This policy is 509 usually enforced at perimeters where a comprehensive security policy 510 is not really desirable or possible, but some level of packet 511 filtering is considered appropriate. One common example of such 512 policy could be an ISP blocking TCP port 25 (SMTP), but allowing all 513 other traffic. 515 When a strict security policy is to be enforced (e.g., at an 516 organizational network's edge), the "default allow" policy tends to 517 be rather inappropriate, since it is usually easier and more 518 effective to identify the traffic that must be allowed through the 519 firewall (and open the necessary "holes" in the firewall) than to 520 identify and block all traffic that may be considered undesirable/ 521 inappropriate. 523 6. Assumptions on IP addresses and Transport Protocol Port Numbers 525 In a number of scenarios, simple firewall rules have traditionally 526 been specified in terms of the associated IP addresses and transport 527 protocol port numbers. In general, this assumes that the associated 528 IP addresses are stable, and that there is a "well known" transport 529 protocol port number associated with each application. 531 In the IPv4 world, IP addresses may be considered rather stable. 532 However, IPv6 introduces the concept of "temporary addresses" 533 [RFC4941] which, by definition, change over time. This may prevent 534 the enforcement of filtering policies based on specific IPv6 535 addresses, or may lead to filtering based on a more coarse 536 granularity (e.g. specific address prefixes, as opposed to specific 537 IPv6 addresses). In some scenarios, from the point of view of 538 enforcing filtering policies, it might be desirable to disable 539 temporary addresses altogether. 541 For example, an administrator might prefer that a caching DNS 542 server, a secondary DNS server doing zone transfers, or an SMTP 543 MTA, always employ the same source IPv6 address, as opposed to the 544 temporary addresses that change over time. 546 The server-side transport protocol port is generally the so-called 547 "well-known port" corresponding to the associated application. While 548 widespread, this practice should probably be considered a kludge/ 549 short-cut rather than a "design principle" that can be relied upon 550 for the general case. For example, use of DNS SRV records [RFC2782], 551 or applications such as "portmapper" [Portmap] [RFC1833] might mean 552 that the associated transport protocol port number cannot be assumed 553 to be well-known, but rather needs to be dynamically learned. In 554 other cases, applications may employ (by design) ephemeral port 555 numbers, and there may be no obvious way to dynamically learn the 556 port number being employed. FTP [RFC0959] and SIP [RFC3261] are 557 examples of such applications. 559 Finally, as a result of widespread packet filtering, many protocols 560 tend to be tunneled employing specific transport-protocol port 561 numbers that are known to be more generally allowed by firewalls, 562 such as TCP port 80 (HTTP). This essentially breaks the assumption 563 that port numbers actually identify the actual application protocol 564 using them. 566 Some of the so called "next generation" firewalls make fewer 567 assumptions about port numbers, and tend to analyze the application 568 data stream in order to infer the application protocol type, 569 regardless of the well-known port being used. While this may prevent 570 the circumvention of some security controls, it also implies Deep 571 Packet Inspection (DPI), and therefore there are a number of 572 associated considerations, both in terms of introduced attack vectors 573 and other possibilities for evasion of security controls (please see 574 Section 9 for further discussion). 576 7. State Associated with Filtering Rules 578 There are two main paradigms for packet filtering: 580 o Stateless filtering 582 o Stateful filtering 584 Stateless filtering implies that the decision on whether to allow or 585 block a specific traffic entity is based solely on the contents of 586 such entity. One common example of such paradigm is the enforcement 587 of network ingress filtering [RFC2827], in which packets may be 588 blocked based on their IP addresses. Stateless filtering scales 589 well, since there are no state requirements on the filtering device 590 other than that associated with maintaining the filtering rules to be 591 applied to the incoming traffic entities (e.g., packets). 593 On the other hand, stateful filtering implies that the decision on 594 whether to allow or block a traffic entity is not only based on the 595 contents of such entity, but also on the existence (or lack of) 596 previous state associated with such entity. A common example of such 597 paradigm is a firewall that "allows outbound connection requests and 598 only allows return traffic from the external network" (such as the 599 policy implicitly enforced my most NAT devices). For obvious 600 reasons, the firewall needs to maintain state in order to be able to 601 enforce such policies; that is, the firewall may need to keep track 602 of all on-going communication instances, possibly applying timeouts 603 and garbage collection on the associated state table. 605 Stateful filtering tends to allow more powerful packet filtering, at 606 the expense of increased state. Thus, stateful filtering may be 607 desirable when trying to perform deep packet inspection, but may be 608 undesirable when the firewall is meant to block some Denial of 609 Service attacks, since the firewall itself may become "the weakest 610 link in the chain". Typically, the higher the firewall operates in 611 the network stack, the more state will be required associated. For 612 example, in order for a firewall to enforce a filtering policy based 613 on applcation-layer request types, the firewall will need to enforce 614 its filtering policy on the application-layer protocol stream, thus 615 implying the need to perform layer-3 and layer-4 reassembly, etc. 617 When stateful packet filtering is warranted, its associated security 618 implications should be considered. For example, an administrator may 619 want to enforce traffic filtering to mitigate denial of service 620 attacks; however, when enforcement of such filtering implies 621 increased state at the firewall, the firewall itself may become the 622 easiest target for performing a denial of service attack. 624 8. Enforcing Protocol Syntax at the Firewall 626 Some firewalls try to enforce the protocol syntax by checking that 627 only traffic complying with existing protocol definitions is allowed. 628 While this can have useful side-effects, such as preventing the 629 aforementioned traffic from triggering pathological behavior at the 630 target system, it also has the nasty side-effect of making innovation 631 difficult. For example, one of the issues in the deployment of 632 Explicit Congestion Notification [RFC3168] has been that common 633 firewalls often inspect reserved/unused bits and require them to be 634 set to zero to close covert channels. Another example is the 635 plethora of filtering rules applied to DNS traffic [DNS-FILTERING]. 636 When a new protocol or feature is defined, the firewall needs to stop 637 applying that rule, and that can be difficult to make happen. 639 NOTE: 640 A somewhat related concept is that of traffic normalization (or 641 "scrubbing"), in which the filtering device can "normalize" 642 traffic by e.g. clearing bits that are expected to be cleared, 643 changing some protocol fields such that they are within "normal" 644 ranges, etc. (see e.g. the discussion of "traffic normalization" 645 in [OpenBSD-PF]). While this can have the useful effect of 646 blocking DoS attacks to sloppy implementations that do not enforce 647 sanity checks on the received packets, it also has the nasty side- 648 effect of making innovation difficult, or even breaking deployed 649 protocols. For example, some firewalls are known enforce a 650 default packet normalization policy that clears the TCP URG bit, 651 as a result of the TCP urgent mechanism being associated with some 652 popular DoS attacks. Widespread deployment of such firewalls has 653 essentially rendered the TCP urgent mechanism unusable, leading to 654 its eventual formal deprecation in [RFC6093]. 656 We note that, as per our definition of "firewall" in Section 2, 657 "traffic normalization" is not considered a firewall function. 659 9. Performing Deep Packet Inspection 661 While filtering packets based on the layer-3 protocol header fields 662 is rather simple and straight-forward, performing enforcing a 663 filtering policy at upper layer protocols can be a challenging task. 665 For example, IP fragmentation may make this task quite challenging, 666 since even the very layer-4 protocol header could be present in a 667 non-first fragment. In a similar vein, IPv6 extension headers may 668 represent a challenge for a filtering device, since they can result 669 in long IPv6 extension header chains [RFC7112] 670 [I-D.gont-v6ops-ipv6-ehs-packet-drops]. 672 This problem is exacerbated as one tries to filter packets based on 673 upper layer protocol contents, since many of such protocols implement 674 some form of fragmentation/segmentation and reassembly. In many 675 cases, the reassembly process could possibly lead to different 676 results, and this may be exploited by attackers for circumventing 677 security controls [Ptacek1998] [RFC6274]. 679 In general, the upper in the protocol stack that a filtering policy 680 is to be enforced, the more complex the task becomes: an attacker has 681 more opportunities for obfuscation, ranging from e.g. ambiguities in 682 IP and/or TCP reassembly, to e.g. application-layer obfuscation (such 683 as HTTP URL obfuscation or JavaScript bytecode obfuscation). This 684 usually implies that, in order to reliably enforce a filtering 685 policy, more state is required on the firewall; and the 686 considerations in Section 7 should be evaluated. 688 10. IANA Considerations 690 This memo asks the IANA for no new parameters. It can before 691 publication as an RFC by the RFC Editor. 693 11. Security Considerations 695 This documents recognizes the role of firewalls in network security, 696 and discusses a number of considerations associated with firewalls 697 which may be of use when designing or deploying firewalls. This 698 document, by itself, does not introduce any security implications. 700 12. Acknowledgements 702 The authors would like to thank (in alphabetical order) Fleming 703 Andraeson, Mark Andrews, Lee Howard, Joel Jaeggli, Al Morton, Eric 704 Vyncke and James Woodyatt, for providing valuable comments on earlier 705 versions of this document. 707 This document is based on [I-D.ietf-opsawg-firewalls-00] authored by 708 Fred Baker, and [I-D.ietf-opsawg-firewalls-01] authored by Paul 709 Hoffman. 711 13. References 713 13.1. Normative References 715 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 716 RFC 1833, DOI 10.17487/RFC1833, August 1995, 717 . 719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 720 Requirement Levels", BCP 14, RFC 2119, 721 DOI 10.17487/RFC2119, March 1997, 722 . 724 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 725 RFC 3205, DOI 10.17487/RFC3205, February 2002, 726 . 728 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 729 Extensions for Stateless Address Autoconfiguration in 730 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 731 . 733 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 734 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 735 DOI 10.17487/RFC6887, April 2013, 736 . 738 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 739 Oversized IPv6 Header Chains", RFC 7112, 740 DOI 10.17487/RFC7112, January 2014, 741 . 743 13.2. Informative References 745 [DNS-FILTERING] 746 Andrews, M., "On Firewalls in Internet Security (Fwd: New 747 Version Notification for draft-gont-opsawg-firewalls- 748 analysis-00.txt)", post to the OPSAWG mailing-list, 749 Message-Id: <20151012002551.8F7CD3A2FFD8@rock.dv.isc.org>, 750 2015, . 753 [I-D.gont-v6ops-ipv6-ehs-packet-drops] 754 Gont, F., Hilliard, N., Doering, G., LIU, S., and W. 755 Kumari, "Operational Implications of IPv6 Packets with 756 Extension Headers", draft-gont-v6ops-ipv6-ehs-packet- 757 drops-02 (work in progress), February 2016. 759 [I-D.ietf-opsawg-firewalls-00] 760 Baker, F., "On Firewalls in Internet Security", draft- 761 ietf-opsawg-firewalls-00 (work in progress), June 2012. 763 [I-D.ietf-opsawg-firewalls-01] 764 Baker, F. and P. Hoffman, "On Firewalls in Internet 765 Security", draft-ietf-opsawg-firewalls-01 (work in 766 progress), October 2012. 768 [I-D.vyncke-advanced-ipv6-security] 769 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced 770 Security for IPv6 CPE", draft-vyncke-advanced- 771 ipv6-security-03 (work in progress), October 2011. 773 [OpenBSD-PF] 774 OpenBSD, , "pf(4) manual page: pf -- packet filter", 2015, 775 . 778 [Portmap] Wikipedia, , "Portmap", 2014, 779 . 781 [Ptacek1998] 782 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 783 of Service: Eluding Network Intrusion Detection", 1998, 784 . 786 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 787 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 788 . 790 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 791 specifying the location of services (DNS SRV)", RFC 2782, 792 DOI 10.17487/RFC2782, February 2000, 793 . 795 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 796 Defeating Denial of Service Attacks which employ IP Source 797 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 798 May 2000, . 800 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 801 DOI 10.17487/RFC2993, November 2000, 802 . 804 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 805 of Explicit Congestion Notification (ECN) to IP", 806 RFC 3168, DOI 10.17487/RFC3168, September 2001, 807 . 809 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 810 A., Peterson, J., Sparks, R., Handley, M., and E. 811 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 812 DOI 10.17487/RFC3261, June 2002, 813 . 815 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 816 RFC 4960, DOI 10.17487/RFC4960, September 2007, 817 . 819 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 820 and D. McPherson, "Dissemination of Flow Specification 821 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 822 . 824 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 825 Capabilities in Customer Premises Equipment (CPE) for 826 Providing Residential IPv6 Internet Service", RFC 6092, 827 DOI 10.17487/RFC6092, January 2011, 828 . 830 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 831 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 832 January 2011, . 834 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 835 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 836 . 838 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments 839 in system design", ACM Transactions on Computer Systems 840 (TOCS) v.2 n.4, p277-288, Nov 1984. 842 Authors' Addresses 843 Fernando Gont 844 SI6 Networks / UTN-FRH 845 Evaristo Carriego 2644 846 Haedo, Provincia de Buenos Aires 1706 847 Argentina 849 Phone: +54 11 4650 8472 850 Email: fgont@si6networks.com 851 URI: http://www.si6networks.com 853 Fred Baker 854 Cisco Systems 855 Santa Barbara, California 93117 856 USA 858 Email: fred@cisco.com