idnits 2.17.1 draft-livingood-web-notification-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 29, 2010) is 5134 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 730, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC2915' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 774, 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) ** Obsolete normative reference: RFC 4329 (Obsoleted by RFC 9239) Summary: 8 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: September 30, 2010 N. Mody 6 Comcast 7 B. Van Lieu 8 Unaffiliated 9 March 29, 2010 11 Example of an ISP Web Notification System 12 draft-livingood-web-notification-05 14 Abstract 16 The objective of this document is to describe one method of providing 17 notifications to web browsers that has been deployed by Comcast, an 18 Internet Service Provider (ISP). Such a notification system can be 19 used by an ISP to provide near-immediate notifications to their 20 users, such as to warn them that their traffic exhibits patterns that 21 are indicative of malware or virus infection, for example. There are 22 other proprietary systems that can perform such notifications but 23 these systems utilize Deep Packet Inspection (DPI) technology. This 24 document describes one example of a system that does not rely upon 25 DPI, and is instead based in open standards and open source 26 applications. While the system described herein is in some ways 27 specific to the Data-Over-Cable Service Interface Specifications 28 (DOCSIS) networks used by most cable-based broadband ISPs, components 29 and concepts described in this document could generally be applied to 30 many different types of networks. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on September 30, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 85 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. High-Level Design of the System . . . . . . . . . . . . . . . 4 87 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 5 88 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 4.2. Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . 6 90 4.3. ICAP Server . . . . . . . . . . . . . . . . . . . . . . . 6 91 4.4. Messaging Service . . . . . . . . . . . . . . . . . . . . 7 92 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7 93 5.1. Functional Components Described . . . . . . . . . . . . . 7 94 5.2. Functional Diagram . . . . . . . . . . . . . . . . . . . . 9 95 6. High Level Communication Flow . . . . . . . . . . . . . . . . 9 96 7. Communication Between Web Proxy and ICAP Server . . . . . . . 11 97 8. End-to-End Web Notification Flow . . . . . . . . . . . . . . . 11 98 8.1. Step-by-Step Description of the End-to-End Web 99 Notification Flow . . . . . . . . . . . . . . . . . . . . 12 100 8.2. Diagram of the End-to-End Web Notification Flow . . . . . 13 101 9. Example HTTP Headers and JavaScript for a Web Notification . . 14 102 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 105 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 106 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 108 14.2. Informative References . . . . . . . . . . . . . . . . . . 19 109 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 19 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 112 1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Introduction 120 Internet Service Providers (ISPs) have a need for a system that is 121 capable of communicating with customers in a nearly immediate manner, 122 to convey critical service notices such as warnings concerning likely 123 malware infection. Given the prevalence of the web browser as the 124 predominant client software in use by Internet users, the web browser 125 is an ideal vehicle for providing notifications. This document 126 describes a system that has been deployed by Comcast, a broadband 127 ISP, to provide near-immediate notifications to web browsers. This 128 type of system is also designed to provide a non-intrusive, though 129 obvious, notification to a user's web browser. 131 In evaluating potential solutions, most commercially available 132 systems were either proprietary and/or utilized inline-based Deep 133 Packet Inspection (DPI) technology. Other ISPs may also desire to 134 use a system based on open standards, non-proprietary software, and 135 which does not require the use of DPI, which is one of the 136 motivations for producing this document. While the system described 137 herein is specific to the Data-Over-Cable Service Interface 138 Specifications (DOCSIS, [CableLabs DOCSIS]) networks used by most 139 cable-based broadband ISPs, components and concepts described in this 140 document can generally be applied to many different types of 141 networks. 143 3. High-Level Design of the System 145 The web notification system design is based on the use of the 146 Internet Content Adaptation Protocol [RFC3507]. The design uses open 147 source applications such as Squid Web Proxy, GreasySpoon ICAP server, 148 and Apache Tomcat. The ICAP protocol allows for message 149 transformation or adaptation. An ICAP client passes a HyperText 150 Transport Protocol (HTTP, [RFC2616]) response to an ICAP server for 151 content adaption. The ICAP Server in turn responds back to the 152 client with the HTTP response containing the notification message. 154 Message modification itself may then be provided via either a HTTP 155 request or HTTP response. However, for the specific system described 156 in this document, only the HTTP response is modified, by using the 157 'respmod' method defined in Section 3.2 of [RFC3507]. 159 4. Design Requirements 161 This section describes all of the requirements taken into 162 consideration for the design of this system. 164 4.1. General 166 REQ1: TCP Port 80: The system should provide notifications via TCP 167 port 80, the well-known port for HTTP traffic. 169 REQ2: Whitelisting: It is possible that the HyperText Markup 170 Language (HTML, [RFC1866]) or JavaScript [RFC4329] used for 171 notifications may cause problems while accessing a particular 172 website. Therefore, such a system should be capable of using 173 a whitelist of website Uniform Resource Indicators (URIs, 174 [RFC2396]) or Fully Qualified Domain Named (FQDNs, Section 175 5.1 of [RFC1035]) that conflict with the system, to instruct 176 the system to not provide a notifications related to certain 177 sites, in order to reduce any errors or unexpected results. 179 REQ3: Instant Messaging (IM): Some IM clients use TCP port 80 in 180 their communications, often as an alternate port when 181 standard, well-known ports do not work. This system should 182 not conflict with or cause unexpected results for IM clients 183 (or any other client types). 185 REQ4: Handling of Active Sessions: To the extent that a web 186 notification system must temporarily route TCP port 80 187 traffic in order to provide a notification, previously 188 established TCP port 80 sessions should not be disrupted and 189 should be routed to the proxy layer. 191 REQ5: No TCP Resets: The use of TCP resets has been widely 192 criticized, both in the Internet community generally as well 193 as in [RFC3360]. As such, except for the case of 194 unintentional errors, the use of TCP resets must be avoided. 196 REQ6: Non-Disruptive: The web notification system should not 197 disrupt the end user experience, such as causing significant 198 clients errors. 200 REQ7: Notification Acknowledgement: Once a user responds and 201 acknowledges a notification, the notification should 202 immediately stop. 204 REQ8: Non-Modification of Content: Such a system should not 205 significantly alter the content of the HTTP response from any 206 website the user is accessing. 208 REQ9: Unexpected Content: The system should transparently handle 209 traffic for which it cannot provide a web notification. 210 Thus, widely varying content should be expected, and all such 211 unexpected traffic should be able to be handled by the system 212 without generating errors or unexpected results. 214 REQ10: No Caching: Web content must not be cached by the system. 216 REQ11: No Advertising Replacement or Insertion: The system must not 217 be used to replace any advertising provided by a website, or 218 insert advertising into websites where none was intended by 219 the owner of a given website. 221 4.2. Web Proxy 223 REQ12: Open-Source Software: The system should use an open source 224 web proxy server, such as Squid. (While it is possible to 225 use any web proxy, the use of open source, and openly 226 documented software is recommended.) 228 REQ13: ICAP Client: The web proxy server should have an integrated 229 ICAP client. 231 REQ14: Access Control: Access to the proxy should be limited 232 exclusively to the IP addresses of users for which 233 notifications are intended, and only for limited periods of 234 time. Furthermore, if a Session Management Broker (SMB) is 235 utilized, as described in Section 5.1 below, then the proxy 236 should restrict access only to the address of the SMB. 238 4.3. ICAP Server 240 REQ15: Request and Response Support: The system should support both 241 request and response adaptation. 243 REQ16: Consistency: The system must be able to consistently provide 244 a specific notification. 246 REQ17: Multiple Notification Types: The system must be able to 247 provide many different types of notifications. 249 REQ18: Simultaneous Differing Notifications: The system must be able 250 to simultaneously serve multiple notifications, including 251 notifications of varying types, to different users. As a 252 result, User A should be able to get the notification 253 intended specifically for User A, at the same time that User 254 B receives an entirely different notification, which was 255 intended specifically for User B. 257 4.4. Messaging Service 259 REQ19: Messaging Service: The Messaging Service, as described in 260 Section 5.1 below caches the notifications for each specific 261 user. Thus, by caching the notification messages, the system 262 may provide notifications without significantly affecting the 263 web browsing experience of the user. 265 REQ20: Process Acknowledgements: The Messaging Service should 266 process acknowledgements to properly remove entries from the 267 cache and forward acknowledgements to the Messaging Service. 269 REQ21: Ensure Notification Targeting Accuracy: The Messaging Service 270 must ensure that notifications are presented to the intended 271 users. 273 REQ22: Keep Records for Customer Support: The Messaging Service 274 should maintain some type of record that a notification has 275 been presented and/or acknowledged, in case a user inquires 276 with customer support personnel. 278 5. Functional Overview 280 This section defines the various core functional components of the 281 system. These components are then shown in a diagram to describe how 282 the various components are linked and relate to one another. 284 5.1. Functional Components Described 286 Please note that when a specific software package is cited below, it 287 is but one example of a possible selection for each component and 288 should not be considered the only possible option. Though this 289 accurately list describes the initial software packages used by the 290 system described herein, those selections are subject to change for a 291 variety of reasons. 293 5.1.A. Web Proxy: The system uses Squid Proxy, an open source web 294 proxy application in wide use, and one which supports an 295 integrated ICAP client. 297 5.1.B. ICAP Server: This should be an open source application 298 capable of supporting content adaptation in both request and 299 response modes. The ICAP Server retrieves the notifications 300 from the Messaging service cache when content adaption is 301 needed. The initial version of this system uses GreasySpoon, 302 an open source application. 304 5.1.C. Customer Database: The Customer Database holds the user 305 information including the notifications setup for each user. 306 The database may also hold status of which users were 307 notified and users pending notification. 309 5.1.D. Messaging Service: This is a process engine that retrieves 310 specific web notification messages from a catalog of possible 311 notifications. When a notification for a specific user is 312 not in cache, the process retrieves this information from the 313 Customer Database and populates the cache for a specific 314 period of time. The initial version of this service uses 315 Apache Tomcat, an open source application. 317 5.1.E. Session Management Broker: A Load Balancer (LB) with a 318 customized layer 7 inspection policy is used to differentiate 319 between HTTP and non-HTTP traffic on TCP port 80. The SMB 320 functions as a full stateful TCP proxy with the ability to 321 forward packets from existing TCP sessions that do not exist 322 in the internal session table. New HTTP sessions are load 323 balanced to the web proxy layer either transparently or using 324 source Network Address Translation (NAT [RFC1631]) from the 325 SMB, with additional layer 7 inspection as needed. Non-HTTP 326 traffic for established TCP sessions not in the SMB session 327 table is simply forwarded to the destination transparently 328 via the TCP proxy layer. 330 5.2. Functional Diagram 332 +--------+ +------------+ +----------+ 333 | ICAP | <----> | Messaging | <----> | Customer | 334 | Server | | Service | | Database | 335 +--------+ +------------+ +----------+ 336 ^ 337 | +----------+ 338 | | | 339 | +-------> | Internet | <-------+ 340 | | | | | 341 | | +----------+ | 342 | | ^ | 343 v v | | 344 +----------+ v v 345 |+--------+| +-------+ +--------+ 346 || ICAP || <----> | SMB | <---> | Access | 347 || Client || +-------+ | Router | 348 |+--------+| +--------+ 349 || SQUID || ^ 350 || Proxy || | 351 |+--------+| v 352 +----------+ +----------+ 353 | Network | 354 | Element* | 355 +----------+ 356 ^ 357 | 358 v 359 +------+ 360 | PC | 361 +------+ 363 * An access network element, such as a Cable Modem Termination 364 System (CMTS). 366 Figure 1: Web Notification System - Functional Components 368 6. High Level Communication Flow 369 6.A. Setup Differentiated Services (DiffServ): Using DiffServe 370 [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] 371 [RFC4594], set a policy to direct TCP port 80 traffic to the 372 web notification system's web proxy. 374 6.B. Session Management: TCP port 80 packets are routed to a Session 375 Management Broker which distinguishes between HTTP or non-HTTP 376 traffic and between new and existing sessions. HTTP packets 377 are forwarded to the web proxy by the SMB. Non-HTTP packets 378 such as instant messaging (IM) traffic are forwarded to a TCP 379 proxy layer for routing to destination or the SMB operates as 380 the full TCP proxy and forwards the non-HTTP packets to the 381 destination. Pre-established TCP sessions on port 80 are 382 identified by the SMB and forwarded with no impact. 384 6.C. Web Proxy Forwards Request: The web proxy forwards the HTTP 385 request on to the destination site, a web server, as a web 386 proxy normally would do. 388 6.D. On Response, Send Message to ICAP Server: When the HTTP 389 response is received from the destination server, the web proxy 390 sends a message to the ICAP server for the web notification. 392 6.E. Messaging Service: The Messaging Service should respond with 393 appropriate notification content or null response if 394 notification is not cached. 396 6.F. ICAP Server Responds: The ICAP server responds and furnishes 397 the appropriate content for the web notification to the web 398 proxy. 400 6.G. Web Proxy Sends Response: The web proxy then forwards the HTTP 401 response to the client web browser containing the web 402 notification. 404 6.H. User Response: The user observes the web notification, and 405 clicks an appropriate option, such as: OK/acknowledged, snooze/ 406 remind me later, etc. 408 6.I. More Information: Depending upon the notification, the user may 409 be provided with more information. Using the example of a web 410 notification to a user explaining that it is highly likely that 411 they have been infected with a virus or malware, the user may 412 click an acknowledgement that indicates that clicking that will 413 take them to a page with information about virus/malware 414 scanning and remediation. 416 6.J. Turn Down DiffServ: Once the notification transaction has 417 completed, remove any special DiffServ settings. 419 7. Communication Between Web Proxy and ICAP Server 421 +------------+ 422 | www URI | 423 +------------+ 424 ^ | 425 (2)| |(3) 426 | v 427 +--------+ (4) +--------+ (4) +--------+ 428 | |------------>| |------------>| | 429 | | (5) | | (5) | | 430 | Proxy |<------------| ICAP |<------------| ICAP | 431 | Module | (6) | Client | (6) | Server | 432 | |------------>| |------------>| | 433 | | (7) | | (7) | | 434 | |<------------| |<------------| | 435 +--------+ +--------+ +--------+ 436 ^ | 437 (1)| |(8) 438 | v 439 +------------+ (9) +------------+ 440 | |----------------------------->| | 441 | Browser | (10) | Web Server | 442 | |<-----------------------------| | 443 +------------+ +------------+ 445 (1) - HTTP GET (TCP 80) 446 (2) - Proxy HTTP GET (TCP 80) 447 (3) - HTTP 200 OK w/ Response 448 (4) - ICAP RESPMOD 449 (5) - ICAP 200 OK 450 (6) - TCP Stream - Encapsulate Header 451 (7) - ICAP 200 OK Insert Message 452 (8) - HTTP 200 OK w/ Response + Message Frame 453 (9) - HTTP GET for Message 454 (10) - HTTP 200 w/ Message Content 456 Figure 2: Communication Between Web Proxy and ICAP Server 458 8. End-to-End Web Notification Flow 459 8.1. Step-by-Step Description of the End-to-End Web Notification Flow 461 8.1.1. Policy-Based Routing 463 1. TCP port 80 packets from the user that needs to be notified may 464 be routed to the Web Proxy via policy based routing. 466 2. Packets are forwarded to the Session Management Broker, which 467 establishes a session with the Web Proxy and routes the packets 468 to the Web Proxy. 470 8.1.2. Web Proxy 472 1. The user's HTTP request is directed to the Web Proxy. 474 2. The Web Proxy receives HTTP traffic and retrieves content from 475 the requested web site. 477 3. The Web Proxy receives the response and forwards it to the ICAP 478 Server for response adaptation. 480 4. The ICAP Server checks the HTTP content in order to determine 481 whether notification message can be inserted. 483 5. The ICAP Server initiates a request to the Messaging Service 484 cache process with the IP address of the user. 486 6. If a notification message for the user exists then the 487 appropriate notification is cached on the Messaging Service. 488 The Messaging Service then returns the appropriate notification 489 content to the ICAP Server. 491 7. Once the notification message is retrieved from Messaging 492 Service cache the ICAP server may insert the notification 493 message in the HTTP response body without altering or modifying 494 the original content of the HTTP response. 496 8. The ICAP Server then sends the response back to the Web Proxy, 497 which in turn forwards the HTTP response back to the browser. 499 9. If the user's IP address is not found or provisioned for a 500 notification message, then the ICAP Server should return a '204 501 No Modifications Needed' response to the ICAP Client as defined 502 in section 4.3.3 of [RFC3507]. As a result, the user will not 503 receive any web notification message. 505 10. The user observes the web notification, and clicks an 506 appropriate option, such as: OK/acknowledged, snooze/ remind me 507 later, etc. 509 8.2. Diagram of the End-to-End Web Notification Flow 511 The two figures below show the communications flow from the Web 512 Browser, through the Web Notification System. 514 The first figure below illustrates what occurs when a notification 515 request cannot be inserted because the notification type for the 516 user's IP address is not cached in the Messaging Service. 518 ICAP ICAP Message Customer 519 Browser Proxy Client Server Service Internet DB 520 | HTTP | | | | | | 521 | GET | Proxy | | | | | 522 +------->| Request | | | | | 523 | +---------|---------|--------|------->| | 524 | | | | | 200 OK | | 525 | |<--------|---------|--------|--------+ | 526 | | ICAP | | | | | 527 | | RESPMOD | ICAP | | | | 528 | +-------->| RESPMOD | Check | | | 529 | | +-------->| Cache | | | 530 | | | | for IP | | | 531 | | | | Match | | | 532 | | | +------->| | | 533 | | | | Cache | | | 534 | | | | Miss | | | 535 | | | |<-------+ Request| | 536 | | | 204 No | | Type | | 537 | | | Modif. | +--------|------->| 538 | | | Needed | | | | 539 | | No |<--------+ | | Type | 540 | | Insert | | | |Returned| 541 | 200 OK |<--------+ | |<-------|--------+ 542 | w/o | | | | | | 543 | Insert | | | | | | 544 |<-------+ | | | | | 545 | | | | | | | 547 Figure 3: End-to-End Web Notification Flow - With Cache Miss 549 The figure below illustrates what occurs when a notification request 550 for the user's IP address is cached in the Messaging Service. 552 ICAP ICAP Message Customer 553 Browser Proxy Client Server Service Internet DB 554 | HTTP | | | | | | 555 | GET | Proxy | | | | | 556 +------->| Request | | | | | 557 | +---------|---------|--------|------->| | 558 | | | | | 200 OK | | 559 | |<--------|---------|--------|--------+ | 560 | | ICAP | | | | | 561 | | RESPMOD | ICAP | | | | 562 | +-------->| RESPMOD | Check | | | 563 | | +-------->| Cache | | | 564 | | | | for IP | | | 565 | | | | Match | | | 566 | | | +------->| | | 567 | | | | Cache | | | 568 | | | | Hit | | | 569 | | | Insert |<-------+ | | 570 | | Return | Type | | | | 571 | | 200 OK |<--------+ | | | 572 | | with | | | | | 573 | | Insert | | | | | 574 | 200 OK |<--------+ | | | | 575 | w/ | | | | | | 576 | Notify | | | | | | 577 |<-------+ | | | | | 578 | | | | | | | 580 Figure 4: End-to-End Web Notification Flow - With Cache Hit 582 9. Example HTTP Headers and JavaScript for a Web Notification 584 The figure below shows an example of a normal HTTP GET request from 585 the user's web browser to www.example.com, a web server on the 586 Internet. 588 ------------------------------------------------------------------------ 589 1. HTTP Get Request to www.example.com 590 ------------------------------------------------------------------------ 591 http://www.example.com/ 593 GET / HTTP/1.1 594 Host: www.example.com 595 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) 596 Gecko/20080404 Firefox/2.0.0.14 597 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 598 Accept-Language: en-us,en;q=0.5 599 Accept-Encoding: gzip,deflate 600 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 601 Keep-Alive: 300 602 Connection: keep-alive 603 Pragma: no-cache 604 ------------------------------------------------------------------------ 606 Figure 5: Example HTTP Headers for a Web Notification - HTTP Get 608 In the figure below, the traffic is routed via the Web Proxy, which 609 communicates with the ICAP Server and returns the response from 610 www.example.com. In this case that response is a 200 OK, with the 611 desired notification message inserted. 613 ------------------------------------------------------------------------ 614 2. Response from www.example.com via PROXY 615 ------------------------------------------------------------------------ 616 HTTP/1.x 200 OK 617 Date: Thu, 08 May 2008 16:26:29 GMT 618 Server: Apache/2.2.3 (CentOS) 619 Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT 620 Etag: "b80f4-1b6-80bfd280" 621 Accept-Ranges: bytes 622 Content-Length: 438 623 Connection: close 624 Content-Type: text/html; charset=UTF-8 625 Age: 18 626 X-Cache: HIT from localhost.localdomain 627 Via: 1.0 localhost.localdomain (squid/3.0.STABLE5) 628 Proxy-Connection: keep-alive 629 ------------------------------------------------------------------------ 631 Figure 6: Example HTTP Headers for a Web Notification - HTTP Response 633 The figure below shows an example of the web notification content 634 inserted in the 200 OK response, in this example JavaScript code. 636 ------------------------------------------------------------------------ 637 3. Example of JavaScript containing Notification Insertion 638 ------------------------------------------------------------------------ 639 641 652 666 ------------------------------------------------------------------------ 668 Figure 7: Example JavaScript Used in a Web Notification 670 10. Deployment Considerations 672 The components of the web notification system should be distributed 673 throughout the network and close to end users. This ensures that the 674 routing performance and the user's web browsing experience remains 675 acceptable. It is also recommended that a HTTP-aware load balancer 676 is used in each datacenter where servers are located, so that traffic 677 can be spread across N+1 servers and the system can be easily scaled 678 out. 680 11. Security Considerations 682 This web notification system was conceived in order to provide an 683 additional method of notifying ISP customers that their computer was 684 infected with malware. Depending upon the nature of the alert 685 contained in the web notification, such as the malware alert, users 686 could fear that it is some kind of phishing attack. As a result, 687 care should be taken with the text and any links contained in the web 688 notification itself. For example, the ISP may find it best to 689 provide a general URI or a telephone number. In contrast to that, 690 the ISP should NOT ask for login credentials or for someone to follow 691 a link in the web notification in order to change their password 692 since these are common phishing techniques. Finally, care should be 693 taken to provide confidence that the web notification is valid and 694 from a trusted party, and/or that the user has an alternate method of 695 checking the validity of the web notification. 697 12. IANA Considerations 699 There are no IANA considerations in this document. 701 NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO 702 PUBLICATION. 704 13. Acknowledgements 706 The authors wish to thank Alissa Cooper for her review of and 707 comments on the document, as well as others who reviewed the 708 document. 710 14. References 712 14.1. Normative References 714 [RFC1035] Mockapetris, P., "Domain names - implementation and 715 specification", STD 13, RFC 1035, November 1987. 717 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 718 Translator (NAT)", RFC 1631, May 1994. 720 [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup 721 Language - 2.0", RFC 1866, November 1995. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 727 Resource Identifiers (URI): Generic Syntax", RFC 2396, 728 August 1998. 730 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 731 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 732 October 1998. 734 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 735 "Definition of the Differentiated Services Field (DS 736 Field) in the IPv4 and IPv6 Headers", RFC 2474, 737 December 1998. 739 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 740 and W. Weiss, "An Architecture for Differentiated 741 Services", RFC 2475, December 1998. 743 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 744 "Assured Forwarding PHB Group", RFC 2597, June 1999. 746 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 747 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 748 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 750 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 751 specifying the location of services (DNS SRV)", RFC 2782, 752 February 2000. 754 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 755 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 757 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 758 "Per Hop Behavior Identification Codes", RFC 3140, 759 June 2001. 761 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 762 J., Courtney, W., Davari, S., Firoiu, V., and D. 763 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 764 Behavior)", RFC 3246, March 2002. 766 [RFC3260] Grossman, D., "New Terminology and Clarifications for 767 Diffserv", RFC 3260, April 2002. 769 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 770 A., Peterson, J., Sparks, R., Handley, M., and E. 771 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 772 June 2002. 774 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 775 Protocol (SIP): Locating SIP Servers", RFC 3263, 776 June 2002. 778 [RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation 779 Protocol (ICAP)", RFC 3507, April 2003. 781 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 782 April 2006. 784 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 785 Guidelines for DiffServ Service Classes", RFC 4594, 786 August 2006. 788 14.2. Informative References 790 [CableLabs DOCSIS] 791 CableLabs, "Data-Over-Cable Service Interface 792 Specifications", CableLabs Specifications Various DOCSIS 793 Reference Documents, . 796 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 797 BCP 60, RFC 3360, August 2002. 799 Appendix A. Document Change Log 801 [RFC Editor: This section is to be removed before publication] 803 -00 version: 805 o -05 - fixed odd spacing in 8.1 807 o -04 - corrections and tweaks by Jason 809 o -03 - corrections and clarifications from Nirmal and BVL 811 o -02 - updated BVL's contact info, clearing one open issue. Also 812 added content to Security Considerations. 814 o -01 - updated doc to reflect that this system is deployed and not 815 in development, closing out two open issues. Added reference for 816 JavaScript, closing an open issue. 818 o -00 - first version published 820 Authors' Addresses 822 Chae Chung 823 Comcast Cable Communications 824 One Comcast Center 825 1701 John F. Kennedy Boulevard 826 Philadelphia, PA 19103 827 US 829 Email: chae_chung@cable.comcast.com 830 URI: http://www.comcast.com 832 Alex Kasyanov 833 Comcast Cable Communications 834 One Comcast Center 835 1701 John F. Kennedy Boulevard 836 Philadelphia, PA 19103 837 US 839 Email: alexander_kasyanov@cable.comcast.com 840 URI: http://www.comcast.com 842 Jason Livingood 843 Comcast Cable Communications 844 One Comcast Center 845 1701 John F. Kennedy Boulevard 846 Philadelphia, PA 19103 847 US 849 Email: jason_livingood@cable.comcast.com 850 URI: http://www.comcast.com 852 Nirmal Mody 853 Comcast Cable Communications 854 One Comcast Center 855 1701 John F. Kennedy Boulevard 856 Philadelphia, PA 19103 857 US 859 Email: nirmal_mody@cable.comcast.com 860 URI: http://www.comcast.com 861 Brian Van Lieu 862 Unaffiliated 863 Bethlehem, PA 18018 864 US 866 Email: brian@vanlieu.net