idnits 2.17.1 draft-livingood-web-notification-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (June 6, 2010) is 5073 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 959, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 979, but no explicit reference was found in the text == Unused Reference: 'RFC2915' is defined on line 983, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: 'CableLabs DOCSIS' is defined on line 1019, 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: 7 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: December 8, 2010 N. Mody 6 Comcast 7 B. Van Lieu 8 Unaffiliated 9 June 6, 2010 11 Example of an ISP Web Notification System 12 draft-livingood-web-notification-07 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 these 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 December 8, 2010. 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. High-Level Design of the System . . . . . . . . . . . . . . . 4 77 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 5 78 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 5 79 4.2. Web Proxy Requirements . . . . . . . . . . . . . . . . . . 7 80 4.3. ICAP Server Requirements . . . . . . . . . . . . . . . . . 8 81 4.4. Messaging Service Requirements . . . . . . . . . . . . . . 9 82 5. Implementation Details . . . . . . . . . . . . . . . . . . . . 10 83 5.1. Functional Components Described, As Implemented . . . . . 10 84 5.2. Functional Diagram, As Implemented . . . . . . . . . . . . 11 85 6. High Level Communication Flow, As Implemented . . . . . . . . 12 86 7. Communication Between Web Proxy and ICAP Server, As 87 Implemented . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8. End-to-End Web Notification Flow, As Implemented . . . . . . . 14 89 8.1. Step-by-Step Description of the End-to-End Web 90 Notification Flow . . . . . . . . . . . . . . . . . . . . 14 91 8.2. Diagram of the End-to-End Web Notification Flow . . . . . 15 92 9. Example HTTP Headers and JavaScript for a Web Notification . . 16 93 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 12. Debating The Necessity of Such a Critical Notification 96 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 13. Suggesting a Walled Garden As An Alternative . . . . . . . . . 20 98 14. Intended Next Steps . . . . . . . . . . . . . . . . . . . . . 21 99 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 100 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 101 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 17.1. Normative References . . . . . . . . . . . . . . . . . . . 22 103 17.2. Informative References . . . . . . . . . . . . . . . . . . 23 104 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 23 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 107 1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Introduction 115 Internet Service Providers (ISPs) have a need for a system that is 116 capable of communicating with customers in a nearly immediate manner, 117 to convey critical service notices such as warnings concerning likely 118 malware infection. Given the prevalence of the web browser as the 119 predominant client software in use by Internet users, the web browser 120 is an ideal vehicle for providing these notifications. This document 121 describes a system that has been deployed by Comcast, a broadband 122 ISP, to provide near-immediate notifications to web browsers. 124 In the course of evaluating potential solutions, the authors 125 discovered that the large majority of commercially available systems 126 utilized Deep Packet Inspection (DPI) technology. While a DPI-based 127 system would certainly work, this and other ISPs are trying to avoid 128 widespread deployment and use of DPI, and are searching for 129 alternatives. Thus, Comcast desired to use a system based on open 130 standards, non-proprietary software, and which MUST NOT require the 131 use of DPI. While the system described herein is specific to the 132 Data-Over-Cable Service Interface Specifications (DOCSIS, [CableLabs 133 DOCSIS]) networks used by most cable-based broadband ISPs, concepts 134 described in this document can generally be applied to many different 135 types of networks should those ISPs be interested in alternatives to 136 DPI. 138 3. High-Level Design of the System 140 The web notification system design is based on the use of the 141 Internet Content Adaptation Protocol [RFC3507]. The design uses open 142 source applications, which are the Squid Web Proxy, GreasySpoon ICAP 143 server, and Apache Tomcat. The ICAP protocol, an existing IETF 144 protocol, allows for message transformation or adaptation. An ICAP 145 client passes a HyperText Transport Protocol (HTTP, [RFC2616]) 146 response to an ICAP server for content adaption. The ICAP Server in 147 turn responds back to the client with the HTTP response containing 148 the notification message by using the 'respmod' method defined in 149 Section 3.2 of [RFC3507]. 151 4. Design Requirements 153 This section describes all of the key requirements taken into 154 consideration by Comcast for the design of this system. This 155 information is provided in order to convey important design choices 156 which were made in order to avoid the use of DPI, among other things. 157 An Additional Background section is included with each requirement to 158 provide additional information, context, or other useful explanation. 160 4.1. General Requirements 162 REQ1: MUST Only Be Used for Critical Service Notifications 163 Additional Background: The system MUST only provide critical 164 notifications, rather than trivial notifications. An example 165 of a critical, non-trivial notification, which is also the 166 primary motivation of this system, is to advise the user that 167 their computer is infected with malware, that their security 168 is at severe risk and/or has already been compromised, and 169 that it is recommended that they take immediate, corrective 170 action NOW. 172 REQ2: MUST Use TCP Port 80 173 Additional Background: The system MUST provide notifications 174 via TCP port 80, the well-known port for HTTP traffic. Since 175 the large majority of customers use a web browser as their 176 primary application, this was deemed the best method to 177 provide them with an immediate, critical notification. 179 REQ3: MUST Support Block Listing 180 Additional Background: While unlikely, since it is possible 181 that the HyperText Markup Language (HTML, [RFC1866]) or 182 JavaScript [RFC4329] used for notifications may cause 183 problems while accessing a particular website. Therefore, 184 such a system MUST be capable of using a block list of 185 website Uniform Resource Indicators (URIs, [RFC2396]) or 186 Fully Qualified Domain Named (FQDNs, Section 5.1 of 187 [RFC1035]) that conflict with the system, so that the system 188 MUST NOT provide a notifications in these cases, in order to 189 eliminate any errors or unexpected results. Also, while 190 extensive development and testing has been performed to 191 ensure that this system does not behave in unexpected ways, 192 and the standard ICAP protocol which has been in use for many 193 years is utilized, it is critical that if it does behave in 194 such a way that there MUST be a method to rapidly except 195 specific URIs or FQDNs. 197 REQ4: MUST NOT Cause Problems with Instant Messaging (IM) Clients 198 Using TCP Port 80 199 Additional Background: Some IM clients use TCP port 80 in 200 their communications, often as an alternate port when 201 standard, well-known ports do not work. Other IM clients may 202 in fact use TCP port 80 by default, in some cases even being 203 based in a web browser. Therefore, this system MUST NOT 204 conflict with or cause unexpected results for IM clients (or 205 any other client types) which use TCP port 80. 207 REQ5: MUST Handle Pre-Existing Active TCP Sessions Gracefully 208 Additional Background: Since the web notification system may 209 temporarily re-route TCP port 80 traffic in order to provide 210 a critical notification, previously established TCP port 80 211 sessions MUST NOT be disrupted and MUST be routed to the 212 proxy layer. Also, since the critical web notification 213 occurs at a point in time, it is logical to conclude that an 214 end user may well have an active TCP port 80 session in 215 progress before the notification is sent, and which is still 216 active at the time of the notification. It is therefore 217 important that any such connections MUST NOT be reset, and 218 that they instead MUST be handled gracefully. 220 REQ6: MUST NOT Use TCP Resets 221 Additional Background: The use of TCP resets has been widely 222 criticized, both in the Internet community generally as well 223 as in [RFC3360]. In Comcast's recent history, for example, 224 the company was criticized for using TCP resets in the course 225 of operating a DPI-based network management system. As such, 226 TCP resets as a function of the system MUST NOT be used. 228 REQ7: MUST Be Non-Disruptive 229 Additional Background: The web notification system MUST NOT 230 disrupt the end user experience, such as causing significant 231 clients errors. 233 REQ8: Notification Acknowledgement MUST Stop Further Immediate 234 Notifications 235 Additional Background: Once a user acknowledges a critical 236 notification, the notification should immediately stop. 237 Otherwise, the user may believe the system is stuck in an 238 error state and may not believe that the critical 239 notification is valid. In addition, it is quite possible 240 that the user will be annoyed that the system did not react 241 to his acknowledgement. 243 REQ9: Non-Modification of Content SHOULD Be Maintained. 244 Additional Background: The system SHOULD NOT significantly 245 alter the content of the HTTP response from any website the 246 user is accessing. 248 REQ10: MUST Handle Unexpected Content Gracefully 249 Additional Background: Sometimes developers and/or 250 implementers of software systems assume that a narrow range 251 of inputs to a system will occur, all of which have been 252 thought of beforehand by the designers. The authors believe 253 this is a poor assumption to make in the design and 254 implementation of a system and, in contrast that unexpected 255 or even malformed inputs SHOULD be assumed. As a result, the 256 system MUST gracefully and transparently handle traffic which 257 is unexpected, and that there will be cases when the system 258 cannot provide a critical web notification as a result of 259 this. Thus, widely varying content should be expected, and 260 all such unexpected traffic MUST be handled by the system 261 without generating user-perceived errors or unexpected 262 results. 264 REQ11: Web Content MUST NOT Be Cached 265 Additional Background: Maintaining the privacy of users 266 important. As such, content flowing through or incidentally 267 observed the system MUST NOT be cached. 269 REQ12: Advertising Replacement or Insertion MUST NOT Be Performed 270 Under ANY Circumstances 271 Additional Background: The system MUST NOT be used to replace 272 any advertising provided by a website, or insert advertising 273 into websites. This therefore includes both cases where a 274 web page already has space for advertising, as well as cases 275 where a web page does not have any advertising. This is a 276 critical area of concern for end users, privacy advocates, 277 and other members of the Internet community. Therefore it 278 must be made abundantly clear that this system MUST NOT and 279 SHALL NOT be used for such purposes. 281 4.2. Web Proxy Requirements 283 REQ13: Open-Source Software MUST Be Used 284 Additional Background: The system MUST use an open source web 285 proxy server. (As noted later, Squid has been chosen.) 286 While it is possible to use any web proxy, the use of open 287 source enables others to easily access openly available 288 documentation for the software, among the other benefits 289 commonly attributed to the use of open source software which 290 are also beneficial. 292 REQ14: ICAP Client SHOULD Be Integrated 293 Additional Background: The web proxy server SHOULD have an 294 integrated ICAP client, which simplifies the design and 295 implementation of the system. 297 REQ15: Access Control MUST Be Implemented 298 Additional Background: Access to the proxy MUST be limited 299 exclusively to the IP addresses of users for which 300 notifications are intended, and only for limited periods of 301 time. Furthermore, since a Session Management Broker (SMB) 302 is utilized, as described in Section 5.1 below, then the 303 proxy MUST restrict access only to the address of the SMB. 305 4.3. ICAP Server Requirements 307 REQ16: MUST Provide ICAP Response Support: 308 Additional Background: The system MUST support response 309 adaptation, in accordance with [RFC3507]. An ICAP client 310 passes a HyperText Transport Protocol (HTTP, [RFC2616]) 311 response to an ICAP server for content adaption. The ICAP 312 Server in turn responds back to the client with the HTTP 313 response containing the notification message by using the 314 'respmod' method defined in Section 3.2 of [RFC3507] 316 REQ17: MUST Provide Consistency of Critical Notifications 317 Additional Background: The system MUST be able to 318 consistently provide a specific notification. For example, 319 if a critical alert to notify a user that they are infected 320 with malware is desired, then that notification should 321 consistently look the same for all users and not vary. 323 REQ18: MUST Support Multiple Notification Types 324 Additional Background: While the initial and sole critical 325 notification sent by the system is intended to alert users of 326 a malware infection, malware is a rapidly and continuously 327 evolving threat. As a result of this reality, the system 328 must be able to evolve to provide different types of critical 329 notifications. For example, if malware begins to diverge 330 into several different categories with substantially 331 different implications for end users, then it MAY become 332 desirable to provide a notification which has been narrowly 333 tailored to each category of malware. 335 REQ19: MUST Support Notification to Multiple Users Simultaneously 336 Additional Background: The system MUST be able to 337 simultaneously serve notifications to different users. For 338 example, if 100 users have been infected with malware and 339 critically need to be notified about this security problem, 340 then the system MUST be capable of providing the notification 341 to several users at a time, or all of the users at the same 342 time, rather that to just one user at a time. 344 4.4. Messaging Service Requirements 346 REQ20: A Messaging Service MUST Be Used 347 Additional Background: The Messaging Service, as described in 348 Section 5.1 below, caches the notifications for each specific 349 user. Thus, the notification messages are cached by the 350 system rather than having to retrieve them each time a 351 notification is needed. As a result, the system can be more 352 easily scaled to provide notification to multiple users 353 simultaneously, as noted in an earlier requirement (MUST 354 Support Notification to Multiple Users Simultaneously). 356 REQ21: MUST Process Acknowledgements On a Timely Basis 357 Additional Background: The Messaging Service MUST quickly 358 process notification acknowledgements by end users, as noted 359 in an earlier requirement (Notification Acknowledgement MUST 360 Stop Further Immediate Notifications). 362 REQ22: MUST Ensure Notification Targeting Accuracy 363 Additional Background: The Messaging Service MUST ensure that 364 notifications are presented to the intended users. For 365 example, if the system intends to provide a critical 366 notification to User A and User B, but not User C, then User 367 C MUST NOT be sent a notification. 369 REQ23: SHOULD Keep Notification Records for Customer Support 370 Purposes 371 Additional Background: The Messaging Service SHOULD maintain 372 some type of record that a notification being sent to a user, 373 in case that user inquires with customer support personnel. 374 For example, when a user is presented with the critical 375 notification advising them of a malware infection, that user 376 may choose to call Comcast's Customer Security Assurance 377 team, in the customer service organization. As a result, a 378 Customer Security Assurance representative should be able to 379 confirm that the user did in fact receive a notification 380 concerning malware infection in the course of providing 381 assistance to the end user in remediating the malware 382 infection. 384 5. Implementation Details 386 This section defines and documents the various core functional 387 components of the system, as they are implemented. These components 388 are then shown in a diagram to describe how the various components 389 are linked and relate to one another. 391 5.1. Functional Components Described, As Implemented 393 This section accurately and transparently describes the software 394 packages used by the system described herein, as well as all of the 395 details of how the system functions. The authors acknowledge that 396 there may be multiple alternative software choices for each 397 component; the purpose of this section is to describe those 398 selections which have been made and deployed. 400 5.1.A. Web Proxy: The system SHOULD use and does use Squid Proxy, an 401 open source web proxy application in wide use, and one which 402 supports an integrated ICAP client. 404 5.1.B. ICAP Server: The system SHOULD use and does use GreasySpoon, 405 an open source application. The ICAP Server retrieves the 406 notifications from the Messaging service cache when content 407 adaption is needed. 409 5.1.C. Customer Database: The Customer Database SHOULD hold the 410 relevant information that the system needs to provide a 411 critical notification to a given user. The database MAY also 412 hold the status of which users were notified and users which 413 are pending notification. 415 5.1.D. Messaging Service: The system SHOULD use and does use Apache 416 Tomcat, an open source application. This is a process engine 417 that retrieves specific web notification messages from a 418 catalog of possible notifications. While only one 419 notification is currently used, concerning malware infection, 420 as noted in Section 4.3 the system MAY eventually need to 421 provide multiple notifications (the specific requirement is 422 MUST Support Multiple Notification Types). When a 423 notification for a specific user is not in cache, the process 424 retrieves this information from the Customer Database and 425 populates the cache for a specific period of time. 427 5.1.E. Session Management Broker (SMB): A Load Balancer (LB) with a 428 customized layer 7 inspection policy SHOULD be and is used to 429 differentiate between HTTP and non-HTTP traffic on TCP port 430 80, in order to meet the requirements documented in Section 4 431 above. The system uses a LB from A10 Networks. The SMB 432 functions as a full stateful TCP proxy with the ability to 433 forward packets from existing TCP sessions that do not exist 434 in the internal session table (to meet the specific 435 requirement MUST Handle Pre-Existing Active TCP Sessions 436 Gracefully). New HTTP sessions are load balanced to the web 437 proxy layer either transparently or using source Network 438 Address Translation (NAT [RFC1631]) from the SMB. Non-HTTP 439 traffic for established TCP sessions not in the SMB session 440 table is simply forwarded to the destination transparently 441 via the TCP proxy layer (again, to meet the specific 442 requirement MUST Handle Pre-Existing Active TCP Sessions 443 Gracefully). 445 5.2. Functional Diagram, As Implemented 447 +--------+ +------------+ +----------+ 448 | ICAP | <----> | Messaging | <----> | Customer | 449 | Server | | Service | | Database | 450 +--------+ +------------+ +----------+ 451 ^ 452 | +----------+ 453 | | | 454 | +-------> | Internet | <-------+ 455 | | | | | 456 | | +----------+ | 457 | | ^ | 458 v v | | 459 +----------+ v v 460 |+--------+| +-------+ +--------+ 461 || ICAP || <----> | SMB | <---> | Access | 462 || Client || +-------+ | Router | 463 |+--------+| +--------+ 464 || SQUID || ^ 465 || Proxy || | 466 |+--------+| v 467 +----------+ +----------+ 468 | CMTS* | 469 +----------+ 470 ^ 471 | 472 v 473 +------+ 474 | PC | 475 +------+ 477 * A Cable Modem Termination System (CMTS) 478 is an access network element. 480 Figure 1: Web Notification System - Functional Components 482 6. High Level Communication Flow, As Implemented 484 6.A. Setup Differentiated Services (DiffServ): Using DiffServe 485 [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] 486 [RFC4594], set a policy to direct TCP port 80 traffic to the 487 web notification system's web proxy. 489 6.B. Session Management: TCP port 80 packets are routed to a Session 490 Management Broker which distinguishes between HTTP or non-HTTP 491 traffic and between new and existing sessions. HTTP packets 492 are forwarded to the web proxy by the SMB. Non-HTTP packets 493 such as instant messaging (IM) traffic are forwarded to a TCP 494 proxy layer for routing to destination or the SMB operates as 495 the full TCP proxy and forwards the non-HTTP packets to the 496 destination. Pre-established TCP sessions on port 80 are 497 identified by the SMB and forwarded with no impact. 499 6.C. 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 6.D. On Response, Send Message to ICAP Server: When the HTTP 504 response is received from the destination server, the web proxy 505 sends a message to the ICAP server for the web notification. 507 6.E. Messaging Service: The Messaging Service should respond with 508 appropriate notification content or null response if 509 notification is not cached. 511 6.F. ICAP Server Responds: The ICAP server responds and furnishes 512 the appropriate content for the web notification to the web 513 proxy. 515 6.G. Web Proxy Sends Response: The web proxy then forwards the HTTP 516 response to the client web browser containing the web 517 notification. 519 6.H. User Response: The user observes the critical web notification, 520 and clicks an appropriate option, such as: OK/acknowledged, 521 snooze/remind me later, etc. 523 6.I. More Information: Depending upon the notification, the user may 524 be provided with more information. For example, as noted 525 previously herein, the system was designed to provide critical 526 notifications concerning malware infection. Thus, in the case 527 of malware infection, the user may be advised to go to a 528 malware remediation web page that provides directions on how to 529 attempt to remove the malware and attempt to secure hosts 530 against future malware infection. 532 6.J. Turn Down DiffServ: Once the notification transaction has 533 completed, remove any special DiffServ settings. 535 7. Communication Between Web Proxy and ICAP Server, As Implemented 537 +------------+ 538 | www URI | 539 +------------+ 540 ^ | 541 (2)| |(3) 542 | v 543 +--------+ (4) +--------+ (4) +--------+ 544 | |------------>| |------------>| | 545 | | (5) | | (5) | | 546 | Proxy |<------------| ICAP |<------------| ICAP | 547 | Module | (6) | Client | (6) | Server | 548 | |------------>| |------------>| | 549 | | (7) | | (7) | | 550 | |<------------| |<------------| | 551 +--------+ +--------+ +--------+ 552 ^ | 553 (1)| |(8) 554 | v 555 +------------+ (9) +------------+ 556 | |----------------------------->| | 557 | Browser | (10) | Web Server | 558 | |<-----------------------------| | 559 +------------+ +------------+ 561 (1) - HTTP GET (TCP 80) 562 (2) - Proxy HTTP GET (TCP 80) 563 (3) - HTTP 200 OK w/ Response 564 (4) - ICAP RESPMOD 565 (5) - ICAP 200 OK 566 (6) - TCP Stream - Encapsulate Header 567 (7) - ICAP 200 OK Insert Message 568 (8) - HTTP 200 OK w/ Response + Message Frame 569 (9) - HTTP GET for Message 570 (10) - HTTP 200 w/ Message Content 572 Figure 2: Communication Between Web Proxy and ICAP Server 574 8. End-to-End Web Notification Flow, As Implemented 576 8.1. Step-by-Step Description of the End-to-End Web Notification Flow 578 8.1.1. Policy-Based Routing 580 1. TCP port 80 packets from the user that needs to be notified are 581 routed to the Web Proxy via policy based routing. 583 2. Packets are forwarded to the Session Management Broker, which 584 establishes a session with the Web Proxy and routes the packets 585 to the Web Proxy. 587 8.1.2. Web Proxy 589 1. The user's HTTP request is directed to the Web Proxy. 591 2. The Web Proxy receives HTTP traffic and retrieves content from 592 the requested web site. 594 3. The Web Proxy receives the response and forwards it to the ICAP 595 Server for response adaptation. 597 4. The ICAP Server checks the HTTP content in order to determine 598 whether notification message can be inserted. 600 5. The ICAP Server initiates a request to the Messaging Service 601 cache process with the IP address of the user. 603 6. If a notification message for the user exists then the 604 appropriate notification is cached on the Messaging Service. 605 The Messaging Service then returns the appropriate notification 606 content to the ICAP Server. 608 7. Once the notification message is retrieved from Messaging 609 Service cache the ICAP server may insert the notification 610 message in the HTTP response body without altering or modifying 611 the original content of the HTTP response. 613 8. The ICAP Server then sends the response back to the Web Proxy, 614 which in turn forwards the HTTP response back to the browser. 616 9. If the user's IP address is not found or provisioned for a 617 notification message, then the ICAP Server should return a '204 618 No Modifications Needed' response to the ICAP Client as defined 619 in section 4.3.3 of [RFC3507]. As a result, the user will not 620 receive any web notification message. 622 10. The user observes the web notification, and clicks an 623 appropriate option, such as: OK/acknowledged, snooze/ remind me 624 later, etc. 626 8.2. Diagram of the End-to-End Web Notification Flow 628 The two figures below show the communications flow from the Web 629 Browser, through the Web Notification System. 631 The first figure below illustrates what occurs when a notification 632 request cannot be inserted because the notification type for the 633 user's IP address is not cached in the Messaging Service. 635 ICAP ICAP Message Customer 636 Browser Proxy Client Server Service Internet DB 637 | HTTP | | | | | | 638 | GET | Proxy | | | | | 639 +------->| Request | | | | | 640 | +---------|---------|--------|------->| | 641 | | | | | 200 OK | | 642 | |<--------|---------|--------|--------+ | 643 | | ICAP | | | | | 644 | | RESPMOD | ICAP | | | | 645 | +-------->| RESPMOD | Check | | | 646 | | +-------->| Cache | | | 647 | | | | for IP | | | 648 | | | | Match | | | 649 | | | +------->| | | 650 | | | | Cache | | | 651 | | | | Miss | | | 652 | | | |<-------+ Request| | 653 | | | 204 No | | Type | | 654 | | | Modif. | +--------|------->| 655 | | | Needed | | | | 656 | | No |<--------+ | | Type | 657 | | Insert | | | |Returned| 658 | 200 OK |<--------+ | |<-------|--------+ 659 | w/o | | | | | | 660 | Insert | | | | | | 661 |<-------+ | | | | | 662 | | | | | | | 664 Figure 3: End-to-End Web Notification Flow - With Cache Miss 666 The figure below illustrates what occurs when a notification request 667 for the user's IP address is cached in the Messaging Service. 669 ICAP ICAP Message Customer 670 Browser Proxy Client Server Service Internet DB 671 | HTTP | | | | | | 672 | GET | Proxy | | | | | 673 +------->| Request | | | | | 674 | +---------|---------|--------|------->| | 675 | | | | | 200 OK | | 676 | |<--------|---------|--------|--------+ | 677 | | ICAP | | | | | 678 | | RESPMOD | ICAP | | | | 679 | +-------->| RESPMOD | Check | | | 680 | | +-------->| Cache | | | 681 | | | | for IP | | | 682 | | | | Match | | | 683 | | | +------->| | | 684 | | | | Cache | | | 685 | | | | Hit | | | 686 | | | Insert |<-------+ | | 687 | | Return | Type | | | | 688 | | 200 OK |<--------+ | | | 689 | | with | | | | | 690 | | Insert | | | | | 691 | 200 OK |<--------+ | | | | 692 | w/ | | | | | | 693 | Notify | | | | | | 694 |<-------+ | | | | | 695 | | | | | | | 697 Figure 4: End-to-End Web Notification Flow - With Cache Hit 699 9. Example HTTP Headers and JavaScript for a Web Notification 701 The figure below shows an example of a normal HTTP GET request from 702 the user's web browser to www.example.com, a web server on the 703 Internet. 705 ------------------------------------------------------------------------ 706 1. HTTP Get Request to www.example.com 707 ------------------------------------------------------------------------ 708 http://www.example.com/ 710 GET / HTTP/1.1 711 Host: www.example.com 712 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) 713 Gecko/20080404 Firefox/2.0.0.14 714 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 715 Accept-Language: en-us,en;q=0.5 716 Accept-Encoding: gzip,deflate 717 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 718 Keep-Alive: 300 719 Connection: keep-alive 720 Pragma: no-cache 721 ------------------------------------------------------------------------ 723 Figure 5: Example HTTP Headers for a Web Notification - HTTP Get 725 In the figure below, the traffic is routed via the Web Proxy, which 726 communicates with the ICAP Server and returns the response from 727 www.example.com. In this case that response is a 200 OK, with the 728 desired notification message inserted. 730 ------------------------------------------------------------------------ 731 2. Response from www.example.com via PROXY 732 ------------------------------------------------------------------------ 733 HTTP/1.x 200 OK 734 Date: Thu, 08 May 2008 16:26:29 GMT 735 Server: Apache/2.2.3 (CentOS) 736 Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT 737 Etag: "b80f4-1b6-80bfd280" 738 Accept-Ranges: bytes 739 Content-Length: 438 740 Connection: close 741 Content-Type: text/html; charset=UTF-8 742 Age: 18 743 X-Cache: HIT from localhost.localdomain 744 Via: 1.0 localhost.localdomain (squid/3.0.STABLE5) 745 Proxy-Connection: keep-alive 746 ------------------------------------------------------------------------ 748 Figure 6: Example HTTP Headers for a Web Notification - HTTP Response 750 The figure below shows an example of the web notification content 751 inserted in the 200 OK response, in this example JavaScript code. 753 ------------------------------------------------------------------------ 754 3. Example of JavaScript containing Notification Insertion 755 ------------------------------------------------------------------------ 756 758 769 783 ------------------------------------------------------------------------ 785 Figure 7: Example JavaScript Used in a Web Notification 787 10. Deployment Considerations 789 The components of the web notification system SHOULD be distributed 790 throughout the network and close to end users. This ensures that the 791 routing performance and the user's web browsing experience remains 792 excellent. In addition, a HTTP-aware load balancer SHOULD used in 793 each datacenter where servers are located, so that traffic can be 794 spread across N+1 servers and the system can be easily scaled. 796 11. Security Considerations 798 This critical web notification system was conceived in order to 799 provide an additional method of notifying end user customers that 800 their computer has been infected with malware. Depending upon the 801 specific text of the notification, users could fear that it is some 802 kind of phishing attack. As a result, care SHOULD and has been taken 803 with the text and any links contained in the web notification itself. 804 For example, should the notification text change over time, it MAY be 805 best to provide a general URI or a telephone number. In contrast to 806 that, the notification MUST NOT ask for login credentials, and MUST 807 NOT ask a user to follow a link in order to change their password, 808 since these are common phishing techniques. Finally, care SHOULD be 809 taken to provide confidence that the web notification is valid and 810 from a trusted party, and/or that the user has an alternate method of 811 checking the validity of the web notification. One alternate method 812 of validating the notification may be to call customer support, in 813 this example to call Comcast's Customer Security Assurance team, 814 which explains a key requirement (specifically, SHOULD Keep 815 Notification Records for Customer Support Purposes) in Section 4.4 816 above. 818 12. Debating The Necessity of Such a Critical Notification System 820 Some members of the community may question whether it is ever, under 821 any circumstances, acceptable to modify Internet content in order to 822 provide critical service notification concerning malware infection - 823 even in the smallest of ways, even if openly and transparently 824 documented, even if thoroughly tested, and even if for the best of 825 motivations. It is important that anyone with such concerns 826 recognize that this document is by no means the first to propose 827 this, particularly as a tactic to combat a security problem, and in 828 fact simply leverages previous work in the IETF, such as [RFC3507]. 829 Such concerned parties should also study the many organizations using 830 ICAP and the many software systems which have implemented ICAP. 832 In addition, concerned members of the community should review 833 Section 2 which describes the fact that this is a common feature of 834 DPI systems, made by DPI vendors and many, if not most, major 835 networking equipment vendors. As the authors describe herein, they 836 are motivated to AVOID the need for widespread, ubiquitous deployment 837 of DPI, via the use of both open source software and open protocols, 838 and are further motivated to transparently describe the details of 839 how such a system functions, what it IS intended to do, what it IS 840 NOT intended to do, and purposes for which it WILL NOT be used. 842 The authors also believe it is important for ISPs to transparently 843 disclose network management techniques and systems, and to have a 844 venue to do so, as has been done here. In addition, the authors 845 believe it is important for the IETF and other members of the 846 Internet community encourage and positively reinforce such 847 disclosures. In the publishing of such a document for reference and 848 comment by the Internet community, this may serve to motivate other 849 ISPs to be similarly open and to engage the IETF and other 850 organizations that are part of the Internet community. Members of 851 the community that argue that documents such as this have no value 852 may wish to consider that such a viewpoint could have unintended 853 effects, such as motivating less disclosure on the part of ISPs and 854 other members of the Internet community, increased rather than 855 decreased use of DPI, and decreased rather than increased 856 participation in the critical technical bodies that make up parts of 857 the Internet community. 859 In addition, it is critical that members of the community recognize 860 the good motivations of ISPs like Comcast to combat the massive and 861 continuing proliferation malware, which is a huge threat to the 862 security of average Internet users and now represents a multi- 863 billion-dollar underground economy engaged in identity theft, 864 financial fraud, transmission of spam, and other criminal activity. 865 Such a critical notification system in fact is only necessary due to 866 the failure of host-based security at defending against and 867 preventing malware infection. As such, ISPs such as Comcast are 868 being urged by their customers and by other parties such as security 869 and/or privacy organizations, as well as governmental organizations, 870 to take action to help solve this massive problem since so many other 871 tactics have been unsuccessful. For example, as Howard Schmidt, the 872 Special Advisory for Cyber Security to President Obama, of the United 873 States of America, was recently quoted: "As attacks on home-based and 874 unsecured networks become as prevalent as those against large 875 organizations, the need for ISPs to do everything they can to make 876 security easier for their subscribers is critical for the 877 preservation of our nation's information backbone. Additionally, 878 there is tremendous potential to grow further the use of broadband 879 around the world; and making safety and security part of an ISP's 880 core offering will enable the end user to fully experience the rich 881 and robust benefits broadband provides." 883 13. Suggesting a Walled Garden As An Alternative 885 A walled garden refers to an environment that controls the 886 information and services that a subscriber is allowed to utilize and 887 what network access permissions are granted. Placing a user in a 888 walled garden is therefore another approach that ISPs may take to 889 notify users, and this method is being explored as a possible 890 alternative in other documents and community efforts. As such, web 891 notifications should be considered one of many possible notification 892 methods which merits documentation. 894 However, a walled garden approach can pose challenges and may in some 895 cases be considered disruptive to end users. For example, a user 896 could be playing a game online, via the use of a dedicated, Internet- 897 connected game console, which would likely stop working when the user 898 was placed in the walled garden. In another example, the user may be 899 in the course of a telephone conversation, using a Voice Over IP 900 (VoIP) device of some type, which would also likely stop working when 901 the user was placed in the walled garden. In both cases, the user is 902 not using a web browser and would not have a way to determine the 903 reason why their service seemingly stopped working. 905 14. Intended Next Steps 907 Unfortunately, no existing working group of the IETF is focused on 908 issues of malware infection and related issues. As a result, there 909 is not a definite venue for this document so this has been submitted 910 to the RFC Editor as an individual submission. While documentation 911 and disclosure of this system is beneficial for the Internet 912 community in and of itself, there are other benefits to having this 913 document published. One of those reasons is that members of the 914 community, including members of the IETF, have a stable document to 915 refer to in case of any potential new work that the community may 916 undertake in the area of malware, security, and critical notification 917 to end users. It is also hoped that, in the tradition of a Request 918 for Comment, other members of the community may be motivated to 919 propose alternative systems or other improvements. In addition, the 920 authors hope to be able to use this reference document with the World 921 Wide Web Consortium (W3C) or other organization, to request the 922 development of alternative or superior methods to provide critical 923 web notifications, as recommended by a member of the Internet 924 Engineering Steering Group (IESG). 926 15. IANA Considerations 928 There are no IANA considerations in this document. 930 NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO 931 PUBLICATION. 933 16. Acknowledgements 935 The authors wish to thank Alissa Cooper for her review of and 936 comments on the document, as well as others who reviewed the 937 document. 939 17. References 941 17.1. Normative References 943 [RFC1035] Mockapetris, P., "Domain names - implementation and 944 specification", STD 13, RFC 1035, November 1987. 946 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 947 Translator (NAT)", RFC 1631, May 1994. 949 [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup 950 Language - 2.0", RFC 1866, November 1995. 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, March 1997. 955 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 956 Resource Identifiers (URI): Generic Syntax", RFC 2396, 957 August 1998. 959 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 960 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 961 October 1998. 963 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 964 "Definition of the Differentiated Services Field (DS 965 Field) in the IPv4 and IPv6 Headers", RFC 2474, 966 December 1998. 968 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 969 and W. Weiss, "An Architecture for Differentiated 970 Services", RFC 2475, December 1998. 972 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 973 "Assured Forwarding PHB Group", RFC 2597, June 1999. 975 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 976 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 977 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 979 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 980 specifying the location of services (DNS SRV)", RFC 2782, 981 February 2000. 983 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 984 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 986 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 987 "Per Hop Behavior Identification Codes", RFC 3140, 988 June 2001. 990 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 991 J., Courtney, W., Davari, S., Firoiu, V., and D. 992 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 993 Behavior)", RFC 3246, March 2002. 995 [RFC3260] Grossman, D., "New Terminology and Clarifications for 996 Diffserv", RFC 3260, April 2002. 998 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 999 A., Peterson, J., Sparks, R., Handley, M., and E. 1000 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1001 June 2002. 1003 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1004 Protocol (SIP): Locating SIP Servers", RFC 3263, 1005 June 2002. 1007 [RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation 1008 Protocol (ICAP)", RFC 3507, April 2003. 1010 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 1011 April 2006. 1013 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1014 Guidelines for DiffServ Service Classes", RFC 4594, 1015 August 2006. 1017 17.2. Informative References 1019 [CableLabs DOCSIS] 1020 CableLabs, "Data-Over-Cable Service Interface 1021 Specifications", CableLabs Specifications Various DOCSIS 1022 Reference Documents, . 1025 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 1026 BCP 60, RFC 3360, August 2002. 1028 Appendix A. Document Change Log 1030 [RFC Editor: This section is to be removed before publication] 1031 o -07 - Made modifications to accommodate concerns raised by the RFC 1032 Editor and his reviewers. This includes CAPITALIZING all RFC 2119 1033 language, adding more context and background to the requirements 1034 section, making the introduction more precise, making the document 1035 describe more of the actual implementation details, updating 1036 security considerations, and adding three new sections (12, 13, 1037 14). 1039 o -06 - Corrected WL/BL error 1041 o -05 - fixed odd spacing in 8.1 1043 o -04 - corrections and tweaks by Jason 1045 o -03 - corrections and clarifications from Nirmal and BVL 1047 o -02 - updated BVL's contact info, clearing one open issue. Also 1048 added content to Security Considerations. 1050 o -01 - updated doc to reflect that this system is deployed and not 1051 in development, closing out two open issues. Added reference for 1052 JavaScript, closing an open issue. 1054 o -00 - first version published 1056 Authors' Addresses 1058 Chae Chung 1059 Comcast Cable Communications 1060 One Comcast Center 1061 1701 John F. Kennedy Boulevard 1062 Philadelphia, PA 19103 1063 US 1065 Email: chae_chung@cable.comcast.com 1066 URI: http://www.comcast.com 1067 Alex Kasyanov 1068 Comcast Cable Communications 1069 One Comcast Center 1070 1701 John F. Kennedy Boulevard 1071 Philadelphia, PA 19103 1072 US 1074 Email: alexander_kasyanov@cable.comcast.com 1075 URI: http://www.comcast.com 1077 Jason Livingood 1078 Comcast Cable Communications 1079 One Comcast Center 1080 1701 John F. Kennedy Boulevard 1081 Philadelphia, PA 19103 1082 US 1084 Email: jason_livingood@cable.comcast.com 1085 URI: http://www.comcast.com 1087 Nirmal Mody 1088 Comcast Cable Communications 1089 One Comcast Center 1090 1701 John F. Kennedy Boulevard 1091 Philadelphia, PA 19103 1092 US 1094 Email: nirmal_mody@cable.comcast.com 1095 URI: http://www.comcast.com 1097 Brian Van Lieu 1098 Unaffiliated 1099 Bethlehem, PA 18018 1100 US 1102 Email: brian@vanlieu.net