<pre>Independent Submission                                          C. Chung
Request for Comments: 6108                                   A. Kasyanov
Category: Informational                                     J. Livingood
ISSN: 2070-1721                                                  N. Mody
                                                                 Comcast
                                                             B. Van Lieu
                                                            Unaffiliated
                                                           February 2011


                <span class="h1">Comcast's Web Notification System Design</span>

Abstract

   The objective of this document is to describe a method of providing
   critical end-user notifications to web browsers, which has been
   deployed by Comcast, an Internet Service Provider (ISP).  Such a
   notification system is being used to provide near-immediate
   notifications to customers, such as to warn them that their traffic
   exhibits patterns that are indicative of malware or virus infection.
   There are other proprietary systems that can perform such
   notifications, but those systems utilize Deep Packet Inspection (DPI)
   technology.  In contrast to DPI, this document describes a system
   that does not rely upon DPI, and is instead based in open IETF
   standards and open source applications.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6108">http://www.rfc-editor.org/info/rfc6108</a>.










<span class="grey">Chung, et al.                 Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. High-Level Design of the System .................................<a href="#page-3">3</a>
   <a href="#section-3">3</a>. Design Requirements .............................................<a href="#page-3">3</a>
      <a href="#section-3.1">3.1</a>. General Requirements .......................................<a href="#page-4">4</a>
      <a href="#section-3.2">3.2</a>. Web Proxy Requirements .....................................<a href="#page-6">6</a>
      <a href="#section-3.3">3.3</a>. ICAP Server Requirements ...................................<a href="#page-7">7</a>
      <a href="#section-3.4">3.4</a>. Messaging Service Requirements .............................<a href="#page-8">8</a>
   <a href="#section-4">4</a>. Implementation Details ..........................................<a href="#page-8">8</a>
      <a href="#section-4.1">4.1</a>. Functional Components Described, as Implemented ............<a href="#page-9">9</a>
      <a href="#section-4.2">4.2</a>. Functional Diagram, as Implemented ........................<a href="#page-10">10</a>
   <a href="#section-5">5</a>. High-Level Communication Flow, as Implemented ..................<a href="#page-11">11</a>
   6. Communication between Web Proxy and ICAP Server, as
      Implemented ....................................................<a href="#page-12">12</a>
   <a href="#section-7">7</a>. End-to-End Web Notification Flow, as Implemented ...............<a href="#page-13">13</a>
      7.1. Step-by-Step Description of the End-to-End Web
           Notification Flow .........................................<a href="#page-14">14</a>
      <a href="#section-7.2">7.2</a>. Diagram of the End-to-End Web Notification Flow ...........<a href="#page-15">15</a>
   <a href="#section-8">8</a>. Example HTTP Headers and JavaScript for a Web Notification .....<a href="#page-16">16</a>
   <a href="#section-9">9</a>. Deployment Considerations ......................................<a href="#page-18">18</a>
   <a href="#section-10">10</a>. Security Considerations .......................................<a href="#page-19">19</a>
   11. Debating the Necessity of Such a Critical Notification
       System ........................................................<a href="#page-19">19</a>
   <a href="#section-12">12</a>. Suggesting a Walled Garden as an Alternative ..................<a href="#page-20">20</a>
   <a href="#section-13">13</a>. Intended Next Steps ...........................................<a href="#page-21">21</a>
   <a href="#section-14">14</a>. Acknowledgements ..............................................<a href="#page-21">21</a>
   <a href="#section-15">15</a>. References ....................................................<a href="#page-21">21</a>
      <a href="#section-15.1">15.1</a>. Normative References .....................................<a href="#page-21">21</a>
      <a href="#section-15.2">15.2</a>. Informative References ...................................<a href="#page-23">23</a>









<span class="grey">Chung, et al.                 Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Internet Service Providers (ISPs) have a need for a system that is
   capable of communicating with customers in a nearly immediate manner,
   to convey critical service notices such as warnings concerning likely
   malware infection.  Given the prevalence of the web browser as the
   predominant client software in use by Internet users, the web browser
   is an ideal vehicle for providing these notifications.  This document
   describes a system that has been deployed by Comcast, a broadband
   ISP, to provide near-immediate notifications to web browsers.

   In the course of evaluating potential solutions, the authors
   discovered that the large majority of commercially available systems
   utilized Deep Packet Inspection (DPI) technology.  While a DPI-based
   system would certainly work, Comcast and other ISPs are trying to
   avoid widespread deployment and use of DPI, and are searching for
   alternatives.  Thus, Comcast desired to use a system that is based on
   open standards and non-proprietary software, and that did not require
   the use of DPI.  While the system described herein is specific to the
   Data-Over-Cable Service Interface Specifications (DOCSIS,
   [<a href="#ref-CableLabs_DOCSIS">CableLabs_DOCSIS</a>]) 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.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  High-Level Design of the System</span>

   The web notification system design is based on the use of the
   Internet Content Adaptation Protocol (ICAP) [<a href="./rfc3507" title="&quot;Internet Content Adaptation Protocol (ICAP)&quot;">RFC3507</a>].  The design
   uses open source applications, which are the Squid web proxy,
   GreasySpoon ICAP server, and Apache Tomcat.  ICAP, an existing IETF
   protocol, allows for message transformation or adaptation.  An ICAP
   client passes a HyperText Transport Protocol (HTTP, [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>])
   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
   <a href="./rfc3507#section-3.2">Section&nbsp;3.2 of [RFC3507]</a>.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Design Requirements</span>

   This section describes all of the key requirements taken into
   consideration by Comcast for the design of this system.  This
   information is provided in order to convey important design choices
   that were made in order to avoid the use of DPI, among other things.
   An "Additional Background" paragraph is included with each
   requirement to provide additional information, context, or other
   useful explanation.




<span class="grey">Chung, et al.                 Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  General Requirements</span>

   R3.1.1.   Must Only Be Used for Critical Service Notifications
             Additional Background: The system must only provide
             critical notifications, rather than trivial notifications.
             An example of a critical, non-trivial notification, which
             is also the primary motivation of this system, is to advise
             the user that their computer is infected with malware, that
             their security is at severe risk and/or has already been
             compromised, and that it is recommended that they take
             immediate, corrective action NOW.

   R3.1.2.   Must Use TCP Port 80
             Additional Background: The system must provide
             notifications via TCP port 80, the well-known port for HTTP
             traffic.  Since the large majority of customers use a web
             browser as their primary application, this was deemed the
             best method to provide them with an immediate, critical
             notification.

   R3.1.3.   Must Support Block Listing
             Additional Background: While unlikely, it is possible that
             the HyperText Markup Language (HTML, [<a href="./rfc2854" title="&quot;The 'text/html' Media Type&quot;">RFC2854</a>]) or
             JavaScript [<a href="./rfc4329" title="&quot;Scripting Media Types&quot;">RFC4329</a>] used for notifications may cause
             problems while accessing a particular website.  Therefore,
             such a system must be capable of using a block list of
             website Uniform Resource Identifiers (URIs, [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>]) or
             Fully Qualified Domain Names (FQDNs, <a href="./rfc1035#section-5.1">Section&nbsp;5.1 of
             [RFC1035]</a>) that conflict with the system, so that the
             system does not provide notifications in these cases, in
             order to minimize any errors or unexpected results.  Also,
             while extensive development and testing has been performed
             to ensure that this system does not behave in unexpected
             ways, and standard ICAP (which has been in use for many
             years) is utilized, it is critical that if it does behave
             in such a way, there must be a method to rapidly exempt
             specific URIs or FQDNs.

   R3.1.4.   Must Not Cause Problems with Instant Messaging (IM) Clients
             Using TCP Port 80
             Additional Background: Some IM clients use TCP port 80 in
             their communications, often as an alternate port when
             standard, well-known ports do not work.  Other IM clients
             may in fact use TCP port 80 by default, in some cases even
             being based in a web browser.  Therefore, this system must
             not conflict with or cause unexpected results for IM
             clients (or any other client types) that use TCP port 80.




<span class="grey">Chung, et al.                 Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


   R3.1.5.   Must Handle Pre-Existing Active TCP Sessions Gracefully
             Additional Background: Since the web notification system
             may temporarily re-route TCP port 80 traffic in order to
             provide a critical notification, previously established TCP
             port 80 sessions must not be disrupted while being routed
             to the proxy layer.  Also, since the critical web
             notification occurs at a well-defined point in time, it is
             logical to conclude that an end user may well have an
             active TCP port 80 session in progress before the
             notification is sent, and which is still active at the time
             of the notification.  It is therefore important that any
             such connections must not be reset, and that they instead
             must be handled gracefully.

   R3.1.6.   Must Not Use TCP Resets
             Additional Background: The use of TCP resets has been
             widely criticized, both in the Internet community generally
             and in [<a href="./rfc3360" title="&quot;Inappropriate TCP Resets Considered Harmful&quot;">RFC3360</a>].  In Comcast's recent history, for
             example, the company was criticized for using TCP resets in
             the course of operating a DPI-based network management
             system.  As such, TCP resets as a function of the system
             must not be used.

   R3.1.7.   Must Be Non-Disruptive
             Additional Background: The web notification system must not
             disrupt the end-user experience, for example by causing
             significant client errors.

   R3.1.8.   User Notification Acknowledgement Must Stop Further
             Immediate Notifications
             Additional Background: Once a user acknowledges a critical
             notification, the notification should immediately stop.
             Otherwise, the user may believe the system is stuck in an
             error state and may not believe that the critical
             notification is valid.  In addition, it is quite possible
             that the user will be annoyed that the system did not react
             to his acknowledgement.

   R3.1.9.   Non-Modification of Content Should Be Maintained
             Additional Background: The system should not significantly
             alter the content of the HTTP response from any website the
             user is accessing.

   R3.1.10.  Must Handle Unexpected Content Gracefully
             Additional Background: Sometimes, developers and/or
             implementers of software systems assume that a narrow range
             of inputs to a system will occur, all of which have been
             thought of beforehand by the designers.  The authors



<span class="grey">Chung, et al.                 Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


             believe this is a poor assumption to make in the design and
             implementation of a system and, in contrast, that
             unexpected or even malformed inputs should be assumed.  As
             a result, the system must gracefully and transparently
             handle traffic that is unexpected, even though there will
             be cases when the system cannot provide a critical web
             notification as a result of this.  Thus, widely varying
             content should be expected, and all such unexpected traffic
             must be handled by the system without generating user-
             perceived errors or unexpected results.

   R3.1.11.  Web Content Must Not Be Cached
             Additional Background: Maintaining the privacy of users is
             important.  As such, content flowing through or
             incidentally observed by the system must not be cached.

   R3.1.12.  Advertising Replacement or Insertion Must Not Be Performed
             Under ANY Circumstances
             Additional Background: The system must not be used to
             replace any advertising provided by a website, or to insert
             advertising into websites.  This therefore includes cases
             where a web page already has space for advertising, as well
             as cases where a web page does not have any advertising.
             This is a critical area of concern for end users, privacy
             advocates, and other members of the Internet community.
             Therefore, it must be made abundantly clear that this
             system will not be used for such purposes.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Web Proxy Requirements</span>

   R3.2.1.  Open Source Software Must Be Used
            Additional Background: The system must use an open source
            web proxy server.  (As noted in <a href="#section-2">Section 2</a> and <a href="#section-4.1">Section 4.1</a>,
            Squid has been chosen.)  While it is possible to use any web
            proxy, the use of open source enables others to easily
            access openly available documentation for the software,
            among the other benefits commonly attributed to the use of
            open source software.

   R3.2.2.  ICAP Client Should Be Integrated
            Additional Background: The web proxy server should have an
            integrated ICAP client, which simplifies the design and
            implementation of the system.








<span class="grey">Chung, et al.                 Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


   R3.2.3.  Access Control Must Be Implemented
            Additional Background: Access to the proxy must be limited
            exclusively to the IP addresses of users for which
            notifications are intended, and only for limited periods of
            time.  Furthermore, since a Session Management Broker (SMB)
            is utilized, as described in <a href="#section-4.1">Section 4.1</a> below, then the
            proxy must restrict access only to the address of the SMB.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  ICAP Server Requirements</span>

   R3.3.1.  Must Provide ICAP Response Support
            Additional Background: The system must support response
            adaptation, in accordance with [<a href="./rfc3507" title="&quot;Internet Content Adaptation Protocol (ICAP)&quot;">RFC3507</a>].  An ICAP client
            passes a HyperText Transport Protocol (HTTP, [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>])
            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 <a href="./rfc3507#section-3.2">Section&nbsp;3.2 of [RFC3507]</a>.

   R3.3.2.  Must Provide Consistency of Critical Notifications
            Additional Background: The system must be able to
            consistently provide a specific notification.  For example,
            if a critical alert to notify a user that they are infected
            with malware is desired, then that notification should
            consistently look the same for all users and not vary.

   R3.3.3.  Must Support Multiple Notification Types
            Additional Background: While the initial and sole critical
            notification sent by the system is intended to alert users
            of a malware infection, malware is a rapidly and
            continuously evolving threat.  As a result of this reality,
            the system must be able to evolve to provide different types
            of critical notifications.  For example, if malware begins
            to diverge into several different categories with
            substantially different implications for end users, then it
            may become desirable to provide a notification that has been
            narrowly tailored to each category of malware.

   R3.3.4.  Must Support Notification to Multiple Users Simultaneously
            Additional Background: The system must be able to
            simultaneously serve notifications to different users.  For
            example, if 100 users have been infected with malware and
            critically need to be notified about this security problem,
            then the system must be capable of providing the
            notification to several users at a time, or all of the users
            at the same time, rather than to just one user at a time.





<span class="grey">Chung, et al.                 Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Messaging Service Requirements</span>

   R3.4.1.  A Messaging Service Must Be Used
            Additional Background: The Messaging Service, as described
            in <a href="#section-4.1">Section 4.1</a> below, caches the notifications for each
            specific user.  Thus, the notification messages are cached
            by the system and do not have to be retrieved each time a
            notification is needed.  As a result, the system can be more
            easily scaled to provide notification to multiple users
            simultaneously, as noted in an earlier requirement ("Must
            Support Notification to Multiple Users Simultaneously").

   R3.4.2.  Must Process Acknowledgements on a Timely Basis
            Additional Background: The Messaging Service must quickly
            process notification acknowledgements by end users, as noted
            in an earlier requirement ("User Notification
            Acknowledgement Must Stop Further Immediate Notifications").

   R3.4.3.  Must Ensure Notification Targeting Accuracy
            Additional Background: The Messaging Service must ensure
            that notifications are presented to the intended users.  For
            example, if the system intends to provide a critical
            notification to User A and User B, but not User C, then
            User C must not be sent a notification.

   R3.4.4.  Should Keep Notification Records for Customer Support
            Purposes
            Additional Background: The Messaging Service should maintain
            some type of record that a notification has been sent to a
            user, in case that user inquires with customer support
            personnel.  For example, when a user is presented with the
            critical notification advising them of a malware infection,
            that user may choose to call Comcast's Customer Security
            Assurance team, in the customer service organization.  As a
            result, a Customer Security Assurance representative should
            be able to confirm that the user did in fact receive a
            notification concerning malware infection in the course of
            providing assistance to the end user in remediating the
            malware infection.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Implementation Details</span>

   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.





<span class="grey">Chung, et al.                 Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Functional Components Described, as Implemented</span>

   This section accurately and transparently describes the software (S)
   packages used by the system described herein, as well as all of the
   details of how the system functions.  The authors acknowledge that
   there may be multiple alternative software choices for each
   component; the purpose of this section is to describe those
   selections that have been made and deployed.

   S4.1.1.  Web Proxy: The system uses Squid Proxy, an open source web
            proxy application in wide use, which supports an integrated
            ICAP client.

   S4.1.2.  ICAP Server: The system uses GreasySpoon, an open source
            application.  The ICAP server retrieves the notifications
            from the Messaging Service cache when content adaption is
            needed.

   S4.1.3.  Customer Database: The Customer Database holds the relevant
            information that the system needs to provide a critical
            notification to a given user.  The database may also hold
            the status of which users were notified and which users are
            pending notification.

   S4.1.4.  Messaging Service: The system uses Apache Tomcat, an open
            source application.  This is a process engine that retrieves
            specific web notification messages from a catalog of
            possible notifications.  While only one notification is
            currently used, concerning malware infection, as noted in
            <a href="#section-3.3">Section 3.3</a> the system may eventually need to provide
            multiple notifications (the specific requirement is "Must
            Support Multiple Notification Types").  When a notification
            for a specific user is not in the cache, the process
            retrieves this information from the Customer Database and
            populates the cache for a specific period of time.

   S4.1.5.  Session Management Broker (SMB): A Load Balancer (LB) with a
            customized layer 7 inspection policy is used to
            differentiate between HTTP and non-HTTP traffic on TCP
            port 80, in order to meet the requirements documented in
            <a href="#section-3">Section 3</a> above.  The system uses a LB from A10 Networks.
            The SMB functions as a full stateful TCP proxy with the
            ability to forward packets from existing TCP sessions that
            do not exist in the internal session table (to meet the
            specific requirement "Must Handle Pre-Existing Active TCP
            Sessions Gracefully").  New HTTP sessions are load balanced
            to the web proxy layer either transparently or using source
            Network Address Translation (NAT [<a href="./rfc3022" title="&quot;Traditional IP Network Address Translator (Traditional NAT)&quot;">RFC3022</a>]) from the SMB.



<span class="grey">Chung, et al.                 Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


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

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Functional Diagram, as Implemented</span>

   +--------+        +------------+        +----------+
   |  ICAP  | &lt;----&gt; | Messaging  | &lt;----&gt; | Customer |
   | Server |        |  Service   |        | Database |
   +--------+        +------------+        +----------+
     ^
     |                +----------+
     |                |          |
     |      +-------&gt; | Internet | &lt;-------+
     |      |         |          |         |
     |      |         +----------+         |
     |      |              ^               |
     v      v              |               |
   +----------+            v               v
   |+--------+|        +-------+       +--------+
   ||  ICAP  || &lt;----&gt; |  SMB  | &lt;---&gt; | Access |
   || Client ||        +-------+       | Router |
   |+--------+|                        +--------+
   || SQUID  ||                            ^
   || Proxy  ||                            |
   |+--------+|                            v
   +----------+                       +----------+
                                      |  CMTS*   |
                                      +----------+
                                          ^
                                          |
                                          v
                                       +------+
                                       |  PC  |
                                       +------+

    * A Cable Modem Termination System (CMTS)
      is an access network element.

         Figure 1: Web Notification System - Functional Components









<span class="grey">Chung, et al.                 Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  High-Level Communication Flow, as Implemented</span>

   In <a href="#section-4">Section 4</a>, the functional components of the system were described,
   and then shown in relation to one another in Figure 1 above.  This
   section describes the high-level communication (C) flow of a
   transaction in the system, in order to explain the general way that
   the functions work together in action.  This will be further
   explained in much more detail in later sections of this document.

   C5.1.   Setup of Differentiated Services (Diffserv): Using Diffserv
           [<a href="./rfc2474" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">RFC2474</a>] [<a href="./rfc2475" title="&quot;An Architecture for Differentiated Services&quot;">RFC2475</a>] [<a href="./rfc2597" title="&quot;Assured Forwarding PHB Group&quot;">RFC2597</a>] [<a href="./rfc3140" title="&quot;Per Hop Behavior Identification Codes&quot;">RFC3140</a>] [<a href="./rfc3246" title="&quot;An Expedited Forwarding PHB (Per-Hop Behavior)&quot;">RFC3246</a>] [<a href="./rfc3260" title="&quot;New Terminology and Clarifications for Diffserv&quot;">RFC3260</a>]
           [<a href="./rfc4594" title="&quot;Configuration Guidelines for DiffServ Service Classes&quot;">RFC4594</a>], set a policy to direct TCP port 80 traffic to the
           web notification system's web proxy.

   C5.2.   Session Management: TCP port 80 packets are routed to a
           Session Management Broker (SMB) that distinguishes between
           HTTP or non-HTTP traffic and between new and existing
           sessions.  HTTP packets are forwarded to the web proxy by the
           SMB.  Non-HTTP packets such as instant messaging (IM) traffic
           are forwarded to a TCP proxy layer for routing to their
           destination, or the SMB operates as a full TCP proxy and
           forwards the non-HTTP packets to the destination.
           Pre-established TCP sessions on port 80 are identified by the
           SMB and forwarded with no impact.

   C5.3.   Web Proxy Forwards Request: The web proxy forwards the HTTP
           request on to the destination site, a web server, as a web
           proxy normally would do.

   C5.4.   On Response, Send Message to ICAP Server: When the HTTP
           response is received from the destination server, the web
           proxy sends a message to the ICAP server for the web
           notification.

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

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

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






<span class="grey">Chung, et al.                 Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


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

   C5.9.   More Information: Depending upon the notification, the user
           may be provided with more information.  For example, as noted
           previously, the system was designed to provide critical
           notifications concerning malware infection.  Thus, in the
           case of malware infection, the user may be advised to go to a
           malware remediation web page that provides directions on how
           to attempt to remove the malware and attempt to secure hosts
           against future malware infection.

   C5.10.  Turn Down Diffserv: Once the notification transaction has
           completed, remove any special Diffserv settings.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Communication between Web Proxy and ICAP Server, as Implemented</span>

   The web proxy and ICAP server are critical components of the system.
   This section shows the communication that occurs between these two
   components.






























<span class="grey">Chung, et al.                 Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


   +------------+
   |  www URI   |
   +------------+
      ^      |
   (2)|      |(3)
      |      v
     +--------+     (4)     +--------+     (4)     +--------+
     |        |------------&gt;|        |------------&gt;|        |
     |        |     (5)     |        |     (5)     |        |
     | Proxy  |&lt;------------|  ICAP  |&lt;------------|  ICAP  |
     | Module |     (6)     | Client |     (6)     | Server |
     |        |------------&gt;|        |------------&gt;|        |
     |        |     (7)     |        |     (7)     |        |
     |        |&lt;------------|        |&lt;------------|        |
     +--------+             +--------+             +--------+
      ^      |
   (1)|      |(8)
      |      v
   +------------+              (9)             +------------+
   |            |-----------------------------&gt;|            |
   |  Browser   |              (10)            | Web Server |
   |            |&lt;-----------------------------|            |
   +------------+                              +------------+

   (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

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  End-to-End Web Notification Flow, as Implemented</span>

   This section describes the exact flow of an end-to-end notification,
   in order to show in detail how the system functions.










<span class="grey">Chung, et al.                 Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Step-by-Step Description of the End-to-End Web Notification Flow</span>

   Policy-Based Routing

   1.  TCP port 80 packets from the user that needs to be notified are
       routed to the web proxy via policy-based routing.

   2.  Packets are forwarded to the Session Management Broker, which
       establishes a session with the web proxy and routes the packets
       to the web proxy.

   Web Proxy

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

   2.   The web proxy receives HTTP traffic and retrieves content from
        the requested website.

   3.   The web proxy receives the response and forwards it to the ICAP
        server for response adaptation.

   4.   The ICAP server checks the HTTP content in order to determine
        whether the notification message can be inserted.

   5.   The ICAP server initiates a request to the Messaging Service
        cache process with the IP address of the user.

   6.   If a notification message for the user exists, then the
        appropriate notification is cached on the Messaging Service.
        The Messaging Service then returns the appropriate notification
        content to the ICAP server.

   7.   Once the notification message is retrieved from the Messaging
        Service cache, the ICAP server may insert the notification
        message in the HTTP response body without altering or modifying
        the original content of the HTTP response.

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

   9.   If the user's IP address is not found or provisioned for a
        notification message, then the ICAP server should return a "204
        No modifications needed" response to the ICAP client as defined
        in <a href="./rfc3507#section-4.3.3">Section&nbsp;4.3.3 of [RFC3507]</a>.  As a result, the user will not
        receive any web notification message.






<span class="grey">Chung, et al.                 Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


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

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Diagram of the End-to-End Web Notification Flow</span>

   The two figures below show the communications flow from the web
   browser, through the web notification system.

   Figure 3 illustrates what occurs when a notification request cannot
   be inserted because the notification type for the user's IP address
   is not cached in the Messaging Service.

                            ICAP     ICAP    Message          Customer
         Browser   Proxy   Client   Server   Service  Internet    DB
           |  HTTP  |         |         |        |        |        |
           |  GET   | Proxy   |         |        |        |        |
           +-------&gt;| Request |         |        |        |        |
           |        +---------|---------|--------|-------&gt;|        |
           |        |         |         |        | 200 OK |        |
           |        |&lt;--------|---------|--------|--------+        |
           |        | ICAP    |         |        |        |        |
           |        | RESPMOD | ICAP    |        |        |        |
           |        +--------&gt;| RESPMOD | Check  |        |        |
           |        |         +--------&gt;| Cache  |        |        |
           |        |         |         | for IP |        |        |
           |        |         |         | Match  |        |        |
           |        |         |         +-------&gt;|        |        |
           |        |         |         | Cache  |        |        |
           |        |         |         | Miss   |        |        |
           |        |         |         |&lt;-------+ Request|        |
           |        |         | 204 No  |        | Type   |        |
           |        |         | Modif.  |        +--------|-------&gt;|
           |        |         | Needed  |        |        |        |
           |        | No      |&lt;--------+        |        | Type   |
           |        | Insert  |         |        |        |Returned|
           | 200 OK |&lt;--------+         |        |&lt;-------|--------+
           | w/o    |         |         |        |        |        |
           | Insert |         |         |        |        |        |
           |&lt;-------+         |         |        |        |        |
           |        |         |         |        |        |        |

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








<span class="grey">Chung, et al.                 Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


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

                            ICAP     ICAP    Message          Customer
         Browser   Proxy   Client   Server   Service  Internet    DB
           |  HTTP  |         |         |        |        |        |
           |  GET   | Proxy   |         |        |        |        |
           +-------&gt;| Request |         |        |        |        |
           |        +---------|---------|--------|-------&gt;|        |
           |        |         |         |        | 200 OK |        |
           |        |&lt;--------|---------|--------|--------+        |
           |        | ICAP    |         |        |        |        |
           |        | RESPMOD | ICAP    |        |        |        |
           |        +--------&gt;| RESPMOD | Check  |        |        |
           |        |         +--------&gt;| Cache  |        |        |
           |        |         |         | for IP |        |        |
           |        |         |         | Match  |        |        |
           |        |         |         +-------&gt;|        |        |
           |        |         |         | Cache  |        |        |
           |        |         |         | Hit    |        |        |
           |        |         | Insert  |&lt;-------+        |        |
           |        | Return  | Type    |        |        |        |
           |        | 200 OK  |&lt;--------+        |        |        |
           |        | with    |         |        |        |        |
           |        | Insert  |         |        |        |        |
           | 200 OK |&lt;--------+         |        |        |        |
           | w/     |         |         |        |        |        |
           | Notify |         |         |        |        |        |
           |&lt;-------+         |         |        |        |        |
           |        |         |         |        |        |        |

        Figure 4: End-to-End Web Notification Flow - with Cache Hit

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Example HTTP Headers and JavaScript for a Web Notification</span>

   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.













<span class="grey">Chung, et al.                 Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


------------------------------------------------------------------------
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  HTTP GET Request to www.example.com</span>
------------------------------------------------------------------------
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.

------------------------------------------------------------------------
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Response from www.example.com via PROXY</span>
------------------------------------------------------------------------
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






<span class="grey">Chung, et al.                 Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


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

------------------------------------------------------------------------
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Example of JavaScript containing Notification Insertion</span>
------------------------------------------------------------------------
&lt;!--all elements used in a notification should have cascading style
sheet (css) properties defined to avoid unwanted inheritance from
parent page--&gt;

&lt;style type="text/css"&gt;
#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);
}
&lt;/style&gt;

&lt;script language="javascript" type="text/javascript"&gt;
// ensure that content is not part of an iframe
if (self.location == top.location) {
  // this is a floating div with 80% transparency
  document.write('&lt;div id="example" name="example"&gt;');
  document.write('&lt;h2&gt;IMPORTANT MESSAGE&lt;/h2&gt;');
  document.write('&lt;p&gt;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('&lt;/div&gt;');
}&lt;/script&gt;
------------------------------------------------------------------------

          Figure 7: Example JavaScript Used in a Web Notification

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Deployment Considerations</span>

   The components of the web notification system should be distributed
   throughout the network and close to end users.  This ensures that the
   routing performance and the user's web browsing experience remain
   excellent.  In addition, a HTTP-aware load balancer should be used in
   each datacenter where servers are located, so that traffic can be
   spread across N+1 servers and the system can be easily scaled.




<span class="grey">Chung, et al.                 Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Security Considerations</span>

   This critical web notification system was conceived in order to
   provide an additional method of notifying end user customers that
   their computer has been infected with malware.  Depending upon the
   specific text of the notification, users could fear that it is some
   kind of phishing attack.  As a result, care has been taken with the
   text and any links contained in the web notification itself.  For
   example, should the notification text change over time, it may be
   best to provide a general URI or a telephone number.  In contrast to
   that, the notification must not ask for login credentials, and must
   not ask a user to follow a link in order to change their password,
   since these are common phishing techniques.  Finally, care should be
   taken to provide confidence that the web notification is valid and
   from a trusted party, and/or that the user has an alternate method of
   checking the validity of the web notification.  One alternate method
   of validating the notification may be to call customer support (in
   this example, Comcast's Customer Security Assurance team); this
   explains a key requirement (specifically, "Should Keep Notification
   Records for Customer Support Purposes") in <a href="#section-3.4">Section 3.4</a>.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Debating the Necessity of Such a Critical Notification System</span>

   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 [<a href="./rfc3507" title="&quot;Internet Content Adaptation Protocol (ICAP)&quot;">RFC3507</a>].
   Such concerned parties should also study the many organizations using
   ICAP and the many software systems that have implemented ICAP.

   In addition, concerned members of the community should review
   <a href="#section-1">Section 1</a>, which describes the fact that this is a common feature of
   DPI systems, made by DPI vendors and many, if not most, major
   networking equipment vendors.  As described herein, the authors of
   this document are motivated to AVOID the need for widespread,
   ubiquitous deployment of DPI, via the use of both open source
   software and open protocols, and are further motivated to
   transparently describe the details of how such a system functions,
   what it IS intended to do, what it IS NOT intended to do, and
   purposes for which it WILL NOT be used.






<span class="grey">Chung, et al.                 Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


   The authors also believe it is important for ISPs to transparently
   disclose network management techniques and systems, and to have a
   venue to do so, as has been done here.  In addition, the authors
   believe it is important for the IETF and other members of the
   Internet community to encourage and positively reinforce such
   disclosures.  In the publishing of such a document for reference and
   comment by the Internet community, this may serve to motivate other
   ISPs to be similarly open and to engage the IETF and other
   organizations that are part of the Internet community.  Not
   publishing such documents could motivate less disclosure on the part
   of ISPs and other members of the Internet community, increase the use
   of DPI, and decrease ISP participation in the critical technical
   bodies that make up parts of the Internet community.

   In addition, it is critical that members of the community recognize
   the good motivations of ISPs like Comcast to combat the massive and
   continuing proliferation of malware, which is a huge threat to the
   security of average Internet users and now represents a multi-
   billion-dollar underground economy engaged in identity theft,
   financial fraud, transmission of spam, and other criminal activity.
   Such a critical notification system in fact is only necessary due to
   the failure of host-based security at defending against and
   preventing malware infection.  As such, ISPs such as Comcast are
   being urged by their customers and by other parties such as security
   and/or privacy organizations, as well as governmental organizations,
   to take action to help solve this massive problem, since so many
   other tactics have been unsuccessful.  For example, as Howard
   Schmidt, the Special Advisory for Cyber Security to President Obama,
   of the United States of America, said in 2005: "As attacks on home-
   based and unsecured networks become as prevalent as those against
   large organizations, the need for ISPs to do everything they can to
   make security easier for their subscribers is critical for the
   preservation of our nation's information backbone.  Additionally,
   there is tremendous potential to grow further the use of broadband
   around the world; and making safety and security part of an ISP's
   core offering will enable the end user to fully experience the rich
   and robust benefits broadband provides".

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  Suggesting a Walled Garden as an Alternative</span>

   A "walled garden" refers to an environment that controls the
   information and services that a subscriber is allowed to utilize and
   what network access permissions are granted.  Placing a user in a
   walled garden is therefore another approach that ISPs may take to
   notify users, and this method is being explored as a possible
   alternative in other documents and community efforts.  As such, web
   notifications should be considered one of many possible notification
   methods that merit documentation.



<span class="grey">Chung, et al.                 Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


   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.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Intended Next Steps</span>

   Unfortunately, at the time of this writing, no existing working group
   of the IETF is focused on issues of malware infection and related
   issues.  As a result, there was not a definite venue for this
   document, so it was submitted to the Independent Submissions Editor
   as an independent submission.  While documentation and disclosure of
   this system are beneficial for the Internet community in and of
   itself, there are other benefits to having this document published.
   One of those reasons is that members of the community, including
   members of the IETF, have a stable document to refer to in the case
   of any potential new work that the community may undertake in the
   area of malware, security, and critical notification to end users.
   It is also hoped that, in the tradition of a Request for Comment,
   other members of the community may be motivated to propose
   alternative systems or other improvements.

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  Acknowledgements</span>

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

<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>.  References</span>

<span class="h3"><a class="selflink" id="section-15.1" href="#section-15.1">15.1</a>.  Normative References</span>

   [<a id="ref-RFC1035">RFC1035</a>]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.

   [<a id="ref-RFC2474">RFC2474</a>]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>,
              December 1998.






<span class="grey">Chung, et al.                 Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


   [<a id="ref-RFC2475">RFC2475</a>]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", <a href="./rfc2475">RFC 2475</a>, December 1998.

   [<a id="ref-RFC2597">RFC2597</a>]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", <a href="./rfc2597">RFC 2597</a>, June 1999.

   [<a id="ref-RFC2616">RFC2616</a>]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.

   [<a id="ref-RFC2854">RFC2854</a>]  Connolly, D. and L. Masinter, "The 'text/html' Media
              Type", <a href="./rfc2854">RFC 2854</a>, June 2000.

   [<a id="ref-RFC3022">RFC3022</a>]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", <a href="./rfc3022">RFC 3022</a>,
              January 2001.

   [<a id="ref-RFC3140">RFC3140</a>]  Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", <a href="./rfc3140">RFC 3140</a>,
              June 2001.

   [<a id="ref-RFC3246">RFC3246</a>]  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)", <a href="./rfc3246">RFC 3246</a>, March 2002.

   [<a id="ref-RFC3260">RFC3260</a>]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", <a href="./rfc3260">RFC 3260</a>, April 2002.

   [<a id="ref-RFC3507">RFC3507</a>]  Elson, J. and A. Cerpa, "Internet Content Adaptation
              Protocol (ICAP)", <a href="./rfc3507">RFC 3507</a>, April 2003.

   [<a id="ref-RFC3986">RFC3986</a>]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              <a href="./rfc3986">RFC 3986</a>, January 2005.

   [<a id="ref-RFC4329">RFC4329</a>]  Hoehrmann, B., "Scripting Media Types", <a href="./rfc4329">RFC 4329</a>,
              April 2006.

   [<a id="ref-RFC4594">RFC4594</a>]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", <a href="./rfc4594">RFC 4594</a>,
              August 2006.








<span class="grey">Chung, et al.                 Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


<span class="h3"><a class="selflink" id="section-15.2" href="#section-15.2">15.2</a>.  Informative References</span>

   [<a id="ref-CableLabs_DOCSIS">CableLabs_DOCSIS</a>]
              CableLabs, "Data-Over-Cable Service Interface
              Specifications", CableLabs Specifications, Various DOCSIS
              Reference Documents, &lt;<a href="http://www.cablelabs.com/specifications/archives/docsis.html">http://www.cablelabs.com/</a>
              <a href="http://www.cablelabs.com/specifications/archives/docsis.html">specifications/archives/docsis.html</a>&gt;.

   [<a id="ref-RFC3360">RFC3360</a>]  Floyd, S., "Inappropriate TCP Resets Considered Harmful",
              <a href="https://www.rfc-editor.org/bcp/bcp60">BCP 60</a>, <a href="./rfc3360">RFC 3360</a>, August 2002.









































<span class="grey">Chung, et al.                 Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6108">RFC 6108</a>            Comcast's Web Notification System      February 2011</span>


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:   <a href="http://www.comcast.com">http://www.comcast.com</a>


   Alex Kasyanov
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US
   EMail: alexander_kasyanov@cable.comcast.com
   URI:   <a href="http://www.comcast.com">http://www.comcast.com</a>


   Jason Livingood
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US
   EMail: jason_livingood@cable.comcast.com
   URI:   <a href="http://www.comcast.com">http://www.comcast.com</a>


   Nirmal Mody
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US
   EMail: nirmal_mody@cable.comcast.com
   URI:   <a href="http://www.comcast.com">http://www.comcast.com</a>


   Brian Van Lieu
   Unaffiliated
   Bethlehem, PA  18018
   US
   EMail: brian@vanlieu.net




Chung, et al.                 Informational                    [Page 24]
</pre>