[要約] RFC 6108は、ComcastのWeb通知システムの設計に関するものであり、その目的は、ユーザーに重要な情報を効果的に伝えるためのシステムを提供することです。
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
Comcast's Web Notification System Design
ComcastのWeb通知システム設計
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.
このドキュメントの目的は、インターネットサービスプロバイダー（ISP）であるComcastが展開したWebブラウザーに重要なエンドユーザー通知を提供する方法を説明することです。このような通知システムは、顧客にほぼ即時の通知を提供するために使用されています。たとえば、トラフィックがマルウェアまたはウイルス感染を示すパターンを示すことを警告しています。このような通知を実行できる他の独自のシステムがありますが、これらのシステムはディープパケット検査（DPI）テクノロジーを利用しています。DPIとは対照的に、このドキュメントは、DPIに依存せず、代わりにオープンIETF標準とオープンソースアプリケーションに基づいているシステムを説明しています。
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 Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6108.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6108で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. High-Level Design of the System .................................3
3. Design Requirements .............................................3
3.1. General Requirements .......................................4
3.2. Web Proxy Requirements .....................................6
3.3. ICAP Server Requirements ...................................7
3.4. Messaging Service Requirements .............................8
4. Implementation Details ..........................................8
4.1. Functional Components Described, as Implemented ............9
4.2. Functional Diagram, as Implemented ........................10
5. High-Level Communication Flow, as Implemented ..................11
6. Communication between Web Proxy and ICAP Server, as
Implemented ....................................................12
7. End-to-End Web Notification Flow, as Implemented ...............13
7.1. Step-by-Step Description of the End-to-End Web
Notification Flow .........................................14
7.2. Diagram of the End-to-End Web Notification Flow ...........15
8. Example HTTP Headers and JavaScript for a Web Notification .....16
9. Deployment Considerations ......................................18
10. Security Considerations .......................................19
11. Debating the Necessity of Such a Critical Notification
System ........................................................19
12. Suggesting a Walled Garden as an Alternative ..................20
13. Intended Next Steps ...........................................21
14. Acknowledgements ..............................................21
15. References ....................................................21
15.1. Normative References .....................................21
15.2. Informative References ...................................23
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.
インターネットサービスプロバイダー（ISP）には、マルウェア感染の可能性に関する警告などの重要なサービス通知を伝えるために、ほぼすぐに顧客と通信できるシステムが必要です。インターネットユーザーが使用している主なクライアントソフトウェアとしてのWebブラウザーの有病率を考えると、Webブラウザーはこれらの通知を提供するのに理想的な手段です。このドキュメントでは、Broadband ISPであるComcastによって展開されたシステムが、Webブラウザーにほぼ模倣された通知を提供するシステムについて説明しています。
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, [CableLabs_DOCSIS]) networks used by most cable-based broadband ISPs, concepts described in this document can generally be applied to many different types of networks should those ISPs be interested in alternatives to DPI.
潜在的なソリューションの評価の過程で、著者は、市販のシステムの大部分が深いパケット検査（DPI）テクノロジーを利用したことを発見しました。DPIベースのシステムは確かに機能しますが、Comcastや他のISPはDPIの広範な展開と使用を回避しようとしており、代替案を検索しています。したがって、Comcastは、オープン標準と非専用ソフトウェアに基づいたシステムを使用することを望んでおり、DPIの使用を必要としませんでした。本明細書に記載されているシステムは、ほとんどのケーブルベースのブロードバンドISPで使用されるデータオーバーケーブルサービスインターフェイスの仕様（Docsis、[cablelabs_docsis]）に固有のものですが、このドキュメントで説明されている概念は、一般にさまざまな種類のネットワークに適用できます。これらのISPは、DPIの代替案に興味があります。
The web notification system design is based on the use of the Internet Content Adaptation Protocol (ICAP) [RFC3507]. 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, [RFC2616]) response to an ICAP server for content adaption. The ICAP server in turn responds back to the client with the HTTP response containing the notification message by using the "respmod" method defined in Section 3.2 of [RFC3507].
Web通知システムの設計は、インターネットコンテンツ適応プロトコル（ICAP）[RFC3507]の使用に基づいています。この設計では、Squid Web Proxy、Greasyspoon ICAPサーバー、およびApache Tomcatであるオープンソースアプリケーションを使用しています。既存のIETFプロトコルであるICAPは、メッセージの変換または適応を可能にします。ICAPクライアントは、コンテンツ適応のためにICAPサーバーへのハイパーテキストトランスポートプロトコル（HTTP、[RFC2616]）の応答を渡します。ICAPサーバーは、[RFC3507]のセクション3.2で定義されている「RESPMOD」メソッドを使用して、通知メッセージを含むHTTP応答を使用してクライアントに応答します。
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.
このセクションでは、このシステムの設計についてComcastが考慮したすべての主要な要件について説明します。この情報は、DPIの使用を避けるために作成された重要な設計の選択を伝えるために提供されます。追加情報、コンテキスト、またはその他の有用な説明を提供するために、各要件に「追加の背景」段落が含まれています。
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.1。重要なサービス通知にのみ使用する必要があります。追加の背景：システムは、些細な通知ではなく、重要な通知のみを提供する必要があります。このシステムの主な動機でもある重要な非自明な通知の例は、ユーザーにマルウェアに感染していること、セキュリティが深刻なリスクにさらされている、および/またはすでに妥協されていることをアドバイスすることです。彼らが今すぐに是正する行動をとることをお勧めします。
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.2。TCPポート80の追加背景を使用する必要があります。システムは、HTTPトラフィックの有名なポートであるTCPポート80を介して通知を提供する必要があります。大多数の顧客は主要なアプリケーションとしてWebブラウザーを使用しているため、これは即時の重要な通知を提供するための最良の方法と見なされました。
R3.1.3. Must Support Block Listing Additional Background: While unlikely, it is possible that the HyperText Markup Language (HTML, [RFC2854]) or JavaScript [RFC4329] used for notifications may cause problems while accessing a particular website. Therefore, such a system must be capable of using a block list of website Uniform Resource Identifiers (URIs, [RFC3986]) or Fully Qualified Domain Names (FQDNs, Section 5.1 of [RFC1035]) 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.3。ブロックのリストをサポートする必要があります。追加の背景：ありそうもありませんが、通知に使用されるハイパーテキストマークアップ言語（HTML、[RFC2854]）またはJavaScript [RFC4329]は、特定のWebサイトにアクセスしながら問題を引き起こす可能性があります。したがって、このようなシステムは、システムと矛盾するウェブサイトのユニフォームリソース識別子（URIS、[RFC3986]）または完全に適格なドメイン名（FQDNS、[RFC1035]のセクション5.1）のブロックリストを使用できる必要があります。エラーや予期しない結果を最小限に抑えるために、これらの場合に通知を提供しません。また、このシステムが予期しない方法で動作しないことを保証するために広範な開発とテストが実行され、標準的なICAP（長年使用されてきました）が利用されていますが、そのような方法で動作する場合が重要です、特定のURIまたは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.
R3.1.4。TCPポート80を使用するインスタントメッセージング（IM）クライアントに問題を引き起こしてはなりません。他のIMクライアントは、実際にはデフォルトでTCPポート80を使用する場合があります。場合によっては、Webブラウザーに基づいている場合もあります。したがって、このシステムは、TCPポート80を使用するIMクライアント（または他のクライアントタイプ）と競合したり、予期しない結果を引き起こしてはなりません。
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.5。既存のアクティブなTCPセッションを処理する必要があります。優雅に追加の背景：Web通知システムは、重要な通知を提供するためにTCPポート80トラフィックを一時的に再ルーティングする可能性があるため、以前に確立されたTCPポート80セッションは、プロキシにルーティングされている間に中断してはなりません層。また、重要なWeb通知は明確に定義された時点で発生するため、通知が送信される前にエンドユーザーが進行中のアクティブなTCPポート80セッションを持っている可能性があると結論付けることは論理的です。通知の時間。したがって、そのような接続をリセットしてはならず、代わりに優雅に処理する必要があることが重要です。
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 [RFC3360]. In Comcast's recent history, for example, the company was criticized for using TCP resets in the course of operating a DPI-based network management system. As such, TCP resets as a function of the system must not be used.
R3.1.6。TCPリセットを使用しないでください。追加の背景：TCPリセットの使用は、一般的にインターネットコミュニティと[RFC3360]の両方で広く批判されています。たとえば、Comcastの最近の歴史では、同社はDPIベースのネットワーク管理システムの運用の過程でTCPリセットを使用したとして批判されました。そのため、システムの関数としてTCPリセットを使用してはなりません。
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.7。破壊的な追加の背景である必要があります。たとえば、クライアントエラーを引き起こすなど、Web通知システムはエンドユーザーエクスペリエンスを妨害してはなりません。
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.8。ユーザー通知の承認は、さらに即時通知を停止する必要があります。追加の背景：ユーザーが重要な通知を認めたら、すぐに通知が停止するはずです。それ以外の場合、ユーザーは、システムがエラー状態に閉じ込められていると信じている場合があり、重要な通知が有効であるとは考えられない場合があります。さらに、システムが彼の承認に反応しなかったことにユーザーがイライラする可能性は十分にあります。
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.9。コンテンツの非修正は追加の背景を維持する必要があります。システムは、ユーザーがアクセスしているWebサイトからHTTP応答のコンテンツを大幅に変更してはなりません。
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 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.10。予期しないコンテンツを優雅に処理する必要があります。時には、ソフトウェアシステムの開発者やソフトウェアの実装者が、システムへの狭い範囲の入力が発生すると仮定します。これらはすべて、デザイナーによって事前に考えられています。著者は、これがシステムの設計と実装において行うのは不十分な仮定であり、対照的に、予期しないまたは奇形の入力さえも想定すべきであると考えています。その結果、システムがこの結果として重要なWeb通知を提供できない場合でも、システムは予想外のトラフィックを優雅に透過的に処理する必要があります。したがって、広く変化するコンテンツが予想される必要があり、そのような予期しないトラフィックはすべて、ユーザーが認識したエラーや予期しない結果を生成せずにシステムによって処理する必要があります。
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.11。Webコンテンツをキャッシュしてはならない追加の背景：ユーザーのプライバシーを維持することが重要です。そのため、システムによって流れる、または偶然に観察されるコンテンツをキャッシュしてはなりません。
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.
R3.1.12。いかなる状況でも広告の交換または挿入を実行してはなりません。追加の背景：システムを使用して、Webサイトが提供する広告を交換したり、広告をWebサイトに挿入したりしてはなりません。したがって、これには、Webページに既に広告のスペースがある場合、およびWebページに広告がない場合が含まれます。これは、エンドユーザー、プライバシー擁護者、およびインターネットコミュニティの他のメンバーにとって懸念の重要な分野です。したがって、このシステムがそのような目的に使用されないことを十分に明確にする必要があります。
R3.2.1. Open Source Software Must Be Used Additional Background: The system must use an open source web proxy server. (As noted in Section 2 and Section 4.1, 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.1。オープンソースソフトウェアは追加の背景を使用する必要があります。システムは、オープンソースWebプロキシサーバーを使用する必要があります。（セクション2およびセクション4.1に記載されているように、Squidが選択されました。）Webプロキシを使用することは可能ですが、オープンソースを使用すると、他の人がソフトウェアのオープンに利用可能なドキュメントに簡単にアクセスできます。オープンソースソフトウェアの使用。
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.
R3.2.2。ICAPクライアントは追加の背景を統合する必要があります：Webプロキシサーバーには、システムの設計と実装を簡素化する統合ICAPクライアントが必要です。
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 Section 4.1 below, then the proxy must restrict access only to the address of the SMB.
R3.2.3。アクセス制御を実装する必要があります。追加の背景：プロキシへのアクセスは、通知が意図されているユーザーのIPアドレスのみに限定され、限られた期間のみ制限する必要があります。さらに、以下のセクション4.1で説明されているように、セッション管理ブローカー（SMB）が利用されるため、プロキシはSMBのアドレスへのみアクセスを制限する必要があります。
R3.3.1. Must Provide ICAP Response Support Additional Background: The system must support response adaptation, in accordance with [RFC3507]. An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616]) response to an ICAP server for content adaption. The ICAP server in turn responds back to the client with the HTTP response containing the notification message by using the "respmod" method defined in Section 3.2 of [RFC3507].
R3.3.1。ICAP応答サポートを提供する必要があります。追加の背景：[RFC3507]に従って、システムは応答適応をサポートする必要があります。ICAPクライアントは、コンテンツ適応のためにICAPサーバーへのハイパーテキストトランスポートプロトコル（HTTP、[RFC2616]）の応答を渡します。ICAPサーバーは、[RFC3507]のセクション3.2で定義されている「RESPMOD」メソッドを使用して、通知メッセージを含むHTTP応答を使用してクライアントに応答します。
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.2。重要な通知の一貫性を提供する必要があります。追加の背景：システムは一貫して特定の通知を提供できる必要があります。たとえば、ユーザーがマルウェアに感染していることをユーザーに通知するためのクリティカルアラートが望ましい場合、その通知はすべてのユーザーに対して一貫して同じように見える必要があります。
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.3。複数の通知タイプをサポートする必要があります。追加の背景：システムによって送信された初期および唯一の重要な通知は、ユーザーにマルウェア感染を警告することを目的としていますが、マルウェアは迅速かつ継続的に進化する脅威です。この現実の結果、システムはさまざまなタイプの重要な通知を提供するために進化できる必要があります。たとえば、マルウェアがエンドユーザーに実質的に異なる意味を持ついくつかの異なるカテゴリに分かれ始めた場合、マルウェアの各カテゴリに狭く調整された通知を提供することが望ましい場合があります。
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.
R3.3.4。複数のユーザーへの通知を同時にサポートする必要があります。追加の背景：システムは、異なるユーザーに通知を同時に提供できる必要があります。たとえば、100人のユーザーがマルウェアに感染しており、このセキュリティの問題について批判的に通知する必要がある場合、システムは一度に複数のユーザーに通知を提供できる必要があります。一度に1人だけのユーザーよりも。
R3.4.1. A Messaging Service Must Be Used Additional Background: The Messaging Service, as described in Section 4.1 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.1。メッセージングサービスは、以下のセクション4.1で説明されているように、各特定のユーザーの通知をキャッシュするように、追加の背景：メッセージングサービスを使用する必要があります。したがって、通知メッセージはシステムによってキャッシュされ、通知が必要になるたびに取得する必要はありません。その結果、以前の要件に記載されているように、システムを複数のユーザーに同時に通知を提供するように簡単にスケーリングできます（「複数のユーザーに同時に通知をサポートする必要がある」）。
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.2。以前の要件に記載されているように（「ユーザー通知の承認はさらに即時通知を停止する必要がある」）。
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.3。通知をターゲットにする正確性を確認する必要があります。たとえば、システムがユーザーCではなくユーザーAとユーザーBに重要な通知を提供する場合、ユーザーCに通知を送信してはなりません。
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.
R3.4.4。カスタマーサポートの目的で通知記録を維持する必要があります。追加の背景：メッセージングサービスは、ユーザーがカスタマーサポート担当者に問い合わせた場合に備えて、ユーザーに通知が送信されたという何らかの記録を維持する必要があります。たとえば、ユーザーがマルウェア感染症についてアドバイスする重要な通知を提示された場合、そのユーザーはカスタマーサービス組織のComcastの顧客セキュリティ保証チームに電話することを選択できます。その結果、顧客のセキュリティ保証担当者は、ユーザーが実際にマルウェア感染に関する通知を受け取ったことを確認できるはずです。
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.
このセクションでは、システムのさまざまなコア機能コンポーネントが実装されたときに定義および文書化されています。次に、これらのコンポーネントを図に示して、さまざまなコンポーネントがどのようにリンクされ、互いに関連しているかを説明します。
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.1。Webプロキシ：システムは、統合されたICAPクライアントをサポートする広範囲に使用してオープンソースWebプロキシアプリケーションであるSquid Proxyを使用します。
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.2。ICAPサーバー：システムは、オープンソースアプリケーションであるGreasyspoonを使用します。ICAPサーバーは、コンテンツの適応が必要なときにメッセージングサービスキャッシュから通知を取得します。
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.3。顧客データベース：顧客データベースは、特定のユーザーに重要な通知を提供するためにシステムが必要とする関連情報を保持しています。また、データベースは、ユーザーに通知された状態と、通知が保留中のユーザーのステータスを保持する場合があります。
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 Section 3.3 the system may eventually need to provide multiple notifications (the specific requirement is "Must Support Multiple Notification Types"). When a notification for a specific user is not in the cache, the process retrieves this information from the Customer Database and populates the cache for a specific period of time.
S4.1.4。メッセージングサービス：システムは、オープンソースアプリケーションであるApache Tomcatを使用します。これは、可能な通知のカタログから特定のWeb通知メッセージを取得するプロセスエンジンです。セクション3.3で述べたように、マルウェア感染に関して現在1つの通知が使用されていますが、システムは最終的に複数の通知を提供する必要がある場合があります（特定の要件は「複数の通知タイプをサポートする必要があります」）。特定のユーザーの通知がキャッシュに含まれていない場合、プロセスはこの情報を顧客データベースから取得し、特定の期間キャッシュに入力します。
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 Section 3 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 [RFC3022]) from the SMB.
S4.1.5。セッション管理ブローカー（SMB）：カスタマイズされたレイヤー7検査ポリシーを備えたロードバランサー（LB）は、上記のセクション3で文書化された要件を満たすために、TCPポート80のHTTPと非HTTPトラフィックを区別するために使用されます。システムは、A10ネットワークからLBを使用します。SMBは、内部セッションテーブルに存在しない既存のTCPセッションからパケットを転送する機能を備えた完全なステートフルTCPプロキシとして機能します（特定の要件を満たすには、「既存のアクティブなTCPセッションを優雅に処理する必要があります」）。新しいHTTPセッションは、SMBのソースネットワークアドレス変換（NAT [RFC3022]）を使用して、Webプロキシレイヤーにロードバランスが取れます。
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").
SMBセッションテーブルにない確立されたTCPセッションの非HTTPトラフィックは、TCPプロキシレイヤーを介して宛先に透過的に転送されます（繰り返しますが、特定の要件を満たすには、既存のアクティブなTCPセッションを優雅に処理する必要があります」）。
+--------+ +------------+ +----------+
| ICAP | <----> | Messaging | <----> | Customer |
| Server | | Service | | Database |
+--------+ +------------+ +----------+
^
| +----------+
| | |
| +-------> | Internet | <-------+
| | | | |
| | +----------+ |
| | ^ |
v v | |
+----------+ v v
|+--------+| +-------+ +--------+
|| ICAP || <----> | SMB | <---> | Access |
|| Client || +-------+ | Router |
|+--------+| +--------+
|| SQUID || ^
|| Proxy || |
|+--------+| v
+----------+ +----------+
| CMTS* |
+----------+
^
|
v
+------+
| PC |
+------+
* A Cable Modem Termination System (CMTS) is an access network element.
* ケーブルモデム終了システム（CMTS）は、アクセスネットワーク要素です。
Figure 1: Web Notification System - Functional Components
図1：Web通知システム - 機能コンポーネント
In Section 4, 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.
セクション4では、システムの機能成分が説明され、上記の図1に互いに関連して示されています。このセクションでは、機能が実際に動作する一般的な方法を説明するために、システム内のトランザクションの高レベルの通信（c）の流れについて説明します。これについては、このドキュメントの後のセクションでさらに詳細に説明します。
C5.1. Setup of Differentiated Services (Diffserv): Using Diffserv [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] [RFC4594], set a policy to direct TCP port 80 traffic to the web notification system's web proxy.
C5.1。差別化されたサービスのセットアップ（DIFFSERV）：DiffServ [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] [RFC4594] [RFC3246] [RFC4594]は、TCPポート80のトラフィックにポリシーを導きます。
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.2。セッション管理：TCPポート80パケットは、HTTPまたは非HTTPトラフィックを区別するセッション管理ブローカー（SMB）にルーティングされます。HTTPパケットは、SMBによってWebプロキシに転送されます。インスタントメッセージング（IM）トラフィックなどの非HTTPパケットは、宛先にルーティングするためにTCPプロキシレイヤーに転送されます。SMBは完全なTCPプロキシとして動作し、非HTTPパケットを宛先に転送します。ポート80の事前に確立されたTCPセッションは、SMBによって識別され、影響なしで転送されます。
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.3。Webプロキシはリクエストを転送します：Webプロキシは、Webプロキシが通常行うように、WebサーバーであるWebサーバーにHTTP要求を宛先サイトに転送します。
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.4。応答時に、ICAPサーバーにメッセージを送信します：HTTP応答が宛先サーバーから受信された場合、WebプロキシはWeb通知のためにICAPサーバーにメッセージを送信します。
C5.5. Messaging Service: The Messaging Service should respond with appropriate notification content or null response if no notification is cached.
C5.5。メッセージングサービス：メッセージングがキャッシュされていない場合は、メッセージングサービスが適切な通知コンテンツまたはnull応答で応答する必要があります。
C5.6. ICAP Server Responds: The ICAP server responds and furnishes the appropriate content for the web notification to the web proxy.
C5.6。ICAPサーバーの応答：ICAPサーバーが応答し、Web通知のための適切なコンテンツをWebプロキシに提供します。
C5.7. Web Proxy Sends Response: The web proxy then forwards the HTTP response containing the web notification to the client web browser.
C5.7。Webプロキシは応答を送信します：Webプロキシは、Web通知を含むHTTP応答をクライアントWebブラウザーに転送します。
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.8。ユーザーの応答：ユーザーは、重要なWeb通知を観察し、次のような適切なオプションをクリックします。
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.9。詳細：通知に応じて、ユーザーに詳細情報が提供される場合があります。たとえば、前述のように、このシステムは、マルウェア感染に関する重要な通知を提供するように設計されています。したがって、マルウェア感染の場合、ユーザーは、マルウェアを削除しようとする方法を提供し、将来のマルウェア感染に対してホストを保護しようとするマルウェア修復Webページに行くことをお勧めします。
C5.10. Turn Down Diffserv: Once the notification transaction has completed, remove any special Diffserv settings.
C5.10。diffserv：通知トランザクションが完了したら、特別なdiffserv設定を削除します。
The web proxy and ICAP server are critical components of the system. This section shows the communication that occurs between these two components.
WebプロキシとICAPサーバーは、システムの重要なコンポーネントです。このセクションは、これら2つのコンポーネント間で発生する通信を示しています。
+------------+
| www URI |
+------------+
^ |
(2)| |(3)
| v
+--------+ (4) +--------+ (4) +--------+
| |------------>| |------------>| |
| | (5) | | (5) | |
| Proxy |<------------| ICAP |<------------| ICAP |
| Module | (6) | Client | (6) | Server |
| |------------>| |------------>| |
| | (7) | | (7) | |
| |<------------| |<------------| |
+--------+ +--------+ +--------+
^ |
(1)| |(8)
| v
+------------+ (9) +------------+
| |----------------------------->| |
| Browser | (10) | Web Server |
| |<-----------------------------| |
+------------+ +------------+
(1) - HTTP GET (TCP 80)
(2) - Proxy HTTP GET (TCP 80)
(3) - HTTP 200 OK w/ Response
(4) - ICAP RESPMOD
(5) - ICAP 200 OK
(6) - TCP Stream - Encapsulate Header
(7) - ICAP 200 OK Insert Message
(8) - HTTP 200 OK w/ Response + Message Frame
(9) - HTTP GET for Message
(10) - HTTP 200 w/ Message Content
Figure 2: Communication between Web Proxy and ICAP Server
図2：WebプロキシとICAPサーバー間の通信
This section describes the exact flow of an end-to-end notification, in order to show in detail how the system functions.
このセクションでは、システムがどのように機能するかを詳細に示すために、エンドツーエンド通知の正確な流れについて説明します。
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.
1. 通知する必要があるユーザーからのTCPポート80パケットは、ポリシーベースのルーティングを介してWebプロキシにルーティングされます。
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.
2. パケットはセッション管理ブローカーに転送され、Webプロキシとのセッションを確立し、パケットをWebプロキシにルーティングします。
Web Proxy
Webプロキシ
1. The user's HTTP request is directed to the web proxy.
1. ユーザーのHTTPリクエストは、Webプロキシに送信されます。
2. The web proxy receives HTTP traffic and retrieves content from the requested website.
2. WebプロキシはHTTPトラフィックを受信し、要求されたWebサイトからコンテンツを取得します。
3. The web proxy receives the response and forwards it to the ICAP server for response adaptation.
3. Webプロキシは応答を受信し、応答適応のためにICAPサーバーに転送します。
4. The ICAP server checks the HTTP content in order to determine whether the notification message can be inserted.
4. ICAPサーバーは、通知メッセージを挿入できるかどうかを判断するために、HTTPコンテンツをチェックします。
5. The ICAP server initiates a request to the Messaging Service cache process with the IP address of the user.
5. ICAPサーバーは、ユーザーのIPアドレスを使用してメッセージングサービスキャッシュプロセスへの要求を開始します。
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.
6. ユーザーの通知メッセージが存在する場合、適切な通知がメッセージングサービスにキャッシュされます。メッセージングサービスは、適切な通知コンテンツをICAPサーバーに返します。
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.
7. 通知メッセージがメッセージングサービスキャッシュから取得されると、ICAPサーバーは、HTTP応答の元のコンテンツを変更または変更せずに、HTTP応答ボディに通知メッセージを挿入できます。
8. The ICAP server then sends the response back to the web proxy, which in turn forwards the HTTP response back to the browser.
8. ICAPサーバーは、応答をWebプロキシに送り返し、HTTP応答をブラウザに転送します。
9. If the user's IP address is not found or provisioned for a notification message, then the ICAP server should return a "204 No modifications needed" response to the ICAP client as defined in Section 4.3.3 of [RFC3507]. As a result, the user will not receive any web notification message.
9. ユーザーのIPアドレスが通知メッセージのために見つかっていないか、プロビジョニングされていない場合、ICAPサーバーは[RFC3507]のセクション4.3.3で定義されているように、ICAPクライアントに対する「204変更なし」の応答を返す必要があります。その結果、ユーザーはWeb通知メッセージを受信しません。
10. The user observes the web notification, and clicks an appropriate option, such as: OK/acknowledged, snooze/remind me later, etc.
10. ユーザーは、Web通知を観察し、次のような適切なオプションをクリックします。
The two figures below show the communications flow from the web browser, through the web notification system.
以下の2つの図は、Webブラウザからの通信フローをWeb通知システムを介して示しています。
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.
図3は、ユーザーのIPアドレスの通知タイプがメッセージングサービスでキャッシュされていないため、通知要求を挿入できない場合に発生することを示しています。
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Miss | | |
| | | |<-------+ Request| |
| | | 204 No | | Type | |
| | | Modif. | +--------|------->|
| | | Needed | | | |
| | No |<--------+ | | Type |
| | Insert | | | |Returned|
| 200 OK |<--------+ | |<-------|--------+
| w/o | | | | | |
| Insert | | | | | |
|<-------+ | | | | |
| | | | | | |
Figure 3: End-to-End Web Notification Flow - with Cache Miss
図3：エンドツーエンドのWeb通知フロー - キャッシュミス付き
Figure 4 illustrates what occurs when a notification request for the user's IP address is cached in the Messaging Service.
図4は、ユーザーのIPアドレスの通知要求がメッセージングサービスでキャッシュされたときに発生することを示しています。
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Hit | | |
| | | Insert |<-------+ | |
| | Return | Type | | | |
| | 200 OK |<--------+ | | |
| | with | | | | |
| | Insert | | | | |
| 200 OK |<--------+ | | | |
| w/ | | | | | |
| Notify | | | | | |
|<-------+ | | | | |
| | | | | | |
Figure 4: End-to-End Web Notification Flow - with Cache Hit
図4：エンドツーエンドのWeb通知フロー - キャッシュがヒットした
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.
以下の図は、ユーザーのWebブラウザーから、インターネット上のWebサーバーであるwww.example.comへの通常のHTTP Get Requestの例を示しています。
------------------------------------------------------------------------
1. HTTP GET Request to www.example.com
------------------------------------------------------------------------
http://www.example.com/
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
------------------------------------------------------------------------
Figure 5: Example HTTP Headers for a Web Notification - HTTP GET
図5：Web通知のHTTPヘッダーの例-HTTPGET
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.
以下の図では、トラフィックはWebプロキシを介してルーティングされており、ICAPサーバーと通信し、www.example.comから応答を返します。この場合、その応答は200 OKであり、目的の通知メッセージが挿入されています。
------------------------------------------------------------------------
2. Response from www.example.com via PROXY
------------------------------------------------------------------------
HTTP/1.x 200 OK
Date: Thu, 08 May 2008 16:26:29 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Age: 18
X-Cache: HIT from localhost.localdomain
Via: 1.0 localhost.localdomain (squid/3.0.STABLE5)
Proxy-Connection: keep-alive
------------------------------------------------------------------------
Figure 6: Example HTTP Headers for a Web Notification - HTTP Response The figure below shows an example of the web notification content inserted in the 200 OK response, in this example JavaScript code.
図6：Web通知の例HTTPヘッダー - HTTP応答以下の図は、この例JavaScriptコードで挿入されたWeb通知コンテンツの例を示しています。
------------------------------------------------------------------------
3. Example of JavaScript containing Notification Insertion
------------------------------------------------------------------------
<!--all elements used in a notification should have cascading style
sheet (css) properties defined to avoid unwanted inheritance from
parent page-->
<style type="text/css">
#example {
position: absolute; left: 100px; top: 50px;
z-index: 9999999; height: auto; width: 550px;
padding: 10px;
border: solid 2px black;
background-color:#FDD017;
opacity: 0.8; filter: alpha(opacity = 80);
}
</style>
<script language="javascript" type="text/javascript">
// ensure that content is not part of an iframe
if (self.location == top.location) {
// this is a floating div with 80% transparency
document.write('<div id="example" name="example">');
document.write('<h2>IMPORTANT MESSAGE</h2>');
document.write('<p>Lorem ipsum dolor sit amet, consecteteur ');
document.write('adipisicing elit, sed do eiusmod tempor ');
document.write('incididunt ut labore et dolore magna aliqua. ');
document.write('Ut enim ad minim veniam, quis nostrud ');
document.write('exercitation ullamco laboris nisi ut aliquip ex ');
document.write('ea commodo consequat.');
document.write('</div>');
}</script>
------------------------------------------------------------------------
Figure 7: Example JavaScript Used in a Web Notification
図7：Web通知で使用されているJavaScriptの例
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.
Web通知システムのコンポーネントは、ネットワーク全体に、およびエンドユーザーに近いものを配布する必要があります。これにより、ルーティングパフォーマンスとユーザーのWebブラウジングエクスペリエンスが優れていることが保証されます。さらに、サーバーが配置されている各データセンターでHTTPを認識したロードバランサーを使用して、トラフィックをN 1サーバーに広げ、システムを簡単にスケーリングできるようにする必要があります。
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 Section 3.4.
この重要なWeb通知システムは、コンピューターがマルウェアに感染していることをエンドユーザーの顧客に通知する追加の方法を提供するために考案されました。通知の特定のテキストに応じて、ユーザーはそれが何らかのフィッシング攻撃であることを恐れることができます。その結果、テキストとWeb通知自体に含まれるリンクには注意が払われています。たとえば、通知テキストが時間の経過とともに変更された場合、一般的なURIまたは電話番号を提供することが最善かもしれません。それとは対照的に、通知はログイン資格情報を要求してはならず、パスワードを変更するためにユーザーにリンクをたどるように依頼してはなりません。これらは一般的なフィッシング手法であるためです。最後に、Web通知が有効であり、信頼できる当事者から、および/またはユーザーがWeb通知の有効性をチェックする代替方法を持っているという自信を提供するように注意する必要があります。通知を検証する別の別の方法の1つは、カスタマーサポートに電話することです（この例では、Comcastの顧客セキュリティ保証チーム）。これは、セクション3.4の重要な要件（具体的には「カスタマーサポートの目的で通知記録を保持する必要がある」）を説明しています。
Some members of the community may question whether it is ever, under any circumstances, acceptable to modify Internet content in order to provide critical service notification concerning malware infection - even in the smallest of ways, even if openly and transparently documented, even if thoroughly tested, and even if for the best of motivations. It is important that anyone with such concerns recognize that this document is by no means the first to propose this, particularly as a tactic to combat a security problem, and in fact simply leverages previous work in the IETF, such as [RFC3507]. Such concerned parties should also study the many organizations using ICAP and the many software systems that have implemented ICAP.
コミュニティの一部のメンバーは、いかなる状況でも、マルウェア感染に関する重要なサービス通知を提供するためにインターネットコンテンツを変更することが許容できるかどうかを疑問視する場合があります。、そして、たとえ最高の動機のためであっても。そのような懸念を持つ人は誰でも、このドキュメントがこれを提案する最初のことであり、特にセキュリティ問題に対抗するための戦術として、そして実際には[RFC3507]などのIETFでの以前の研究を単に活用することを認識することが重要です。このような関係者は、ICAPを使用して多くの組織とICAPを実装した多くのソフトウェアシステムを調査する必要があります。
In addition, concerned members of the community should review Section 1, 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.
さらに、コミュニティの関係者はセクション1を確認する必要があります。セクション1は、これがDPIベンダーとほとんどではないにしても多くの主要なネットワーキング機器ベンダーによって作成されたDPIシステムの一般的な機能であるという事実を説明しています。本書に記載されているように、このドキュメントの著者は、オープンソースソフトウェアとオープンプロトコルの両方を使用することにより、DPIの広範なユビキタスな展開の必要性を回避するように動機付けられており、そのようなシステムがどのように機能するかの詳細を透過的に説明する動機付けがさらに動機付けられている、それが意図されていること、それが行うことを意図していないこと、そしてそれが使用されない目的。
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.
著者はまた、ISPがネットワーク管理の技術とシステムを透過的に開示し、ここで行われているように、そのための場所を持つことが重要であると考えています。さらに、著者は、IETFやインターネットコミュニティの他のメンバーがそのような開示を奨励し、積極的に強化することが重要であると考えています。インターネットコミュニティによる参照とコメントのためのこのようなドキュメントの公開では、これは他のISPが同様にオープンになり、IETFやインターネットコミュニティの一部である他の組織に関与するように動機付けるのに役立つ可能性があります。そのような文書を公開しないことは、ISPSおよびインターネットコミュニティの他のメンバーの一部での開示を少なくする可能性があり、DPIの使用を増やし、インターネットコミュニティの一部を構成する重要な技術団体へのISP参加を減らすことができます。
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".
さらに、コミュニティのメンバーが、コムキャスのようなISPの良い動機を認識して、マルウェアの大規模で継続的な拡散と戦うことが重要であることが重要です。個人情報の盗難、金融詐欺、スパムの伝達、およびその他の犯罪行為に従事する地下経済。このような重要な通知システムは、実際には、マルウェア感染を防御および防止する際のホストベースのセキュリティが失敗したためにのみ必要です。そのため、ComcastなどのISPは、他の多くの戦術が失敗しているため、この大規模な問題を解決するための行動を取るために、政府組織だけでなく、セキュリティやプライバシー組織などの他の当事者によって促されています。。たとえば、アメリカ合衆国のオバマ大統領へのサイバーセキュリティの特別勧告であるハワード・シュミットは、2005年に次のように述べています。加入者がセキュリティを容易にするためにできる限りのことを行うことは、私たちの国の情報バックボーンの保存にとって重要です。さらに、世界中のブロードバンドの使用をさらに成長させる可能性が非常に高く、ISPの安全性とセキュリティの一部を作る可能性があります。コア製品は、エンドユーザーがブロードバンドが提供する豊富で堅牢な利点を完全に体験できるようになります。
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.
「壁に囲まれた庭」とは、サブスクライバーが利用できる情報とサービスを制御する環境と、ネットワークアクセス許可が付与される環境を指します。したがって、ユーザーを壁に囲まれた庭に配置することは、ISPがユーザーに通知するために取る可能性のある別のアプローチであり、この方法は他の文書やコミュニティの取り組みで可能な代替手段として調査されています。そのため、Web通知は、ドキュメントに値する多くの可能な通知方法の1つと見なされるべきです。
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.
ただし、壁に囲まれたアプローチは課題を引き起こす可能性があり、場合によってはエンドユーザーにとって破壊的と見なされる場合があります。たとえば、ユーザーは、専用のインターネットに接続されたゲームコンソールを使用して、オンラインでゲームをプレイすることができます。別の例では、ユーザーは電話での会話の過程で、何らかのタイプのVoice over IP（VoIP）デバイスを使用している場合があります。どちらの場合も、ユーザーはWebブラウザを使用しておらず、サービスが機能しなくなったように見える理由を判断する方法がありません。
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.
残念ながら、この執筆時点では、IETFの既存のワーキンググループは、マルウェア感染や関連する問題の問題に焦点を当てていません。その結果、このドキュメントの明確な会場はなかったため、独立した提出物として独立した提出エディターに提出されました。このシステムの文書化と開示は、インターネットコミュニティ自体にとって有益ですが、このドキュメントを公開することには他の利点があります。これらの理由の1つは、IETFのメンバーを含むコミュニティのメンバーが、コミュニティがマルウェア、セキュリティ、および批判的な通知の分野で引き受ける可能性のある潜在的な新しい仕事の場合に言及する安定した文書を持っていることです。ユーザー。また、コメントのリクエストの伝統において、コミュニティの他のメンバーが代替システムまたはその他の改善を提案するように動機付けられるかもしれないことも期待されています。
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.
著者は、ドキュメントのレビューとコメントについてAlissa Cooperに感謝したいと考えています。彼の優れたフィードバックと、文書をレビューした他の人たちについては、Nevil Brownleeを求めています。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC2854] Connolly、D。およびL. Masinter、「The Text/HTML」メディアタイプ」、RFC 2854、2000年6月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140] Black、D.、Brim、S.、Carpenter、B。、およびF. Le Faucheur、「Per Hopの動作識別コード」、RFC 3140、2001年6月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、Bennet、J.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis、 "迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation Protocol (ICAP)", RFC 3507, April 2003.
[RFC3507] Elson、J。およびA. Cerpa、「インターネットコンテンツ適応プロトコル（ICAP）」、RFC 3507、2003年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, April 2006.
[RFC4329] Hoehrmann、B。、「スクリプトメディアタイプ」、RFC 4329、2006年4月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、RFC 4594、2006年8月。
[CableLabs_DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifications", CableLabs Specifications, Various DOCSIS Reference Documents, <http://www.cablelabs.com/ specifications/archives/docsis.html>.
[cablelabs_docsis] cablelabs、「データオーバーサービスインターフェイス仕様」、cablelabs仕様、さまざまなdocsisリファレンスドキュメント、<http://www.cablelabs.com/仕様/アーカイブ/docsis.html>。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]フロイド、S。、「不適切なTCPリセットは有害と見なされる」、BCP 60、RFC 3360、2002年8月。
Authors' Addresses
著者のアドレス
Chae Chung Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: chae_chung@cable.comcast.com URI: http://www.comcast.com
Chae Chung Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 US Email：chae_chung@cable.comcast.com URI：http：//www.comcast.com
Alex Kasyanov Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: alexander_kasyanov@cable.comcast.com URI: http://www.comcast.com
Alex Kasyanov Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 US Email：alexander_kasyanov@cable.comcast.com URI：http：//www.comcast.com
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: jason_livingood@cable.comcast.com URI: http://www.comcast.com
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 US Email：jason_livingood@cable.comcast.com URI：http：//www.comcast.com
Nirmal Mody Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: nirmal_mody@cable.comcast.com URI: http://www.comcast.com
Nirmal Mody Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 US Email：nirmal_mody@cable.comcast.com URI：http：//www.comcast.com
Brian Van Lieu Unaffiliated Bethlehem, PA 18018 US EMail: brian@vanlieu.net
ブライアン・ヴァン・リュー、ペンシルベニア州ベツレヘム18018米国の電子メール：brian@vanlieu.net