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