idnits 2.17.1 draft-iab-host-firewalls-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 93: '...ation facilities MUST NOT cause uninte...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2014) is 3641 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.blanchet-iab-internetoverport443' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC6250' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-iab-filtering-considerations-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational May 7, 2014 5 Expires: November 8, 2014 7 Reflections On Host Firewalls 8 draft-iab-host-firewalls-04.txt 10 Abstract 12 In today's Internet, the need for firewalls is generally accepted in 13 the industry and indeed firewalls are widely deployed in practice. 14 Unlike traditional firewalls that protect network links, host 15 firewalls run in end user systems. Often the result is that software 16 may be running and potentially consuming resources, but then 17 communication is blocked by a host firewall. It's taken for granted 18 that this end state is either desirable or the best that can be 19 achieved in practice, rather than (for example) an end state where 20 the relevant software is not running or is running in a way that 21 would not result in unwanted communication. In this document, we 22 explore the issues behind these assumptions and provide suggestions 23 on improving the architecture going forward. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 8, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Category 1: Attack Surface Reduction . . . . . . . . . . . . 5 63 3.1. Discussion of Approaches . . . . . . . . . . . . . . . . 6 64 3.1.1. Fix the Software . . . . . . . . . . . . . . . . . . 6 65 3.1.2. Don't Use the Software . . . . . . . . . . . . . . . 7 66 3.1.3. Run the Software Behind a Host Firewall . . . . . . . 7 67 4. Category 2: Security Policy . . . . . . . . . . . . . . . . . 8 68 4.1. Discussion of Approaches . . . . . . . . . . . . . . . . 8 69 4.1.1. Security Policies in Applications . . . . . . . . . . 8 70 4.1.2. Security Policies in Host Firewalls . . . . . . . . . 9 71 4.1.3. Security Policies in a Service . . . . . . . . . . . 9 72 5. Stealth Mode . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 9. IAB Members at the Time of This Writing . . . . . . . . . . . 11 77 10. Informative References . . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 [I-D.iab-filtering-considerations] discusses the issue of blocking or 83 filtering abusive or objectionable content and communications, and 84 the effects on the overall Internet architecture. This document 85 complements that discussion by focusing on the architectural effects 86 of host firewalls on hosts and applications. 88 "Behavior of and Requirements for Internet Firewalls" [RFC2979] 89 provides an introduction to firewalls and the requirement for 90 transparency in particular, stating: 92 The introduction of a firewall and any associated tunneling or 93 access negotiation facilities MUST NOT cause unintended failures 94 of legitimate and standards-compliant usage that would work were 95 the firewall not present. 97 Many firewalls today do not follow that guidance today, such as by 98 blocking traffic containing IP options or IPv6 extension headers (see 99 [RFC7045] for more discussion). 101 In Section 2.1 of "Reflections on Internet Transparency" [RFC4924], 102 the IAB provided additional thoughts on firewalls and their impact on 103 the Internet architecture, including issues around disclosure 104 obligations and complexity as applications evolve to circumvent 105 firewalls. This document extends that discussion with additional 106 considerations. 108 Traditionally, firewalls have been about arming customers to protect 109 against bugs in applications and services. This document discusses a 110 number of fundamental questions such as who a firewall is meant to 111 protect from what. It does so primarily, though not exclusively, 112 from an end system perspective with a focus on host firewalls in 113 particular. 115 While the Internet Security Glossary [RFC4949] contains an extended 116 definition of a firewall, informally, most people would tend to think 117 of a firewall as simply "something that blocks unwanted traffic" (see 118 [RFC4948] for a discussion on many types of unwanted traffic). A 119 fundamental question is, however: "unwanted by whom?" 121 Possible answers include end users, application developers, network 122 administrators, host administrators, firewall vendors, and content 123 providers. We will exclude by definition the sender of the traffic 124 in question, since the sender would generally want such traffic to be 125 delivered. Still, the other entities have different, and often 126 conflicting, desires which means that a type of traffic might be 127 wanted by one entity and unwanted by another entity. Thus, not 128 surprisingly, there exist various types of firewalls, and various 129 types of "arms race" as we will discuss in Section 4.1.2. 131 1.1. Terminology 133 In this document we distinguish between a "host firewall" which 134 simply intends to protect the single computer on which it runs, and a 135 "network firewall" which is located in the network and intends to 136 protect the network and any hosts behind it. 138 A Network Address Translator (NAT) is also often viewed, or even 139 marketed, as a type of network firewall; Section 2.2 of [RFC4864] 140 addresses this misconception, but nevertheless some of the same 141 observations in the present document may also apply to NATs. 143 Sandboxed environments, such as those provided by browsers, can also 144 be thought of as a type of host firewall in the more general sense. 146 For example, a cross-site check in a browser can be thought of as a 147 mechanism to block unwanted outbound traffic per a "same origin 148 policy" where a script can only communicate with the "site" from 149 which the script was obtained, for some definition of site such as 150 the scheme and authority in a URI. 152 The term "application" is used in this document generically to apply 153 to any component that can receive traffic. In this sense, it could 154 refer to a process running on a computer (including a system service) 155 or even to a portion of a TCP/IP stack itself, such as a component 156 that responds to pings. 158 2. Firewall Rules 160 Desires for wanted or unwanted traffic can be expressed in terms of 161 "allow" vs. "block" rules, with some way to resolve conflicting 162 rules. Many firewalls are actually implemented in terms of such 163 rules. Figure 1 shows some typical sources of such rules. 165 Source | Consumer | Consumer | Enterprise | Enterprise 166 | Scenario | Scenario | Scenario | Scenario 167 | Host | Network | Host | Network 168 | Firewall | Firewall | Firewall | Firewall 169 ----------+------------+-------------+------------+------------ 170 End user | Sometimes | Sometimes | | 171 | (as host | (as network | | 172 | admin) | admin) | | 173 ----------+------------+-------------+------------+------------ 174 App | Yes | Sometimes | | 175 developer | | (via | | 176 | | protocols) | | 177 ----------+------------+-------------+------------+------------ 178 Network | | Sometimes | | Yes 179 admin | | | | 180 ----------+------------+-------------+------------+------------ 181 Host | Sometimes | | Yes | 182 admin | | | | 183 ----------+------------+-------------+------------+------------ 184 Firewall | Yes | Yes | Yes | Yes 185 vendor | | | | 186 ----------+------------+-------------+------------+------------ 188 Common sources of firewall rules 190 Figure 1 192 Figure 1 assumes that network firewalls are administered by network 193 administrators (if any), and host firewalls are administered by host 194 administrators (if any). A firewall may also have rules provided by 195 the firewall vendor itself. 197 End users typically cannot directly provide rules to firewalls that 198 affect other users, unless the end user is a host or network 199 administrators. Application developers can, however, provide such 200 rules to some firewalls, such as providing rules at installation 201 time, for example by invoking an API provided by a host firewall 202 included with the operating system, or by providing metadata to the 203 operating system for use by firewalls, or by using a protocol such as 204 UPnP [UPNPWANIP] or the Port Control Protocol (PCP) [RFC6887] to 205 communicate with a network firewall (see Section 4.1.3 for a longer 206 discussion). 208 Firewall rules generally fall into two categories: 210 1. Attack surface reduction: Rules intended to prevent an 211 application from doing things the developer does not want it to 212 do. 214 2. Security policy: Rules intended to prevent an application from 215 doing things the developer might want it to do, but an 216 administrator does not. 218 A firewall is unnecessary if both categories are empty. We will now 219 treat each category in turn, focusing specifically on host firewalls 220 (although some points might be equally applicable to network 221 firewalls). 223 3. Category 1: Attack Surface Reduction 225 As noted above, this category of firewall rule typically attempts to 226 prevent applications from doing things the developer did not intend. 228 One might ask whether this category of rules is typically empty, and 229 the answer is that it is not today. One reason stems from mitigating 230 the threat of vulnerability exploitation by putting a security 231 barrier in a separate process isolated from the potentially 232 compromised process. Furthermore, there is also some desire for a 233 "stealth mode" (see Section 5 below). 235 Hence, typically a firewall will have rules to block everything by 236 default. A one-time, privileged, application install step adds one 237 or more Allow rules, and then normal (unprivileged) application 238 execution is then constrained by the resulting rules. 240 A second reason this category of rules is non-empty is where they are 241 used as workarounds for cases the application developer found too 242 onerous to implement. These cases include: 244 1. Simple policies that the developer would want, but that are 245 difficult to implement. One example might be a policy that an 246 application should communicate only within the local network 247 (e.g., a home or enterprise) but not be reachable from the global 248 Internet or while the device is moved to some public network such 249 as a hotspot. A second example might be the reverse, i.e., a 250 policy to communicate over the Internet but not with local 251 entities. The need for this category would be reduced by better 252 platform support for such policies, making them easier for 253 developers to implement and use. 255 2. Complex policies where the developer cannot possibly be aware of 256 specifics. One example might be a policy to communicate only 257 during, or only outside of, normal business hours, where the 258 exact hours may vary by location and time of year. Another 259 example might be a policy to avoid communication over links that 260 cost too much, where the definition of "too much" may vary by 261 customer, and indeed the end host and application might not even 262 be aware of the costs. The need for this category would be 263 reduced by better platform support for such policies, allowing 264 the application to communicate through some simple API with some 265 other library or service that can deal with the specifics. 267 3.1. Discussion of Approaches 269 When running an application would result in unwanted behavior, 270 customers have three choices, which we will discuss in turn: 272 a. fix (or get the developer to fix) the software, 274 b. not use the software, or 276 c. let the software run, but then use a firewall to thwart it and 277 prevent it from working in unwanted ways. 279 3.1.1. Fix the Software 281 Firewall vendors point out that one can more quickly and reliably 282 update firewall rules than application software. Indeed some 283 applications might have no way to update them, and support for other 284 applications might no longer be available (e.g., if the developers 285 are no longer around). Most modern operating systems (and any 286 applications that come with them) have automatic updates, as do some 287 independent applications. But until all applications have automatic 288 updates, and automatic updates are actually used, it will still be 289 the case that firewall rules can be updated more quickly than 290 software patches. Furthermore, in some contexts (e.g., within some 291 enterprises), a possibly lengthy retesting and recertification 292 process must be employed before applications can be updated. 294 In short, mechanisms to encourage and ease the use of secure 295 automatic software updates are important and would greatly reduce 296 overall complexity. Such mechanisms should allow scheduling updates 297 at appropriate times, taking into account operational considerations 298 such as dependencies, compatibility, testing and maintenance windows. 300 3.1.2. Don't Use the Software 302 A key question to ask is whether the application could still do 303 something useful when firewalled. If the answer is yes, then not 304 using the software is probably unrealistic. For example, a game with 305 both single-player and multi-player capabilities could still be 306 useful in single-player mode when firewalled. If instead the answer 307 is no, it is better to not allow the application to run in the first 308 place, and some host firewalls can indeed block applications from 309 running. 311 3.1.3. Run the Software Behind a Host Firewall 313 As noted earlier, one disadvantage of this approach is that resources 314 still get consumed. For example, the application can still consume 315 memory, CPU, bandwidth (up to the point of blockage), ports in the 316 transport layer protocol, and possibly other resources depending on 317 the application, for operations that provide no benefit while 318 firewalled. 320 A second important disadvantage of this approach is the bad user 321 experience. Typically the application and the end-user won't know 322 why the application doesn't work. A poorly designed application 323 might not cope well and consume even more resources (e.g., retrying 324 an operation that continually fails). 326 A third disadvantage is that it is common for a firewall rule to 327 block more that is appropriate for attack surface reduction, 328 impacting protocol operation and even having adverse effects on other 329 endpoints. For example, some firewalls that cannot perform full deep 330 packet inspection at line speed have adopted a block by default 331 approach to anything they don't understand from the first few bytes; 332 this is very harmful to innovation as it interferes with the ability 333 to deploy new protocols and features. 335 As another example, blocking ICMP adversely affects path MTU 336 discovery which can cause problems for other entities (see [RFC4890] 337 and Section 3.1.1 of [RFC2979] for further discussion). This can 338 happen due to lack of understanding all the details of application 339 behavior, or due to accidental misconfiguration. Section 2.1 of 340 [RFC5505] states, "Anything that can be configured can be 341 misconfigured," and discusses this in more detail. 343 In short, it is important to make applications more aware of the 344 constraints of their environment and hence better able to behave well 345 when constrained. 347 4. Category 2: Security Policy 349 As noted in Section 2, this category of firewall rule typically 350 attempts to prevent an application from doing things an administrator 351 does not want them to do, even if the application developer did. 353 One might ask whether this category of rules is typically empty, and 354 the answer varies somewhat. For enterprise-scenario firewalls, it is 355 almost never empty, and hence the problems discussed in Section 3.1.3 356 can be common here too. Similarly, for consumer-scenario firewalls, 357 it is generally not empty but there are some notable exceptions. For 358 example, for the host firewall in some operation systems, this 359 category always starts empty and most users never change this. 361 4.1. Discussion of Approaches 363 Security policy can be implemented in any of three places, which we 364 will discuss in turn: the application, a firewall, or a library/ 365 service that the application explicitly uses. 367 4.1.1. Security Policies in Applications 369 In this option, each application must implement support for 370 potentially complex security policies, along with ways for 371 administrators to configure them. Although the explicit interaction 372 with applications avoids the problems discussed in Section 3.1.3, 373 this approach is impractical for a number of reasons. First, the 374 complexity makes it difficult to implement and is error-prone, 375 especially for application developers whose primary expertise is not 376 networking. Second, the potentially large number of applications 377 (and application developers) results in an inconsistent experience 378 that makes it difficult for an administrator to manage common 379 policies across applications, thus driving up training and 380 operational costs. 382 4.1.2. Security Policies in Host Firewalls 384 Putting security policies in firewalls without explicit interaction 385 with the applications results in the problems discussed in 386 Section 3.1.3. In addition, this leads to "arms races" where the 387 applications are incented to evolve to get around the security 388 policies, since the desires of the end user or developer can conflict 389 with the desires of an administrator. As stated in Section 2.1 of 390 [RFC4924]: 392 In practice, filtering intended to block or restrict application 393 usage is difficult to successfully implement without customer 394 consent, since over time developers will tend to re-engineer 395 filtered protocols so as to avoid the filters. Thus over time, 396 filtering is likely to result in interoperability issues or 397 unnecessary complexity. These costs come without the benefit of 398 effective filtering since many application protocols began to use 399 HTTP as a transport protocol after application developers observed 400 that firewalls allow HTTP traffic while dropping packets for 401 unknown protocols. 403 Such arms races stem from inherent tussles between the desires of 404 different entities. For example, the tussle between end user desires 405 and administrator desires leads to an arms race between firewalls and 406 deep packet inspection on the one hand, vs. the use of obfuscation or 407 tunnels on the other. 409 Although such arms races are often thought of in the context of 410 network firewalls, they also occur with host firewalls. It is, 411 however, generally easier for a host firewall to overcome, since it 412 may be more practical for a host firewall to establish some form of 413 trust between the policy-desiring entities, and have a trusted 414 arbiter. 416 4.1.3. Security Policies in a Service 418 In this approach, applications use a library or other external 419 service whereby the applications have explicit knowledge of the 420 impact of the security policies in order to avoid the problems in 421 Section 3.1.3, and in a sandboxed environment this might be the 422 application's only way to interact with the network. 424 Thus in this opt-in approach, applications provide a description of 425 the network access requested, and the library/service can ensure that 426 applications and/or users are informed in a way they can understand, 427 and that administrators can craft policy that affects the 428 applications. 430 This approach is very difficult to do in a firewall-vendor-specific 431 library/service when there can be multiple firewall implementations 432 (including ones in the middle of the network), since it is usually 433 impractical for an application developer to know about and develop 434 for many different firewall APIs. It is, however, possible to employ 435 this approach with a firewall-vendor-agnostic library/service that 436 can communicate with both applications and firewalls. Thus 437 application developers and firewall developers can use a common 438 platform. 440 We observe that this approach is very different from the classic 441 firewall approach. It is, however the approach used by some host 442 operating system firewalls, and it is also the approach used by PCP 443 in the IETF. As such, we encourage the deployment and use of this 444 model. 446 Furthermore, while this approach lessens the incentive for arms races 447 as discussed above, one important issue still remains. Namely, there 448 is no standard mechanism today for a library/service to learn complex 449 policies from the network. Further work in this area is needed. 451 5. Stealth Mode 453 There is often a desire to hide from address and port scans on a 454 public network. However, compliance to many RFCs requires responding 455 to various messages. For example, TCP [RFC0793] compliance requires 456 sending a RST in response to a SYN when there is no listener, and 457 ICMPv6 [RFC4443] compliance requires sending an Echo Reply in 458 response to an Echo Request. 460 Firewall rules can allow such stealth without changing the statement 461 of compliance of the basic protocols. However, stealth mode could 462 instead be implemented as a configurable option used by the 463 applications themselves. For example, rather than a firewall rule to 464 drop a certain outbound message after an application generates it, 465 fewer resources would be consumed if the application knew not to 466 generate it in the first place. 468 6. Security Considerations 470 There is a common misconception that firewalls protect users from 471 malware on their computer, when in fact firewalls protect users from 472 buggy software. There is some concern that firewalls give users a 473 false sense of security; firewalls are not invulnerable and will not 474 prevent malware from running if the user allows it. 476 This document has focused primarily on host firewalls. For 477 additional discussion (focused more on network firewalls), see 478 [RFC2979], and [I-D.iab-filtering-considerations]. 480 7. IANA Considerations 482 This document requires no actions by the IANA. 484 8. Acknowledgements 486 Stuart Cheshire provided the motivation for this document by asking 487 the thought-provoking question of why one would want to firewall an 488 application rather than simply stop running it. The ensuring 489 discussion, and subsequent IAB tech chat in November 2011, led to 490 this document. Dan Simon, Stephen Bensley, Gerardo Diaz Cuellar, 491 Brian Carpenter, and Paul Hoffman also provided helpful suggestions. 493 9. IAB Members at the Time of This Writing 495 Bernard Aboba 496 Jari Arkko 497 Marc Blanchet 498 Ross Callon 499 Alissa Cooper 500 Joel Halpern 501 Russ Housley 502 Eliot Lear 503 Xing Li 504 Erik Nordmark 505 Andrew Sullivan 506 Dave Thaler 507 Hannes Tschofenig 509 10. Informative References 511 [I-D.blanchet-iab-internetoverport443] 512 Blanchet, M., "Implications of Blocking Outgoing Ports 513 Except Ports 80 and 443", draft-blanchet-iab- 514 internetoverport443-02 (work in progress), July 2013. 516 [I-D.iab-filtering-considerations] 517 Barnes, R., Cooper, A., and O. Kolkman, "Technical 518 Considerations for Internet Service Blocking and 519 Filtering", draft-iab-filtering-considerations-06 (work in 520 progress), January 2014. 522 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 523 793, September 1981. 525 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 526 Firewalls", RFC 2979, October 2000. 528 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 529 Message Protocol (ICMPv6) for the Internet Protocol 530 Version 6 (IPv6) Specification", RFC 4443, March 2006. 532 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 533 E. Klein, "Local Network Protection for IPv6", RFC 4864, 534 May 2007. 536 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 537 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 539 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 540 Transparency", RFC 4924, July 2007. 542 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 543 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 544 4948, August 2007. 546 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 547 4949, August 2007. 549 [RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, 550 "Principles of Internet Host Configuration", RFC 5505, May 551 2009. 553 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 554 2011. 556 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 557 6455, December 2011. 559 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 560 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 561 2013. 563 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 564 of IPv6 Extension Headers", RFC 7045, December 2013. 566 [UPNPWANIP] 567 UPnP Forum, , "WANIPConnection:2 Service", September 2010, 568 . 571 Author's Address 573 Dave Thaler 574 Microsoft Corporation 575 One Microsoft Way 576 Redmond, WA 98052 577 USA 579 Phone: +1 425 703 8835 580 Email: dthaler@microsoft.com