Internet Engineering Task Force                                 C. Chung
Internet-Draft                                               A. Kasyanov
Intended status: Informational                              J. Livingood
Expires: September 23, 2010                                      N. Mody
                                                                 Comcast
                                                             B. Van Lieu
                                                            Unaffiliated
                                                          March 22, 2010


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

Abstract

   The objective of this document is to describe one method of providing
   notifications to web browsers that has been deployed by Comcast, a
   large Internet Service Provider (ISP).  Such a notification system
   can be used by an ISP to provide near-immediate notifications to
   their users, such as to warn them that their traffic exhibits
   patterns that are indicative of malware or virus infection, for
   example.  There are other proprietary systems that can perform such
   notifications but these systems utilize Deep Packet Inspection (DPI)
   technology.  This document describes one example of a system that
   does not rely upon DPI, and is instead based in open standards and
   open source applications.  While the system described herein is in
   some ways specific to the Data-Over-Cable Service Interface
   Specifications (DOCSIS) networks used by most cable-based broadband
   ISPs, components and concepts described in this document can
   generally be applied to many different types of networks.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.



Chung, et al.          Expires September 23, 2010               [Page 1]


Internet-Draft  Example of an ISP Web Notification System     March 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 23, 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 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 September 23, 2010               [Page 2]


Internet-Draft  Example of an ISP Web Notification System     March 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  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Web Proxy  . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  ICAP Server  . . . . . . . . . . . . . . . . . . . . . . .  6
     4.4.  Messaging Service  . . . . . . . . . . . . . . . . . . . .  7
   5.  Functional Overview  . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Functional Components Described  . . . . . . . . . . . . .  7
     5.2.  Functional Diagram . . . . . . . . . . . . . . . . . . . .  9
   6.  High Level Communication Flow  . . . . . . . . . . . . . . . .  9
   7.  Communication Between Web Proxy and ICAP Server  . . . . . . . 11
   8.  End-to-End Web Notification Flow . . . . . . . . . . . . . . . 11
     8.1.  Step-by-Step Description of the End-to-End Web
           Notification Flow  . . . . . . . . . . . . . . . . . . . . 12
     8.2.  Diagram of the End-to-End Web Notification Flow  . . . . . 13
   9.  Example HTTP Headers for a Web Notification  . . . . . . . . . 15
   10. Deployment Considerations  . . . . . . . . . . . . . . . . . . 16
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     14.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19






















Chung, et al.          Expires September 23, 2010               [Page 3]


Internet-Draft  Example of an ISP Web Notification System     March 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.
   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 notifications.  This document describes a
   system that has been deployed by Comcast, a large broadband ISP, to
   provide near-immediate notifications to web browsers.  This type of
   system is also designed to provide a non-intrusive, though obvious,
   notification to a user's web browser.

   In evaluating potential solutions, most commercially available
   systems were either proprietary and/or utilized inline-based Deep
   Packet Inspection (DPI) technology.  Similiar to Comcast's needs many
   other ISPs may also desire to use a system based on open standards,
   non-proprietary software, and which does 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, components and
   concepts described in this document can generally be applied to many
   different types of networks.


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 such as Squid Web Proxy, GreasySpoon ICAP server,
   and Apache Tomcat.  The ICAP 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.

   Message modification itself may then be provided via either a HTTP
   request or HTTP response.  However, for the specific system described
   in this document, only the HTTP response is modified, by using the
   'respmod' method defined in Section 3.2 of [RFC3507].





Chung, et al.          Expires September 23, 2010               [Page 4]


Internet-Draft  Example of an ISP Web Notification System     March 2010


4.  Design Requirements

   This section describes all of the requirements taken into
   consideration for the design of this system.

4.1.  General

   REQ1:   TCP Port 80: The system should provide notifications via TCP
           port 80, the well-known port for HTTP traffic.

   REQ2:   Whitelisting: 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 should be capable of using
           a whitelist of website Uniform Resource Indicators (URIs,
           [RFC2396]) or Fully Qualified Domain Named (FQDNs, Section
           5.1 of [RFC1035]) that conflict with the system, to instruct
           the system to not provide a notifications related to certain
           sites, in order to reduce any errors or unexpected results.

   REQ3:   Instant Messaging (IM): Some IM clients use TCP port 80 in
           their communications, often as an alternate port when
           standard, well-known ports do not work.  This system should
           not conflict with or cause unexpected results for IM clients.

   REQ4:   Handling of Active Sessions: To the extent that a web
           notification system must temporarily route TCP port 80
           traffic in order to provide a notification.  Previously
           established TCP port 80 sessions should not be disrupted and
           should be routed to the proxy layer.

   REQ5:   No TCP Resets: The use of TCP resets has been widely
           criticized, both in the Internet community generally as well
           as in [RFC3360].  As such, except for the case of
           unintentional errors, the use of TCP resets must be avoided.

   REQ6:   Non-Disruptive: The web notification system should not
           disrupt the end user experience, such as causing significant
           clients errors.

   REQ7:   Notification Acknowledgement: Once a user responds and
           acknowledges a notification, the notification should
           immediately stop.

   REQ8:   Non-Modification of Content: Such a system should not
           significantly alter the content of the HTTP response from any
           website the user is accessing.




Chung, et al.          Expires September 23, 2010               [Page 5]


Internet-Draft  Example of an ISP Web Notification System     March 2010


   REQ9:   Unexpected Content: The system should transparently handle
           traffic for which it cannot provide a web notification.
           Thus, widely varying content should be expected, and all such
           unexpected traffic should be able to be handled by the system
           without generating errors or unexpected results.

   REQ10:  No Caching: Web content must not be cached by the system.

   REQ11:  No Advertising Replacement or Insertion: The system must not
           be used to replace any advertising provided by a website, or
           insert advertising into websites where none was intended by
           the owner of a given website.

4.2.  Web Proxy

   REQ12:  Open-Source Software: The system should use an open source
           web proxy server, such as Squid.  (While it is possible to
           use any web proxy, the use of open source, and openly
           documented software is recommended.)

   REQ13:  ICAP Client: The web proxy server should have an integrated
           ICAP client.

   REQ14:  Access Control: Access to the proxy should be limited
           exclusively to the IP addresses of users for which
           notifications are intended, and only for limited periods of
           time.  Furthermore, if a Session Management Broker (SMB) is
           utilized, as described in Section 5.1 below, then the proxy
           should restrict access only to the IP of the SMB.

4.3.  ICAP Server

   REQ15:  Request and Response Support: The system should support both
           request and response adaptation.

   REQ16:  Consistency: The system must be able to consistently provide
           a specific notification.

   REQ17:  Multiple Notification Types: The system must be able to
           provide many different types of notifications.

   REQ18:  Simultaneous Differing Notifications: The system must be able
           to simultaneously serve multiple notifications, including
           notifications of varying types, to different users.  As a
           result, User A should be able to get the notification
           intended specifically for User A, at the same time that User
           B receives an entirely different notification, which was
           intended specifically for User B.



Chung, et al.          Expires September 23, 2010               [Page 6]


Internet-Draft  Example of an ISP Web Notification System     March 2010


4.4.  Messaging Service

   REQ19:  Messaging Service: The Messaging Service, as described in
           Section 5.1 below caches the notifications for each specific
           user.  Thus, by caching the notification messages, the system
           may provide notifications without significantly affecting the
           web browsing experience of the user.

   REQ20:  Process Acknowledgements: The Messaging Service should
           process acknowledgements to properly remove entries from the
           cache and forward acknowledgements to the Messaging Service.

   REQ21:  Ensure Notification Targeting Accuracy: The Messaging Service
           must ensure that notifications are presented to the intended
           users.

   REQ22:  Keep Records for Customer Care: The Messaging Service should
           maintain some type of record that a notification has been
           presented and/or acknowledged, in case a user inquires with
           customer care personnel.


5.  Functional Overview

   This section defines the various core functional components of the
   system.  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

   It should be noted that when specific software cited is but one
   example of a possible selection for each component.  As the state of
   the art changes, so will the software choices described in this
   document.

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

   5.1.B.  ICAP Server: This should be an open source application
           capable of supporting content adaptation in both request and
           response modes.  The ICAP Server retrieves the notifications
           from the Messaging service cache when content adaption is
           needed.  The initial version of this system uses GreasySpoon,
           an open source application.






Chung, et al.          Expires September 23, 2010               [Page 7]


Internet-Draft  Example of an ISP Web Notification System     March 2010


   5.1.C.  Customer Database: The Customer Database holds the user
           information including the notifications setup for each user.
           The database may also hold status of which users were
           notified and users pending notification.

   5.1.D.  The Messaging Service is a process engine that retrieves
           specific web notification messages from a catalog of possible
           notifications.  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.  The initial version of this service uses
           Apache Tomcat, an open source application.

   5.1.E.  Session Management Broker: A Load Balancer (LB) with a
           customized layer 7 inspection policy is used to differentiate
           between HTTP and non-HTTP traffic on TCP port 80.  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.  New HTTP sessions are load
           balanced to the web proxy layer either transparently or using
           source Network Address Translation (NAT [RFC1631]) from the
           SMB, with additional layer 7 inspection as needed.  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.  The initial version of this system
           uses a Session Management Broker which has been developed
           internally by Comcast.
























Chung, et al.          Expires September 23, 2010               [Page 8]


Internet-Draft  Example of an ISP Web Notification System     March 2010


5.2.  Functional Diagram


   +--------+        +------------+        +----------+
   |  ICAP  | <----> | Messaging  | <----> | Customer |
   | Server |        |  Service   |        | Database |
   +--------+        +------------+        +----------+
     ^
     |                +----------+
     |                |          |
     |      +-------> | Internet | <-------+
     |      |         |          |         |
     |      |         +----------+         |
     |      |              ^               |
     v      v              |               |
   +----------+            v               v
   |+--------+|        +-------+       +--------+
   ||  ICAP  || <----> |  SMB  | <---> | Access |
   || Client ||        +-------+       | Router |
   |+--------+|                        +--------+
   || SQUID  ||                            ^
   || Proxy  ||                            |
   |+--------+|                            v
   +----------+                       +----------+
                                      | Network  |
                                      | Element* |
                                      +----------+
                                          ^
                                          |
                                          v
                                       +------+
                                       |  PC  |
                                       +------+

    * An access network element, such as a Cable Modem Termination
     System (CMTS).



         Figure 1: Web Notification System - Functional Components


6.  High Level Communication Flow








Chung, et al.          Expires September 23, 2010               [Page 9]


Internet-Draft  Example of an ISP Web Notification System     March 2010


   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: 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 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.  Using the example of a web
         notification to a user explaining that it is highly likely that
         they have been infected with a virus or malware, the user may
         click an acknowledgement that indicates that clicking that will
         take them to a page with information about virus/malware
         scanning and remediation.





Chung, et al.          Expires September 23, 2010              [Page 10]


Internet-Draft  Example of an ISP Web Notification System     March 2010


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


7.  Communication Between Web Proxy and ICAP Server

   +------------+
   |  www URL   |
   +------------+
      ^      |
   (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


8.  End-to-End Web Notification Flow






Chung, et al.          Expires September 23, 2010              [Page 11]


Internet-Draft  Example of an ISP Web Notification System     March 2010


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

   Policy Based Routing

   1.  TCP port 80 packets from the users that need to be notified may
       be routed to the web proxy via policy based routing.

   2.  Packets are forwarded to the Load Balancer, which establishes a
       session with the web proxy and routes the packets to the proxy.

   Web Proxy

   1.  User's HTTP request is directed to the web proxy.

   2.  Web proxy received HTTP traffic and retrieves content from the
       requested web site.

   3.  Web proxy receives 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.

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

       B.  The ICAP Server then sends the response back to the web
           proxy, which in turn forwards the HTTP response back to the
           browser.

   8.  If the user IP 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 September 23, 2010              [Page 12]


Internet-Draft  Example of an ISP Web Notification System     March 2010


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

   This flow shows the communications flow from the web client, through
   the entire system.












































Chung, et al.          Expires September 23, 2010              [Page 13]


Internet-Draft  Example of an ISP Web Notification System     March 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 |        | Cache  |
     |        |         |         | Match  |        | Miss   |
     |        |         |         +------->|        | Request|
     |        |         |         |        |        | Type   |
     |        |         |         |        +--------|------->|
     |        |         | Cache   |        |        |        |
     |        |         | Miss    |        |        |        |
     |        |         | No      |        |        |        |
     |        |         | Insert  |        |        |        |
     |        |<--------|---------|--------+        |Type    |
     | 200 OK |         |         |        |        |Returned|
     | No     |         |         |        |<-------|--------+
     | Insert |         |         |        |        |        |
     |<-------+         |         |        |        |        |
     |        |         | Cache   |        |        |        |
     |        |         | Hit     |        |        |        |
     |        |         | Insert  |        |        |        |
     | 200 OK |<--------|---------|--------+        |        |
     | Insert |         |         |        |        |        |
     |<-------+         |         |        |        |        |
     |        |         | HTTP    |        |        |        |
     |        |         | GET to  |        |        |        |
     |        |         | Content |        |        |        |
     |        |         | Portal  |        |        |        |
     +--------|---------|---------|--------|------->|        |
     |        |         | 200 OK  |        |        |        |
     |        |         | w/      |        |        |        |
     |        |         | Notify  |        |        |        |
     |<-------|---------|---------|--------|--------+        |

                Figure 3: End-to-End Web Notification Flow


9.  Example HTTP Headers for a Web Notification



Chung, et al.          Expires September 23, 2010              [Page 14]


Internet-Draft  Example of an ISP Web Notification System     March 2010


Web-Browser HTTP Headers

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

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

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



Chung, et al.          Expires September 23, 2010              [Page 15]


Internet-Draft  Example of an ISP Web Notification System     March 2010


  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 4


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 surfing experience remains
   acceptable.  It is also recommended that a HTTP-aware load balancer
   is 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
   out.


11.  Security Considerations

   This web notification system was conceived in order to provide an
   additional method of notifying ISP customers that their computer was
   infected with malware.  Depending upon the nature of the alert
   contained in the web notification, such as the malware alert, users
   could fear that it is some kind of phishing attack.  As a result,
   care should be taken with the text and any links contained in the web
   notification itself.  For example, the ISP may find it best to
   provide a general URI or a telephone number.  In contrast to that,
   the ISP should not ask for login credentials or for someone to follow
   a link in the web notification 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



Chung, et al.          Expires September 23, 2010              [Page 16]


Internet-Draft  Example of an ISP Web Notification System     March 2010


   from a trusted party, and/or that the user has an alternate method of
   checking the validity of the web notification.


12.  IANA Considerations

   There are no IANA considerations in this document.

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


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


14.  References

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




Chung, et al.          Expires September 23, 2010              [Page 17]


Internet-Draft  Example of an ISP Web Notification System     March 2010


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

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



Chung, et al.          Expires September 23, 2010              [Page 18]


Internet-Draft  Example of an ISP Web Notification System     March 2010


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

   -00 version:

   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










Chung, et al.          Expires September 23, 2010              [Page 19]


Internet-Draft  Example of an ISP Web Notification System     March 2010


   Alex Kasyanov
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: alexander_kasyanov@cable.comcast.com
   URI:   http://www.comcast.com


   Jason Livingood
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: jason_livingood@cable.comcast.com
   URI:   http://www.comcast.com


   Nirmal Mody
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: nirmal_mody@cable.comcast.com
   URI:   http://www.comcast.com


   Brian Van Lieu
   Unaffiliated
   Bethlehem, PA  18018
   US

   Email: brian@vanlieu.net












Chung, et al.          Expires September 23, 2010              [Page 20]