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
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.
このドキュメントの目的は、Comcastは、インターネットサービスプロバイダ(ISP)によって展開されている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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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ブラウザは、これらの通知を提供するための理想的な車両です。この文書では、Webブラウザに近い即時通知を提供するために、コムキャスト、ブロードバンドISPによって展開されたシステムが記載されています。
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ベースのシステムは確かに働くだろうが、コムキャストと他の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].
ウェブ通知システムの設計は、インターネットコンテンツアダプテーションプロトコル(ICAP)[RFC3507]の使用に基づいています。デザインは、イカのWebプロキシ、GreasySpoon ICAPサーバ、およびApache Tomcatのあるオープンソース・アプリケーションを使用しています。 ICAP、既存のIETFプロトコルは、メッセージ変換または適合を可能にします。 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.
このセクションでは、このシステムの設計のためのコムキャストによって考慮され、キーのすべての要件を説明しています。この情報は、とりわけ、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追加の背景を使用する必要があります。システムは、TCPポート80、HTTPトラフィック用のwell-knownポートを経由して通知を提供しなければなりません。顧客の大多数が彼らの主なアプリケーションとして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]は通知に使用することが可能です。したがって、そのようなシステムは、システムように、システムと競合するウェブサイトのユニフォームリソース識別子(URIは、[RFC3986])のブロックリストを使用するか、または完全修飾ドメイン名(FQDN、[RFC1035]のセクション5.1)ことができなければなりませんエラーまたは予期しない結果を最小限に抑えるために、これらの場合に通知を提供しません。大規模な開発とテストは、このシステムが予期しない動作しません。また、(長年にわたり使用されている)標準ICAPが利用されることを保証するために行われている間、また、それがない場合は、このような方法で動作することが重要です、急速に特定のURIやFQDNのを免除する方法がなければなりません。
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を使用します。他のIMクライアントは、実際にも、Webブラウザに基づいているいくつかのケースでは、デフォルトではTCPポート80を使用することができます。したがって、このシステムはと競合するか、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セッション優雅に追加背景を処理する必要があります:ウェブ通知システムが一時的に可能性があるため、再ルートTCPポート80のトラフィックを、重要な通知を提供するために、以前に確立されたTCPポート80回のセッションは、プロキシにルーティングされた状態で中断されてはなりません層。重要なウェブ通知が時間内に明確に定義された時点で発生するのでまた、通知が送信される前に、エンドユーザーがうまく進行中のアクティブな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。無停止追加の背景である必要があります。ウェブ通知システムは、重大なクライアント・エラーを引き起こすことによって、たとえば、エンドユーザーエクスペリエンスを妨害してはなりません。
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。予期しないコンテンツ優雅に追加背景を処理する必要があります。時々、開発者および/またはソフトウェアシステムの実装者は、設計者によって事前に考えてきたすべてが、システムへの入力の狭い範囲が発生することを想定しています。筆者も、予期しない、または不正な入力が想定されるべきであること、これはシステムの設計と実装に作ると、対照的に貧弱な仮定であると考えています。その結果、システムが正常かつ透過的システムは、この結果として、重要なウェブ通知を提供することができないとき例があるだろうにもかかわらず、予想外のことであるトラフィックを処理する必要があります。このように、多種多様なコンテンツが期待されるべきであり、すべてのそのような予想外のトラフィックは、ユーザ知覚エラーや予期しない結果を生成することなく、システムによって処理されなければなりません。
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ページが既に広告のためのスペースを持っている場合、同様のケースが含まれています。これは、エンドユーザーが、プライバシー擁護派、およびインターネットコミュニティの他のメンバーへの関心の重要な領域です。したがって、このシステムは、このような目的のために使用されないことを明白にしなければなりません。
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アドレスのみに限定されなければなりません。セッション管理ブローカー(SMB)が利用されているので以下のセクション4.1に記載されるようにさらに、、、、プロキシは、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人のユーザーがマルウェアに感染し、批判的に、このセキュリティ上の問題を通知する必要がありますされている場合たとえば、その後、システムではなく、同時に一度に複数のユーザーへの通知、またはユーザのすべてを提供することが可能でなければなりません一度に一つだけのユーザーよりも。
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。メッセージング・サービス通知が意図したユーザーに提示されていることを確認する必要があります正確追加の背景をターゲットに通知が確認する必要があります。例えば、システムは、ユーザA及びユーザBに重要な通知を提供することを目的とする場合ではなく、ユーザCは、ユーザ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.
このセクションでは、正確かつ透過的に本明細書に記載のシステムによって使用されるソフトウェア(S)パッケージ、ならびにすべての方法のシステム機能の詳細について説明します。著者は、各コンポーネントの複数の代替ソフトウェアの選択肢があるかもしれないことを認めます。このセクションの目的はなさと展開されているこれらの選択を記述することです。
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クライアントをサポートSquidプロキシ、広い使用中のオープンソースのWebプロキシアプリケーションを使用しています。
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節で述べたように、システムは、最終的には、複数の通知を提供する必要があるかもしれません(特定の要件は、「複数の通知タイプをサポートしなければならない」です)。特定のユーザーに対する通知がキャッシュ内にない場合は、プロセスは、顧客データベースからこの情報を取得し、特定の期間のキャッシュに移入されます。
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を使用しています。 (具体的な要件は、「既存のActive TCPセッションの優雅を処理しなければならない」満たすために)内部セッションテーブルに存在しない既存のTCPセッションからのパケットを転送する能力を備えた完全なステートフルTCPプロキシとしてSMB機能。新しいHTTPセッションは、Webプロキシ層のいずれかに透過またはSMBからソースネットワークアドレス変換(NAT [RFC3022])を使用してにロードバランスされています。
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").
+--------+ +------------+ +----------+ | 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:ウェブ通知システム - 機能コンポーネント
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]は、ウェブ通知システムのWebプロキシに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プロキシは、宛先サイト、ウェブサーバーに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 Serverが応答します: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ブラウザへのWeb通知を含むHTTPレスポンスを転送します。
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。ユーザーの処置:ユーザーは、重要なウェブ通知を観察し、そのように、適切なオプションをクリック:OK /認め、スヌーズ/後で私に思い出させる、など
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サーバは、システムの重要なコンポーネントです。このセクションでは、これら二つの構成要素間で発生する通信を示します。
+------------+ | 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
(1) - HTTP GET(TCP 80)(2) - プロキシHTTPのGET(TCP 80)(3) - HTTP 200 OK応答/ W(4) - ICAP RESPMOD(5) - ICAP 200 OK(6) - TCPストリーム - カプセル化ヘッダ(7) - ICAP 200 OKメッセージを挿入(8) - HTTP 200 OK W /レスポンス+メッセージフレーム(9) - HTTP GETメッセージ(10)のための - HTTP 200W /メッセージ内容
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プロキシ
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サーバは、順番に戻ってブラウザにHTTPレスポンスを転送するWebプロキシ、に応答を送信します。
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.
ユーザーのIPアドレスが見つからないか、または通知メッセージ用にプロビジョニングされていない場合は、[RFC3507]のセクション4.3.3で定義されているよう9.、その後、ICAPサーバは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通知を観察し、そのように、適切なオプションをクリック:OK /認め、スヌーズ/後で私に思い出させる、など
The two figures below show the communications flow from the web browser, through the web notification system.
以下の2つの図は、ウェブ通知システムを介して、ウェブブラウザからの通信の流れを示しています。
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.
下の図は、www.example.comへのユーザのウェブブラウザ、インターネット上のWebサーバからの通常のHTTP GETリクエストの例を示します。
------------------------------------------------------------------------ 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ヘッダ - HTTP GET
In the figure below, the traffic is routed via the web proxy, which communicates with the ICAP server and returns the response from www.example.com. In this case, that response is a 200 OK, with the desired notification message inserted.
下の図では、トラフィックは、ICAPサーバと通信し、www.example.comからの応答を返すWebプロキシを介してルーティングされます。所望の通知メッセージを挿入して、この場合、その応答は、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
図6:Web通知で例HTTPヘッダ - HTTPレスポンス
The figure below shows an example of the web notification content inserted in the 200 OK response, in this example JavaScript code.
以下の図は、この例ではJavaScriptコードで、200 OK応答に挿入ウェブ通知内容の一例を示しています。
------------------------------------------------------------------------ 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:例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ブラウジング体験が優れておくことができます。そのトラフィックがN + 1台のサーバーに分散することができ、システムを容易にスケーリングすることができるように加えて、HTTP対応ロードバランサは、サーバが配置されている各データセンターで使用されるべきです。
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通知自体に含まれるすべてのリンクで撮影されました。例えば、時間の経過通知テキストの変更は、それが一般的なURIまたは電話番号を提供するために最善のかもしれなければなりません。それとは対照的に、通知は、ログイン資格情報を要求してはならない、とこれらは一般的なフィッシング技術なので、自分のパスワードを変更するためにリンクをたどるようにユーザーに依頼してはいけません。最後に、ケアは、Web通知が有効で信頼パーティからあり、かつ/またはユーザがWeb通知の有効性をチェックする別の方法を持っているという確信を提供するために取られるべきです。通知を検証する一つの別の方法は、(この例では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.
また、地域社会の懸念のメンバーが、これはDPIベンダーと多くのではなく、ほとんどの場合、主要なネットワーキング機器ベンダーによって作られたDPIシステムの共通の特徴があるという事実を説明し、セクション1を、確認する必要があります。本明細書に記載されるように、この文書の著者は、オープンソースソフトウェアとオープン両方のプロトコルの使用を介して、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やインターネットコミュニティの一部である他の組織に係合するように機能することができます。そのような文書を公開しないことは、ISPやインターネットコミュニティの他のメンバーの一部にあまり開示のやる気を引き出す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".
また、コミュニティのメンバーは、平均的なインターネットユーザーのセキュリティに対する大きな脅威であり、現在、数十億ドル規模を表し、マルウェアの大規模かつ継続的な増殖を戦うためにComcastのようなのISPの良い動機を認識することが重要です地下経済は、個人情報の盗難、金融詐欺、スパムの送信、および他の犯罪活動に従事しました。実際にはこのような重要な通知システムは、原因を防御し、マルウェア感染の予防のホストベースのセキュリティの障害のために必要なだけです。他の多くの戦術が成功していないので、このようなように、このようなコムキャストなどのISPは、この大規模な問題を解決するための行動を取るために、彼らの顧客が、そのようなセキュリティおよび/またはプライバシーの組織だけでなく、政府機関など、他の当事者によって付勢されています。例えば、ハワード・シュミット、米国のオバマ大統領へのサイバーセキュリティのための特別顧問として、2005年に言った:「ホームベースおよび無担保のネットワークへの攻撃が大規模な組織に対するものの必要性と同じくらい一般的になったよう。また、さらに世界中でブロードバンドの利用を成長させる大きな可能性がある私たちの国の情報バックボーンの保全のために重要である加入者のためのセキュリティを容易にするために、彼らはできる限りのことを行うためのISP、および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はユーザーに通知するかかる場合があります別のアプローチであり、この方法は、他の文書とコミュニティの努力で可能な代替として検討されています。そのため、ウェブの通知は、ドキュメントに値する多くの可能な通知方法のいずれかを考慮しなければなりません。
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.
しかし、壁、庭のアプローチは、課題を提起することができますし、いくつかのケースでは、エンドユーザーに破壊的と考えることができます。例えば、ユーザはおそらく、ユーザーが壁に囲まれた庭に置かれた時に動作を停止します専用の、インターネットに接続されたゲームコンソールの使用を経て、オンラインゲームをプレイすることができます。別の例では、ユーザーは、おそらくユーザーは壁に囲まれた庭に置かれた時に動作を停止しますいくつかの種類のボイスオーバー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の既存のワーキンググループは、マルウェアの感染と関連する問題の問題に焦点を当てていません。その結果、このドキュメントのための明確な会場がありませんでしたので、それは独立したサブミッションとして独立提出エディタに提出されました。このシステムのドキュメントおよび開示は、それ自体のインターネットコミュニティのために有益ですが、公表され、この文書を有することに他の利点があります。それらの理由の一つは、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.
著者は、彼の優れたフィードバックだけでなく、文書をレビューし、他人のために彼女のレビューと文書でコメントのアリッサ・クーパー、およびNevilブラウンリーに感謝したいです。
[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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC2854]コノリー、D.およびL. Masinter、 " '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]黒、D.、つば、S.、大工、B.、およびF.ルFaucheur、 "当たりホップ行動識別コード"、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.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、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]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
[RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation Protocol (ICAP)", RFC 3507, April 2003.
[RFC3507]エルソン、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子(URI):汎用構文"、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.、チャン、K.、およびF.ベイカー、 "DiffServのサービスクラスの設定時の注意事項"、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
チェ・チョンComcastのケーブルコミュニケーションズ一つコムキャストセンター1701ジョンF.ケネディ大通りフィラデルフィア、PA 19103米国電子メール: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
アレックス・カシヤノフComcastのケーブルコミュニケーションズ一つコムキャストセンター1701ジョンF.ケネディ大通りフィラデルフィア、PA 19103米国電子メール: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
ジェイソンLivingood Comcastのケーブルコミュニケーションズ一つコムキャストセンター1701ジョンF.ケネディ大通りフィラデルフィア、PA 19103米国電子メール: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
ニーマルモディComcastのケーブルコミュニケーションズ一つコムキャストセンター1701ジョンF.ケネディ大通りフィラデルフィア、PA 19103米国電子メール:nirmal_mody@cable.comcast.com URI:http://www.comcast.com
Brian Van Lieu Unaffiliated Bethlehem, PA 18018 US EMail: brian@vanlieu.net
ブライアン・ヴァン・リュー無所属ベツレヘム、PA 18018米国電子メール:brian@vanlieu.net