diff options
Diffstat (limited to 'doc/rfc/rfc6108.txt')
| -rw-r--r-- | doc/rfc/rfc6108.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc6108.txt b/doc/rfc/rfc6108.txt new file mode 100644 index 0000000..eb558b7 --- /dev/null +++ b/doc/rfc/rfc6108.txt @@ -0,0 +1,1347 @@ + + + + + + +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 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to 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 + + Internet Service Providers (ISPs) have a need for a system that is + capable of communicating with customers in a nearly immediate manner, + to convey critical service notices such as warnings concerning likely + malware infection. Given the prevalence of the web browser as the + predominant client software in use by Internet users, the web browser + is an ideal vehicle for providing these notifications. This document + describes a system that has been deployed by Comcast, a broadband + ISP, to provide near-immediate notifications to web browsers. + + In the course of evaluating potential solutions, the authors + discovered that the large majority of commercially available systems + utilized Deep Packet Inspection (DPI) technology. While a DPI-based + system would certainly work, Comcast and other ISPs are trying to + avoid widespread deployment and use of DPI, and are searching for + alternatives. Thus, Comcast desired to use a system that is based on + open standards and non-proprietary software, and that did not require + the use of DPI. While the system described herein is specific to the + Data-Over-Cable Service Interface Specifications (DOCSIS, + [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 + + The web notification system design is based on the use of the + Internet Content Adaptation Protocol (ICAP) [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 + + This section describes all of the key requirements taken into + consideration by Comcast for the design of this system. This + information is provided in order to convey important design choices + that were made in order to avoid the use of DPI, among other things. + An "Additional Background" paragraph is included with each + requirement to provide additional information, context, or other + useful explanation. + + + + +Chung, et al. Informational [Page 3] + +RFC 6108 Comcast's Web Notification System February 2011 + + +3.1. General Requirements + + R3.1.1. Must Only Be Used for Critical Service Notifications + Additional Background: The system must only provide + critical notifications, rather than trivial notifications. + An example of a critical, non-trivial notification, which + is also the primary motivation of this system, is to advise + the user that their computer is infected with malware, that + their security is at severe risk and/or has already been + compromised, and that it is recommended that they take + immediate, corrective action NOW. + + R3.1.2. Must Use TCP Port 80 + Additional Background: The system must provide + notifications via TCP port 80, the well-known port for HTTP + traffic. Since the large majority of customers use a web + browser as their primary application, this was deemed the + best method to provide them with an immediate, critical + notification. + + R3.1.3. Must Support Block Listing + Additional Background: While unlikely, it is possible that + the HyperText Markup Language (HTML, [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 + + + R3.1.5. Must Handle Pre-Existing Active TCP Sessions Gracefully + Additional Background: Since the web notification system + may temporarily re-route TCP port 80 traffic in order to + provide a critical notification, previously established TCP + port 80 sessions must not be disrupted while being routed + to the proxy layer. Also, since the critical web + notification occurs at a well-defined point in time, it is + logical to conclude that an end user may well have an + active TCP port 80 session in progress before the + notification is sent, and which is still active at the time + of the notification. It is therefore important that any + such connections must not be reset, and that they instead + must be handled gracefully. + + R3.1.6. Must Not Use TCP Resets + Additional Background: The use of TCP resets has been + widely criticized, both in the Internet community generally + and in [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 + + + believe this is a poor assumption to make in the design and + implementation of a system and, in contrast, that + unexpected or even malformed inputs should be assumed. As + a result, the system must gracefully and transparently + handle traffic that is unexpected, even though there will + be cases when the system cannot provide a critical web + notification as a result of this. Thus, widely varying + content should be expected, and all such unexpected traffic + must be handled by the system without generating user- + perceived errors or unexpected results. + + R3.1.11. Web Content Must Not Be Cached + Additional Background: Maintaining the privacy of users is + important. As such, content flowing through or + incidentally observed by the system must not be cached. + + R3.1.12. Advertising Replacement or Insertion Must Not Be Performed + Under ANY Circumstances + Additional Background: The system must not be used to + replace any advertising provided by a website, or to insert + advertising into websites. This therefore includes cases + where a web page already has space for advertising, as well + as cases where a web page does not have any advertising. + This is a critical area of concern for end users, privacy + advocates, and other members of the Internet community. + Therefore, it must be made abundantly clear that this + system will not be used for such purposes. + +3.2. Web Proxy Requirements + + R3.2.1. Open Source Software Must Be Used + Additional Background: The system must use an open source + web proxy server. (As noted in 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 + + + R3.2.3. Access Control Must Be Implemented + Additional Background: Access to the proxy must be limited + exclusively to the IP addresses of users for which + notifications are intended, and only for limited periods of + time. Furthermore, since a Session Management Broker (SMB) + is utilized, as described in Section 4.1 below, then the + proxy must restrict access only to the address of the SMB. + +3.3. ICAP Server Requirements + + R3.3.1. Must Provide ICAP Response Support + Additional Background: The system must support response + adaptation, in accordance with [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 + + R3.4.1. A Messaging Service Must Be Used + Additional Background: The Messaging Service, as described + in 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 + + This section defines and documents the various core functional + components of the system, as they are implemented. These components + are then shown in a diagram to describe how the various components + are linked and relate to one another. + + + + + +Chung, et al. Informational [Page 8] + +RFC 6108 Comcast's Web Notification System February 2011 + + +4.1. Functional Components Described, as Implemented + + This section accurately and transparently describes the software (S) + packages used by the system described herein, as well as all of the + details of how the system functions. The authors acknowledge that + there may be multiple alternative software choices for each + component; the purpose of this section is to describe those + selections that have been made and deployed. + + S4.1.1. Web Proxy: The system uses Squid Proxy, an open source web + proxy application in wide use, which supports an integrated + ICAP client. + + S4.1.2. ICAP Server: The system uses GreasySpoon, an open source + application. The ICAP server retrieves the notifications + from the Messaging Service cache when content adaption is + needed. + + S4.1.3. Customer Database: The Customer Database holds the relevant + information that the system needs to provide a critical + notification to a given user. The database may also hold + the status of which users were notified and which users are + pending notification. + + S4.1.4. Messaging Service: The system uses Apache Tomcat, an open + source application. This is a process engine that retrieves + specific web notification messages from a catalog of + possible notifications. While only one notification is + currently used, concerning malware infection, as noted in + 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 + + + Non-HTTP traffic for established TCP sessions not in the SMB + session table is simply forwarded to the destination + transparently via the TCP proxy layer (again, to meet the + specific requirement "Must Handle Pre-Existing Active TCP + Sessions Gracefully"). + +4.2. Functional Diagram, as Implemented + + +--------+ +------------+ +----------+ + | ICAP | <----> | Messaging | <----> | Customer | + | Server | | Service | | Database | + +--------+ +------------+ +----------+ + ^ + | +----------+ + | | | + | +-------> | Internet | <-------+ + | | | | | + | | +----------+ | + | | ^ | + v v | | + +----------+ v v + |+--------+| +-------+ +--------+ + || ICAP || <----> | SMB | <---> | Access | + || Client || +-------+ | Router | + |+--------+| +--------+ + || SQUID || ^ + || Proxy || | + |+--------+| v + +----------+ +----------+ + | CMTS* | + +----------+ + ^ + | + v + +------+ + | PC | + +------+ + + * A Cable Modem Termination System (CMTS) + is an access network element. + + Figure 1: Web Notification System - Functional Components + + + + + + + + + +Chung, et al. Informational [Page 10] + +RFC 6108 Comcast's Web Notification System February 2011 + + +5. High-Level Communication Flow, as Implemented + + In 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 + + + C5.8. User Response: The user observes the critical web + notification, and clicks an appropriate option, such as: OK/ + acknowledged, snooze/remind me later, etc. + + C5.9. More Information: Depending upon the notification, the user + may be provided with more information. For example, as noted + previously, the system was designed to provide critical + notifications concerning malware infection. Thus, in the + case of malware infection, the user may be advised to go to a + malware remediation web page that provides directions on how + to attempt to remove the malware and attempt to secure hosts + against future malware infection. + + C5.10. Turn Down Diffserv: Once the notification transaction has + completed, remove any special Diffserv settings. + +6. Communication between Web Proxy and ICAP Server, as Implemented + + The web proxy and ICAP server are critical components of the system. + This section shows the communication that occurs between these two + components. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chung, et al. Informational [Page 12] + +RFC 6108 Comcast's Web Notification System February 2011 + + + +------------+ + | www URI | + +------------+ + ^ | + (2)| |(3) + | v + +--------+ (4) +--------+ (4) +--------+ + | |------------>| |------------>| | + | | (5) | | (5) | | + | Proxy |<------------| ICAP |<------------| ICAP | + | Module | (6) | Client | (6) | Server | + | |------------>| |------------>| | + | | (7) | | (7) | | + | |<------------| |<------------| | + +--------+ +--------+ +--------+ + ^ | + (1)| |(8) + | v + +------------+ (9) +------------+ + | |----------------------------->| | + | Browser | (10) | Web Server | + | |<-----------------------------| | + +------------+ +------------+ + + (1) - HTTP GET (TCP 80) + (2) - Proxy HTTP GET (TCP 80) + (3) - HTTP 200 OK w/ Response + (4) - ICAP RESPMOD + (5) - ICAP 200 OK + (6) - TCP Stream - Encapsulate Header + (7) - ICAP 200 OK Insert Message + (8) - HTTP 200 OK w/ Response + Message Frame + (9) - HTTP GET for Message + (10) - HTTP 200 w/ Message Content + + Figure 2: Communication between Web Proxy and ICAP Server + +7. End-to-End Web Notification Flow, as Implemented + + This section describes the exact flow of an end-to-end notification, + in order to show in detail how the system functions. + + + + + + + + + + +Chung, et al. Informational [Page 13] + +RFC 6108 Comcast's Web Notification System February 2011 + + +7.1. Step-by-Step Description of the End-to-End Web Notification Flow + + Policy-Based Routing + + 1. TCP port 80 packets from the user that needs to be notified are + routed to the web proxy via policy-based routing. + + 2. Packets are forwarded to the Session Management Broker, which + establishes a session with the web proxy and routes the packets + to the web proxy. + + Web Proxy + + 1. The user's HTTP request is directed to the web proxy. + + 2. The web proxy receives HTTP traffic and retrieves content from + the requested website. + + 3. The web proxy receives the response and forwards it to the ICAP + server for response adaptation. + + 4. The ICAP server checks the HTTP content in order to determine + whether the notification message can be inserted. + + 5. The ICAP server initiates a request to the Messaging Service + cache process with the IP address of the user. + + 6. If a notification message for the user exists, then the + appropriate notification is cached on the Messaging Service. + The Messaging Service then returns the appropriate notification + content to the ICAP server. + + 7. Once the notification message is retrieved from the Messaging + Service cache, the ICAP server may insert the notification + message in the HTTP response body without altering or modifying + the original content of the HTTP response. + + 8. The ICAP server then sends the response back to the web proxy, + which in turn forwards the HTTP response back to the browser. + + 9. If the user's IP address is not found or provisioned for a + notification message, then the ICAP server should return a "204 + No modifications needed" response to the ICAP client as defined + in Section 4.3.3 of [RFC3507]. As a result, the user will not + receive any web notification message. + + + + + + +Chung, et al. Informational [Page 14] + +RFC 6108 Comcast's Web Notification System February 2011 + + + 10. The user observes the web notification, and clicks an + appropriate option, such as: OK/acknowledged, snooze/remind me + later, etc. + +7.2. Diagram of the End-to-End Web Notification Flow + + The two figures below show the communications flow from the web + browser, through the web notification system. + + Figure 3 illustrates what occurs when a notification request cannot + be inserted because the notification type for the user's IP address + is not cached in the Messaging Service. + + ICAP ICAP Message Customer + Browser Proxy Client Server Service Internet DB + | HTTP | | | | | | + | GET | Proxy | | | | | + +------->| Request | | | | | + | +---------|---------|--------|------->| | + | | | | | 200 OK | | + | |<--------|---------|--------|--------+ | + | | ICAP | | | | | + | | RESPMOD | ICAP | | | | + | +-------->| RESPMOD | Check | | | + | | +-------->| Cache | | | + | | | | for IP | | | + | | | | Match | | | + | | | +------->| | | + | | | | Cache | | | + | | | | Miss | | | + | | | |<-------+ Request| | + | | | 204 No | | Type | | + | | | Modif. | +--------|------->| + | | | Needed | | | | + | | No |<--------+ | | Type | + | | Insert | | | |Returned| + | 200 OK |<--------+ | |<-------|--------+ + | w/o | | | | | | + | Insert | | | | | | + |<-------+ | | | | | + | | | | | | | + + Figure 3: End-to-End Web Notification Flow - with Cache Miss + + + + + + + + +Chung, et al. Informational [Page 15] + +RFC 6108 Comcast's Web Notification System February 2011 + + + Figure 4 illustrates what occurs when a notification request for the + user's IP address is cached in the Messaging Service. + + ICAP ICAP Message Customer + Browser Proxy Client Server Service Internet DB + | HTTP | | | | | | + | GET | Proxy | | | | | + +------->| Request | | | | | + | +---------|---------|--------|------->| | + | | | | | 200 OK | | + | |<--------|---------|--------|--------+ | + | | ICAP | | | | | + | | RESPMOD | ICAP | | | | + | +-------->| RESPMOD | Check | | | + | | +-------->| Cache | | | + | | | | for IP | | | + | | | | Match | | | + | | | +------->| | | + | | | | Cache | | | + | | | | Hit | | | + | | | Insert |<-------+ | | + | | Return | Type | | | | + | | 200 OK |<--------+ | | | + | | with | | | | | + | | Insert | | | | | + | 200 OK |<--------+ | | | | + | w/ | | | | | | + | Notify | | | | | | + |<-------+ | | | | | + | | | | | | | + + Figure 4: End-to-End Web Notification Flow - with Cache Hit + +8. Example HTTP Headers and JavaScript for a Web Notification + + The figure below shows an example of a normal HTTP GET request from + the user's web browser to www.example.com, a web server on the + Internet. + + + + + + + + + + + + + +Chung, et al. Informational [Page 16] + +RFC 6108 Comcast's Web Notification System February 2011 + + +------------------------------------------------------------------------ +1. HTTP GET Request to www.example.com +------------------------------------------------------------------------ +http://www.example.com/ + +GET / HTTP/1.1 +Host: www.example.com +User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) + Gecko/20080404 Firefox/2.0.0.14 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-us,en;q=0.5 +Accept-Encoding: gzip,deflate +Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 +Keep-Alive: 300 +Connection: keep-alive +Pragma: no-cache +------------------------------------------------------------------------ + + Figure 5: Example HTTP Headers for a Web Notification - HTTP GET + + + In the figure below, the traffic is routed via the web proxy, which + communicates with the ICAP server and returns the response from + www.example.com. In this case, that response is a 200 OK, with the + desired notification message inserted. + +------------------------------------------------------------------------ +2. Response from www.example.com via PROXY +------------------------------------------------------------------------ +HTTP/1.x 200 OK +Date: Thu, 08 May 2008 16:26:29 GMT +Server: Apache/2.2.3 (CentOS) +Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT +Etag: "b80f4-1b6-80bfd280" +Accept-Ranges: bytes +Content-Length: 438 +Connection: close +Content-Type: text/html; charset=UTF-8 +Age: 18 +X-Cache: HIT from localhost.localdomain +Via: 1.0 localhost.localdomain (squid/3.0.STABLE5) +Proxy-Connection: keep-alive +------------------------------------------------------------------------ + + Figure 6: Example HTTP Headers for a Web Notification - HTTP Response + + + + + + +Chung, et al. Informational [Page 17] + +RFC 6108 Comcast's Web Notification System February 2011 + + + The figure below shows an example of the web notification content + inserted in the 200 OK response, in this example JavaScript code. + +------------------------------------------------------------------------ +3. Example of JavaScript containing Notification Insertion +------------------------------------------------------------------------ +<!--all elements used in a notification should have cascading style +sheet (css) properties defined to avoid unwanted inheritance from +parent page--> + +<style type="text/css"> +#example { + position: absolute; left: 100px; top: 50px; + z-index: 9999999; height: auto; width: 550px; + padding: 10px; + border: solid 2px black; + background-color:#FDD017; + opacity: 0.8; filter: alpha(opacity = 80); +} +</style> + +<script language="javascript" type="text/javascript"> +// ensure that content is not part of an iframe +if (self.location == top.location) { + // this is a floating div with 80% transparency + document.write('<div id="example" name="example">'); + document.write('<h2>IMPORTANT MESSAGE</h2>'); + document.write('<p>Lorem ipsum dolor sit amet, consecteteur '); + document.write('adipisicing elit, sed do eiusmod tempor '); + document.write('incididunt ut labore et dolore magna aliqua. '); + document.write('Ut enim ad minim veniam, quis nostrud '); + document.write('exercitation ullamco laboris nisi ut aliquip ex '); + document.write('ea commodo consequat.'); + document.write('</div>'); +}</script> +------------------------------------------------------------------------ + + Figure 7: Example JavaScript Used in a Web Notification + +9. Deployment Considerations + + The components of the web notification system should be distributed + throughout the network and close to end users. This ensures that the + routing performance and the user's web browsing experience remain + excellent. In addition, a HTTP-aware load balancer should be used in + each datacenter where servers are located, so that traffic can be + spread across N+1 servers and the system can be easily scaled. + + + + +Chung, et al. Informational [Page 18] + +RFC 6108 Comcast's Web Notification System February 2011 + + +10. Security Considerations + + This critical web notification system was conceived in order to + provide an additional method of notifying end user customers that + their computer has been infected with malware. Depending upon the + specific text of the notification, users could fear that it is some + kind of phishing attack. As a result, care has been taken with the + text and any links contained in the web notification itself. For + example, should the notification text change over time, it may be + best to provide a general URI or a telephone number. In contrast to + that, the notification must not ask for login credentials, and must + not ask a user to follow a link in order to change their password, + since these are common phishing techniques. Finally, care should be + taken to provide confidence that the web notification is valid and + from a trusted party, and/or that the user has an alternate method of + checking the validity of the web notification. One alternate method + of validating the notification may be to call customer support (in + this example, Comcast's Customer Security Assurance team); this + explains a key requirement (specifically, "Should Keep Notification + Records for Customer Support Purposes") in Section 3.4. + +11. Debating the Necessity of Such a Critical Notification System + + Some members of the community may question whether it is ever, under + any circumstances, acceptable to modify Internet content in order to + provide critical service notification concerning malware infection - + even in the smallest of ways, even if openly and transparently + documented, even if thoroughly tested, and even if for the best of + motivations. It is important that anyone with such concerns + recognize that this document is by no means the first to propose + this, particularly as a tactic to combat a security problem, and in + fact simply leverages previous work in the IETF, such as [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 + + + The authors also believe it is important for ISPs to transparently + disclose network management techniques and systems, and to have a + venue to do so, as has been done here. In addition, the authors + believe it is important for the IETF and other members of the + Internet community to encourage and positively reinforce such + disclosures. In the publishing of such a document for reference and + comment by the Internet community, this may serve to motivate other + ISPs to be similarly open and to engage the IETF and other + organizations that are part of the Internet community. Not + publishing such documents could motivate less disclosure on the part + of ISPs and other members of the Internet community, increase the use + of DPI, and decrease ISP participation in the critical technical + bodies that make up parts of the Internet community. + + In addition, it is critical that members of the community recognize + the good motivations of ISPs like Comcast to combat the massive and + continuing proliferation of malware, which is a huge threat to the + security of average Internet users and now represents a multi- + billion-dollar underground economy engaged in identity theft, + financial fraud, transmission of spam, and other criminal activity. + Such a critical notification system in fact is only necessary due to + the failure of host-based security at defending against and + preventing malware infection. As such, ISPs such as Comcast are + being urged by their customers and by other parties such as security + and/or privacy organizations, as well as governmental organizations, + to take action to help solve this massive problem, since so many + other tactics have been unsuccessful. For example, as Howard + Schmidt, the Special Advisory for Cyber Security to President Obama, + of the United States of America, said in 2005: "As attacks on home- + based and unsecured networks become as prevalent as those against + large organizations, the need for ISPs to do everything they can to + make security easier for their subscribers is critical for the + preservation of our nation's information backbone. Additionally, + there is tremendous potential to grow further the use of broadband + around the world; and making safety and security part of an ISP's + core offering will enable the end user to fully experience the rich + and robust benefits broadband provides". + +12. Suggesting a Walled Garden as an Alternative + + A "walled garden" refers to an environment that controls the + information and services that a subscriber is allowed to utilize and + what network access permissions are granted. Placing a user in a + walled garden is therefore another approach that ISPs may take to + notify users, and this method is being explored as a possible + alternative in other documents and community efforts. As such, web + notifications should be considered one of many possible notification + methods that merit documentation. + + + +Chung, et al. Informational [Page 20] + +RFC 6108 Comcast's Web Notification System February 2011 + + + However, a walled-garden approach can pose challenges and may in some + cases be considered disruptive to end users. For example, a user + could be playing a game online, via the use of a dedicated, Internet- + connected game console, which would likely stop working when the user + was placed in the walled garden. In another example, the user may be + in the course of a telephone conversation, using a Voice Over IP + (VoIP) device of some type, which would also likely stop working when + the user was placed in the walled garden. In both cases, the user is + not using a web browser and would not have a way to determine the + reason why their service seemingly stopped working. + +13. Intended Next Steps + + Unfortunately, at the time of this writing, no existing working group + of the IETF is focused on issues of malware infection and related + issues. As a result, there was not a definite venue for this + document, so it was submitted to the Independent Submissions Editor + as an independent submission. While documentation and disclosure of + this system are beneficial for the Internet community in and of + itself, there are other benefits to having this document published. + One of those reasons is that members of the community, including + members of the IETF, have a stable document to refer to in the case + of any potential new work that the community may undertake in the + area of malware, security, and critical notification to end users. + It is also hoped that, in the tradition of a Request for Comment, + other members of the community may be motivated to propose + alternative systems or other improvements. + +14. Acknowledgements + + The authors wish to thank Alissa Cooper for her review of and + comments on the document, and Nevil Brownlee for his excellent + feedback, as well as others who reviewed the document. + +15. References + +15.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + December 1998. + + + + + + +Chung, et al. Informational [Page 21] + +RFC 6108 Comcast's Web Notification System February 2011 + + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, December 1998. + + [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, + "Assured Forwarding PHB Group", RFC 2597, June 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media + Type", RFC 2854, June 2000. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + January 2001. + + [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, + "Per Hop Behavior Identification Codes", RFC 3140, + June 2001. + + [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, + J., Courtney, W., Davari, S., Firoiu, V., and D. + Stiliadis, "An Expedited Forwarding PHB (Per-Hop + Behavior)", RFC 3246, March 2002. + + [RFC3260] Grossman, D., "New Terminology and Clarifications for + Diffserv", RFC 3260, April 2002. + + [RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation + Protocol (ICAP)", RFC 3507, April 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, + April 2006. + + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + August 2006. + + + + + + + + +Chung, et al. Informational [Page 22] + +RFC 6108 Comcast's Web Notification System February 2011 + + +15.2. Informative References + + [CableLabs_DOCSIS] + CableLabs, "Data-Over-Cable Service Interface + Specifications", CableLabs Specifications, Various DOCSIS + Reference Documents, <http://www.cablelabs.com/ + specifications/archives/docsis.html>. + + [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", + BCP 60, RFC 3360, August 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chung, et al. Informational [Page 23] + +RFC 6108 Comcast's Web Notification System February 2011 + + +Authors' Addresses + + Chae Chung + Comcast Cable Communications + One Comcast Center + 1701 John F. Kennedy Boulevard + Philadelphia, PA 19103 + US + EMail: chae_chung@cable.comcast.com + URI: 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] + |