Example of an ISP Web Notification System
draft-livingood-web-notification-08

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 these 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on December 9, 2010.

Copyright Notice

Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Requirements Language
2.  Introduction
3.  High-Level Design of the System
4.  Design Requirements
    4.1.  General Requirements
    4.2.  Web Proxy Requirements
    4.3.  ICAP Server Requirements
    4.4.  Messaging Service Requirements
5.  Implementation Details
    5.1.  Functional Components Described, As Implemented
    5.2.  Functional Diagram, As Implemented
6.  High Level Communication Flow, As Implemented
7.  Communication Between Web Proxy and ICAP Server, As Implemented
8.  End-to-End Web Notification Flow, As Implemented
    8.1.  Step-by-Step Description of the End-to-End Web Notification Flow
    8.2.  Diagram of the End-to-End Web Notification Flow
9.  Example HTTP Headers and JavaScript for a Web Notification
10.  Deployment Considerations
11.  Security Considerations
12.  Debating The Necessity of Such a Critical Notification System
13.  Suggesting a Walled Garden As An Alternative
14.  Intended Next Steps
15.  IANA Considerations
16.  Acknowledgements
17.  References
    17.1.  Normative References
    17.2.  Informative References
Appendix A.  Document Change Log
§  Authors' Addresses

1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  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, this 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 based on open standards, non-proprietary software, and which MUST NOT require the use of DPI. While the system described herein is specific to the Data-Over-Cable Service Interface Specifications (DOCSIS, [CableLabs DOCSIS] (CableLabs, “Data-Over-Cable Service Interface Specifications,” .)) 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.

3.  High-Level Design of the System

The web notification system design is based on the use of the Internet Content Adaptation Protocol [RFC3507] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.). The design uses open source applications, which are the Squid Web Proxy, GreasySpoon ICAP server, and Apache Tomcat. The ICAP protocol, an existing IETF protocol, allows for message transformation or adaptation. An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.)) 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] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.).

4.  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 which were made in order to avoid the use of DPI, among other things. An Additional Background section is included with each requirement to provide additional information, context, or other useful explanation.

4.1.  General Requirements

REQ1:

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.

REQ2:

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.

REQ3:

MUST Support Block Listing Additional Background: While unlikely, since it is possible that the HyperText Markup Language (HTML, [RFC1866] (Berners-Lee, T. and D. Connolly, “Hypertext Markup Language - 2.0,” November 1995.)) or JavaScript [RFC4329] (Hoehrmann, B., “Scripting Media Types,” April 2006.) 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 Indicators (URIs, [RFC2396] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” August 1998.)) or Fully Qualified Domain Named (FQDNs, Section 5.1 of [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)) that conflict with the system, so that the system MUST NOT provide a notifications in these cases, in order to eliminate 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 the standard ICAP protocol which has been in use for many years is utilized, it is critical that if it does behave in such a way that there MUST be a method to rapidly except specific URIs or FQDNs.

REQ4:

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) which use TCP port 80.

REQ5:

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 and MUST be routed to the proxy layer. Also, since the critical web notification occurs at a 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.

REQ6:

MUST NOT Use TCP Resets Additional Background: The use of TCP resets has been widely criticized, both in the Internet community generally as well as in [RFC3360] (Floyd, S., “Inappropriate TCP Resets Considered Harmful,” August 2002.). 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.

REQ7:

MUST Be Non-Disruptive Additional Background: The web notification system MUST NOT disrupt the end user experience, such as causing significant clients errors.

REQ8:

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.

REQ9:

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.

REQ10:

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 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 which is unexpected, and that 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.

REQ11:

Web Content MUST NOT Be Cached Additional Background: Maintaining the privacy of users important. As such, content flowing through or incidentally observed the system MUST NOT be cached.

REQ12:

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 insert advertising into websites. This therefore includes both 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 MUST NOT and SHALL NOT be used for such purposes.

4.2.  Web Proxy Requirements

REQ13:

Open-Source Software MUST Be Used Additional Background: The system MUST use an open source web proxy server. (As noted later, 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 which are also beneficial.

REQ14:

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.

REQ15:

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 5.1 (Functional Components Described, As Implemented) below, then the proxy MUST restrict access only to the address of the SMB.

4.3.  ICAP Server Requirements

REQ16:

MUST Provide ICAP Response Support: Additional Background: The system MUST support response adaptation, in accordance with [RFC3507] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.). An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.)) 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] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.)

REQ17:

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.

REQ18:

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 which has been narrowly tailored to each category of malware.

REQ19:

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 that to just one user at a time.

4.4.  Messaging Service Requirements

REQ20:

A Messaging Service MUST Be Used Additional Background: The Messaging Service, as described in Section 5.1 (Functional Components Described, As Implemented) below, caches the notifications for each specific user. Thus, the notification messages are cached by the system rather than having to retrieve them 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).

REQ21:

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 (Notification Acknowledgement MUST Stop Further Immediate Notifications).

REQ22:

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.

REQ23:

SHOULD Keep Notification Records for Customer Support Purposes Additional Background: The Messaging Service SHOULD maintain some type of record that a notification being 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.

5.  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.

5.1.  Functional Components Described, As Implemented

This section accurately and transparently describes the software 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 which have been made and deployed.

5.1.A.

Web Proxy: The system SHOULD use and does use Squid Proxy, an open source web proxy application in wide use, and one which supports an integrated ICAP client.

5.1.B.

ICAP Server: The system SHOULD use and does use GreasySpoon, an open source application. The ICAP Server retrieves the notifications from the Messaging service cache when content adaption is needed.

5.1.C.

Customer Database: The Customer Database SHOULD hold 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 users which are pending notification.

5.1.D.

Messaging Service: The system SHOULD use and does use 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 4.3 (ICAP Server Requirements) 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 cache, the process retrieves this information from the Customer Database and populates the cache for a specific period of time.

5.1.E.

Session Management Broker (SMB): A Load Balancer (LB) with a customized layer 7 inspection policy SHOULD be and is used to differentiate between HTTP and non-HTTP traffic on TCP port 80, in order to meet the requirements documented in Section 4 (Design Requirements) 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 [RFC1631] (Egevang, K. and P. Francis, “The IP Network Address Translator (NAT),” May 1994.)) from the SMB. 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).

5.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.

6.  High Level Communication Flow, As Implemented

6.A.

Setup Differentiated Services (DiffServ): Using DiffServe [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.) [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.) [RFC2597] (Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group,” June 1999.) [RFC3140] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” 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),” March 2002.) [RFC3260] (Grossman, D., “New Terminology and Clarifications for Diffserv,” April 2002.) [RFC4594] (Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” August 2006.), set a policy to direct TCP port 80 traffic to the web notification system's web proxy.

6.B.

Session Management: TCP port 80 packets are routed to a Session Management Broker which 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 destination or the SMB operates as the 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.

6.C.

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.

6.D.

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.

6.E.

Messaging Service: The Messaging Service should respond with appropriate notification content or null response if notification is not cached.

6.F.

ICAP Server Responds: The ICAP server responds and furnishes the appropriate content for the web notification to the web proxy.

6.G.

Web Proxy Sends Response: The web proxy then forwards the HTTP response to the client web browser containing the web notification.

6.H.

User Response: The user observes the critical web notification, and clicks an appropriate option, such as: OK/acknowledged, snooze/remind me later, etc.

6.I.

More Information: Depending upon the notification, the user may be provided with more information. For example, as noted previously herein, 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.

6.J.

Turn Down DiffServ: Once the notification transaction has completed, remove any special DiffServ settings.

7.  Communication Between Web Proxy and ICAP Server, As Implemented

+------------+
|  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

8.  End-to-End Web Notification Flow, As Implemented

8.1.  Step-by-Step Description of the End-to-End Web Notification Flow

8.1.1. 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.

8.1.2. 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 web site.
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 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 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] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.). As a result, the user will not receive any web notification message.
10. The user observes the web notification, and clicks an appropriate option, such as: OK/acknowledged, snooze/ remind me later, etc.

8.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.

The first figure below 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 |         |         |        |        |        |
        |<-------+         |         |        |        |        |
        |        |         |         |        |        |        |

The figure below 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 |         |         |        |        |        |
        |<-------+         |         |        |        |        |
        |        |         |         |        |        |        |

9.  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.

------------------------------------------------------------------------
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
------------------------------------------------------------------------

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
------------------------------------------------------------------------

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 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>
------------------------------------------------------------------------

10.  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 remains excellent. In addition, a HTTP-aware load balancer SHOULD 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.

11.  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 SHOULD and 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 to call Comcast's Customer Security Assurance team, which explains a key requirement (specifically, SHOULD Keep Notification Records for Customer Support Purposes) in Section 4.4 (Messaging Service Requirements) above.

12.  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] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.). Such concerned parties should also study the many organizations using ICAP and the many software systems which have implemented ICAP.

In addition, concerned members of the community should review Section 2 (Introduction) 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 the authors describe herein, they 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.

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 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. Members of the community that argue that documents such as this have no value may wish to consider that such a viewpoint could have unintended effects, such as motivating less disclosure on the part of ISPs and other members of the Internet community, increased rather than decreased use of DPI, and decreased rather than increased 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 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, was recently quoted: "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."

13.  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 which merits documentation.

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.

14.  Intended Next Steps

Unfortunately, no existing working group of the IETF is focused on issues of malware infection and related issues. As a result, there is not a definite venue for this document so this has been submitted to the RFC Editor as an individual submission. While documentation and disclosure of this system is 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 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.

15.  IANA Considerations

There are no IANA considerations in this document.

NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO PUBLICATION.

16.  Acknowledgements

The authors wish to thank Alissa Cooper for her review of and comments on the document, as well as others who reviewed the document.

17.  References

17.1. Normative References

17.2. Informative References

Appendix A.  Document Change Log

[RFC Editor: This section is to be removed before publication]

• -08 - One minor deletion, based on feedback from the RFC Editor
• -07 - Made modifications to accommodate concerns raised by the RFC Editor and his reviewers. This includes CAPITALIZING all RFC 2119 language, adding more context and background to the requirements section, making the introduction more precise, making the document describe more of the actual implementation details, updating security considerations, and adding three new sections (12, 13, 14).
• -06 - Corrected WL/BL error
• -05 - fixed odd spacing in 8.1
• -04 - corrections and tweaks by Jason
• -03 - corrections and clarifications from Nirmal and BVL
• -02 - updated BVL's contact info, clearing one open issue. Also added content to Security Considerations.
• -01 - updated doc to reflect that this system is deployed and not in development, closing out two open issues. Added reference for JavaScript, closing an open issue.
• -00 - first version published

Authors' Addresses