idnits 2.17.1 draft-livingood-web-notification-09.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 324: '...ions for end users, then it MAY become...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 15, 2010) is 5002 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2434' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 975, but no explicit reference was found in the text == Unused Reference: 'RFC2915' is defined on line 979, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'CableLabs DOCSIS' is defined on line 1015, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 4329 (Obsoleted by RFC 9239) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Chung 3 Internet-Draft A. Kasyanov 4 Intended status: Informational J. Livingood 5 Expires: February 16, 2011 N. Mody 6 Comcast 7 B. Van Lieu 8 Unaffiliated 9 August 15, 2010 11 Comcast's Web Notification System Design 12 draft-livingood-web-notification-09 14 Abstract 16 The objective of this document is to describe a method of providing 17 critical end user notifications to web browsers, which has been 18 deployed by Comcast, an Internet Service Provider (ISP). Such a 19 notification system is being used to provide near-immediate 20 notifications to customers, such as to warn them that their traffic 21 exhibits patterns that are indicative of malware or virus infection. 22 There are other proprietary systems that can perform such 23 notifications but those systems utilize Deep Packet Inspection (DPI) 24 technology. In contrast to DPI, this document describes a system 25 that does not rely upon DPI, and is instead based in open IETF 26 standards and open source applications. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 16, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. High-Level Design of the System . . . . . . . . . . . . . . . 4 76 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. General Requirements . . . . . . . . . . . . . . . . . . . 5 78 3.2. Web Proxy Requirements . . . . . . . . . . . . . . . . . . 7 79 3.3. ICAP Server Requirements . . . . . . . . . . . . . . . . . 8 80 3.4. Messaging Service Requirements . . . . . . . . . . . . . . 8 81 4. Implementation Details . . . . . . . . . . . . . . . . . . . . 9 82 4.1. Functional Components Described, As Implemented . . . . . 9 83 4.2. Functional Diagram, As Implemented . . . . . . . . . . . . 11 84 5. High Level Communication Flow, As Implemented . . . . . . . . 11 85 6. Communication Between Web Proxy and ICAP Server, As 86 Implemented . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 7. End-to-End Web Notification Flow, As Implemented . . . . . . . 14 88 7.1. Step-by-Step Description of the End-to-End Web 89 Notification Flow . . . . . . . . . . . . . . . . . . . . 14 90 7.2. Diagram of the End-to-End Web Notification Flow . . . . . 16 91 8. Example HTTP Headers and JavaScript for a Web Notification . . 17 92 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 19 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 11. Debating The Necessity of Such a Critical Notification 95 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 12. Suggesting a Walled Garden As An Alternative . . . . . . . . . 21 97 13. Intended Next Steps . . . . . . . . . . . . . . . . . . . . . 22 98 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 99 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 100 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 16.1. Normative References . . . . . . . . . . . . . . . . . . . 22 102 16.2. Informative References . . . . . . . . . . . . . . . . . . 24 103 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 Internet Service Providers (ISPs) have a need for a system that is 109 capable of communicating with customers in a nearly immediate manner, 110 to convey critical service notices such as warnings concerning likely 111 malware infection. Given the prevalence of the web browser as the 112 predominant client software in use by Internet users, the web browser 113 is an ideal vehicle for providing these notifications. This document 114 describes a system that has been deployed by Comcast, a broadband 115 ISP, to provide near-immediate notifications to web browsers. 117 In the course of evaluating potential solutions, the authors 118 discovered that the large majority of commercially available systems 119 utilized Deep Packet Inspection (DPI) technology. While a DPI-based 120 system would certainly work, this and other ISPs are trying to avoid 121 widespread deployment and use of DPI, and are searching for 122 alternatives. Thus, Comcast desired to use a system based on open 123 standards, non-proprietary software, and which did not require the 124 use of DPI. While the system described herein is specific to the 125 Data-Over-Cable Service Interface Specifications (DOCSIS, [CableLabs 126 DOCSIS]) networks used by most cable-based broadband ISPs, concepts 127 described in this document can generally be applied to many different 128 types of networks should those ISPs be interested in alternatives to 129 DPI. 131 2. High-Level Design of the System 133 The web notification system design is based on the use of the 134 Internet Content Adaptation Protocol [RFC3507]. The design uses open 135 source applications, which are the Squid Web Proxy, GreasySpoon ICAP 136 server, and Apache Tomcat. The ICAP protocol, an existing IETF 137 protocol, allows for message transformation or adaptation. An ICAP 138 client passes a HyperText Transport Protocol (HTTP, [RFC2616]) 139 response to an ICAP server for content adaption. The ICAP Server in 140 turn responds back to the client with the HTTP response containing 141 the notification message by using the 'respmod' method defined in 142 Section 3.2 of [RFC3507]. 144 3. Design Requirements 146 This section describes all of the key requirements taken into 147 consideration by Comcast for the design of this system. This 148 information is provided in order to convey important design choices 149 which were made in order to avoid the use of DPI, among other things. 150 An Additional Background section is included with each requirement to 151 provide additional information, context, or other useful explanation. 153 3.1. General Requirements 155 3.1.1. Must Only Be Used for Critical Service Notifications 156 Additional Background: The system must only provide critical 157 notifications, rather than trivial notifications. An 158 example of a critical, non-trivial notification, which is 159 also the primary motivation of this system, is to advise the 160 user that their computer is infected with malware, that 161 their security is at severe risk and/or has already been 162 compromised, and that it is recommended that they take 163 immediate, corrective action NOW. 165 3.1.2. Must Use TCP Port 80 166 Additional Background: The system must provide notifications 167 via TCP port 80, the well-known port for HTTP traffic. 168 Since the large majority of customers use a web browser as 169 their primary application, this was deemed the best method 170 to provide them with an immediate, critical notification. 172 3.1.3. Must Support Block Listing 173 Additional Background: While unlikely, since it is possible 174 that the HyperText Markup Language (HTML, [RFC1866]) or 175 JavaScript [RFC4329] used for notifications may cause 176 problems while accessing a particular website. Therefore, 177 such a system must be capable of using a block list of 178 website Uniform Resource Indicators (URIs, [RFC2396]) or 179 Fully Qualified Domain Named (FQDNs, Section 5.1 of 180 [RFC1035]) that conflict with the system, so that the system 181 does not provide notifications in these cases, in order to 182 minimize any errors or unexpected results. Also, while 183 extensive development and testing has been performed to 184 ensure that this system does not behave in unexpected ways, 185 and the standard ICAP protocol (which has been in use for 186 many years) is utilized, it is critical that if it does 187 behave in such a way that there must be a method to rapidly 188 exempt specific URIs or FQDNs. 190 3.1.4. Must Not Cause Problems with Instant Messaging (IM) Clients 191 Using TCP Port 80 192 Additional Background: Some IM clients use TCP port 80 in 193 their communications, often as an alternate port when 194 standard, well-known ports do not work. Other IM clients 195 may in fact use TCP port 80 by default, in some cases even 196 being based in a web browser. Therefore, this system must 197 not conflict with or cause unexpected results for IM clients 198 (or any other client types) which use TCP port 80. 200 3.1.5. Must Handle Pre-Existing Active TCP Sessions Gracefully 201 Additional Background: Since the web notification system may 202 temporarily re-route TCP port 80 traffic in order to provide 203 a critical notification, previously established TCP port 80 204 sessions must not be disrupted while being routed to the 205 proxy layer. Also, since the critical web notification 206 occurs at a well-define point in time, it is logical to 207 conclude that an end user may well have an active TCP port 208 80 session in progress before the notification is sent, and 209 which is still active at the time of the notification. It 210 is therefore important that any such connections must not be 211 reset, and that they instead must be handled gracefully. 213 3.1.6. Must Not Use TCP Resets 214 Additional Background: The use of TCP resets has been widely 215 criticized, both in the Internet community generally as well 216 as in [RFC3360]. In Comcast's recent history, for example, 217 the company was criticized for using TCP resets in the 218 course of operating a DPI-based network management system. 219 As such, TCP resets as a function of the system must not be 220 used. 222 3.1.7. Must Be Non-Disruptive 223 Additional Background: The web notification system must not 224 disrupt the end user experience, for example by causing 225 significant clients errors. 227 3.1.8. User Notification Acknowledgement Must Stop Further 228 Immediate Notifications 229 Additional Background: Once a user acknowledges a critical 230 notification, the notification should immediately stop. 231 Otherwise, the user may believe the system is stuck in an 232 error state and may not believe that the critical 233 notification is valid. In addition, it is quite possible 234 that the user will be annoyed that the system did not react 235 to his acknowledgement. 237 3.1.9. Non-Modification of Content Should Be Maintained. 238 Additional Background: The system should not significantly 239 alter the content of the HTTP response from any website the 240 user is accessing. 242 3.1.10. Must Handle Unexpected Content Gracefully 243 Additional Background: Sometimes developers and/or 244 implementers of software systems assume that a narrow range 245 of inputs to a system will occur, all of which have been 246 thought of beforehand by the designers. The authors believe 247 this is a poor assumption to make in the design and 248 implementation of a system and, in contrast, that unexpected 249 or even malformed inputs should be assumed. As a result, 250 the system must gracefully and transparently handle traffic 251 which is unexpected, even though there will be cases when 252 the system cannot provide a critical web notification as a 253 result of this. Thus, widely varying content should be 254 expected, and all such unexpected traffic must be handled by 255 the system without generating user-perceived errors or 256 unexpected results. 258 3.1.11. Web Content Must Not Be Cached 259 Additional Background: Maintaining the privacy of users 260 important. As such, content flowing through or incidentally 261 observed the system must not be cached. 263 3.1.12. Advertising Replacement or Insertion Must Not Be Performed 264 Under ANY Circumstances 265 Additional Background: The system must not be used to 266 replace any advertising provided by a website, or to insert 267 advertising into websites. This therefore includes both 268 cases where a web page already has space for advertising, as 269 well as cases where a web page does not have any 270 advertising. This is a critical area of concern for end 271 users, privacy advocates, and other members of the Internet 272 community. Therefore it must be made abundantly clear that 273 this system will not be used for such purposes. 275 3.2. Web Proxy Requirements 277 3.2.1. Open-Source Software Must Be Used 278 Additional Background: The system must use an open source web 279 proxy server. (As noted later, Squid has been chosen.) 280 While it is possible to use any web proxy, the use of open 281 source enables others to easily access openly available 282 documentation for the software, among the other benefits 283 commonly attributed to the use of open source software. 285 3.2.2. ICAP Client Shoud Be Integrated 286 Additional Background: The web proxy server should have an 287 integrated ICAP client, which simplifies the design and 288 implementation of the system. 290 3.2.3. Access Control Must Be Implemented 291 Additional Background: Access to the proxy must be limited 292 exclusively to the IP addresses of users for which 293 notifications are intended, and only for limited periods of 294 time. Furthermore, since a Session Management Broker (SMB) 295 is utilized, as described in Section 4.1 below, then the 296 proxy must restrict access only to the address of the SMB. 298 3.3. ICAP Server Requirements 300 3.3.1. Must Provide ICAP Response Support: 301 Additional Background: The system must support response 302 adaptation, in accordance with [RFC3507]. An ICAP client 303 passes a HyperText Transport Protocol (HTTP, [RFC2616]) 304 response to an ICAP server for content adaption. The ICAP 305 Server in turn responds back to the client with the HTTP 306 response containing the notification message by using the 307 'respmod' method defined in Section 3.2 of [RFC3507] 309 3.3.2. Must Provide Consistency of Critical Notifications 310 Additional Background: The system must be able to 311 consistently provide a specific notification. For example, 312 if a critical alert to notify a user that they are infected 313 with malware is desired, then that notification should 314 consistently look the same for all users and not vary. 316 3.3.3. Must Support Multiple Notification Types 317 Additional Background: While the initial and sole critical 318 notification sent by the system is intended to alert users of 319 a malware infection, malware is a rapidly and continuously 320 evolving threat. As a result of this reality, the system 321 must be able to evolve to provide different types of critical 322 notifications. For example, if malware begins to diverge 323 into several different categories with substantially 324 different implications for end users, then it MAY become 325 desirable to provide a notification which has been narrowly 326 tailored to each category of malware. 328 3.3.4. Must Support Notification to Multiple Users Simultaneously 329 Additional Background: The system must be able to 330 simultaneously serve notifications to different users. For 331 example, if 100 users have been infected with malware and 332 critically need to be notified about this security problem, 333 then the system must be capable of providing the notification 334 to several users at a time, or all of the users at the same 335 time, rather that to just one user at a time. 337 3.4. Messaging Service Requirements 339 3.4.1. A Messaging Service Must Be Used 340 Additional Background: The Messaging Service, as described in 341 Section 4.1 below, caches the notifications for each specific 342 user. Thus, the notification messages are cached by the 343 system rather than having to retrieve them each time a 344 notification is needed. As a result, the system can be more 345 easily scaled to provide notification to multiple users 346 simultaneously, as noted in an earlier requirement (Must 347 Support Notification to Multiple Users Simultaneously). 349 3.4.2. Must Process Acknowledgements On a Timely Basis 350 Additional Background: The Messaging Service must quickly 351 process notification acknowledgements by end users, as noted 352 in an earlier requirement (User Notification Acknowledgement 353 Must Stop Further Immediate Notifications). 355 3.4.3. Must Ensure Notification Targeting Accuracy 356 Additional Background: The Messaging Service must ensure that 357 notifications are presented to the intended users. For 358 example, if the system intends to provide a critical 359 notification to User A and User B, but not User C, then User 360 C must not be sent a notification. 362 3.4.4. Should Keep Notification Records for Customer Support 363 Purposes 364 Additional Background: The Messaging Service should maintain 365 some type of record that a notification being sent to a user, 366 in case that user inquires with customer support personnel. 367 For example, when a user is presented with the critical 368 notification advising them of a malware infection, that user 369 may choose to call Comcast's Customer Security Assurance 370 team, in the customer service organization. As a result, a 371 Customer Security Assurance representative should be able to 372 confirm that the user did in fact receive a notification 373 concerning malware infection in the course of providing 374 assistance to the end user in remediating the malware 375 infection. 377 4. Implementation Details 379 This section defines and documents the various core functional 380 components of the system, as they are implemented. These components 381 are then shown in a diagram to describe how the various components 382 are linked and relate to one another. 384 4.1. Functional Components Described, As Implemented 386 This section accurately and transparently describes the software 387 packages used by the system described herein, as well as all of the 388 details of how the system functions. The authors acknowledge that 389 there may be multiple alternative software choices for each 390 component; the purpose of this section is to describe those 391 selections which have been made and deployed. 393 4.1.1. Web Proxy: The system uses Squid Proxy, an open source web 394 proxy application in wide use, and one which supports an 395 integrated ICAP client. 397 4.1.2. ICAP Server: The system uses GreasySpoon, an open source 398 application. The ICAP Server retrieves the notifications 399 from the Messaging service cache when content adaption is 400 needed. 402 4.1.3. Customer Database: The Customer Database holds the relevant 403 information that the system needs to provide a critical 404 notification to a given user. The database may also hold the 405 status of which users were notified and which users are 406 pending notification. 408 4.1.4. Messaging Service: The system uses Apache Tomcat, an open 409 source application. This is a process engine that retrieves 410 specific web notification messages from a catalog of possible 411 notifications. While only one notification is currently 412 used, concerning malware infection, as noted in Section 3.3 413 the system may eventually need to provide multiple 414 notifications (the specific requirement is Must Support 415 Multiple Notification Types). When a notification for a 416 specific user is not in the cache, the process retrieves this 417 information from the Customer Database and populates the 418 cache for a specific period of time. 420 4.1.5. Session Management Broker (SMB): A Load Balancer (LB) with a 421 customized layer 7 inspection policy is used to differentiate 422 between HTTP and non-HTTP traffic on TCP port 80, in order to 423 meet the requirements documented in Section 3 above. The 424 system uses a LB from A10 Networks. The SMB functions as a 425 full stateful TCP proxy with the ability to forward packets 426 from existing TCP sessions that do not exist in the internal 427 session table (to meet the specific requirement Must Handle 428 Pre-Existing Active TCP Sessions Gracefully). New HTTP 429 sessions are load balanced to the web proxy layer either 430 transparently or using source Network Address Translation 431 (NAT [RFC1631]) from the SMB. Non-HTTP traffic for 432 established TCP sessions not in the SMB session table is 433 simply forwarded to the destination transparently via the TCP 434 proxy layer (again, to meet the specific requirement Must 435 Handle Pre-Existing Active TCP Sessions Gracefully). 437 4.2. Functional Diagram, As Implemented 439 +--------+ +------------+ +----------+ 440 | ICAP | <----> | Messaging | <----> | Customer | 441 | Server | | Service | | Database | 442 +--------+ +------------+ +----------+ 443 ^ 444 | +----------+ 445 | | | 446 | +-------> | Internet | <-------+ 447 | | | | | 448 | | +----------+ | 449 | | ^ | 450 v v | | 451 +----------+ v v 452 |+--------+| +-------+ +--------+ 453 || ICAP || <----> | SMB | <---> | Access | 454 || Client || +-------+ | Router | 455 |+--------+| +--------+ 456 || SQUID || ^ 457 || Proxy || | 458 |+--------+| v 459 +----------+ +----------+ 460 | CMTS* | 461 +----------+ 462 ^ 463 | 464 v 465 +------+ 466 | PC | 467 +------+ 469 * A Cable Modem Termination System (CMTS) 470 is an access network element. 472 Figure 1: Web Notification System - Functional Components 474 5. High Level Communication Flow, As Implemented 476 In Section 4 the functional components of the system were described, 477 and then shown in relation to one another in Figure 1 above. This 478 section describes the high level communication flow of a transaction 479 in the system, in order to explain the general way that the functions 480 work together in action. This will be further explained in much more 481 detail in later sections of this document. 483 5.1. Setup Differentiated Services (DiffServ): Using DiffServe 484 [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] 485 [RFC4594], set a policy to direct TCP port 80 traffic to the 486 web notification system's web proxy. 488 5.2. Session Management: TCP port 80 packets are routed to a 489 Session Management Broker (SMB) which distinguishes between 490 HTTP or non-HTTP traffic and between new and existing 491 sessions. HTTP packets are forwarded to the web proxy by the 492 SMB. Non-HTTP packets such as instant messaging (IM) traffic 493 are forwarded to a TCP proxy layer for routing to destination 494 or the SMB operates as a full TCP proxy and forwards the non- 495 HTTP packets to the destination. Pre-established TCP sessions 496 on port 80 are identified by the SMB and forwarded with no 497 impact. 499 5.3. Web Proxy Forwards Request: The web proxy forwards the HTTP 500 request on to the destination site, a web server, as a web 501 proxy normally would do. 503 5.4. On Response, Send Message to ICAP Server: When the HTTP 504 response is received from the destination server, the web 505 proxy sends a message to the ICAP server for the web 506 notification. 508 5.5. Messaging Service: The Messaging Service should respond with 509 appropriate notification content or null response if no 510 notification is cached. 512 5.6. ICAP Server Responds: The ICAP server responds and furnishes 513 the appropriate content for the web notification to the web 514 proxy. 516 5.7. Web Proxy Sends Response: The web proxy then forwards the HTTP 517 response containing the web notification to the client web 518 browser. 520 5.8. User Response: The user observes the critical web 521 notification, and clicks an appropriate option, such as: OK/ 522 acknowledged, snooze/remind me later, etc. 524 5.9. More Information: Depending upon the notification, the user 525 may be provided with more information. For example, as noted 526 previously, the system was designed to provide critical 527 notifications concerning malware infection. Thus, in the case 528 of malware infection, the user may be advised to go to a 529 malware remediation web page that provides directions on how 530 to attempt to remove the malware and attempt to secure hosts 531 against future malware infection. 533 5.10. Turn Down DiffServ: Once the notification transaction has 534 completed, remove any special DiffServ settings. 536 6. Communication Between Web Proxy and ICAP Server, As Implemented 538 The Web Proxy and ICAP Server are critical components of the system. 539 This section shows the communication that occurs between these two 540 components. 542 +------------+ 543 | www URI | 544 +------------+ 545 ^ | 546 (2)| |(3) 547 | v 548 +--------+ (4) +--------+ (4) +--------+ 549 | |------------>| |------------>| | 550 | | (5) | | (5) | | 551 | Proxy |<------------| ICAP |<------------| ICAP | 552 | Module | (6) | Client | (6) | Server | 553 | |------------>| |------------>| | 554 | | (7) | | (7) | | 555 | |<------------| |<------------| | 556 +--------+ +--------+ +--------+ 557 ^ | 558 (1)| |(8) 559 | v 560 +------------+ (9) +------------+ 561 | |----------------------------->| | 562 | Browser | (10) | Web Server | 563 | |<-----------------------------| | 564 +------------+ +------------+ 566 (1) - HTTP GET (TCP 80) 567 (2) - Proxy HTTP GET (TCP 80) 568 (3) - HTTP 200 OK w/ Response 569 (4) - ICAP RESPMOD 570 (5) - ICAP 200 OK 571 (6) - TCP Stream - Encapsulate Header 572 (7) - ICAP 200 OK Insert Message 573 (8) - HTTP 200 OK w/ Response + Message Frame 574 (9) - HTTP GET for Message 575 (10) - HTTP 200 w/ Message Content 577 Figure 2: Communication Between Web Proxy and ICAP Server 579 7. End-to-End Web Notification Flow, As Implemented 581 This section describes the exact flow of an end-to-end notification, 582 in order to show in detail how the system functions. 584 7.1. Step-by-Step Description of the End-to-End Web Notification Flow 586 7.1.1. Policy-Based Routing 587 1. TCP port 80 packets from the user that needs to be notified are 588 routed to the Web Proxy via policy based routing. 590 2. Packets are forwarded to the Session Management Broker, which 591 establishes a session with the Web Proxy and routes the packets 592 to the Web Proxy. 594 7.1.2. Web Proxy 596 1. The user's HTTP request is directed to the Web Proxy. 598 2. The Web Proxy receives HTTP traffic and retrieves content from 599 the requested web site. 601 3. The Web Proxy receives the response and forwards it to the ICAP 602 Server for response adaptation. 604 4. The ICAP Server checks the HTTP content in order to determine 605 whether the notification message can be inserted. 607 5. The ICAP Server initiates a request to the Messaging Service 608 cache process with the IP address of the user. 610 6. If a notification message for the user exists then the 611 appropriate notification is cached on the Messaging Service. 612 The Messaging Service then returns the appropriate notification 613 content to the ICAP Server. 615 7. Once the notification message is retrieved from the Messaging 616 Service cache the ICAP server may insert the notification 617 message in the HTTP response body without altering or modifying 618 the original content of the HTTP response. 620 8. The ICAP Server then sends the response back to the Web Proxy, 621 which in turn forwards the HTTP response back to the browser. 623 9. If the user's IP address is not found or provisioned for a 624 notification message, then the ICAP Server should return a '204 625 No Modifications Needed' response to the ICAP Client as defined 626 in section 4.3.3 of [RFC3507]. As a result, the user will not 627 receive any web notification message. 629 10. The user observes the web notification, and clicks an 630 appropriate option, such as: OK/acknowledged, snooze/ remind me 631 later, etc. 633 7.2. Diagram of the End-to-End Web Notification Flow 635 The two figures below show the communications flow from the Web 636 Browser, through the Web Notification System. 638 Figure 3 illustrates what occurs when a notification request cannot 639 be inserted because the notification type for the user's IP address 640 is not cached in the Messaging Service. 642 ICAP ICAP Message Customer 643 Browser Proxy Client Server Service Internet DB 644 | HTTP | | | | | | 645 | GET | Proxy | | | | | 646 +------->| Request | | | | | 647 | +---------|---------|--------|------->| | 648 | | | | | 200 OK | | 649 | |<--------|---------|--------|--------+ | 650 | | ICAP | | | | | 651 | | RESPMOD | ICAP | | | | 652 | +-------->| RESPMOD | Check | | | 653 | | +-------->| Cache | | | 654 | | | | for IP | | | 655 | | | | Match | | | 656 | | | +------->| | | 657 | | | | Cache | | | 658 | | | | Miss | | | 659 | | | |<-------+ Request| | 660 | | | 204 No | | Type | | 661 | | | Modif. | +--------|------->| 662 | | | Needed | | | | 663 | | No |<--------+ | | Type | 664 | | Insert | | | |Returned| 665 | 200 OK |<--------+ | |<-------|--------+ 666 | w/o | | | | | | 667 | Insert | | | | | | 668 |<-------+ | | | | | 669 | | | | | | | 671 Figure 3: End-to-End Web Notification Flow - With Cache Miss 673 Figure 4 illustrates what occurs when a notification request for the 674 user's IP address is cached in the Messaging Service. 676 ICAP ICAP Message Customer 677 Browser Proxy Client Server Service Internet DB 678 | HTTP | | | | | | 679 | GET | Proxy | | | | | 680 +------->| Request | | | | | 681 | +---------|---------|--------|------->| | 682 | | | | | 200 OK | | 683 | |<--------|---------|--------|--------+ | 684 | | ICAP | | | | | 685 | | RESPMOD | ICAP | | | | 686 | +-------->| RESPMOD | Check | | | 687 | | +-------->| Cache | | | 688 | | | | for IP | | | 689 | | | | Match | | | 690 | | | +------->| | | 691 | | | | Cache | | | 692 | | | | Hit | | | 693 | | | Insert |<-------+ | | 694 | | Return | Type | | | | 695 | | 200 OK |<--------+ | | | 696 | | with | | | | | 697 | | Insert | | | | | 698 | 200 OK |<--------+ | | | | 699 | w/ | | | | | | 700 | Notify | | | | | | 701 |<-------+ | | | | | 702 | | | | | | | 704 Figure 4: End-to-End Web Notification Flow - With Cache Hit 706 8. Example HTTP Headers and JavaScript for a Web Notification 708 The figure below shows an example of a normal HTTP GET request from 709 the user's web browser to www.example.com, a web server on the 710 Internet. 712 ------------------------------------------------------------------------ 713 1. HTTP Get Request to www.example.com 714 ------------------------------------------------------------------------ 715 http://www.example.com/ 717 GET / HTTP/1.1 718 Host: www.example.com 719 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) 720 Gecko/20080404 Firefox/2.0.0.14 721 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 722 Accept-Language: en-us,en;q=0.5 723 Accept-Encoding: gzip,deflate 724 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 725 Keep-Alive: 300 726 Connection: keep-alive 727 Pragma: no-cache 728 ------------------------------------------------------------------------ 730 Figure 5: Example HTTP Headers for a Web Notification - HTTP Get 732 In the figure below, the traffic is routed via the Web Proxy, which 733 communicates with the ICAP Server and returns the response from 734 www.example.com. In this case that response is a 200 OK, with the 735 desired notification message inserted. 737 ------------------------------------------------------------------------ 738 2. Response from www.example.com via PROXY 739 ------------------------------------------------------------------------ 740 HTTP/1.x 200 OK 741 Date: Thu, 08 May 2008 16:26:29 GMT 742 Server: Apache/2.2.3 (CentOS) 743 Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT 744 Etag: "b80f4-1b6-80bfd280" 745 Accept-Ranges: bytes 746 Content-Length: 438 747 Connection: close 748 Content-Type: text/html; charset=UTF-8 749 Age: 18 750 X-Cache: HIT from localhost.localdomain 751 Via: 1.0 localhost.localdomain (squid/3.0.STABLE5) 752 Proxy-Connection: keep-alive 753 ------------------------------------------------------------------------ 755 Figure 6: Example HTTP Headers for a Web Notification - HTTP Response 757 The figure below shows an example of the web notification content 758 inserted in the 200 OK response, in this example JavaScript code. 760 ------------------------------------------------------------------------ 761 3. Example of JavaScript containing Notification Insertion 762 ------------------------------------------------------------------------ 763 765 776 790 ------------------------------------------------------------------------ 792 Figure 7: Example JavaScript Used in a Web Notification 794 9. Deployment Considerations 796 The components of the web notification system should be distributed 797 throughout the network and close to end users. This ensures that the 798 routing performance and the user's web browsing experience remains 799 excellent. In addition, a HTTP-aware load balancer should used in 800 each datacenter where servers are located, so that traffic can be 801 spread across N+1 servers and the system can be easily scaled. 803 10. Security Considerations 805 This critical web notification system was conceived in order to 806 provide an additional method of notifying end user customers that 807 their computer has been infected with malware. Depending upon the 808 specific text of the notification, users could fear that it is some 809 kind of phishing attack. As a result, care has been taken with the 810 text and any links contained in the web notification itself. For 811 example, should the notification text change over time, it may be 812 best to provide a general URI or a telephone number. In contrast to 813 that, the notification must not ask for login credentials, and must 814 not ask a user to follow a link in order to change their password, 815 since these are common phishing techniques. Finally, care should be 816 taken to provide confidence that the web notification is valid and 817 from a trusted party, and/or that the user has an alternate method of 818 checking the validity of the web notification. One alternate method 819 of validating the notification may be to call customer support, in 820 this example to call Comcast's Customer Security Assurance team, 821 which explains a key requirement (specifically, should Keep 822 Notification Records for Customer Support Purposes) in Section 3.4 823 above. 825 11. Debating The Necessity of Such a Critical Notification System 827 Some members of the community may question whether it is ever, under 828 any circumstances, acceptable to modify Internet content in order to 829 provide critical service notification concerning malware infection - 830 even in the smallest of ways, even if openly and transparently 831 documented, even if thoroughly tested, and even if for the best of 832 motivations. It is important that anyone with such concerns 833 recognize that this document is by no means the first to propose 834 this, particularly as a tactic to combat a security problem, and in 835 fact simply leverages previous work in the IETF, such as [RFC3507]. 836 Such concerned parties should also study the many organizations using 837 ICAP and the many software systems which have implemented ICAP. 839 In addition, concerned members of the community should review 840 Section 1 which describes the fact that this is a common feature of 841 DPI systems, made by DPI vendors and many, if not most, major 842 networking equipment vendors. As the authors describe herein, they 843 are motivated to AVOID the need for widespread, ubiquitous deployment 844 of DPI, via the use of both open source software and open protocols, 845 and are further motivated to transparently describe the details of 846 how such a system functions, what it IS intended to do, what it IS 847 NOT intended to do, and purposes for which it WILL NOT be used. 849 The authors also believe it is important for ISPs to transparently 850 disclose network management techniques and systems, and to have a 851 venue to do so, as has been done here. In addition, the authors 852 believe it is important for the IETF and other members of the 853 Internet community encourage and positively reinforce such 854 disclosures. In the publishing of such a document for reference and 855 comment by the Internet community, this may serve to motivate other 856 ISPs to be similarly open and to engage the IETF and other 857 organizations that are part of the Internet community. Not 858 publishing such documents could motivate less disclosure on the part 859 of ISPs and other members of the Internet community, increase the use 860 of DPI, and decrease ISP participation in the critical technical 861 bodies that make up parts of the Internet community. 863 In addition, it is critical that members of the community recognize 864 the good motivations of ISPs like Comcast to combat the massive and 865 continuing proliferation of malware, which is a huge threat to the 866 security of average Internet users and now represents a multi- 867 billion-dollar underground economy engaged in identity theft, 868 financial fraud, transmission of spam, and other criminal activity. 869 Such a critical notification system in fact is only necessary due to 870 the failure of host-based security at defending against and 871 preventing malware infection. As such, ISPs such as Comcast are 872 being urged by their customers and by other parties such as security 873 and/or privacy organizations, as well as governmental organizations, 874 to take action to help solve this massive problem since so many other 875 tactics have been unsuccessful. For example, as Howard Schmidt, the 876 Special Advisory for Cyber Security to President Obama, of the United 877 States of America, was recently quoted: "As attacks on home-based and 878 unsecured networks become as prevalent as those against large 879 organizations, the need for ISPs to do everything they can to make 880 security easier for their subscribers is critical for the 881 preservation of our nation's information backbone. Additionally, 882 there is tremendous potential to grow further the use of broadband 883 around the world; and making safety and security part of an ISP's 884 core offering will enable the end user to fully experience the rich 885 and robust benefits broadband provides." 887 12. Suggesting a Walled Garden As An Alternative 889 A walled garden refers to an environment that controls the 890 information and services that a subscriber is allowed to utilize and 891 what network access permissions are granted. Placing a user in a 892 walled garden is therefore another approach that ISPs may take to 893 notify users, and this method is being explored as a possible 894 alternative in other documents and community efforts. As such, web 895 notifications should be considered one of many possible notification 896 methods which merits documentation. 898 However, a walled garden approach can pose challenges and may in some 899 cases be considered disruptive to end users. For example, a user 900 could be playing a game online, via the use of a dedicated, Internet- 901 connected game console, which would likely stop working when the user 902 was placed in the walled garden. In another example, the user may be 903 in the course of a telephone conversation, using a Voice Over IP 904 (VoIP) device of some type, which would also likely stop working when 905 the user was placed in the walled garden. In both cases, the user is 906 not using a web browser and would not have a way to determine the 907 reason why their service seemingly stopped working. 909 13. Intended Next Steps 911 Unfortunately, no existing working group of the IETF is focused on 912 issues of malware infection and related issues. As a result, there 913 is not a definite venue for this document, so it has been submitted 914 to the RFC Editor as an individual submission. While documentation 915 and disclosure of this system is beneficial for the Internet 916 community in and of itself, there are other benefits to having this 917 document published. One of those reasons is that members of the 918 community, including members of the IETF, have a stable document to 919 refer to in case of any potential new work that the community may 920 undertake in the area of malware, security, and critical notification 921 to end users. It is also hoped that, in the tradition of a Request 922 for Comment, other members of the community may be motivated to 923 propose alternative systems or other improvements. 925 14. IANA Considerations 927 There are no IANA considerations in this document. 929 NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO 930 PUBLICATION. 932 15. Acknowledgements 934 The authors wish to thank Alissa Cooper for her review of and 935 comments on the document, Neville Brownlee for his excellent 936 feedback, as well as others who reviewed the document. 938 16. References 940 16.1. Normative References 942 [RFC1035] Mockapetris, P., "Domain names - implementation and 943 specification", STD 13, RFC 1035, November 1987. 945 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 946 Translator (NAT)", RFC 1631, May 1994. 948 [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup 949 Language - 2.0", RFC 1866, November 1995. 951 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 952 Resource Identifiers (URI): Generic Syntax", RFC 2396, 953 August 1998. 955 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 956 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 957 October 1998. 959 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 960 "Definition of the Differentiated Services Field (DS 961 Field) in the IPv4 and IPv6 Headers", RFC 2474, 962 December 1998. 964 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 965 and W. Weiss, "An Architecture for Differentiated 966 Services", RFC 2475, December 1998. 968 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 969 "Assured Forwarding PHB Group", RFC 2597, June 1999. 971 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 972 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 973 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 975 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 976 specifying the location of services (DNS SRV)", RFC 2782, 977 February 2000. 979 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 980 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 982 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 983 "Per Hop Behavior Identification Codes", RFC 3140, 984 June 2001. 986 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 987 J., Courtney, W., Davari, S., Firoiu, V., and D. 988 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 989 Behavior)", RFC 3246, March 2002. 991 [RFC3260] Grossman, D., "New Terminology and Clarifications for 992 Diffserv", RFC 3260, April 2002. 994 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 995 A., Peterson, J., Sparks, R., Handley, M., and E. 996 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 997 June 2002. 999 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1000 Protocol (SIP): Locating SIP Servers", RFC 3263, 1001 June 2002. 1003 [RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation 1004 Protocol (ICAP)", RFC 3507, April 2003. 1006 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 1007 April 2006. 1009 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1010 Guidelines for DiffServ Service Classes", RFC 4594, 1011 August 2006. 1013 16.2. Informative References 1015 [CableLabs DOCSIS] 1016 CableLabs, "Data-Over-Cable Service Interface 1017 Specifications", CableLabs Specifications Various DOCSIS 1018 Reference Documents, . 1021 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 1022 BCP 60, RFC 3360, August 2002. 1024 Appendix A. Document Change Log 1026 [RFC Editor: This section is to be removed before publication] 1028 o -09 - Made changes recommended by the RFC Editor in a review and 1029 discussion at IETF 78. This included fixing several nits, 1030 changing the formatting of some parts of the document, removing 1031 references to RFC 2119, and expanding a few sections slightly, 1032 such as by adding an introductory paragraph to a section without 1033 one. Also, made changes recommended by the RFC Editor, following 1034 a review of this document with the RFC Editor's Editorial Board 1036 o -08 - One minor deletion, based on feedback from the RFC Editor 1038 o -07 - Made modifications to accommodate concerns raised by the RFC 1039 Editor and his reviewers. This includes CAPITALIZING all RFC 2119 1040 language, adding more context and background to the requirements 1041 section, making the introduction more precise, making the document 1042 describe more of the actual implementation details, updating 1043 security considerations, and adding three new sections (12, 13, 1044 14). 1046 o -06 - Corrected WL/BL error 1048 o -05 - fixed odd spacing in 8.1 1050 o -04 - corrections and tweaks by Jason 1052 o -03 - corrections and clarifications from Nirmal and BVL 1054 o -02 - updated BVL's contact info, clearing one open issue. Also 1055 added content to Security Considerations. 1057 o -01 - updated doc to reflect that this system is deployed and not 1058 in development, closing out two open issues. Added reference for 1059 JavaScript, closing an open issue. 1061 o -00 - first version published 1063 Authors' Addresses 1065 Chae Chung 1066 Comcast Cable Communications 1067 One Comcast Center 1068 1701 John F. Kennedy Boulevard 1069 Philadelphia, PA 19103 1070 US 1072 Email: chae_chung@cable.comcast.com 1073 URI: http://www.comcast.com 1075 Alex Kasyanov 1076 Comcast Cable Communications 1077 One Comcast Center 1078 1701 John F. Kennedy Boulevard 1079 Philadelphia, PA 19103 1080 US 1082 Email: alexander_kasyanov@cable.comcast.com 1083 URI: http://www.comcast.com 1084 Jason Livingood 1085 Comcast Cable Communications 1086 One Comcast Center 1087 1701 John F. Kennedy Boulevard 1088 Philadelphia, PA 19103 1089 US 1091 Email: jason_livingood@cable.comcast.com 1092 URI: http://www.comcast.com 1094 Nirmal Mody 1095 Comcast Cable Communications 1096 One Comcast Center 1097 1701 John F. Kennedy Boulevard 1098 Philadelphia, PA 19103 1099 US 1101 Email: nirmal_mody@cable.comcast.com 1102 URI: http://www.comcast.com 1104 Brian Van Lieu 1105 Unaffiliated 1106 Bethlehem, PA 18018 1107 US 1109 Email: brian@vanlieu.net