INFORMATIONAL

Independent Submission C. Chung Request for Comments: 6108 A. Kasyanov Category: Informational J. Livingood ISSN: 2070-1721 N. Mody Comcast B. Van Lieu Unaffiliated February 2011 Comcast's Web Notification System Design Abstract The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6108. Chung, et al. Informational [Page 1]

RFC 6108 Comcast's Web Notification System February 2011 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction ....................................................3 2. High-Level Design of the System .................................3 3. Design Requirements .............................................3 3.1. General Requirements .......................................4 3.2. Web Proxy Requirements .....................................6 3.3. ICAP Server Requirements ...................................7 3.4. Messaging Service Requirements .............................8 4. Implementation Details ..........................................8 4.1. Functional Components Described, as Implemented ............9 4.2. Functional Diagram, as Implemented ........................10 5. High-Level Communication Flow, as Implemented ..................11 6. Communication between Web Proxy and ICAP Server, as Implemented ....................................................12 7. End-to-End Web Notification Flow, as Implemented ...............13 7.1. Step-by-Step Description of the End-to-End Web Notification Flow .........................................14 7.2. Diagram of the End-to-End Web Notification Flow ...........15 8. Example HTTP Headers and JavaScript for a Web Notification .....16 9. Deployment Considerations ......................................18 10. Security Considerations .......................................19 11. Debating the Necessity of Such a Critical Notification System ........................................................19 12. Suggesting a Walled Garden as an Alternative ..................20 13. Intended Next Steps ...........................................21 14. Acknowledgements ..............................................21 15. References ....................................................21 15.1. Normative References .....................................21 15.2. Informative References ...................................23 Chung, et al. Informational [Page 2]

RFC 6108 Comcast's Web Notification System February 2011 1 . Introduction CableLabs_DOCSIS]) networks used by most cable-based broadband ISPs, concepts described in this document can generally be applied to many different types of networks should those ISPs be interested in alternatives to DPI. 2 . High-Level Design of the System RFC3507]. The design uses open source applications, which are the Squid web proxy, GreasySpoon ICAP server, and Apache Tomcat. ICAP, an existing IETF protocol, allows for message transformation or adaptation. An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616]) response to an ICAP server for content adaption. The ICAP server in turn responds back to the client with the HTTP response containing the notification message by using the "respmod" method defined in Section 3.2 of [RFC3507]. 3 . Design Requirements Chung, et al. Informational [Page 3]

RFC 6108 Comcast's Web Notification System February 2011 3.1 . General Requirements RFC2854]) or JavaScript [RFC4329] used for notifications may cause problems while accessing a particular website. Therefore, such a system must be capable of using a block list of website Uniform Resource Identifiers (URIs, [RFC3986]) or Fully Qualified Domain Names (FQDNs, Section 5.1 of [RFC1035]) that conflict with the system, so that the system does not provide notifications in these cases, in order to minimize any errors or unexpected results. Also, while extensive development and testing has been performed to ensure that this system does not behave in unexpected ways, and standard ICAP (which has been in use for many years) is utilized, it is critical that if it does behave in such a way, there must be a method to rapidly exempt specific URIs or FQDNs. R3.1.4. Must Not Cause Problems with Instant Messaging (IM) Clients Using TCP Port 80 Additional Background: Some IM clients use TCP port 80 in their communications, often as an alternate port when standard, well-known ports do not work. Other IM clients may in fact use TCP port 80 by default, in some cases even being based in a web browser. Therefore, this system must not conflict with or cause unexpected results for IM clients (or any other client types) that use TCP port 80. Chung, et al. Informational [Page 4]

RFC 6108 Comcast's Web Notification System February 2011 RFC3360]. In Comcast's recent history, for example, the company was criticized for using TCP resets in the course of operating a DPI-based network management system. As such, TCP resets as a function of the system must not be used. R3.1.7. Must Be Non-Disruptive Additional Background: The web notification system must not disrupt the end-user experience, for example by causing significant client errors. R3.1.8. User Notification Acknowledgement Must Stop Further Immediate Notifications Additional Background: Once a user acknowledges a critical notification, the notification should immediately stop. Otherwise, the user may believe the system is stuck in an error state and may not believe that the critical notification is valid. In addition, it is quite possible that the user will be annoyed that the system did not react to his acknowledgement. R3.1.9. Non-Modification of Content Should Be Maintained Additional Background: The system should not significantly alter the content of the HTTP response from any website the user is accessing. R3.1.10. Must Handle Unexpected Content Gracefully Additional Background: Sometimes, developers and/or implementers of software systems assume that a narrow range of inputs to a system will occur, all of which have been thought of beforehand by the designers. The authors Chung, et al. Informational [Page 5]

RFC 6108 Comcast's Web Notification System February 2011 3.2 . Web Proxy Requirements Section 2 and Section 4.1, Squid has been chosen.) While it is possible to use any web proxy, the use of open source enables others to easily access openly available documentation for the software, among the other benefits commonly attributed to the use of open source software. R3.2.2. ICAP Client Should Be Integrated Additional Background: The web proxy server should have an integrated ICAP client, which simplifies the design and implementation of the system. Chung, et al. Informational [Page 6]

RFC 6108 Comcast's Web Notification System February 2011 Section 4.1 below, then the proxy must restrict access only to the address of the SMB. 3.3 . ICAP Server Requirements RFC3507]. An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616]) response to an ICAP server for content adaption. The ICAP server in turn responds back to the client with the HTTP response containing the notification message by using the "respmod" method defined in Section 3.2 of [RFC3507]. R3.3.2. Must Provide Consistency of Critical Notifications Additional Background: The system must be able to consistently provide a specific notification. For example, if a critical alert to notify a user that they are infected with malware is desired, then that notification should consistently look the same for all users and not vary. R3.3.3. Must Support Multiple Notification Types Additional Background: While the initial and sole critical notification sent by the system is intended to alert users of a malware infection, malware is a rapidly and continuously evolving threat. As a result of this reality, the system must be able to evolve to provide different types of critical notifications. For example, if malware begins to diverge into several different categories with substantially different implications for end users, then it may become desirable to provide a notification that has been narrowly tailored to each category of malware. R3.3.4. Must Support Notification to Multiple Users Simultaneously Additional Background: The system must be able to simultaneously serve notifications to different users. For example, if 100 users have been infected with malware and critically need to be notified about this security problem, then the system must be capable of providing the notification to several users at a time, or all of the users at the same time, rather than to just one user at a time. Chung, et al. Informational [Page 7]

RFC 6108 Comcast's Web Notification System February 2011 3.4 . Messaging Service Requirements Section 4.1 below, caches the notifications for each specific user. Thus, the notification messages are cached by the system and do not have to be retrieved each time a notification is needed. As a result, the system can be more easily scaled to provide notification to multiple users simultaneously, as noted in an earlier requirement ("Must Support Notification to Multiple Users Simultaneously"). R3.4.2. Must Process Acknowledgements on a Timely Basis Additional Background: The Messaging Service must quickly process notification acknowledgements by end users, as noted in an earlier requirement ("User Notification Acknowledgement Must Stop Further Immediate Notifications"). R3.4.3. Must Ensure Notification Targeting Accuracy Additional Background: The Messaging Service must ensure that notifications are presented to the intended users. For example, if the system intends to provide a critical notification to User A and User B, but not User C, then User C must not be sent a notification. R3.4.4. Should Keep Notification Records for Customer Support Purposes Additional Background: The Messaging Service should maintain some type of record that a notification has been sent to a user, in case that user inquires with customer support personnel. For example, when a user is presented with the critical notification advising them of a malware infection, that user may choose to call Comcast's Customer Security Assurance team, in the customer service organization. As a result, a Customer Security Assurance representative should be able to confirm that the user did in fact receive a notification concerning malware infection in the course of providing assistance to the end user in remediating the malware infection. 4 . Implementation Details Chung, et al. Informational [Page 8]

RFC 6108 Comcast's Web Notification System February 2011 4.1 . Functional Components Described, as Implemented Section 3.3 the system may eventually need to provide multiple notifications (the specific requirement is "Must Support Multiple Notification Types"). When a notification for a specific user is not in the cache, the process retrieves this information from the Customer Database and populates the cache for a specific period of time. S4.1.5. Session Management Broker (SMB): A Load Balancer (LB) with a customized layer 7 inspection policy is used to differentiate between HTTP and non-HTTP traffic on TCP port 80, in order to meet the requirements documented in Section 3 above. The system uses a LB from A10 Networks. The SMB functions as a full stateful TCP proxy with the ability to forward packets from existing TCP sessions that do not exist in the internal session table (to meet the specific requirement "Must Handle Pre-Existing Active TCP Sessions Gracefully"). New HTTP sessions are load balanced to the web proxy layer either transparently or using source Network Address Translation (NAT [RFC3022]) from the SMB. Chung, et al. Informational [Page 9]

RFC 6108 Comcast's Web Notification System February 2011 4.2 . Functional Diagram, as Implemented Chung, et al. Informational [Page 10]

RFC 6108 Comcast's Web Notification System February 2011 5 . High-Level Communication Flow, as Implemented Section 4, the functional components of the system were described, and then shown in relation to one another in Figure 1 above. This section describes the high-level communication (C) flow of a transaction in the system, in order to explain the general way that the functions work together in action. This will be further explained in much more detail in later sections of this document. C5.1. Setup of Differentiated Services (Diffserv): Using Diffserv [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] [RFC4594], set a policy to direct TCP port 80 traffic to the web notification system's web proxy. C5.2. Session Management: TCP port 80 packets are routed to a Session Management Broker (SMB) that distinguishes between HTTP or non-HTTP traffic and between new and existing sessions. HTTP packets are forwarded to the web proxy by the SMB. Non-HTTP packets such as instant messaging (IM) traffic are forwarded to a TCP proxy layer for routing to their destination, or the SMB operates as a full TCP proxy and forwards the non-HTTP packets to the destination. Pre-established TCP sessions on port 80 are identified by the SMB and forwarded with no impact. C5.3. Web Proxy Forwards Request: The web proxy forwards the HTTP request on to the destination site, a web server, as a web proxy normally would do. C5.4. On Response, Send Message to ICAP Server: When the HTTP response is received from the destination server, the web proxy sends a message to the ICAP server for the web notification. C5.5. Messaging Service: The Messaging Service should respond with appropriate notification content or null response if no notification is cached. C5.6. ICAP Server Responds: The ICAP server responds and furnishes the appropriate content for the web notification to the web proxy. C5.7. Web Proxy Sends Response: The web proxy then forwards the HTTP response containing the web notification to the client web browser. Chung, et al. Informational [Page 11]

RFC 6108 Comcast's Web Notification System February 2011 6 . Communication between Web Proxy and ICAP Server, as Implemented Chung, et al. Informational [Page 12]

RFC 6108 Comcast's Web Notification System February 2011 7 . End-to-End Web Notification Flow, as Implemented Chung, et al. Informational [Page 13]

RFC 6108 Comcast's Web Notification System February 2011 7.2 . Diagram of the End-to-End Web Notification Flow Chung, et al. Informational [Page 15]

RFC 6108 Comcast's Web Notification System February 2011 8 . Example HTTP Headers and JavaScript for a Web Notification Chung, et al. Informational [Page 16]

RFC 6108 Comcast's Web Notification System February 2011 1 . HTTP GET Request to www.example.com 2 . Response from www.example.com via PROXY Chung, et al. Informational [Page 17]

RFC 6108 Comcast's Web Notification System February 2011 3 . Example of JavaScript containing Notification Insertion 9 . Deployment Considerations Chung, et al. Informational [Page 18]

RFC 6108 Comcast's Web Notification System February 2011 10 . Security Considerations Section 3.4. 11 . Debating the Necessity of Such a Critical Notification System RFC3507]. Such concerned parties should also study the many organizations using ICAP and the many software systems that have implemented ICAP. In addition, concerned members of the community should review Section 1, which describes the fact that this is a common feature of DPI systems, made by DPI vendors and many, if not most, major networking equipment vendors. As described herein, the authors of this document are motivated to AVOID the need for widespread, ubiquitous deployment of DPI, via the use of both open source software and open protocols, and are further motivated to transparently describe the details of how such a system functions, what it IS intended to do, what it IS NOT intended to do, and purposes for which it WILL NOT be used. Chung, et al. Informational [Page 19]

RFC 6108 Comcast's Web Notification System February 2011 12 . Suggesting a Walled Garden as an Alternative Chung, et al. Informational [Page 20]

RFC 6108 Comcast's Web Notification System February 2011 http://www.comcast.com Alex Kasyanov Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: alexander_kasyanov@cable.comcast.com URI: http://www.comcast.com Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: jason_livingood@cable.comcast.com URI: http://www.comcast.com Nirmal Mody Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: nirmal_mody@cable.comcast.com URI: http://www.comcast.com Brian Van Lieu Unaffiliated Bethlehem, PA 18018 US EMail: brian@vanlieu.net Chung, et al. Informational [Page 24]