


Internet Engineering Task Force                                 C. Chung
Internet-Draft                                               A. Kasyanov
Intended status: Informational                              J. Livingood
Expires: December 9, 2010                                        N. Mody
                                                                 Comcast
                                                             B. Van Lieu
                                                            Unaffiliated
                                                            June 7, 2010


               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.



Chung, et al.           Expires December 9, 2010                [Page 1]

Internet-Draft  Example of an ISP Web Notification System      June 2010


   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.






























Chung, et al.           Expires December 9, 2010                [Page 2]

Internet-Draft  Example of an ISP Web Notification System      June 2010


Table of Contents

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

















Chung, et al.           Expires December 9, 2010                [Page 3]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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 [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]) 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].  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])
   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].






Chung, et al.           Expires December 9, 2010                [Page 4]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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]) 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 Indicators (URIs, [RFC2396]) or
           Fully Qualified Domain Named (FQDNs, Section 5.1 of
           [RFC1035]) 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.






Chung, et al.           Expires December 9, 2010                [Page 5]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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






Chung, et al.           Expires December 9, 2010                [Page 6]

Internet-Draft  Example of an ISP Web Notification System      June 2010


   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.



Chung, et al.           Expires December 9, 2010                [Page 7]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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

   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,



Chung, et al.           Expires December 9, 2010                [Page 8]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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








Chung, et al.           Expires December 9, 2010                [Page 9]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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 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
           above.  The system uses a LB from A10 Networks.  The SMB



Chung, et al.           Expires December 9, 2010               [Page 10]

Internet-Draft  Example of an ISP Web Notification System      June 2010


           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]) 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.



Chung, et al.           Expires December 9, 2010               [Page 11]

Internet-Draft  Example of an ISP Web Notification System      June 2010


         Figure 1: Web Notification System - Functional Components


6.  High Level Communication Flow, As Implemented

   6.A.  Setup Differentiated Services (DiffServ): Using DiffServe
         [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260]
         [RFC4594], 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



Chung, et al.           Expires December 9, 2010               [Page 12]

Internet-Draft  Example of an ISP Web Notification System      June 2010


         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

         Figure 2: Communication Between Web Proxy and ICAP Server




Chung, et al.           Expires December 9, 2010               [Page 13]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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].  As a result, the user will not
        receive any web notification message.




Chung, et al.           Expires December 9, 2010               [Page 14]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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

       Figure 3: End-to-End Web Notification Flow - With Cache Miss

   The figure below illustrates what occurs when a notification request
   for the user's IP address is cached in the Messaging Service.





Chung, et al.           Expires December 9, 2010               [Page 15]

Internet-Draft  Example of an ISP Web Notification System      June 2010


                            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


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.















Chung, et al.           Expires December 9, 2010               [Page 16]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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

   The figure below shows an example of the web notification content
   inserted in the 200 OK response, in this example JavaScript code.




Chung, et al.           Expires December 9, 2010               [Page 17]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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

          Figure 7: Example JavaScript Used in a Web Notification


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



Chung, et al.           Expires December 9, 2010               [Page 18]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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



Chung, et al.           Expires December 9, 2010               [Page 19]

Internet-Draft  Example of an ISP Web Notification System      June 2010


   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.



Chung, et al.           Expires December 9, 2010               [Page 20]

Internet-Draft  Example of an ISP Web Notification System      June 2010


   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






Chung, et al.           Expires December 9, 2010               [Page 21]

Internet-Draft  Example of an ISP Web Notification System      June 2010


17.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1631]  Egevang, K. and P. Francis, "The IP Network Address
              Translator (NAT)", RFC 1631, May 1994.

   [RFC1866]  Berners-Lee, T. and D. Connolly, "Hypertext Markup
              Language - 2.0", RFC 1866, November 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

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

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2915]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
              (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [RFC3140]  Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", RFC 3140,
              June 2001.



Chung, et al.           Expires December 9, 2010               [Page 22]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3507]  Elson, J. and A. Cerpa, "Internet Content Adaptation
              Protocol (ICAP)", RFC 3507, April 2003.

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

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


Appendix A.  Document Change Log

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

   o  -08 - One minor deletion, based on feedback from the RFC Editor

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



Chung, et al.           Expires December 9, 2010               [Page 23]

Internet-Draft  Example of an ISP Web Notification System      June 2010


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

   o  -06 - Corrected WL/BL error

   o  -05 - fixed odd spacing in 8.1

   o  -04 - corrections and tweaks by Jason

   o  -03 - corrections and clarifications from Nirmal and BVL

   o  -02 - updated BVL's contact info, clearing one open issue.  Also
      added content to Security Considerations.

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

   o  -00 - first version published


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






Chung, et al.           Expires December 9, 2010               [Page 24]

Internet-Draft  Example of an ISP Web Notification System      June 2010


   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.           Expires December 9, 2010               [Page 25]


