idnits 2.17.1 draft-livingood-web-notification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2009) is 5304 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2434' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC2915' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 737, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Chung 3 Internet-Draft A. Kasyanov 4 Intended status: Informational J. Livingood 5 Expires: April 11, 2010 N. Mody 6 B. Van Lieu 7 Comcast 8 October 8, 2009 10 Example of an ISP Web Notification System 11 draft-livingood-web-notification-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 11, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 The objective of this document is to describe one method of providing 60 notifications to web browsers being developed by Comcast, a large 61 Internet Service Provider (ISP). Such a notification system can be 62 used by an ISP to provide near-immediate notifications to their 63 users, such as to warn them that their traffic exhibits patterns that 64 are indicative of malware or virus infection, for example. There are 65 many proprietary systems that can perform such notifications on the 66 market today, some of which use inline-based Deep Packet Inspection 67 (DPI) systems. This document describes one example of such a system 68 that does not rely upon DPI systems, and is instead based in open 69 standards and open source systems. While the system described herein 70 is in some ways specific to the DOCSIS networks used by most cable- 71 based broadband ISPs, components and concepts described in this 72 document can generally be applied to many different types of 73 networks. 75 Table of Contents 77 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 78 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. High-Level Design of the System . . . . . . . . . . . . . . . 4 80 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 5 81 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 4.2. Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . 6 83 4.3. ICAP Server . . . . . . . . . . . . . . . . . . . . . . . 6 84 4.4. Messaging Service . . . . . . . . . . . . . . . . . . . . 7 85 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7 86 5.1. Functional Components Described . . . . . . . . . . . . . 7 87 5.2. Functional Diagram . . . . . . . . . . . . . . . . . . . . 9 88 6. High Level Communication Flow . . . . . . . . . . . . . . . . 10 89 7. Communication Between Web Proxy and ICAP Server . . . . . . . 11 90 8. End-to-End Web Notification Flow . . . . . . . . . . . . . . . 13 91 8.1. Step-by-Step Description of the End-to-End Web 92 Notification Flow . . . . . . . . . . . . . . . . . . . . 13 93 8.2. Diagram of the End-to-End Web Notification Flow . . . . . 14 94 9. Example HTTP Headers for a Web Notification . . . . . . . . . 16 95 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 17 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 98 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 99 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 101 14.2. Informative References . . . . . . . . . . . . . . . . . . 19 102 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 20 103 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 106 1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Introduction 114 Internet Service Providers (ISPs) have a need for a system that is 115 capable of communicating with selected customers in a nearly 116 immediate manner. Given the prevalence of the web browser as the 117 predominant client software in use by Internet users, the web browser 118 is an ideal vehicle for providing notifications. This document 119 describes a system being developed by Comcast, a large broadband ISP, 120 to provide notifications to web browsers, which can be used to 121 provide such near-immediate notifications to users. This type of 122 system is designed to provide a non-intrusive, though obvious, 123 notification to a user's web browser. 125 In evaluating potential solutions, most commercially available 126 systems were either proprietary and/or required inline-based Deep 127 Packet Inspection (DPI) systems. However, Comcast and many other 128 ISPs may desire to use a system based on open standards, non- 129 proprietary software, and which does not require the use of DPI. 130 While the system described herein is specific to the Data-Over-Cable 131 Service Interface Specifications (DOCSIS, [CableLabs DOCSIS]) 132 networks used by most cable-based broadband ISPs, components and 133 concepts described in this document can generally be applied to many 134 different types of networks. 136 3. High-Level Design of the System 138 The web notification system design is based on the use of the 139 Internet Content Adaptation Protocol [RFC3507]. The design uses open 140 source applications such as the Squid Web Proxy, the GreasySpoon ICAP 141 server, and Apache Tomcat. The ICAP protocol allows for message 142 transformation or adaptation. An ICAP client passes a HyperText 143 Transport Protocol (HTTP, [RFC2616]) message to an ICAP server for 144 some type of processing. The ICAP Server will in turn respond back 145 to the client with the modified HTTP message containing the 146 notification message. 148 Message modification itself may then be provided via either a HTTP 149 request or HTTP response. However, for the specific system described 150 in this document, only the HTTP response is modified, by using the 151 'respmod' method defined in Section 3.2 of [RFC3507]. 153 4. Design Requirements 155 This section describes all of the requirements taken into 156 consideration for the design of this system. 158 4.1. General 160 REQ1: TCP Port 80: The system should provide notifications via TCP 161 port 80, the well-known port for HTTP traffic. 163 REQ2: Whitelisting: It is possible that the HyperText Markup 164 Language (HTML, [RFC1866]) or JavaScript used for 165 notifications may cause problems for access to a particular 166 website. Therefore, such a system should be capable of using 167 a whitelist of website Uniform Resource Indicators (URIs, 168 [RFC2396]) or Fully Qualified Domain Named (FQDNs, Section 169 5.1 of [RFC1035]) that conflict with the system, to instruct 170 the system to not provide a notifications related to certain 171 sites, in order to reduce any errors or unexpected results. 173 REQ3: Instant Messaging (IM): Some IM clients use TCP port 80 in 174 their communications, often as an alternate port when 175 standard, well-known ports do not work. This system should 176 not conflict with or cause unexpected results for IM clients. 178 REQ4: Handling of Active Sessions: To the extent that a web 179 notification system must temporarily route TCP port 80 180 traffic, in order to provide a notification, previously 181 active TCP port 80 sessions should be maintained. 183 REQ5: No TCP Resets: The use of TCP resets has been widely 184 criticized, both in the Internet community generally as well 185 as in [RFC3360]. As such, except for the case of 186 unintentional errors, the use of TCP resets must not be used. 188 REQ6: Non-Disruptive: The web notification system should not 189 disrupt the end user experience, such as causing significant 190 clients errors. 192 REQ7: Notification Acknowledgement: Once a user responds and 193 acknowledges a notification, the notification should 194 immediately stop, so it is not repeatedly and annoyingly 195 presented, again and again, in a short period of time. 197 REQ8: Non-Modification of Content: Such a system should not 198 significantly alter the content of any website the user is 199 accessing. 201 REQ9: Unexpected Content: The system should transparently handle 202 traffic for which it cannot provide a web notification. 203 Thus, widely varying content should be expected, and all such 204 unexpected traffic should be able to be handled by the system 205 without generating errors or unexpected results. 207 REQ10: No Caching: Web content must not be cached by the system. 209 REQ11: No Advertising Replacement or Insertion: The system must not 210 be used to replace any advertising provided by a website, or 211 insert advertising into websites where none was intended by 212 the owner of a given website. 214 4.2. Web Proxy 216 REQ12: Open-Source Software: The system should use an open source 217 web proxy server, such as Squid. (While it is possible to 218 use any web proxy, the use of open source, and openly 219 documented software is recommended.) 221 REQ13: ICAP Client: The web proxy server should have an integrated 222 ICAP client. 224 REQ14: Access Control: Access to the proxy should be limited 225 exclusively to the IP addresses of users for which 226 notifications are intended, and only for limited periods of 227 time. Furthermore, if a Session Management Broker (SMB) is 228 utilized, as described in Section 5.1 below, then the proxy 229 should restrict access only to the IP of the SMB. 231 4.3. ICAP Server 233 REQ15: Request and Response Support: The system should support both 234 request and response adaptation. 236 REQ16: Consistency: The system must be able to consistently provide 237 a specific notification. 239 REQ17: Multiple Notification Types: The system must be able to 240 provide many different types of notifications. 242 REQ18: Simultaneous Differing Notifications: The system must be able 243 to simultaneously serve multiple notifications, including 244 notifications of varying types, to different users. As a 245 result, User A should be able to get the notification 246 intended specifically for User A, at the same time that User 247 B receives an entirely different notification, which was 248 intended specifically for User B. 250 4.4. Messaging Service 252 REQ19: Messaging Service: The Messaging Service, as described in 253 Section 5.1 below caches the notifications for each specific 254 user. Thus, by caching the notification messages, the system 255 may provide notifications without significantly affecting the 256 web browsing experience of the user. 258 REQ20: Process Acknowledgements: The Messaging Service should 259 process acknowledgements to properly remove entries from the 260 cache and forward acknowledgements to the Messaging Service. 262 REQ21: Ensure Notification Targeting Accuracy: The Messaging Service 263 must ensure that notifications are presented to the intended 264 users. 266 REQ22: Keep Records for Customer Care: The Messaging Service should 267 maintain some type of record that a notification has been 268 presented and/or acknowledged, in case a user inquires with 269 customer care personnel. 271 5. Functional Overview 273 This section defines the various core functional components of the 274 system. These components are then shown in a diagram to describe how 275 the various components are linked and relate to one another. 277 5.1. Functional Components Described 279 It should be noted that when specific software cited is but one 280 example of a possible selection for each component. As the state of 281 the art changes, so too many the best or most appropriate software 282 choices here vary. 284 5.1.A. Web Proxy: A standard web proxy server. The initial version 285 of this system uses the Squid Proxy, an open source 286 application in wide use. 288 5.1.B. ICAP Server: This should be an open source application 289 capable of supporting content adaptation in both request and 290 response modes. The ICAP Server retrieves the notifications 291 from the Messaging service cache when content adaption is 292 needed. The initial version of this system uses GreasySpoon, 293 an open source application. 295 5.1.C. Customer Database: The Customer Database holds the user 296 information including the notifications setup for each user. 297 The database may also hold status of which users were 298 notified and users pending notification. 300 5.1.D. The Messaging Service is a process engine that retrieves 301 specific web notification messages from a catalog of possible 302 notifications. A When a notification for a specific user is 303 not in cache, the process retrieves this information from the 304 Customer Database and populates the cache for a specific 305 period of time. The initial version of this service uses 306 Apache Tomcat, an open source application. 308 5.1.E. Session Management Broker: A Load Balancer (LB) with a 309 customized layer 7 inspection policy was used to 310 differentiate between HTTP and non-HTTP traffic on TCP port 311 80. The LB functions as a full stateful TCP proxy with the 312 ability to forward packets from existing TCP sessions that do 313 not exist in the internal session table. New HTTP sessions 314 are load balanced to a proxy layer either transparently or 315 using source Network Address Translation (NAT [RFC1631]) from 316 the LB, with additional layer 7 inspection as needed. 317 Established TCP sessions not in the LB session table are 318 simply forwarded to the destination transparently via the 319 proxy layer. The initial version of this system uses a 320 Session Management Broker which has been developed internally 321 by Comcast. 323 5.2. Functional Diagram 325 +--------+ +------------+ +----------+ 326 | ICAP | <----> | Messaging | <----> | Customer | 327 | Server | | Service | | Database | 328 +--------+ +------------+ +----------+ 329 ^ 330 | +----------+ 331 | | | 332 | +-------> | Internet | <-------+ 333 | | | | | 334 | | +----------+ | 335 | | ^ | 336 | | | | 337 v v | | 338 +----------+ V v 339 |+--------+| +-------+ +--------+ 340 || ICAP || <----> | SMB | <---> | Access | 341 || Client || +-------+ | Router | 342 |+--------+| +--------+ 343 || SQUID || ^ 344 || Proxy || | 345 |+--------+| | 346 +----------+ | 347 v 348 +----------+ 349 | Network | 350 | Element* | 351 +----------+ 352 ^ 353 | 354 | 355 v 356 +------+ 357 | PC | 358 +------+ 360 * An access network element, such as a Cable Modem Termination 361 System (CMTS). 363 Figure 1: Web Notification System - Functional Components 365 6. High Level Communication Flow 367 6.A. Setup Differentiated Services (DiffServ): Using DiffServe 368 [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] 369 [RFC4594], set a policy to direct TCP port 80 traffic to the 370 web notification system's web proxy. 372 6.B. Session Management: TCP port 80 Packets are routed to a load 373 balancer where the load balancer then distinguishes new TCP 374 port 80 sessions as HTTP or non-HTTP. For HTTP sessions, the 375 load balancer forwards to the proxy. For non-HTTP traffic such 376 as instant messaging (IM), the load balancer either forwards to 377 a TCP proxy layer for handling or operates as a full TCP proxy 378 for non-HTTP sessions and forwards to the destination. Pre- 379 established TCP sessions on port 80 are identified by the load 380 balancer and forwarded with no impact. 382 6.C. Web Proxy Forwards Request: The web proxy forwards the HTTP 383 request on to the destination site, as a web proxy normally 384 would do. 386 6.D. On Response, Send Message to ICAP Server: When the HTTP 387 response is received, the web proxy sends a message to the ICAP 388 server for the web notification. 390 6.E. Messaging Service: Messaging Service should respond with 391 appropriate notification content or null response if 392 notification is not cached. 394 6.F. ICAP Server Responds: The ICAP server responds and furnishes 395 the appropriate content of the appropriate web notification to 396 the web proxy. 398 6.G. Web Proxy Sends Response: The web proxy then sends a "200 OK" 399 HTTP message to the original web client, containing the 400 originally requested content and the web notification. 402 6.H. User Response: The user observes the web notification, and 403 clicks an appropriate option, such as: OK/acknowledged, snooze/ 404 remind me later, etc. 406 6.I. More Information: Depending upon the notification, the user may 407 be provided with more information. Using the example of a web 408 notification to a user explaining that it is highly likely that 409 they have been infected with a virus or malware, the user may 410 click an acknowledgement that indicates that clicking that will 411 take them to a page with information about virus/malware 412 scanning and remediation. 414 6.J. Turn Down DiffServ: Once the notification transaction has 415 completed, remove any special DiffServ settings. 417 7. Communication Between Web Proxy and ICAP Server 418 +------------+ 419 | | 420 | www URL | 421 | | 422 +------------+ 423 ^ | 424 | | 425 (2)| |(3) 426 | | 427 | v 428 +--------+ (4) +--------+ (4) +--------+ 429 | |------------>| |------------>| | 430 | | | | | | 431 | | (5) | | (5) | | 432 | |<------------| |<------------| | 433 | Proxy | | ICAP | | ICAP | 434 | Module | (6) | Client | (6) | Server | 435 | |------------>| |------------>| | 436 | | | | | | 437 | | (7) | | (7) | | 438 | |<------------| |<------------| | 439 +--------+ +--------+ +--------+ 440 ^ | 441 | | 442 (1)| |(8) 443 | | 444 | v 445 +------------+ (9) +------------+ 446 | |----------------------------->| | 447 | | | | 448 | Browser | | Web Server | 449 | | (10) | | 450 | |<-----------------------------| | 451 +------------+ +------------+ 453 (1) - HTTP GET (TCP 80) 454 (2) - Proxy HTTP GET (TCP 80) 455 (3) - HTTP 200 OK w/ Response 456 (4) - ICAP RESPMOD 457 (5) - ICAP 200 OK 458 (6) - TCP Stream - Encapsulate Header 459 (7) - ICAP 200 OK Insert Message 460 (8) - HTTP 200 OK w/ Response + Message Frame 461 (9) - HTTP GET for Message 462 (10) - HTTP 200 w/ Message Content 463 Figure 2: Communication Between Web Proxy and ICAP Server 465 8. End-to-End Web Notification Flow 467 8.1. Step-by-Step Description of the End-to-End Web Notification Flow 469 Policy Based Routing 471 1. TCP port 80 packets from the users that need to be notified maybe 472 routed to the web proxy via policy based routing. 474 2. Packets are forwarded to the Load Balancer, which establishes a 475 session with the web proxy and routes the packets to the proxy. 477 Web Proxy 479 1. User's HTTP request is directed to the web proxy. 481 2. Web proxy received HTTP traffic and retrieves content from the 482 requested web site. 484 3. Web proxy receives response and forwards it to the ICAP server 485 for response adaptation. 487 4. The ICAP Server checks the HTTP content in order to determine 488 whether notification message can be inserted. 490 5. The ICAP Server initiates a HTTP Post to the Messaging Service 491 cache process with the IP address of the user. 493 6. If a notification message for the user exists then the 494 appropriate notification is cached on the Messaging Service. The 495 Messaging Service then returns the appropriate HTML content to 496 the ICAP Server. 498 7. 500 A. Once the notification message is retrieved from Messaging 501 Service cache the ICAP server may insert the notification 502 message in the HTTP response body without altering or 503 modifying the original content of the HTTP 200 OK response. 505 B. The ICAP Server then sends the response back to the web 506 proxy, which in turn forwards the HTTP 200 OK response back 507 to the browser. 509 8. If the user IP is not found or provisioned for a notification 510 message, then the ICAP Server should return a '204 No 511 modifications needed' response to the ICAP Client as defined in 512 section 4.3.3 of [RFC3507]. As a result, the user will not 513 receive any web notification message. 515 9. The user observes the web notification, and clicks an appropriate 516 option, such as: OK/acknowledged, snooze/ remind me later, etc. 518 8.2. Diagram of the End-to-End Web Notification Flow 520 This flow shows the communications flow from the web client, through 521 the entire system. 523 ICAP ICAP Message Customer 524 Browser Proxy Client Server Service Internet DB 525 | HTTP | | | | | | 526 | GET | | Proxy | | | | 527 +------->| | Request | | | | 528 | +---------|---------|--------|------->| | 529 | | | | 200 OK | | | 530 | |<--------|---------|--------|--------+ | 531 | | ICAP | | | | | 532 | | RESPMOD | ICAP | | | | 533 | +-------->| RESPMOD | | | | 534 | | +-------->| | | | 535 | | | | Check | | | 536 | | | | Cache | | | 537 | | | | for IP | | Cache | 538 | | | | Match | | Miss | 539 | | | +------->| | Request| 540 | | | | | | Type | 541 | | | | +--------|------->| 542 | | | Cache | | | | 543 | | | Miss | | | | 544 | | | No | | | | 545 | | | Insert | | | | 546 | |<--------|---------|--------+ |Type | 547 | 200 OK | | | | |Returned| 548 | No | | | |<-------|--------+ 549 | Insert | | | | | | 550 |<-------+ | | | | | 551 | | | Cache | | | | 552 | | | Hit | | | | 553 | | | Insert | | | | 554 | 200 OK |<--------|---------|--------+ | | 555 | Insert | | | | | | 556 |<-------+ | | | | | 557 | | | HTTP | | | | 558 | | | GET to | | | | 559 | | | Content | | | | 560 | | | Portal | | | | 561 +--------|---------|---------|--------|------->| | 562 | | | 200 OK | | | | 563 | | | w/ | | | | 564 | | | Notify | | | | 565 |<-------|---------|---------|--------|--------+ | 566 | | | | | | | 568 Figure 3: End-to-End Web Notification Flow 570 9. Example HTTP Headers for a Web Notification 572 Web-Browser HTTP Headers 574 ---------------------------------------------- 575 1. HTTP Get Request to www.example.com 576 ---------------------------------------------- 578 http://www.example.com/ 580 GET / HTTP/1.1 581 Host: www.example.com 582 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) 583 Gecko/20080404 Firefox/2.0.0.14 584 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 585 Accept-Language: en-us,en;q=0.5 586 Accept-Encoding: gzip,deflate 587 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 588 Keep-Alive: 300 589 Connection: keep-alive 590 Pragma: no-cache 592 ---------------------------------------------- 593 2. Response from www.example.com via PROXY 594 ---------------------------------------------- 596 HTTP/1.x 200 OK 597 Date: Thu, 08 May 2008 16:26:29 GMT 598 Server: Apache/2.2.3 (CentOS) 599 Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT 600 Etag: "b80f4-1b6-80bfd280" 601 Accept-Ranges: bytes 602 Content-Length: 438 603 Connection: close 604 Content-Type: text/html; charset=UTF-8 605 Age: 18 606 X-Cache: HIT from localhost.localdomain 607 Via: 1.0 localhost.localdomain (squid/3.0.STABLE5) 608 Proxy-Connection: keep-alive 610 ----------------------------------------------------------- 611 3. Example of JavaScript containing Notification Insertion 612 ----------------------------------------------------------- 614 616 627 642 ---------------------------------------------- 644 Figure 4 646 10. Deployment Considerations 648 The components of such a web notification system should be 649 distributed throughout a network, close to users. When distributed 650 in such a manner, this ensures that performance remains acceptable 651 across a wide geography. It is also a best practice that a HTTP- 652 aware load balancer is used in each datacenter where servers are 653 located, so that traffic can be spread across N+1 servers and the 654 system can be easily scaled out. 656 11. Security Considerations 658 There are no security considerations have yet been added document. 659 Will be a focus of a future update. 661 12. IANA Considerations 663 There are no IANA considerations in this document. 665 NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO 666 PUBLICATION. 668 13. Acknowledgements 670 The authors will probably wish to acknowledge someone's review or 671 contribution at some point, which is the purpose of this section. :-) 673 14. References 675 14.1. Normative References 677 [RFC1035] Mockapetris, P., "Domain names - implementation and 678 specification", STD 13, RFC 1035, November 1987. 680 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 681 Translator (NAT)", RFC 1631, May 1994. 683 [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup 684 Language - 2.0", RFC 1866, November 1995. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 690 Resource Identifiers (URI): Generic Syntax", RFC 2396, 691 August 1998. 693 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 694 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 695 October 1998. 697 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 698 "Definition of the Differentiated Services Field (DS 699 Field) in the IPv4 and IPv6 Headers", RFC 2474, 700 December 1998. 702 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 703 and W. Weiss, "An Architecture for Differentiated 704 Services", RFC 2475, December 1998. 706 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 707 "Assured Forwarding PHB Group", RFC 2597, June 1999. 709 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 710 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 711 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 713 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 714 specifying the location of services (DNS SRV)", RFC 2782, 715 February 2000. 717 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 718 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 720 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 721 "Per Hop Behavior Identification Codes", RFC 3140, 722 June 2001. 724 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 725 J., Courtney, W., Davari, S., Firoiu, V., and D. 726 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 727 Behavior)", RFC 3246, March 2002. 729 [RFC3260] Grossman, D., "New Terminology and Clarifications for 730 Diffserv", RFC 3260, April 2002. 732 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 733 A., Peterson, J., Sparks, R., Handley, M., and E. 734 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 735 June 2002. 737 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 738 Protocol (SIP): Locating SIP Servers", RFC 3263, 739 June 2002. 741 [RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation 742 Protocol (ICAP)", RFC 3507, April 2003. 744 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 745 Guidelines for DiffServ Service Classes", RFC 4594, 746 August 2006. 748 14.2. Informative References 750 [CableLabs DOCSIS] 751 CableLabs, "Data-Over-Cable Service Interface 752 Specifications", CableLabs Specifications Various DOCSIS 753 Reference Documents, . 756 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 757 BCP 60, RFC 3360, August 2002. 759 Appendix A. Document Change Log 761 [RFC Editor: This section is to be removed before publication] 763 -00 version: 765 o -00 published 767 Appendix B. Open Issues 769 1 - Abstract: change "being developed by Comcast" to "used by 770 Comcast" depending upon status of field testing 772 2 - Intro: change "system being developed by Comcast" to "system used 773 by Comcast" depending upon status of field testing 775 3 - Need an RFC reference for JavaScript, upon first use? 777 4 - Add an informative reference to 778 draft-oreirdan-mody-bot-remediation-03 780 5 - Add content to Security Considerations 782 Authors' Addresses 784 Chae Chung 785 Comcast Cable Communications 786 One Comcast Center 787 1701 John F. Kennedy Boulevard 788 Philadelphia, PA 19103 789 US 791 Email: chae_chung@cable.comcast.com 792 URI: http://www.comcast.com 793 Alex Kasyanov 794 Comcast Cable Communications 795 One Comcast Center 796 1701 John F. Kennedy Boulevard 797 Philadelphia, PA 19103 798 US 800 Email: alexander_kasyanov@cable.comcast.com 801 URI: http://www.comcast.com 803 Jason Livingood 804 Comcast Cable Communications 805 One Comcast Center 806 1701 John F. Kennedy Boulevard 807 Philadelphia, PA 19103 808 US 810 Email: jason_livingood@cable.comcast.com 811 URI: http://www.comcast.com 813 Nirmal Mody 814 Comcast Cable Communications 815 One Comcast Center 816 1701 John F. Kennedy Boulevard 817 Philadelphia, PA 19103 818 US 820 Email: nirmal_mody@cable.comcast.com 821 URI: http://www.comcast.com 823 Brian Van Lieu 824 Comcast Cable Communications 825 One Comcast Center 826 1701 John F. Kennedy Boulevard 827 Philadelphia, PA 19103 828 US 830 Email: brian_vanlieu@cable.comcast.com 831 URI: http://www.comcast.com