RFC5039 日本語訳
5039 The Session Initiation Protocol (SIP) and Spam. J. Rosenberg, C.Jennings. January 2008. (Format: TXT=73341 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 5039 C. Jennings
Category: Informational Cisco
January 2008
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 5039年のC.ジョニングスカテゴリ: 情報のコクチマス2008年1月
The Session Initiation Protocol (SIP) and Spam
セッション開始プロトコル(一口)とスパム
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.
大量のお節介なメッセージの伝達と定義されたスパムはインターネットメールを苦しめました。 残念ながら、スパムは、メールするために制限されません。 それはユーザからユーザへのコミュニケーションを可能にするどんなシステムにも影響できます。 Session Initiationプロトコル(SIP)はユーザからユーザへのマルチメディア通信のシステムを定義します。 したがって、ばらまくのはちょうどメールのように影響されやすいです。 本書では、私たちはSIPでスパムの問題を分析します。 私たちは最初に、問題が同じである方法とそれがメールと異なっている方法を特定します。 私たちは、次に、メールのために議論した様々な可能な解決策を調べて、SIPへの彼らの適用性を考えます。
Rosenberg & Jennings Informational [Page 1] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[1ページ]のRFC5039SIPは2008年1月にばらまかれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Call Spam . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. IM Spam . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Presence Spam . . . . . . . . . . . . . . . . . . . . . . 7
3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Content Filtering . . . . . . . . . . . . . . . . . . . . 8
3.2. Black Lists . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. White Lists . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Consent-Based Communications . . . . . . . . . . . . . . . 10
3.5. Reputation Systems . . . . . . . . . . . . . . . . . . . . 12
3.6. Address Obfuscation . . . . . . . . . . . . . . . . . . . 14
3.7. Limited-Use Addresses . . . . . . . . . . . . . . . . . . 14
3.8. Turing Tests . . . . . . . . . . . . . . . . . . . . . . . 15
3.9. Computational Puzzles . . . . . . . . . . . . . . . . . . 17
3.10. Payments at Risk . . . . . . . . . . . . . . . . . . . . . 17
3.11. Legal Action . . . . . . . . . . . . . . . . . . . . . . . 18
3.12. Circles of Trust . . . . . . . . . . . . . . . . . . . . . 19
3.13. Centralized SIP Providers . . . . . . . . . . . . . . . . 19
4. Authenticated Identity in Email . . . . . . . . . . . . . . . 20
4.1. Sender Checks . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Signature-Based Techniques . . . . . . . . . . . . . . . . 21
5. Authenticated Identity in SIP . . . . . . . . . . . . . . . . 22
6. Framework for Anti-Spam in SIP . . . . . . . . . . . . . . . . 23
7. Additional Work . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Informative References . . . . . . . . . . . . . . . . . . . . 25
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 問題定義. . . . . . . . . . . . . . . . . . . . . . 3 2.1。 スパム. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2に電話をしてください。 不-.72.3をばらまいてください。 存在スパム. . . . . . . . . . . . . . . . . . . . . . 7 3。 ソリューションスペース. . . . . . . . . . . . . . . . . . . . . . . . 8 3.1。 コンテントのフィルタリング. . . . . . . . . . . . . . . . . . . . 8 3.2。 黒人は.93.3を記載します。 ホワイトは.93.4を記載します。 同意ベースのコミュニケーション. . . . . . . . . . . . . . . 10 3.5。 評判システム. . . . . . . . . . . . . . . . . . . . 12 3.6。 困惑. . . . . . . . . . . . . . . . . . . 14 3.7を記述してください。 株式会社使用は.143.8を記述します。 チューリングは.153.9をテストします。 コンピュータのパズル. . . . . . . . . . . . . . . . . . 17 3.10。 リスク. . . . . . . . . . . . . . . . . . . . . 17 3.11の支払い。 訴訟. . . . . . . . . . . . . . . . . . . . . . . 18 3.12。 信用. . . . . . . . . . . . . . . . . . . . . 19 3.13の円。 一口プロバイダー. . . . . . . . . . . . . . . . 19 4を集結しました。 メール. . . . . . . . . . . . . . . 20 4.1でアイデンティティを認証しました。 送付者は.214.2をチェックします。 署名ベースのテクニック. . . . . . . . . . . . . . . . 21 5。 一口. . . . . . . . . . . . . . . . 22 6におけるアイデンティティを認証しました。 一口. . . . . . . . . . . . . . . . 23 7における反スパムのための枠組み。 追加仕事. . . . . . . . . . . . . . . . . . . . . . . 24 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 24 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 24 10。 有益な参照. . . . . . . . . . . . . . . . . . . . 25
Rosenberg & Jennings Informational [Page 2] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[2ページ]のRFC5039SIPは2008年1月にばらまかれます。
1. Introduction
1. 序論
Spam, defined as the transmission of bulk unsolicited email, has been a plague on the Internet email system. Many solutions have been documented and deployed to counter the problem. None of these solutions is ideal. However, one thing is clear: the spam problem would be much less significant had solutions been deployed ubiquitously before the problem became widespread.
大量の求められていないメールの伝達と定義されたスパムはインターネットメールシステムにおける疫病です。 多くの解決策が、問題を打ち返すために記録されて、配備されました。 これらの解決策のいずれも理想的ではありません。 しかしながら、1つのものが明確です: 問題が広範囲になる前に解決策が遍在して配備されたなら、スパム問題はあまりそれほど重要でないでしょう。
The Session Initiation Protocol (SIP) [2] is used for multimedia communications between users, including voice, video, instant messaging, and presence. Consequently, it can be just as much of a target for spam as email. To deal with this, solutions need to be defined and recommendations put into place for dealing with spam as soon as possible.
Session Initiationプロトコル(SIP)[2]は声、ビデオ、インスタントメッセージング、および存在を含むユーザの間のマルチメディア通信に使用されます。 その結果、それはスパムのためのメールするのとちょうど同じくらい大した目標であるかもしれません。 これ、定義されるべき解決策の必要性、および推薦に対処するには、できるだけ早くスパムに対処するために場所を入れてください。
This document serves to meet those goals by defining the problem space more concretely, analyzing the applicability of solutions used in the email space, identifying protocol mechanisms that have been defined for SIP that can help the problem, and making recommendations for implementors.
このドキュメントは、問題の定義スペースのそばでそれらの目標をより具体的に達成するのに役立ちます、メールスペースで使用される解決策の適用性を分析して、問題を助けることができるSIPのために定義されて、作成者のために推薦状をしているプロトコルメカニズムを特定して。
2. Problem Definition
2. 問題定義
The spam problem in email is well understood, and we make no attempt to further elaborate on it here. The question, however, is what is the meaning of spam when applied to SIP? Since SIP covers a broad range of functionality, there appear to be three related but different manifestations:
メールによるスパム問題はよく理解されています、そして、私たちはここで促進しない試みを全くそれで入念にします。 しかしながら、質問はSIPに適用されるとスパムの意味であることですか? SIPが広範囲な機能性をカバーしているので、3つの関連しますが、異なった顕現があるように見えます:
Call Spam: This type of spam is defined as a bulk unsolicited set of
session initiation attempts (i.e., INVITE requests), attempting to
establish a voice, video, instant messaging [1], or other type of
communications session. If the user should answer, the spammer
proceeds to relay their message over the real-time media. This is
the classic telemarketer spam, applied to SIP. This is often
called SPam over Ip Telephony, or SPIT.
スパムに電話をしてください: このタイプのスパムは大量の求められていないセットのセッション開始試み(すなわち、INVITE要求)と定義されます、声を確立するのを試みて、ビデオ、インスタントメッセージング[1]、または他のタイプのコミュニケーションセッション。 ユーザが答えるなら、リアルタイムのメディアの上でそれらのメッセージをリレーするスパマー売り上げです。 これはSIPに適用された古典的なテレマーケティングをする人スパムです。 これはIp Telephony、またはSPITの上にしばしばSPamと呼ばれます。
IM Spam: This type of spam is similar to email. It is defined as a
bulk unsolicited set of instant messages, whose content contains
the message that the spammer is seeking to convey. IM spam is
most naturally sent using the SIP MESSAGE [3] request. However,
any other request that causes content to automatically appear on
the user's display will also suffice. That might include INVITE
requests with large Subject headers (since the Subject is
sometimes rendered to the user), or INVITE requests with text or
HTML bodies. This is often called SPam over Instant Messaging, or
SPIM.
不-ばらまいてください: このタイプのスパムは、メールするために同様です。 それは運ぶインスタントメッセージの大量の求められていないセットと定義されます。(インスタントメッセージの内容はスパマーが探しているというメッセージを含みます)。 IMスパムにSIP MESSAGE[3]要求を最も自然に使用させます。 しかしながら、また、内容が自動的にユーザの表示に現れるいかなる他の要求も十分でしょう。 大きいSubjectヘッダー(時々Subjectをユーザに提供するので)と共にINVITE要求を含んでいるか、またはそれはテキストかHTML本体でINVITE要求を含むかもしれません。 これはInstant Messaging、またはSPIMの上にしばしばSPamと呼ばれます。
Rosenberg & Jennings Informational [Page 3] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[3ページ]のRFC5039SIPは2008年1月にばらまかれます。
Presence Spam: This type of spam is similar to IM spam. It is
defined as a bulk unsolicited set of presence requests (i.e.,
SUBSCRIBE requests [4] for the presence event package [6]), in an
attempt to get on the "buddy list" or "white list" of a user in
order to send them IM or initiate other forms of communications.
This is occasionally called SPam over Presence Protocol, or SPPP.
存在スパム: このタイプのスパムはIMスパムと同様です。 それが大量の求められていないセットの存在要求と定義される、(登録、すなわち、存在出来事を求める要求[4]は[6])をパッケージします、IMをそれらに送るか、または他のフォームに関するコミュニケーションを開始に送るためにユーザの「友達リスト」か「ホワイトリスト」に乗る試みで。 これはPresenceプロトコル、またはSPPPの上に時折SPamと呼ばれます。
There are many other SIP messages that a spammer might send. However, most of the other ones do not result in content being delivered to a user, nor do they seek input from a user. Rather, they are answered by automata. OPTIONS is a good example of this. There is little value for a spammer in sending an OPTIONS request, since it is answered automatically by the User Agent Server (UAS). No content is delivered to the user, and they are not consulted.
スパマーが発信するかもしれないという他の多くのSIPメッセージがあります。 しかしながら、他のものの大部分はユーザに送られる内容をもたらしません、そして、彼らはユーザからの入力を求めません。 むしろ、それらはオートマトンによって答えられます。 OPTIONSはこの好例です。 OPTIONSが要求する発信にはスパマーのための値がほとんどありません、それがUserエージェントServer(UAS)によって自動的に答えられるので。 内容を全くユーザに送りません、そして、それらに相談しません。
In the sections below, we consider the likelihood of these various forms of SIP spam. This is done in some cases by a rough cost analysis. It should be noted that all of these analyses are approximate, and serve only to give a rough sense of the order of magnitude of the problem.
下のセクションでは、私たちはこれらの様々なフォームのSIPスパムの見込みを考えます。 いくつかの場合、概算原価分析でこれをします。 これらの分析のすべてが、大体であり、単に問題の桁の荒い感覚を与えるのに役立つことに注意されるべきです。
2.1. Call Spam
2.1. スパムに電話をしてください。
Will call spam occur? That is an important question to answer. Clearly, it does occur in the existing telephone network, in the form of telemarketer calls. Although these calls are annoying, they do not arrive in the same kind of volume as email spam. The difference is cost; it costs more for the spammer to make a phone call than it does to send email. This cost manifests itself in terms of the cost for systems that can perform telemarketer call, and in cost per call.
呼び出しスパムは起こるでしょうか? それは答える重要な問題です。 明確に、それは既存の電話網、テレマーケティングをする人呼び出しの形に起こります。 これらの呼び出しは煩わしいのですが、それらはメールスパムへの同じ種類のボリュームに達しません。 違いは費用です。 スパマーが電話をかけるのにメールを送るのはそうする以上かかります。 この費用はシステムのためのテレマーケティングをする人呼び出しを実行できる費用、および1呼び出しあたりの費用で現れます。
Both of these costs are substantially reduced by SIP. A SIP call spam application is easy to write. It is just a SIP User Agent that initiates, in parallel, a large number of calls. If a call connects, the spam application generates an ACK and proceeds to play out a recorded announcement, and then it terminates the call. This kind of application can be built entirely in software, using readily available (and indeed, free) off-the-shelf software components. It can run on a low-end PC and requires no special expertise to execute.
SIPはこれらのコストの両方をかなり減少させます。 SIP呼び出しスパムアプリケーションは書きやすいです。 それはただ平行で多くの呼び出しを開始するSIP Userエージェントです。 呼び出しが接続するなら、スパムアプリケーションは、ACKを発生させて、記録された発表を終えかけます、そして、次に、それは呼び出しを終えます。 ソフトウェア、完全に容易に利用可能な使用でこの種類の適用を組み込むことができる、(本当に、解放、)、市販のソフトウェアの部品。 それは、ローエンドPCで動くことができて、実行するどんな特別な専門的技術も必要としません。
The cost per call is also substantially reduced. A normal residential phone line allows only one call to be placed at a time. If additional lines are required, a user must purchase more expensive connectivity. Typically, a T1 or T3 would be required for a large- volume telemarketing service. That kind of access is very expensive and well beyond the reach of an average user. A T1 line is approximately US $250 per month, and about 1.5 cents per minute for calls. T1 lines used only for outbound calls (such as in this case)
また、1呼び出しあたりのコストはかなり削減されます。 正常な住宅の電話回線は一度に置かれるという1つの要求だけを許します。 追加線が必要であるなら、ユーザは、より高価な接続性を購入しなければなりません。 T1かT3が大きいボリュームテレマーケティングサービスに通常、必要でしょう。 その種類のアクセスは、一般ユーザーの範囲を超えて非常に高価であって、良いです。 T1線はほとんど1カ月あたり250ドル、および呼び出しのための分あたりおよそ1.5セント米国です。 外国行きの呼び出しにだけ使用されるT1線(この場合)
Rosenberg & Jennings Informational [Page 4] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[4ページ]のRFC5039SIPは2008年1月にばらまかれます。
are even more expensive than inbound trunks due to the reciprocal termination charges that a provider pays and receives.
本国行きのトランクスはプロバイダーに支払って、受信されるという相互的な解約料がそうするより高価な状態で、同等です。
There are two aspects to the capacity: the call attempt rate, and the number of simultaneous successful calls that can be in progress. A T1 would allow a spammer, at most, 24 simultaneous calls, and assuming about 10 seconds for each call attempt, about 2.4 call attempts per second. At high-volume calling, the per-minute rates far exceed the flat monthly fee for the T1. The result is a cost of 250,000 microcents for each successful spam delivery, assuming 10 seconds of content.
容量への2つの局面があります: 呼び出し試み率、および進行できる同時のうまくいっている呼び出しの数。 T1はスパマーを許容するでしょう、大部分と、24の同時の呼び出しと、それぞれの呼び出し試みあたりおよそ10秒を仮定するのに、1秒あたりおよそ2.4の呼び出し試み。 大容量では、呼ぶ分は遠くに評価します。T1のために一律の月料金を超えてください。 10秒の内容を仮定して、結果はそれぞれのうまくいっているスパム配送のための25万microcentsの費用です。
With SIP, this cost is much reduced. Consider a spammer using a typical broadband Internet connection that provides 500 Kbps of upstream bandwidth. Initiating a call requires just a single INVITE message. Assuming, for simplicity's sake, that this is 1 KB, a 500 Kbps upstream DSL or cable modem connection will allow about 62 call attempts per second. A successful call requires enough bandwidth to transmit a message to the receiver. Assuming a low compression codec (say, G.723.1 at 5.3 Kbps), this requires approximately 16 Kbps after RTP, UDP, and IP overheads. With 500 Kbps upstream bandwidth, this means as many as 31 simultaneous calls can be in progress. With 10 seconds of content per call, that allows for 3.1 successful call attempts per second. If broadband access is around $50/month, the cost per successful voice spam is about 6.22 microcents each. This assumes that calls can be made 24 hours a day, 30 days a month, which may or may not be the case.
SIPと共に、このコストは非常に削減されます。 上流の帯域幅の500Kbpsを提供する典型的なブロードバンドインターネット回線を使用して、スパマーを考えてください。 呼び出しを開始するのはまさしくただ一つのINVITEメッセージを必要とします。 簡単さのためにこれが500の1KB、Kbpsの上流のDSLまたはケーブル・モデム接続であると仮定するのが1秒あたりおよそ62の呼び出し試みを許すでしょう。 うまくいっている呼び出しは、帯域幅が受信機に送信するのを十分必要とします。低い圧縮コーデックが(たとえば、5.3KbpsのG.723.1)であると仮定して、これはRTP、UDP、およびIPオーバーヘッドの後におよそ16Kbpsを必要とします。 500Kbpsと共に、上流の帯域幅、31の同時の呼び出しと同じくらい多くのこの手段は進行できます。 1呼び出しあたりの10秒の内容で、それは1秒あたり3.1のうまくいっている呼び出し試みを考慮します。 広帯域アクセスがおよそ50ドル/月であるなら、うまくいっている音声スパムあたりの費用はそれぞれおよそ6.22microcentsです。 これは、1日24時間、30日間電話を1カ月かけることができると仮定します(ケースであるかもしれません)。
These figures indicate that SIP call spam is roughly four orders of magnitude cheaper to send than traditional circuit-based telemarketer calls. This low cost is certainly going to be very attractive to spammers. Indeed, many spammers utilize computational and bandwidth resources provided by others, by infecting their machines with viruses that turn them into "zombies" that can be used to generate spam. This can reduce the cost of call spam to nearly zero.
これらの数字は、SIP呼び出しスパムが発信するのに伝統的なサーキットベースのテレマーケティングをする人呼び出しよりおよそ4桁安いのを示します。 確かに、この低価格はスパマーにとって非常に魅力的になるでしょう。 本当に、多くのスパマーが他のものでコンピュータと帯域幅調達資金を利用します、それらをスパムを発生させるのに使用できる「ゾンビ」に変えるウイルスで彼らのマシンを染めることによって。 これは呼び出しスパムのコストをおよそゼロまで削減できます。
Even ignoring the zombie issue, this reduction in cost is even more amplified for international calls. Currently, there are few telemarketing calls across international borders, largely due to the large cost of making international calls. This is one of the reasons why the "do not call list", a United States national list of numbers that telemarketers cannot call -- has been effective. The law only affects U.S. companies, but since most telemarketing calls are domestic, it has been effective. Unfortunately (and fortunately), the IP network provides no boundaries of these sorts, and calls to any SIP URI are possible from anywhere in the world. This will allow for international spam at a significantly reduced cost.
ゾンビ問題を無視さえして、この原価低減は国際電話のためにさらに増幅されてさえいます。 現在、テレマーケティング呼び出しが主に国際電話をする大きい費用のために国際的な境界のむこうにわずかしかありません。 これは「呼び出しは記載しない」で、a合衆国国家が記載するテレマーケティングをする人が電話をすることができない数の理由の1つです--有効でした。 法は米国会社に影響するだけですが、ほとんどのテレマーケティング呼び出しがドメスティックであるので、それは有効です。 残念ながら(幸い)、IPネットワークはこれらの種類の境界を全く提供しません、そして、どんなSIP URIへの呼び出しも世界でどこでも、から可能です。 これはかなり減少している費用で国際的なスパムを考慮するでしょう。
Rosenberg & Jennings Informational [Page 5] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[5ページ]のRFC5039SIPは2008年1月にばらまかれます。
International spam is likely to be even more annoying than national spam, since it may arrive in languages that the recipient doesn't even speak.
国際スパムは国家のスパムよりさらに煩わしい傾向があります、受取人が話してさえいない言語で到着するかもしれないので。
These figures assume that the primary limitation is the access bandwidth and not CPU, disk, or termination costs. Termination costs merit further discussion. Currently, most Voice over IP (VoIP) calls terminate on the Public Switched Telephone Network (PSTN), and this termination costs the originator of the call money. These costs are similar to the per-minute rates of a T1. It ranges anywhere from half a cent to three cents per minute, depending on volume and other factors. However, equipment costs, training, and other factors are much lower for SIP-based termination than a T1, making the cost still lower than circuit connectivity. Furthermore, the current trend in VoIP systems is to make termination free for calls that never touch the PSTN, that is, calls to actual SIP endpoints. Thus, as more and more SIP endpoints come online, termination costs will probably drop. Until then, SIP spam can be used in concert with termination services for a lower-cost form of traditional telemarketer calls, made to normal PSTN endpoints.
これらの数字は、第一の制限がCPU、ディスク、または終了コストではなく、アクセス帯域幅であると仮定します。 終了コストはさらなる議論に値します。 現在、ほとんどのボイス・オーバー IP(VoIP)呼び出しがPublic Switched Telephone Network(PSTN)で終わります、そして、この終了はコールマネーの創始者かかります。 これらのコストはT1の1分あたりのレートと同様です。 ボリュームと他の要素によって、それはどこでも1分あたり0.5セントから3セントで及びます。 しかしながら、SIPベースの終了には、設備コスト、トレーニング、および他の要素はT1よりはるかに低いです、費用をサーキットの接続性よりなお低くして。 その上、VoIPシステムにおける現在の傾向は呼び出しにおける、無料の終了をPSTN(すなわち、実際のSIP終点への呼び出し)に決して、触れさせないことです。 したがって、ますます多くのSIP終点がオンラインで来るのに従って、終了コストはたぶん低下するでしょう。 それまで、正常なPSTN終点にかけられる伝統的なテレマーケティングをする人電話の低い費用フォームのための終了サービスと協力してSIPスパムを使用できます。
It is useful to compare these figures with email. VoIP can deliver approximately 3.1 successful call attempts per second. Email spam can, of course, deliver more. Assuming 1 KB per email, and an upstream link of 500 Kbps, a spammer can generate 62.5 messages per second. This number goes down with larger messages of course. Interestingly, spam filters delete large numbers of these mails, so the cost per viewed message is likely to be much higher. In that sense, call spam is much more attractive, since its content is much more likely to be examined by a user if a call attempt is successful.
これらの数字をメールと比べるのは役に立ちます。 VoIPは1秒あたりおよそ3.1のうまくいっている呼び出し試みを提供できます。 メールスパムはもちろんさらに配送されることができます。 1メールあたり1KB、および500Kbpsの上流のリンクを仮定する場合、スパマーは1秒あたり62.5のメッセージを発生させることができます。 この数はもちろんより大きいメッセージにかかります。 おもしろく、スパムフィルターがこれらの多くのメールを削除するので、見られたメッセージあたりの費用ははるかに高い傾向があります。 その意味で、呼び出しスパムははるかに魅力的です、呼び出し試みがうまくいくなら内容がユーザによってはるかに調べられそうであるので。
Another part of the cost of spamming is collecting addresses. Spammers have, over time, built up immense lists of email addresses, each of the form user@domain, to which spam is directed. SIP uses the same form of addressing, making it likely that email addresses can easily be turned into valid SIP addresses. Telephone numbers also represent valid SIP addresses; in concert with a termination provider, a spammer can direct SIP calls at traditional PSTN devices. It is not clear whether email spammers have also been collecting phone numbers as they perform their Web sweeps, but it is probably not hard to do so. Furthermore, unlike email addresses, phone numbers are a finite address space and one that is fairly densely packed. As a result, going sequentially through phone numbers is likely to produce a fairly high hit rate. Thus, it seems like the cost is relatively low for a spammer to obtain large numbers of SIP addresses to which spam can be directed.
ばらまくことの費用の別の部分はアドレスを集めることです。 スパマーは時間がたつにつれて、Eメールアドレスの莫大なリスト、それぞれのフォーム user@domain を確立しました。(スパムは user@domain に向けられます)。 SIPは同じフォームのアドレシングを使用します、容易にEメールアドレスを有効なSIPアドレスに変えることができるのをありそうにして。 また、電話番号は有効なSIPアドレスを表します。 終了プロバイダーと協力して、スパマーは伝統的なPSTN装置にSIP呼び出しを向けることができます。 また、メールスパマーが彼らのウェブ視聴率調査期間を実行しますが、たぶんそうしにくくないので電話番号を集めているかどうかは、明確ではありません。 その上、電話番号は、Eメールアドレスと異なって、有限アドレス空間と密に公正に梱包されたものです。 その結果、電話番号に連続して直面しているのはかなり高いヒット率を生産しそうです。 したがって、スパマーがスパムを向けることができる多くのSIPアドレスを得るように費用が比較的低いように見えます。
Rosenberg & Jennings Informational [Page 6] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[6ページ]のRFC5039SIPは2008年1月にばらまかれます。
2.2. IM Spam
2.2. 不-スパム
IM spam is very much like email, in terms of the costs for deploying and generating spam. Assuming, for the sake of argument, a 1KB message to be sent and 500 Kbps of upstream bandwidth, that is 62.5 messages per second. At $50/month, the result is .31 microcents per message. This is less than voice spam, but not substantially less. The cost is probably on par with email spam. However, IM is much more intrusive than email. In today's systems, IMs automatically pop up and present themselves to the user. Email, of course, must be deliberately selected and displayed. However, most popular IM systems employ white lists, which only allow IM to be delivered if the sender is on the white list. Thus, whether or not IM spam will be useful seems to depend a lot on the nature of the systems as the network is opened up. If they are ubiquitously deployed with white- list access, the value of IM spam is likely to be low.
IMスパムはスパムを配備して、発生させるためのコストに関するメールに似ています。 上流の帯域幅の議論、1KBの送られるべきメッセージ、および500Kbpsのためにそれを仮定するのは、1秒あたり62.5のメッセージです。 50ドル/月に、1メッセージあたり結果は.31microcentsです。 これは、音声スパムより少ないのですが、実質的により少ないというわけではありません。 費用がたぶん平価にメールスパムであります。 しかしながら、IMはメールよりはるかに押しつけがましいです。 今日のシステムでは、IMsは自動的に急に現れて、ユーザに出向きます。 もちろんメールを故意に選択して、表示しなければなりません。 しかしながら、ほとんどのポピュラーなIMシステムがホワイトリストを使います。(送付者がホワイトリストにいる場合にだけ、ホワイトリストは、IMが届けられるのを許容します)。 したがって、IMスパムが役に立つかどうかがネットワークが開けられるときシステムの本質に大いによるように思えます。 それらが白いリストアクセスで遍在して配備されるなら、IMスパムの値は低い傾向があります。
It is important to point out that there are two different types of IM systems: page mode and session mode. Page mode IM systems work much like email, with each IM being sent as a separate message. In session mode IM, there is signaling in advance of communication to establish a session, and then IMs are exchanged, perhaps point-to- point, as part of the session. The modality impacts the types of spam techniques that can be applied. Techniques for email can be applied identically to page mode IM, but session mode IM is more like telephony, and many techniques (such as content filtering) are harder to apply.
2つの異なったタイプのIMシステムがあると指摘するのは重要です: ページモードとセッションモード。 ページモードIMシステムはメールのように別々のメッセージとして各IMを送って動作します。 セッションモードIMには、コミュニケーションの前にセッションを確立すると合図するのがあります、そして、次に、IMsを交換します、恐らくポイントからポイント、セッションの一部として。 様式は適用できるスパムのテクニックのタイプに影響を与えます。 セッションモードIMはさらに電話に似ています、そして、同様にメールのためのテクニックをページモードIMに適用できますが、多くのテクニック(コンテントのフィルタリングなどの)はより適用しにくいです。
2.3. Presence Spam
2.3. 存在スパム
As defined above, presence spam is the generation of bulk unsolicited SUBSCRIBE messages. The cost of this is within a small constant factor of IM spam so the same cost estimates can be used here. What would be the effect of such spam? Most presence systems provide some kind of consent framework. A watcher that has not been granted permission to see the user's presence will not gain access to their presence. However, the presence request is usually noted and conveyed to the user, allowing them to approve or deny the request. In SIP, this is done using the watcherinfo event package [7]. This package allows a user to learn the identity of the watcher, in order to make an authorization decision.
存在スパムが上で定義されるように大量求められていないことの世代である、登録、メッセージ。 ここで費用見積りを使用できるようにとても同じIMスパムの小さい恒常的要因の中にこの費用はあります。 そのようなスパムの効果は何でしょうか? ほとんどの存在システムがある種の同意枠組みを提供します。 ユーザの存在を見る許可が与えられていないウォッチャーはそれらの存在へのアクセスを得ないでしょう。 しかしながら、彼らが要求を承認するか、または否定するのを許容して、存在要求は、通常、注意されて、ユーザに伝えられます。 SIPでは、これはwatcherinfoイベントパッケージ[7]を使用し終わっています。 このパッケージで、ユーザは、認可決定をするようにウォッチャーのアイデンティティを学ぶことができます。
Interestingly, this provides a vehicle for conveying information to a user. By generating SUBSCRIBE requests from identities such as sip:please-buy-my-product@spam.example.com, brief messages can be conveyed to the user, even though the sender does not have, and never will receive, permission to access presence. As such, presence spam can be viewed as a form of IM spam, where the amount of content to be
おもしろく、これはユーザに情報を伝達するための乗り物を提供します。 一口などのアイデンティティからの要求: 登録、 please-buy-my-product@spam.example.com を発生させることによって、簡潔なメッセージをユーザに伝えることができます、送付者は、存在にアクセスする許可を持たないで、また決して受けないでしょうが。 そういうものとして、見なすためにIMスパム、どこに関する内容の量のフォームとして存在スパムを見なすことができるか。
Rosenberg & Jennings Informational [Page 7] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[7ページ]のRFC5039SIPは2008年1月にばらまかれます。
conveyed is limited. The limit is equal to the amount of information generated by the watcher that gets conveyed to the user through the permission system.
運び、制限されます。 限界は許可システムを通してユーザまで運ばれるウォッチャーによって発生した情報量と等しいです。
This type of spam also shows up in consent frameworks used to prevent call spam, as discussed in Section 3.4.
また、このタイプのスパムは呼び出しスパムを防ぐのにセクション3.4で議論するように使用される同意枠組みで現れます。
3. Solution Space
3. ソリューションスペース
In this section, we consider the various solutions that might be possible to deal with SIP spam. We primarily consider techniques that have been employed to deal with email spam. It is important to note that the solutions documented below are not meant to be an exhaustive study of the spam solutions used for email but rather just a representative set. We also consider some solutions that appear to be SIP-specific.
このセクションでは、私たちは、可能であるかもしれない様々な解決策がSIPスパムに対処すると考えます。 私たちは、メールに対処するのに使われたテクニックがばらまかれると主として考えます。 以下に記録された解決策がメールに使用されるスパム解決策の徹底的な研究であることは意味されないことに注意するのが重要ですが、むしろまさしく代表はセットしました。 また、私たちは、現れる何らかの解決法がSIP特有であると考えます。
3.1. Content Filtering
3.1. コンテントのフィルタリング
The most common form of spam protection used in email is based on content filtering. Spam filters analyze the content of the email, and look for clues that the email is spam. Bayesian spam filters are in this category.
メールで使用される最も一般的な形式のスパム保護はコンテントのフィルタリングに基づいています。 スパムフィルターは、メールの中身を分析して、メールがスパムであるという手がかりを探します。 ベイズ理論スパムフィルターがこのカテゴリにあります。
Unfortunately, this type of spam filtering, while successful for email spam, is completely useless for call spam. There are two reasons. First, in the case where the user answers the call, the call is already established and the user is paying attention before the content is delivered. The spam cannot be analyzed before the user sees it. Second, if the content is stored before the user accesses it (e.g., with voicemail), the content will be in the form of recorded audio or video. Speech and video recognition technology is not likely to be good enough to analyze the content and determine whether or not it is spam. Indeed, if a system tried to perform speech recognition on a recording in order to perform such an analysis, it would be easy for the spammers to make calls with background noises, poor grammar, and varied accents, all of which will throw off recognition systems. Video recognition is even harder to do and remains primarily an area of research.
残念ながら、メールスパムでうまくいきますが、呼び出しスパムには、このタイプのスパムフィルタリングは完全に役に立ちません。 2つの理由があります。 まず最初に、ユーザが電話口に出る場合では、呼び出しは既に確立されます、そして、内容を送る前にユーザは注意を向けています。 ユーザがそれを見る前にスパムを分析できません。 2番目に、ユーザがそれ(例えば、ボイスメールがある)にアクセスする前に内容が格納されると、内容が記録されたオーディオかビデオの形にあるでしょう。 スピーチとビデオ認識技術は内容を分析して、それがスパムであるかどうか決定できるくらい良い傾向がありません。 本当に、システムがそのような分析を実行するために録音に音声認識を実行しようとするなら、スパマーがバックグラウンドノイズ、貧しい文法、および様々なアクセントで電話をかけるのは、簡単でしょうに。そのすべてが認定制度を混乱させるでしょう。ビデオ認識は、さらにしにくくて、主として研究の領域のままで残っています。
IM spam, due to its similarity to email, can be countered with content analysis tools. Indeed, the same tools and techniques used for email will directly work for IM spam.
メールする類似性のため満足している解析ツールでIMスパムを打ち返すことができます。 本当に、同じツールとメールに使用されるテクニックはIMスパムのために直接動作するでしょう。
Rosenberg & Jennings Informational [Page 8] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[8ページ]のRFC5039SIPは2008年1月にばらまかれます。
3.2. Black Lists
3.2. ブラックリスト
Black listing is an approach whereby the spam filter maintains a list of addresses that identify spammers. These addresses include both usernames (spammer@example.com) and entire domains (example.com). Pure blacklists are not very effective in email for two reasons. First, email addresses are easy to spoof, making it easy for the sender to pretend to be someone else. If the sender varies the addresses they send from, the black list becomes almost completely useless. The second problem is that, even if the sender doesn't forge the From address, email addresses are in almost limitless supply. Each domain contains an infinite supply of email addresses, and new domains can be obtained for very low cost. Furthermore, there will always be public providers that will allow users to obtain identities for almost no cost (for example, Yahoo or AOL mail accounts). The entire domain cannot be blacklisted because it contains so many valid users. Blacklisting needs to be for individual users. Those identities are easily changed.
黒いリストはスパムフィルターがスパマーを特定するアドレスのリストを維持するアプローチです。 これらのアドレスはユーザ名( spammer@example.com )と全体のドメイン(example.com)の両方を含んでいます。 純粋なブラックリストは2つの理由によるメールでそれほど効果的ではありません。 まず最初に、送付者が、他の誰かであるふりをするのを簡単にして、Eメールアドレスはだましやすいです。 送付者がそれらが発信するアドレスを変えるなら、ブラックリストはほぼ完全に役に立たなくなります。 2番目の問題は送付者がFromアドレスを偽造しないでもEメールアドレスがほとんど限のない供給中であるということです。 各ドメインはEメールアドレスの無限の供給を含んでいます、そして、非常に低い費用として新しいドメインを得ることができます。 その上、ユーザがほとんど費用がないのにアイデンティティを得ることができる公共のプロバイダーがいつもあるでしょう(例えば、YahooかAOLがアカウントを郵送します)。 とても多くの正規ユーザーを含むので、全体のドメインをブラックリストに載せることができません。 ブラックリストは、個々のユーザのためにある必要があります。 容易にそれらのアイデンティティを変えます。
As a result, as long as identities are easy to manufacture, or zombies are used, black lists will have limited effectiveness for email.
その結果、アイデンティティは製造しやすいか、またはゾンビが使用されている限り、ブラックリストがメールのために有効性を制限してしまうでしょう。
Blacklists are also likely to be ineffective for SIP spam. Mechanisms for inter-domain authenticated identity for email and SIP are discussed in Section 4 and Section 5. Assuming these mechanisms are used and enabled in inter-domain communications, it becomes difficult to forge sender addresses. However, it still remains cheap to obtain a nearly infinite supply of addresses.
また、ブラックリストもSIPスパムに効力がない傾向があります。 相互ドメインへのメカニズムはメールのためにアイデンティティを認証しました、そして、セクション4とセクション5でSIPについて議論します。 これらのメカニズムが相互ドメインコミュニケーションで使用されて、可能にされると仮定して、送付者アドレスを偽造するのは難しくなります。 しかしながら、まだ、安いままで、アドレスのほとんど無限の供給を得るのは残っています。
3.3. White Lists
3.3. ホワイトリスト
White lists are the opposite of black lists. It is a list of valid senders that a user is willing to accept email from. Unlike black lists, a spammer cannot change identities to get around the white list. White lists are susceptible to address spoofing, but a strong identity authentication mechanism can prevent that problem. As a result, the combination of white lists and strong identity, as described in Section 4.2 and Section 5, are a good form of defense against spam.
ホワイトリストはブラックリストの正反対です。 それはユーザが受け入れても構わないとメールを思っている有効な送付者のリストです。 ブラックリストと異なって、スパマーは、ホワイトリストを逃れるためにアイデンティティを変えることができません。 ホワイトリストはスプーフィングを記述するのにおいて影響されやすいのですが、強いアイデンティティ認証機構はその問題を防ぐことができます。 セクション4.2とセクション5における結果とホワイトリストの組み合わせと説明されるとしての強いアイデンティティがスパムに対するちゃんとした行儀作法のディフェンスであるので。
However, they are not a complete solution, since they would prohibit a user from ever being able to receive email from someone who was not explicitly put on the white list. As a result, white lists require a solution to the "introduction problem" - how to meet someone for the first time, and decide whether they should be placed in the white list. In addition to the introduction problem, white lists demand time from the user to manage.
しかしながら、それらは完全解ではありません、彼らがかつて明らかにホワイトリストに載せられなかっただれかからメールを受け取ることができることからユーザを禁じるでしょう、したがって。 その結果、ホワイトリストは「序論問題」の解決策を必要とします--初めてだれかに会って、それらがホワイトリストに置かれるべきであるかどうか決める方法。 序論問題に加えて、ホワイトリストは、管理するためにユーザからの時間を要求します。
Rosenberg & Jennings Informational [Page 9] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[9ページ]のRFC5039SIPは2008年1月にばらまかれます。
In IM systems, white lists have proven exceptionally useful at preventing spam. This is due, in no small part, to the fact that the white list exists naturally in the form of the buddy list. Users don't have to manage this list just for the purposes of spam prevention; it provides general utility, and assists in spam prevention for free. Many popular IM systems also have strong identity mechanisms since they do not allow communications with IM systems in other administrative domains. The introduction problem in these systems is solved with a consent framework, described below.
IMシステムで、ホワイトリストは例外的にスパムを防ぐのに有用であることが分かりました。 これは当然です、どんな小さい部分でもそうしません、ホワイトリストが友達リストの形に自然に存在しているという事実に。 ユーザはまさしくスパム防止の目的のためのこのリストを管理する必要はありません。 それは、ただで一般的なユーティリティを提供して、スパム防止を助けます。 また、他の管理ドメインのIMシステムとのコミュニケーションを許容しないので、多くのポピュラーなIMシステムには強いアイデンティティメカニズムがあります。 これらのシステムの序論問題は以下で説明された同意枠組みで解決されています。
The success of white lists in IM systems has applicability to SIP as well. This is because SIP also provides a buddy list concept and has an advanced presence system as part of its specifications. The introduction problem remains. In email, techniques like Turing tests have been employed to address the introduction problem. Turing tests are considered further in the sections below. As with email, a technique for solving the introduction problem would need to be applied in conjunction with a white list.
IMシステムのホワイトリストの成功はまた、SIPに適用性を持っています。 これはSIPがまた、友達リスト概念を提供して、仕様の一部として高度な存在システムを持っているからです。 序論問題は残っています。 メールでは、チューリングテストのようなテクニックは、その序論問題を訴えるのに使われました。 チューリングテストは下のセクションで、より遠くに考えられます。 メールなら、序論問題を解決するためのテクニックは、ホワイトリストに関連して適用される必要があるでしょう。
If a user's computer is compromised and used a zombie, that computer can usually be used to send spam to anyone that has put the user on their white list.
ユーザのコンピュータが妥協して、使用されて、ゾンビ、そのコンピュータが妥協できるなら通常、使用されて、それらのホワイトリストにユーザを載せただれにもスパムを送ってください。
3.4. Consent-Based Communications
3.4. 同意ベースのコミュニケーション
A consent-based solution is used in conjunction with white or black lists. That is, if user A is not on user B's white or black list, and user A attempts to communicate with user B, user A's attempt is initially rejected, and they are told that consent is being requested. Next time user B connects, user B is informed that user A had attempted communications. User B can then authorize or reject user A.
同意ベースの解決策は白いか黒いリストに関連して使用されます。 すなわち、ユーザAがユーザのビーズの白いか黒いリストにいないで、ユーザAが、ユーザBとコミュニケートするのを試みるなら、ユーザAの試みは初めは拒絶されます、そして、それらは同意が要求されていると言われます。 次の時間ユーザBは接続して、ユーザBにユーザAがコミュニケーションを試みたと知らされます。 そして、ユーザBは、ユーザAを権限を与えるか、または拒絶できます。
These kinds of consent-based systems are used widely in presence and IM. Since most of today's popular IM systems only allow communications within a single administrative domain, sender identities can be authenticated. Email often uses similar consent- based systems for mailing lists. They use a form of authentication based on sending cookies to an email address to verify that a user can receive mail at that address.
これらの種類の同意ベースのシステムは存在とIMで広く使用されます。 今日のポピュラーなIMシステムの大部分がただ一つの管理ドメインの中にコミュニケーションを許容するだけであるので、送付者のアイデンティティを認証できます。 しばしば同様の同意が基礎づけた用途にメーリングリストのシステムをメールしてください。 ユーザがそのアドレスにメールを受け取ることができることを確かめるためにクッキーをEメールアドレスに送ることに基づいて彼らは認証のフォームを使用します。
This kind of consent-based communications has been standardized in SIP for presence, using the watcher information event package [7] and data format [8], which allow a user to find out that someone has subscribed. Then, the XML Configuration Access Protocol (XCAP) [10] is used, along with the XML format for presence authorization [11] to provide permission for the user to communicate.
この種類の同意ベースのコミュニケーションは存在のためにSIPで標準化されました、ウォッチャー情報イベントパッケージ[7]とデータの形式[8](ユーザは、だれかが申し込んだのを見つけることができます)を使用して。 そして、存在認可[11]がユーザが交信する許可を提供するのにXML Configuration Accessプロトコル(XCAP)[10]はXML形式と共に使用されます。
Rosenberg & Jennings Informational [Page 10] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[10ページ]のRFC5039SIPは2008年1月にばらまかれます。
A consent framework has also been developed that is applicable to other forms of SIP communications [12]. However, this framework focuses on authorizing the addition of users to "mailing lists", known as exploders in SIP terminology. Though spammers typically use such exploder functions, presumably one run by a spammer would not use this technique. Consequently, this consent framework is not directly applicable to the spam problem. It is, however, useful as a tool for managing a white list. Through the PUBLISH mechanism, it allows a user to upload a permission document [13] that indicates that they will only accept incoming calls from a particular sender.
また、他のフォームに関するSIPコミュニケーション[12]に適切な同意枠組みを開発してあります。 しかしながら、この枠組みは、発破器としてSIP用語で知られている「メーリングリスト」へのユーザの追加を認可するのは焦点を合わせます。 スパマーはそのような発破器機能を通常使用しますが、おそらく、スパマーが走らせたのはこのテクニックを使用しないでしょう。 その結果、この同意枠組みは直接スパム問題に適用可能ではありません。 しかしながら、それはホワイトリストを管理するためのツールとして役に立ちます。 PUBLISHメカニズムを通して、それで、ユーザは彼らが特定の送付者からかかってきた電話を受け入れるだけであるのを示す許可ドキュメント[13]をアップロードできます。
Can a consent framework, like the ones used for presence, help solve call spam? At first glance, it would seem to help a lot. However, it might just change the nature of the spam. Instead of being bothered with content, in the form of call spam or IM spam, users are bothered with consent requests. A user's "communications inbox" might instead be filled with requests for communications from a multiplicity of users. Those requests for communications don't convey much useful content to the user, but they can convey some. At the very least, they will convey the identity of the requester. The user part of the SIP URI allows for limited free form text, and thus could be used to convey brief messages. One can imagine receiving consent requests with identities like "sip:please-buy-my-product-at-this-website@spam.example.com", for example. Fortunately, it is possible to apply traditional content filtering systems to the header fields in the SIP messages, thus reducing these kinds of consent request attacks.
存在に使用されるもののように、同意枠組みは、呼び出しスパムを解決するのを助けることができますか? 一見したところでは、それは大いに助けるように思えるでしょう。 しかしながら、それはただスパムの自然を変えるかもしれません。 内容で呼び出しスパムかIMスパムの形で苦しめられることの代わりに、ユーザは同意要求で苦しめられます。 ユーザの「コミュニケーション受信トレイ」は代わりにユーザの多様性からのコミュニケーションに関する要求で満たされるかもしれません。 コミュニケーションに関するそれらの要求は多くの役に立つ内容をユーザに伝えませんが、それらはいくつかを運ぶことができます。 少なくとも、彼らはリクエスタのアイデンティティを伝えるでしょう。 SIP URIの一部が考慮するユーザは、自由形式テキストを制限して、その結果、簡潔なメッセージを伝えるのに使用できました。 人は、例えば、「一口: please-buy-my-product-at-this-website@spam.example.com 」のようなアイデンティティで同意要求を受け取ると想像できます。 幸い、伝統的なコンテントのフィルタリングシステムをSIPメッセージのヘッダーフィールドに適用するのは可能です、その結果、これらの種類の同意要求攻撃を抑えます。
In order for the spammer to convey more extensive content to the user, the user must explicitly accept the request, and only then can the spammer convey the full content. This is unlike email spam, where, even though much spam is automatically deleted, some percentage of the content does get through, and is seen by users, without their explicit consent that they want to see it. Thus, if consent is required first, the value in sending spam is reduced, and perhaps it will cease for those spam cases where consent is not given to spammers.
スパマーが、より大規模な内容をユーザに伝えるように、ユーザは明らかに要請を受け入れなければなりません、そして、次に、スパマーは完全な内容を伝えることができるだけです。 これはメールスパムと異なっています、内容の何らかの割合が多くのスパムが自動的に削除されますが、通って、ユーザによって見られるところで、彼らがそれを見たがっている自分達の明白な同意なしで。 したがって、同意が最初に必要であるなら、送付スパムの値は減少します、そして、恐らく、それは同意がスパマーに与えられていないそれらのスパムケースのためにやむでしょう。
As such, the real question is whether or not the consent system would make it possible for a user to give consent to non-spammers and reject spammers. Authenticated identity can help. A user in an enterprise would know to give consent to senders in other enterprises in the same industry, for example. However, in the consumer space, if sip:bob@example.com tries to communicate with a user, how does that user determine whether Bob is a spammer or a long-lost friend from high school? There is no way based on the identity alone. In such a case, a useful technique is to grant permission for Bob to communicate but to ensure that the permission is extremely limited.
そういうものとして、本当の質問は同意制度でユーザが非スパマーに承諾を与えて、スパマーを拒絶するのが可能になるだろうかどうかということです。 認証されたアイデンティティは助けることができます。 企業のユーザは、例えば、同じ産業で送付者に他の企業で承諾を与えるのを知っているでしょう。 しかしながら、消費者スペースでは、一口: bob@example.com がユーザとコミュニケートしようとするなら、そのユーザは、高校からボブがスパマーかそれとも長らく所在不明の友であるかをどのように決心していますか? 単独でアイデンティティに基づく道が全くありません。 このような場合には、役に立つテクニックがボブが交信する許可を与えることですが、それを確実にするために、許可は非常に限られています。
Rosenberg & Jennings Informational [Page 11] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[11ページ]のRFC5039SIPは2008年1月にばらまかれます。
In particular, Bob may be granted permission to send no more than 200 words of text in a single IM, which he can use to identify himself, so that the user can determine whether or not more permissions are appropriate. It may even be possible that an automated system could do some form of content analysis on this initial short message. However, this 200 words of text may be enough for a spammer to convey their message, in much the same way they might convey it in the user part of the SIP URI.
特に、彼が自分の身分を証明するのに使用できる独身のIMのテキストに関する200未満の知らせを送る許可をボブに与えるかもしれません、ユーザが、より多くの許容が適切であるかどうかと決心できるように。 自動化されたシステムがこの初期の短いメッセージにおける何らかの形式の満足している分析をするかもしれないのは、可能でさえあるかもしれません。 しかしながら、スパマーがそれらのメッセージを伝えるように、テキストのこの200の単語が十分であるかもしれません、SIP URIのユーザ部分をそれを運ぶかもしれない似たり寄ったりの方法で。
Thus, it seems that a consent-based framework, along with white lists and black lists, cannot fully solve the problem for SIP, although it does appear to help.
したがって、同意ベースの枠組みがホワイトリストとブラックリストと共にSIPのための問題を完全に解決できるというわけではないように思えます、助けるように見えますが。
3.5. Reputation Systems
3.5. 評判システム
A reputation system is also used in conjunction with white or black lists. Assume that user A is not on user B's white list, and A attempts to contact user B. If a consent-based system is used, B is prompted to consent to communications from A, and along with the consent, a reputation score might be displayed in order to help B decide whether or not they should accept communications from A.
また、評判システムは白いか黒いリストに関連して使用されます。 Bが、それらがAからコミュニケーションを受け入れるべきであるかどうか決めるのを助けるためにユーザAがユーザビーズホワイトリスト、およびユーザB.Ifに連絡するA試みのときに同意ベースのシステムが使用されている、BがAからのコミュニケーションに承諾するようにうながされるということでなく、同意、評判スコアと共に表示されるかもしれないと仮定してください。
Traditionally, reputation systems are implemented in highly centralized messaging architectures; the most widespread reputation systems in messaging today have been deployed by monolithic instant messaging providers (though many Web sites with a high degree of interactivity employ very similar concepts of reputation). Reputation is calculated based on user feedback. For example, a button on the user interface of the messaging client might empower users to inform the system that a particular user is abusive. Of course, the input of any single user has to be insufficient to ruin one's reputation, but consistent negative feedback would give the abusive user a negative reputation score.
伝統的に、評判システムは非常に集結されたメッセージング構造で導入されます。 今日通信するのにおいて最も広範囲の評判システムは一枚岩的なインスタントメッセージングプロバイダーによって配備されました(高度の対話性がある多くのウェブサイトが評判の非常に同様の概念を使いますが)。 評判はユーザフィードバックに基づいて計算されます。 例えば、メッセージングクライアントのユーザーインタフェースの上のボタンは、ユーザが、特定のユーザが虐待的であることをシステムに知らせるのに権限を与えるかもしれません。 もちろん、どんなシングルユーザーの入力も人の評判を破滅させるためには不十分でなければなりませんが、一貫した負のフィードバックは負の評判スコアを虐待的なユーザに与えるでしょう。
Reputation systems have been successful in systems where centralization of resources (user identities, authentication, etc.) and monolithic control dominate. Examples of these include the large instant messaging providers that run IM systems that do not exchange messages with other administrative domains. That control, first of all, provides a relatively strong identity assertion for users (since all users trust a common provider, and the common provider is the arbiter of authentication and identity). Secondly, it provides a single place where reputation can be managed.
評判システムはリソース(ユーザアイデンティティ、認証など)と一枚岩的なコントロールの中央集権化が支配されるシステムに成功しています。 これらに関する例は他の管理ドメインとメッセージを交換しないIMシステムを動かす大きいインスタントメッセージングプロバイダーを含んでいます。 まず、そのコントロールは比較的強いアイデンティティ主張をユーザに提供します(すべてのユーザが一般的なプロバイダーを信じて、一般的なプロバイダーが認証とアイデンティティの仲裁者であるので)。 第二に、それは評判に対処できる単一の場所を提供します。
Reputation systems based on negative reputation scores suffer from many of the same problems as black lists, since effectively the consequence of having a negative reputation is that you are blacklisted. If identities are very easy to acquire, a user with a
負の評判スコアに基づく評判システムはブラックリストと同じ問題の多くが欠点です、否定的評判を持つ結果が事実上あなたがブラックリストに載せられるということであるので。 アイデンティティが取得するまさしくその小休止、aをもっているユーザであるなら
Rosenberg & Jennings Informational [Page 12] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[12ページ]のRFC5039SIPは2008年1月にばらまかれます。
negative reputation will simply acquire a new identity. Moreover, negative reputation is generated by tattling, which requires users to be annoyed enough to click the warning button -- a process that can be abused. In some reputation systems, "reputation mafias" consisting of large numbers of users routinely bully or extort victims by threatening collectively to give victims a negative reputation.
否定的評判は単に新しいアイデンティティを取得するでしょう。 そのうえ、どれが、ユーザが警告ボタンをクリックできるくらいいらいらしているのを必要とするかをしゃべって漏らすのによる否定的評判が発生している--乱用できる過程。 いくつかの評判システムでは、否定的評判を犠牲者に与えるとまとめて脅かすことによって、多くのユーザから成る「評判マフィア」は、犠牲者をきまりきっていじめるか、または強奪します。
Reputation systems based on positive reputation, where users praise each other for being good, rather than tattling on each other for being bad, have some similar drawbacks. Collectives of spammers, or just one spammer who acquires a large number identities, could praise one another in order to create an artificial positive reputation. Users similarly have to overcome the inertia required to press the "praise" button. Unlike negative reputation systems, however, positive reputation is not circumvented when users acquire a new identity, since basing authorization decisions on positive reputation is essentially a form of white listing.
積極的な評判に基づく評判システムはユーザが悪いように互いの上でしゃべって漏らすよりむしろ良いように互いを称賛するところにいくつかの同様の欠点を持っています。 スパマー、または多くのアイデンティティを取得するちょうど1人のスパマーの集合体は、人工の積極的な評判を引き起こすためにお互いを称賛できました。 ユーザは同様に「称賛」ボタンを押すのに必要である慣性に打ち勝たなければなりません。 しかしながら、否定的評判システムと異なって、ユーザが新しいアイデンティティを取得するとき、積極的な評判は回避されません、認可決定を積極的な評判に基礎づけるのが、本質的には白いリストのフォームであるので。
So, while positive reputation systems are superior to negative reputation systems, they are far from perfect. Intriguingly, though, combining presence-based systems with reputation systems leads to an interesting fusion. The "buddy-list" concept of presence is, in effect, a white list - and one can infer that the users on one's buddy list are people whom you are "praising". This eliminates the problem of user inertia in the use of the "praise" button, and automates the initial establishment of reputation.
それで、積極的な評判システムは否定的評判システムより優れていますが、それらは全く完全ではありません。 もっとも、興味をそそるように存在ベースのシステムを評判システムに結合するのはおもしろい溶融に通じます。 事実上、存在の「友達リスト」概念はホワイトリストです、そして、1つは人の友達リストの上のユーザがあなたが「称賛している」人々であると推論できます。 これは、「称賛」ボタンの使用におけるユーザの慣性の問題を解決して、評判の当初設定を自動化します。
And of course, your buddies in turn have buddies. Collectively, you and your buddies (and their buddies, and so on) constitute a social network of reputation. If there were a way to leverage this social network, it would eliminate the need for centralization of the reputation system. Your perception of a particular user's reputation might be dependent on your relationship to them in the social network: are they one buddy removed (strong reputation), four buddies removed (weaker reputation), three buddies removed but connected to you through several of your buddies, etc. This web of trust furthermore would have the very desirable property that circles of spammers adding one another to their own buddy lists would not affect your perception of their reputation unless their circle linked to your own social network.
もちろん、そして、あなたの友達には、友達が順番にいます。 あなたとあなたの友達(そして、彼らの友達など)は評判のソーシャルネットワークをまとめて、構成します。 このソーシャルネットワークに投機する方法があれば、それは評判システムの中央集権化の必要性を排除するでしょうに。 特定のユーザの評判に関するあなたの知覚はソーシャルネットワークでそれらとのあなたの関係に依存しているかもしれません: 彼らは外された、1人の友達(強い評判)、外された、4人の友達(より弱い評判)、あなたの数人の友達を通してあなたに取り除きましたが、接した3人の友達ですなど。 信用のこのウェブには、その上、スパマーの輪がそれら自身の友達リストにお互いを追加して、それらの円があなた自身のソーシャルネットワークにリンクされない場合彼らの評判に関するあなたの知覚に影響しない非常に望ましい特性があるでしょう。
If a users machine is compromised and turned into a zombie, this allows SPAM to be sent and may impact their reputation in a negative way. Once their reputation decreases, it becomes extremely difficult to reestablish a positive reputation.
ユーザマシンが妥協して、ゾンビに変えられるなら、これは、スパムが送られるのを許容して、負の方法で彼らの評判に影響を与えるかもしれません。 彼らの評判がいったん静まると、積極的な評判を復職させるのは非常に難しくなります。
Rosenberg & Jennings Informational [Page 13] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[13ページ]のRFC5039SIPは2008年1月にばらまかれます。
3.6. Address Obfuscation
3.6. アドレス困惑
Spammers build up their spam lists by gathering email addresses from Web sites and other public sources of information. One way to minimize spam is to make your address difficult or impossible to gather. Spam bots typically look for text in pages of the form "user@domain", and assume that anything of that form is an email address. To hide from such spam bots, many Web sites have recently begun placing email addresses in an obfuscated form, usable to humans but difficult for an automata to read as an email address. Examples include forms such as, "user at example dot com" or "j d r o s e n a t e x a m p l e d o t c o m".
スパマーはウェブサイトからの集会Eメールアドレスと他の公立の情報筋で彼らのスパムリストを確立します。 スパムを最小にする1つの方法はあなたのアドレスを集めるのを難しいか不可能にすることです。 スパムウマバエの幼虫は、フォーム" user@domain "のページのテキストを通常探して、そのフォームについて何がEメールアドレスであるとでも仮定します。 そのようなスパムウマバエの幼虫から隠れるために、多くのウェブサイトが最近、オートマトンがEメールアドレスと読む人間にとって使用可能な、しかし、難しい困惑させられた書式にEメールアドレスを置き始めました。 インクルードがそのようなものを形成する例、「例のドットコムのユーザ」または「j d r o s e n a t e x a m p l e d o t c o m。」
These techniques are equally applicable to prevention of SIP spam, and are likely to be as equally effective or ineffective in its prevention.
これらのテクニックは、等しくSIPスパムの防止に適切であり、防止で等しく同じくらい有効であるか、または同じくらい効力がない傾向があります。
It is worth mentioning that the source of addresses need not be a Web site - any publicly accessible service containing addresses will suffice. As a result, ENUM [9] has been cited as a potential gold mine for spammers. It would allow a spammer to collect SIP and other URIs by traversing the tree in e164.arpa and mining it for data. This problem is mitigated in part if only number prefixes, as opposed to actual numbers, appear in the DNS. Even in that case, however, it provides a technique for a spammer to learn which phone numbers are reachable through cheaper direct SIP connectivity.
アドレスの源がウェブサイトである必要はないと言及する価値があります--アドレスを含むどんな公的にアクセスしやすいサービスも十分でしょう。 その結果、潜在的金鉱はスパマーのためにENUM[9]に挙げられました。 それで、スパマーは、e164.arpaで木を横断して、データのためにそれを採掘することによって、SIPと他のURIを集めることができるでしょう。 数の接頭語だけが実数と対照的にDNSに現れるなら、この問題は一部緩和されます。 しかしながら、その場合さえ、スパマーが、どの電話番号が、より安いダイレクトSIPの接続性を通して届いているかを学ぶように、それはテクニックを提供します。
3.7. Limited-Use Addresses
3.7. 株式会社使用アドレス
A related technique to address obfuscation is limited-use addresses. In this technique, a user has a large number of email addresses at their disposal, each of which has constraints on its applicability. A limited-use address can be time-bound, so that it expires after a fixed period. Or, a different email address can be given to each correspondent. When spam arrives from that correspondent, the limited-use address they were given is terminated. In another variation, the same limited-use address is given to multiple users that share some property; for example, all work colleagues, all coworkers from different companies, all retailers, and so on. Should spam begin arriving on one of the addresses, it is invalidated, preventing communications from anyone else that received the limited use address.
困惑を記述する関連手法は限られた使用アドレスです。 ユーザには、このテクニックで、彼らの自由に、多くのEメールアドレスがあります。それは適用性にそれぞれ規制を持っています。 限られた使用アドレスが時間行きである場合があるので、それは一定期間の後に期限が切れます。 または、異なったEメールアドレスを各通信員に与えることができます。 スパムがその通信員から到着すると、それらが与えられた限られた使用アドレスは終えられます。 別の変化では、何らかの特性を共有する複数のユーザに同じ限られた使用アドレスを与えます。 例えば、すべてが異なった会社、すべての小売業者などから同僚、すべての同僚を働かせます。 スパムがアドレスの1つで到着し始めるなら、それは無効にされます、使用が記述する制限を受けた他の誰からもコミュニケーションを防いで。
This technique is equally applicable to SIP. One of the drawbacks of the approach is that it can make it hard for people to reach you; if an email address you hand out to a friend becomes spammed, changing it requires you to inform your friend of the new address. SIP can help solve this problem in part, by making use of presence [6].
このテクニックは等しくSIPに適切です。 アプローチの欠点の1つは人々があなたに連絡するのを困難にすることができるということです。 あなたが友人に与えるEメールアドレスがばらまかれるようになるなら、それを変えるのは、あなたが新しいアドレスについて友人に知らせるのを必要とします。 SIPは、存在[6]を利用することによって一部この問題を解決するのを助けることができます。
Rosenberg & Jennings Informational [Page 14] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[14ページ]のRFC5039SIPは2008年1月にばらまかれます。
Instead of handing out your email address to your friends, you would hand out your presence URI. When a friend wants to send you an email, they subscribe to your presence (indeed, they are likely to be continuously subscribed from a buddy list application). The presence data can include an email address where you can be reached. This email address can be obfuscated and be of single use, different for each buddy who requests your presence. They can also be constantly changed, as these changes are pushed directly to your buddies. In a sense, the buddy list represents an automatically updated address book, and would therefore eliminate the problem.
あなたのEメールアドレスをあなたの友人に与えることの代わりに、あなたは存在URIを与えるでしょう。 友人がメールをあなたに送りたがっているとき、彼らはあなたの存在に加入します(本当に、それらは友達リストアプリケーションから絶え間なく申し込まれそうです)。 存在データはあなたに連絡できるEメールアドレスを含むことができます。 このEメールアドレスは、困惑させられて、ただ一つに役に立つ場合があります立会いを求める各友達にとって、異なった。 また、これらの変化が直接あなたの友達に押されるのに従って、絶えずそれらを変えることができます。 ある意味で、友達リストは、自動的にアップデートされたアドレス帳を表して、したがって、問題を解決するでしょう。
Another approach is to give a different address to each and every correspondent, so that it is never necessary to tell a "good" user that an address needs to be changed. This is an extreme form of limited-use addresses, which can be called a single-use address. Mechanisms are available in SIP for the generation of [16] an infinite supply of single use addresses. However, the hard part remains a useful mechanism for distribution and management of those addresses.
別のアプローチは異なったアドレスをありとあらゆる通信員に与えることです、アドレスが、変えられる必要であると「良い」ユーザに言うのは決して必要でないように。 これは極端なフォームの限られた使用アドレスです。(そのアドレスをただ一つの使用アドレスと呼ぶことができます)。 メカニズムはSIPでただ一つの使用の無限の供給が記述する[16]の世代に利用可能です。 しかしながら、固い部分はそれらのアドレスの分配と管理において、役に立つメカニズムのままで残っています。
3.8. Turing Tests
3.8. チューリングTests
In email, Turing tests are mechanisms whereby the sender of the message is given some kind of puzzle or challenge, which only a human can answer (since Turing tests rely on video or audio puzzles, they sometimes cannot be solved by individuals with handicaps). These tests are also known as captchas (Completely Automated Public Turing test to tell Computers and Humans Apart). If the puzzle is answered correctly, the sender is placed on the user's white list. These puzzles frequently take the form of recognizing a word or sequence of numbers in an image with a lot of background noise. The tests need to be designed such that automata cannot easily perform the image recognition needed to extract the word or number sequence, but a human user usually can. Designing such tests is not easy, since ongoing advances in image processing and artificial intelligence continually raise the bar. Consequently, the effectiveness of captchas are tied to whether spammers can come up with or obtain algorithms for automatically solving them.
メールでは、チューリングテストは、ある種のパズルがメッセージ送信者に与えられるメカニズムか挑戦(チューリングテストがビデオかオーディオパズルを当てにするので、個人は時々ハンディキャップでそれらを解決できない)です。(人間だけがその挑戦に答えることができます)。 また、これらのテストはcaptchas(コンピュータとHumans Apartに言う完全にAutomated Publicチューリングテスト)として知られています。 パズルが正しく答えられるなら、送付者はユーザのホワイトリストに置かれます。 これらのパズルは頻繁に多くのバックグラウンドノイズを伴うイメージによる単語か数列を認識する形を取ります。 テストは、オートマトンが容易に単語か数順を抜粋するのに必要である画像認識を実行できないように、設計されている必要がありますが、通常、人間のユーザは必要があることができます。 イメージプロセッシングと人工知能における進行中の進歩が絶えず水準を上げるので、そのようなテストを設計するのは簡単ではありません。 その結果、captchasの有効性はスパマーが自動的にそれらを解決するためのアルゴリズムを思いつくか、または得ることができるかと結ばれます。
Like many of the other email techniques, Turing tests are dependent on sender identity, which cannot easily be authenticated in email.
もう片方の多くがテクニックをメールするように、チューリングテストは送付者のアイデンティティに依存しています。容易に、メールでアイデンティティを認証できません。
Turing tests can be used to prevent IM spam in much the same way they can be used to prevent email spam.
メールスパムを防ぐのにそれらを使用できる似たり寄ったりの方法でIMスパムを防ぐのにチューリングテストを使用できます。
Turing tests can be applied to call spam as well, although not directly, because call spam does not usually involve the transfer of images and other content that can be used to verify that a human is
また、スパムと呼ぶためにチューリングテストを適用できます、直接がではありませんが、呼び出しスパムが通常人間がそうであることを確かめるのに使用できるイメージと他の内容の転送にかかわらないので
Rosenberg & Jennings Informational [Page 15] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[15ページ]のRFC5039SIPは2008年1月にばらまかれます。
on the other end. If most of the calls are voice, the technique needs to be adapted to voice. This is not that difficult to do. Here is how it could be done. User A calls user B and is not on user B's white or black list. User A is transferred to an Interactive Voice Response (IVR) system. The IVR system tells the user that they are going to hear a series of numbers (say 5 of them), and that they have to enter those numbers on the keypad. The IVR system reads out the numbers while background music is playing, making it difficult for an automated speech recognition system to be applied to the media. The user then enters the numbers on their keypad. If they are entered correctly, the user is added to the white list.
もう片方では、終わってください。 呼び出しの大部分が声であるなら、テクニックは、声に適合させられる必要があります。 これはするのがそんなに難しくはありません。 ここに、どうそれができたかがあります。 ユーザAは、ユーザBに電話をして、ユーザのビーズの白いか黒いリストにいません。 ユーザAはInteractive Voice Response(IVR)システムに転勤になります。 IVRシステムは彼らが一連の数を聞いて(それらの5つを言ってください)、キーパッドのそれらの数を入れなければならないとユーザに言います。 バックグラウンド・ミュージックが演奏されている間、IVRシステムは数を読みだします、自動化された音声理解システムがメディアに適用されるのを難しくして。 そして、ユーザはそれらのキーパッドの数を入れます。 それらが正しく入られるなら、ユーザはホワイトリストに追加されます。
This kind of voice-based Turing test is easily extended to a variety of media, such as video and text, and user interfaces by making use of the SIP application interaction framework [14]. This framework allows client devices to interact with applications in the network, where such interaction is done with stimulus signaling, including keypads (supported with the Keypad Markup Language [15]), but also including Web browsers, voice recognition, and so on. The framework allows the application to determine the media capabilities of the device (or user, in cases where they are handicapped) and interact with them appropriately.
この種類の声のベースのチューリングテストは容易にさまざまなメディアに広げられます、ビデオや、テキストや、SIPアプリケーション間連携枠組み[14]を利用するのによるユーザインタフェースなどのように。 クライアント装置はこの枠組みでネットワークでアプリケーションと対話できます、キーパッドを含んでいて。(そこでは、そのような相互作用が刺激シグナリングで行われます)。(Keypad Markup Language[15])と共に支持されますが、ウェブブラウザ、音声認識をまた含んでいますなど。 枠組みで、アプリケーションを装置(または、彼らはハンディキャップがある場合におけるユーザ)のメディア能力を決定して、適切にそれらと対話します。
In the case of voice, the Turing test would need to be made to run in the language of the caller. This is possible in SIP, using the Accept-Language header field, though this is not widely used at the moment, and meant for languages of SIP message components, not the media streams.
声の場合では、チューリングテストは、訪問者の言語が立候補させられる必要があるでしょう。 これはSIPで可能です、Accept-言語ヘッダーフィールドを使用して、これが、現在広く使用されて、SIPメッセージの部品の言語のために意味されませんが、メディアの流れでない。
The primary problem with the voice Turing test is the same one that email tests have: instead of having an automata process the test, a spammer can pay cheap workers to take the tests. Assuming cheap labor in a poor country can be obtained for about 60 cents per hour, and assuming a Turing test of a 30-second duration, this is about 0.50 cents per test and thus 0.50 cents per message to send an IM spam. Lower labor rates would reduce this further; the number quoted here is based on real online bids in September of 2006 made for actual work of this type.
声のチューリングテストに関する第一の問題はメールテストが持っている同じものです: オートマトンにテストを処理させることの代わりに、スパマーは、安い労働者が就任宣誓するのを支払うことができます。 これは、貧しい国で安い労働力を引き受けるのが、毎時のおよそ60セントに得られて、30秒の持続時間のチューリングテストを仮定できて、1テストあたりおよそ0.50セントとその結果、IMスパムを送るメッセージあたり0.50セントです。 低い賃金率はこれをさらに減少させるでしょう。 ここで引用された数はこのタイプの実際の仕事のために作られた2006年9月に全くオンラインの付け値に基づいています。
As an alternative to paying cheap workers to take the tests, the tests can be taken by human users that are tricked into completing the tests in order to gain access to what they believe is a legitimate resource. This was done by a spambot that posted the tests on a pornography site, and required users to complete the tests in order to gain access to content.
安い労働者が就任宣誓するのを支払うことに代わる手段として、彼らが正統のリソースであると信じていることへのアクセスを得るためにテストを終了するようにだまされる人間のユーザはテストを受けることができます。 ポルノサイトにテストを掲示して、内容へのアクセスを得るためにユーザがテストを終了するのを必要としたスパムボットはこれをしました。
Due to these limitations, Turing tests may never completely solve the problem.
これらの制限のため、チューリングテストは完全に問題を決して解決するかもしれないというわけではありません。
Rosenberg & Jennings Informational [Page 16] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[16ページ]のRFC5039SIPは2008年1月にばらまかれます。
3.9. Computational Puzzles
3.9. コンピュータのパズル
This technique is similar to Turing tests. When user A tries to communicate with user B, user B asks user A to perform a computation and pass the result back. This computation has to be something a human user cannot perform and something expensive enough to increase user A's cost to communicate. This cost increase has to be high enough to make it prohibitively expensive for spammers but inconsequential for legitimate users.
このテクニックはチューリングテストと同様です。 ユーザAがユーザBとコミュニケートしようとするとき、ユーザBは、計算を実行して、結果を戻すようにユーザAに頼みます。 この計算は、人間のユーザが実行できない何かと交信するためにユーザAの費用を上げることができるくらい何か高価なものでなければなりません。 このコスト増はそれをスパマーには法外に高価ですが、正統のユーザにとって取るに足らなくすることができるくらい高くなければなりません。
One of the problems with the technique is that there is wide variation in the computational power of the various clients that might legitimately communicate. The CPU speed on a low-end cell phone is around 50 MHz, while a high-end PC approaches 5 GHz. This represents almost two orders of magnitude difference. Thus, if the test is designed to be reasonable for a cell phone to perform, it is two orders of magnitude cheaper to perform for a spammer on a high- end machine. Recent research has focused on defining computational puzzles that challenge the CPU/memory bandwidth, as opposed to just the CPU [26]. It seems that there is less variety in the CPU/memory bandwidth across devices, roughly a single order of magnitude.
テクニックに関する問題の1つは合法的に交信するかもしれない様々なクライアントのコンピュータのパワーの広い変化があるということです。 ローエンド携帯電話の上のCPU速度はおよそ50MHzですが、上位PCは5ギガヘルツにアプローチします。 これはおよそ2桁の違いを表します。 したがって、テストが携帯電話が働くのが妥当になるように設計されるなら、スパマーのために高いエンドマシンに働くのは2桁より安いです。 最近の研究は、まさしくCPU[26]と対照的にCPU/メモリ帯域幅に挑戦するコンピュータのパズルを定義するのは焦点を合わせました。 CPU/メモリ帯域幅には、より少ないバラエティーが装置のむこうにあるようにおよそ1桁思えます。
Recent work [28] suggests that, due to the ability of spammers to use virus-infected machines (also known as zombies) to generate the spam, the amount of computational power available to the spammers is substantial, and it may be impossible to have them compute a puzzle that is sufficiently hard that will not also block normal emails. If combined with white listing, computational puzzles would only be utilized for new communications partners. Of course, if the partner on the white list is a zombie, spam will come from that source. The frequency of communications with new partners is arguably higher for email than for multimedia, and thus the computational puzzle techniques may be more effective for SIP than for email in dealing with the introduction problem.
近作[28]はスパマーがスパムを発生させるのに、ウイルス機械(また、ゾンビとして、知られている)を使用する能力のためにスパマーにとって、利用可能なコンピュータのパワーの大きさがかなりなものであり、また、彼らに十分困難なパズルを計算させるように、それが正常なメールを妨げないのが、不可能であるかもしれないと示唆します。 記載する白に結合されるなら、コンピュータのパズルは新しいコミュニケーションパートナーに利用されるだけでしょう。 もちろん、ホワイトリストの上のパートナーがゾンビであるなら、スパムはそのソースから来るでしょう。 メールには、新しいパートナーとのコミュニケーションの頻度が論証上マルチメディアより高く、SIPには、その結果、序論問題に対処することではコンピュータのパズルのテクニックはメールより効果的であるかもしれません。
These techniques are an active area of research right now, and any results for email are likely to be usable for SIP.
たった今これらのテクニックは研究の活動領域です、そして、メールのためのどんな結果もSIPに使用可能である傾向があります。
3.10. Payments at Risk
3.10. 危険な支払い
This approach has been proposed for email [27]. When user A sends email to user B, user A deposits a small amount of money (say, one dollar) into user B's account. If user B decides that the message is not spam, user B refunds this money back to user A. If the message is spam, user B keeps the money. This technique requires two transactions to complete: a transfer from A to B, and a transfer from B back to A. The first transfer has to occur before the message can be received in order to avoid reuse of "pending payments" across
このアプローチはメール[27]のために提案されました。 ユーザAがユーザBにメールを送るとき、ユーザAは少量のお金(たとえば、あるドル)をユーザビーズアカウントに預けます。 ユーザBが、メッセージがばらまかないことであると決めるなら、ユーザBはこの返金を還付します。ユーザA.Ifにおいて、メッセージがスパムである、ユーザBはお金を保ちます。 このテクニックは、以下を完成するために2つの取引を必要とします。 横切って「未定の支払い」の再利用を避けるためにメッセージを受け取ることができる前にA. AからBと、Bからの転送から最初の転送までの転送は起こらなければなりません。
Rosenberg & Jennings Informational [Page 17] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[17ページ]のRFC5039SIPは2008年1月にばらまかれます。
several messages, which would eliminate the utility of the solution. The second one then needs to occur when the message is found not to be spam.
いくつかのメッセージ。(そのメッセージは解決策に関するユーティリティを排除するでしょう)。 そして、2番目の人は、メッセージがスパムでないことがわかっているとき、起こる必要があります。
This technique appears just as applicable to call spam and IM spam as it is to email spam. Like many of the other techniques, this exchange would only happen the first time you talk to people. Its proper operation therefore requires a good authenticated identity infrastructure.
このテクニックはスパムと呼ぶのにおいてちょうど同じくらい適切に見えます、そして、スパムをメールすることになっているとき、IMはばらまきます。 他のテクニックの多くのように、あなたが初めて人々と話すとき、この交換は起こるだけでしょう。 したがって、適切な操作は良い認証されたアイデンティティインフラストラクチャを必要とします。
This technique has the potential to make it arbitrarily expensive to send spam of any sort. However, it relies on cheap micro-payment techniques on the Internet. Traditional costs for Internet payments are around 25 cents per transaction, which would probably be prohibitive. However, recent providers have been willing to charge 15% of the transaction for small transactions, as small as one cent. This cost would have to be shouldered by users of the system. The cost that would need to be shouldered per user is equal to the number of messages from unknown senders (that is, senders not on the white list) that are received. For a busy user, assume about 10 new senders per day. If the deposit is 5 cents, the transaction provider would take 0.75 cents and deliver 4.25 cents. If the sender is allowed, the recipient returns 4.25 cents, the provider takes 0.64 cents, and returns 3.6 cents. This costs the sender 0.65 cents on each transaction, if it was legitimate. If there are ten new recipients per day, that is US $1.95 per month, which is relatively inexpensive.
このテクニックには、どんな種類のスパムも送るのを任意に高価にする可能性があります。 しかしながら、それはインターネットで安いマイクロペイメントのテクニックを当てにします。 1取引あたりインターネット支払いのための伝統的なコストはおよそ25セントです。(それは、たぶん禁止でしょう)。 しかしながら、最近のプロバイダーは、小さい取引のための取引の15%を請求することを同じくらい望んでいて、1セントと同じくらい小さいです。 この費用はシステムのユーザによって負担されなければならないでしょう。 ユーザ単位で背負われる必要がある費用は受け取られていている見知らぬ送信者(すなわち、送付者は白に記載しません)からのメッセージの数と等しいです。 忙しいユーザに関しては、1日あたりおよそ10人の新しい送付者を仮定してください。 預金が5セントであるなら、取引プロバイダーは、0.75セント取って、4.25セント配送するでしょう。 送付者が許容されているなら、受取人が4.25セントを返して、プロバイダーは、0.64セント取って、3.6セント戻ります。 それが正統であったなら、送付者は各取引での0.65セントをこれに費やします。 1日あたり10人の新しい受取人がいれば、それは1カ月あたり1.95ドル米国です。(月は比較的安価です)。
Assuming a micro-payment infrastructure exists, another problem with payment-at-risk is that it loses effectiveness when there are strong inequities in the value of currency between sender and recipient. For example, a poor person in a Third World country might keep the money in each mail message, regardless of whether it is spam. Similarly, a poor person might not be willing to include money in an email, even if legitimate, for fear that the recipient might keep it. If the amount of money is lowered to help handle these problems, it might become sufficiently small that spammers can just afford to spend it.
マイクロペイメントインフラストラクチャが存在すると仮定して、支払い危険であるのに関する別の問題は送付者と受取人の間に通貨の値に強い不公平があるとき、有効性を失うということです。 例えば、第三世界国の貧乏人は各メール・メッセージにお金を保つかもしれません、それがスパムであるかどうかにかかわらず。 同様に、貧乏人はメールのお金を含んでいることを望まないかもしれません、正統であっても、受取人がそれを保つかもしれないという恐れによって。 金額がこれらの問題を扱うのを助けるために下げられるなら、スパマーにはそれを費やす余裕がただあるのは十分小さくなるかもしれません。
3.11. Legal Action
3.11. 訴訟
In this solution, countries pass laws that prohibit spam. These laws could apply to IM or call spam just as easily as they could apply to email spam. There is a lot of debate about whether these laws would really be effective in preventing spam.
この解決策では、国はスパムを禁止する法案を可決します。 これらの法は、スパムをメールするのに申し込むことができたのとちょうど同じくらい容易にIMに当てはまるか、またはスパムと呼ぶかもしれません。 これらの法が本当にスパムを防ぐのにおいて効果的であるだろうかどうかの多くの討論があります。
As a recent example in the US, "do not call" lists seem to be effective. However, due to the current cost of long-distance phone
リストは、有効になるように米国の最近の例としての、「電話をしないでください。」ように思えます。 しかしながら、長距離の現在の費用は電話をします。
Rosenberg & Jennings Informational [Page 18] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[18ページ]のRFC5039SIPは2008年1月にばらまかれます。
calls, the telemarketing is coming from companies within the US. As such, calls from such telemarketers can be traced. If a telemarketer violates the "do not call" list, the trace allows legal action to be taken against them. A similar "do not irritate" list for VoIP or for email would be less likely to work because the spam is likely to come from international sources. This problem could be obviated if there was a strong way to identify the sender's legal entity, and then determine whether it was in a jurisdiction where it was practical to take legal action against them. If the spammer is not in such a jurisdiction, the SIP spam could be rejected.
呼び出しであり、テレマーケティングは米国の中の会社から来るでしょう。 そういうものとして、そのようなテレマーケティングをする人からの呼び出しをたどることができます。 テレマーケティングをする人が「電話をしないでください」というリストに違反するなら、跡は、訴訟がそれらに対して起こされるのを許容します。 スパムが国際的なソースから来そうであるので、VoIPかメールのための「いらだたせないでください」という同様のリストは、より働きそうにないでしょう。 それらに対して訴訟を起こすのが実用的であったところで送付者の法人を特定して、次にそれが管轄であったかを決定する強い方法があれば、この問題を取り除くことができるでしょうに。 スパマーがそのような管轄でいないなら、SIPスパムは拒絶されるかもしれません。
There are also schemes that cause laws other than anti-spam laws to be broken if spam is sent. This does not inherently reduce SPAM, but it allows more legal options to be brought to bear against the spammer. For example, Habeas <http://www.habeas.com> inserts material in the header that, if it was inserted by a spammer without an appropriate license, would allegedly causes the spammer to violate US copyright and trademark laws, possibly reciprocal laws, and similar laws in many countries.
スパムを送るならアンチスパム法以外の法が壊れていることを引き起こす計画もあります。 これは本来スパムを減少させませんが、それは、より法的なオプションがスパマーに対して生かされるのを許容します。 例えば、Habeas<http://www.habeas.com>はそれが適切な許可なしでスパマーによって挿入されるなら、スパマーが米国著作権に違反することを引き起こすとされていて、法を商標登録するヘッダー、ことによると相互的な法、および多くの国の同様の法に材料を挿入します。
3.12. Circles of Trust
3.12. 信用の円
In this model, a group of domains (e.g., a set of enterprises) all get together. They agree to exchange SIP calls amongst each other, and they also agree to introduce a fine should any one of them be caught spamming. Each company would then enact measures to terminate employees who spam from their accounts.
このモデルでは、ドメインのグループは皆、集まります(例えば、1セットの企業)。 彼らは、互いの中でSIP呼び出しを交換するのに同意します、そして、また、それらのどれかがばらまくのが捕らえられるなら、それらは罰金を紹介するのに同意します。 そして、各社は彼らのアカウントからばらまく従業員を終える測定を制定するでしょう。
This technique relies on secure inter-domain authentication - that is, domain B can know that messages are received from domain A. In SIP, this is readily provided by usage of the mutually authenticated Transport Level Security (TLS)[22] between providers or SIP Identity [17].
このテクニックは安全な相互ドメイン認証に依存します--すなわち、ドメインBはドメインA.In SIPからメッセージを受け取って、互いに認証されたTransport Level Security(TLS)[22]の用法でプロバイダーかSIP Identity[17]の間に容易にこれを提供するのを知ることができます。
This kind of technique works well for small domains or small sets of providers, where these policies can be easily enforced. However, it is unclear how well it scales up. Could a very large domain truly prevent its users from spamming? At what point would the network be large enough that it would be worthwhile to send spam and just pay the fine? How would the pricing be structured to allow both small and large domains alike to participate?
この種類のテクニックは小さいドメインか小さいセットのプロバイダーにうまくいきます。そこでは、容易にこれらの方針は励行されることができます。 しかしながら、どれくらいよく拡大するかは不明瞭です。 非常に大きいドメインによって、本当に、ユーザはばらまくことができませんか? どんなポイントで、ネットワークはスパムを送って、ただ罰金を支払う価値があるほど大きいでしょうか? 価格設定は、小さいものも同様に大きいドメインも参加するのを許容するためにどのように構造化されますか?
3.13. Centralized SIP Providers
3.13. 集結された一口プロバイダー
This technique is a variation on the circles of trust described in Section 3.12. A small number of providers get established as "inter- domain SIP providers". These providers act as a SIP-equivalent to the interexchange carriers in the PSTN. Every enterprise, consumer
このテクニックはセクション3.12で説明された信用の円の変化です。 少ない数のプロバイダーが「相互ドメインSIPプロバイダー」と書き立てられます。 これらのプロバイダーは相互交換接続キャリアとSIP-同等物としてPSTNで機能します。 あらゆる企業、消費者
Rosenberg & Jennings Informational [Page 19] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[19ページ]のRFC5039SIPは2008年1月にばらまかれます。
SIP provider, or other SIP network (call these the local SIP providers) connects to one of these inter-domain providers. The local SIP providers only accept SIP messages from their chosen inter- domain provider. The inter-domain provider charges the local provider, per SIP message, for the delivery of SIP messages to other local providers. The local provider can choose to pass on this cost to its own customers if it so chooses.
SIPプロバイダーの、または、他のSIPネットワークはこれらの相互ドメインプロバイダーの1つに接続します(これらをローカルのSIPプロバイダーと呼びます)。 ローカルのSIPプロバイダーはそれらの選ばれた相互ドメインプロバイダーからSIPメッセージを受け入れるだけです。 相互ドメインプロバイダーはSIPメッセージの配送のためにSIPメッセージあたりのローカルのプロバイダーを他のローカルのプロバイダーに請求します。 そう選ぶなら、ローカルのプロバイダーは、それ自身の顧客へのこの費用を伝えるのを選ぶことができます。
The inter-domain SIP providers then form bi-lateral agreements with each other, exchanging SIP messages according to strict contracts. These contracts require that each of the inter-domain providers be responsible for charging a minimum per-message fee to their own customers. Extensive auditing procedures can be put into place to verify this. Besides such contracts, there may or may not be a flow of funds between the inter-domain providers.
そして、厳しい契約通りにSIPメッセージを交換して、相互ドメインSIPプロバイダーは互いとの双方の協定を結びます。 これらの契約は、それぞれの相互ドメインプロバイダーが1メッセージあたり1つの最小の料金をそれら自身の顧客に請求するのに原因となるのを必要とします。 これについて確かめる場所に大規模な監査の手順を入れることができます。 そのような契約以外に、相互ドメインプロバイダーの間には、基金の流れがあるかもしれません。
The result of such a system is that a fixed cost can be associated with sending a SIP message, and that this cost does not require micro-payments to be exchanged between local providers, as it does in Section 3.10. Since all of the relationships are pre-established and negotiated, cheaper techniques for monetary transactions (such as monthly post-paid transactions) can be used.
そのようなシステムの結果はSIPメッセージを送ると固定費を関連づけることができて、この費用が、マイクロペイメントがローカルのプロバイダーの間で交換されるのを必要としないということです、セクション3.10でそうするように。 関係のすべてがあらかじめ設立されて、交渉されるので、金融取引(毎月の郵便前払いの取引などの)のための、より安いテクニックを使用できます。
This technique can be made to work in SIP, whereas it cannot in email, because inter-domain SIP connectivity has not yet been broadly established. In email, there already exists a no-cost form of inter- domain connectivity that cannot be eliminated without destroying the utility of email. If, however, SIP inter-domain communications get established from the start using this structure, there is a path to deployment.
メールでさせることができませんが、このテクニックはSIPで働かされることができます、相互ドメインSIPの接続性がまだ広く確立されていないので。 メールでは、メールに関するユーティリティを無効にしないで排除できない相互ドメインの接続性の費用がないフォームは既に存在しています。 しかしながら、SIP相互ドメインコミュニケーションが始めからこの構造を使用することで設立されるなら、展開への経路があります。
This structure is more or less the same as the one in place for the PSTN today, and since there is relatively little spam on the PSTN (compared to email!), there is some proof that this kind of arrangement can work. However, centralized architectures as these are deliberately eschewed because they put back into SIP much of the complexity and monopolistic structures that the protocol aims to eliminate.
この構造は今日PSTNにおいて、適所にあるものと多少同じです、そして、比較的小さいスパムがPSTNにあるので(メールと比較される!)、この種類のアレンジメントが働くことができるという何らかの証拠があります。 しかしながら、複雑さとプロトコルが取り除くことを目指す独占的な構造の多くをSIPに戻すので、これらとしての集結された構造は故意に避けられます。
4. Authenticated Identity in Email
4. メールによる認証されたアイデンティティ
Though not a form of anti-spam in and of itself, authenticated or verifiable identities are a key part of making other anti-spam mechanisms work. Many of the techniques described above are most effective when combined with a white or black list, which itself requires a strong form of identity.
そういうものの反スパムのフォームではありませんが、認証されたか証明可能なアイデンティティは他の反スパムメカニズムを働かせる主要な部分です。 白いか黒いリスト(自体アイデンティティの強形を必要とする)に結合されると、上で説明されたテクニックの多くが最も効果的です。
Rosenberg & Jennings Informational [Page 20] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[20ページ]のRFC5039SIPは2008年1月にばらまかれます。
In email, two types of authenticated identity have been developed - sender checks and signature-based solutions.
メールでは、認証されたアイデンティティの2つのタイプが発生しました--送付者チェックと署名ベースの解答。
4.1. Sender Checks
4.1. 送付者はチェックします。
In email, DNS resource records have been defined that will allow a domain that receives a message to verify that the sender is a valid Message Transfer Agent (MTA) for the sending domain [18] [19] [20] [21]. They don't prevent spam by themselves, but may help in preventing spoofed emails. As has been mentioned several times, a form of strong authenticated identity is key in making many other anti-spam techniques work.
メールでは、発信ドメイン[18][19][20][21]のために送付者が有効なMessage Transferエージェント(MTA)であることを確かめるメッセージを受け取るドメインを許容するDNSリソース記録が定義されました。 彼らは、自分たちでスパムを防ぎませんが、だまされたメールを防ぐのを手伝うかもしれません。 何度か言及されたように、他の多くの反スパムのテクニックを働かせるのにおいて強い認証されたアイデンティティのフォームは主要です。
Are these techniques useful for SIP? They can be used for SIP but are not necessary. In SIP, TLS with mutual authentication can be used inter-domain. A provider receiving a message can then reject any message coming from a domain that does not match the asserted identity of the sender of the message. Such a policy only works in the "trapezoid" model of SIP, whereby there are only two domains in any call - the sending domain, which is where the originator resides, and the receiving domain. These techniques are discussed in Section 26.3.2.2 of RFC 3261 [2]. In forwarding situations, the assumption no longer holds and these techniques no longer work. However, the authenticated identity mechanism for SIP, discussed in Section 5, does work in more complex network configurations and provides fairly strong assertion of identity.
これらのテクニックはSIPの役に立ちますか? それらは、SIPに使用できますが、必要ではありません。 SIPでは、互いの認証があるTLSは中古の相互ドメインであるかもしれません。 そして、メッセージを受け取るプロバイダーはメッセージ送信者の断言されたアイデンティティに合っていないドメインから来るどんなメッセージも拒絶できます。 SIPで、どんな呼び出しにも2つのドメインしかありません。(それは、創始者が住んでいるところです)。そのような政策はSIPの「台形」モデルにうまく行くだけです--送付ドメイン、および受信ドメイン。 セクション26.3でこれらのテクニックについて議論します。.2 .2RFC3261[2]。 推進状況で、仮定はもう成立しません、そして、これらのテクニックはもう利きません。 しかしながら、セクション5で議論したSIPのための認証されたアイデンティティメカニズムは、より複雑なネットワーク・コンフィギュレーションで働いて、アイデンティティの強い主張を公正に提供します。
4.2. Signature-Based Techniques
4.2. 署名ベースのテクニック
Domain Keys Identified Mail (DKIM) Signatures [23] (and several non- standard techniques that preceded it) provide strong identity assertions by allowing the sending domain to sign an email, and then providing mechanisms by which the receiving MTA or Mail User Agent (MUA) can validate the signature.
ドメインキーズIdentifiedメール(DKIM)署名[23](そして、それに先行したいくつかの非標準のテクニック)は、送付ドメインがメールにサインするのを許容して、次に、受信MTAかメール・ユーザー・エージェント(MUA)が署名を有効にすることができるメカニズムを前提とすることによって、強いアイデンティティ主張を提供します。
Unfortunately, when used with blacklists, this kind of authenticated identity is only as useful as the fraction of the emails that utilize it. This is partly true for white lists as well; if any unauthenticated email is accepted for an address on a white list, a spammer can spoof that address. However, a white list can be effective with limited deployment of DKIM if all the people on the white list are those whose domains are utilizing the mechanism, and the users on that white list aren't zombies.
残念ながら、ブラックリストと共に使用されると、この種類の認証されたアイデンティティは単にそれを利用するメールの部分と同じくらい役に立ちます。 また、ホワイトリストに、これは一部本当です。 アドレスのためにホワイトリストで何か非認証されたメールを受け入れるなら、スパマーはそのアドレスをだますことができます。 しかしながら、ホワイトリストはホワイトリストの上のすべての人々がドメインがメカニズムを利用しているそれらであるならDKIMの限られた展開によって有効である場合があります、そして、そのホワイトリストの上のユーザはゾンビではありません。
This kind of identity mechanism is also applicable to SIP, and is in fact, exactly what is defined by SIP's authenticated identity mechanism [17].
この種類のアイデンティティメカニズムは、また、SIPに適切であり、事実上と、まさにSIPの認証されたアイデンティティメカニズム[17]によって定義されることです。
Rosenberg & Jennings Informational [Page 21] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[21ページ]のRFC5039SIPは2008年1月にばらまかれます。
Other signature-based approaches for email include S/MIME[24] and OpenPGP[25].
メールのための他の署名ベースのアプローチはS/MIMEの[24]とOpenPGP[25]を含んでいます。
5. Authenticated Identity in SIP
5. 一口における認証されたアイデンティティ
One of the key parts of many of the solutions described above is the ability to securely identify the sender of a SIP message. SIP provides a secure solution for this problem, called SIP Identity [17], and it is important to discuss it here.
上で説明された解決策の多くの主要な部分の1つはしっかりとSIPメッセージの送付者を特定する能力です。 SIPはSIP Identity[17]と呼ばれるこの問題の安全な解決法を提供します、そして、ここでそれについて議論するのは重要です。
The solution starts by having each domain authenticate its own users. SIP provides HTTP digest authentication as part of the core SIP specification, and all clients and servers are required to support it. Indeed, digest is widely deployed for SIP. However, digest alone has many known vulnerabilities, most notably offline dictionary attacks. These vulnerabilities are all resolved by having each client maintain a persistent TLS connection to the server. The client verifies the server identity using TLS, and then authenticates itself to the server using a digest exchange over TLS. This technique, which is also documented in RFC 3261, is very secure but not widely deployed yet. In the long term, this approach will be necessary for the security properties needed to prevent SIP spam.
各ドメインにそれ自身のユーザを認証させることによって、解決策は始まります。 SIPはコアSIP仕様の一部としてHTTPダイジェスト認証を前提とします、そして、すべてのクライアントとサーバが、それを支持するのに必要です。 本当に、ダイジェストはSIPのために広く配備されます。 しかしながら、ダイジェストだけには、多くの知られている脆弱性、ほとんどの著しくオフラインの辞書攻撃があります。 各クライアントにしつこいTLS接続をサーバに維持させることによって、これらの脆弱性はすべて決議されています。クライアントは、TLSを使用することでサーバのアイデンティティについて確かめて、次に、TLSの上のダイジェスト交換を使用することでサーバにそれ自体を認証します。 このテクニック(また、RFC3261に記録される)は、まだ非常に安全ですが、広く配備されていません。 長期で、このアプローチはSIPスパムを防ぐのが必要であるセキュリティの特性に必要になるでしょう。
Once a domain has authenticated the identity of a user, when it relays a message from that user to another domain, the sending domain can assert the identity of the sender, and include a signature to validate that assertion. This is done using the SIP identity mechanism [17].
そのユーザから別のドメインまで伝言を伝えるとき、ドメインがいったんユーザのアイデンティティを認証すると、送付ドメインは、送付者のアイデンティティについて断言して、その主張を有効にするために署名を含むことができます。 これはSIPアイデンティティメカニズム[17]を使用し終わっています。
A weaker form of identity assertion is possible using the P-Asserted- Identity header field [5], but this technique requires mutual trust among all domains. Unfortunately, this becomes exponentially harder to provide as the number of interconnected domains grows. As that happens, the value of the identity assertion becomes equal to the trustworthiness of the least trustworthy domain. Since spam is a consequence of the receiving domain not being able to trust the sending domains to disallow the hosts in the sending to send spam, the P-Asserted-Identity technique becomes ineffective at exactly the same levels of interconnectedness that introduce spam.
より弱い形式のアイデンティティ主張はPで断言されたアイデンティティのヘッダーフィールド[5]を使用することで可能ですが、このテクニックはすべてのドメインの中で信頼関係を必要とします。 残念ながら、これはインタコネクトされたドメインの数が成長するとき指数関数的に提供しにくいようになります。 それが起こるのに従って、アイデンティティ主張の値は最も信頼できないドメインの信頼できることと等しくなります。 スパムがスパムを送るために発信でホストを禁じるために送付ドメインを信じることができない受信ドメインの結果であるので、アイデンティティであると断言されたPのテクニックはスパムを紹介するインタコネクトのまさに同じレベルで効力がなくなります。
Consider the following example to help illustrate this fact. A malicious domain -- let us call them spam.example.com, would like to send SIP INVITE requests with false P-Asserted-Identity, indicating users outside of its own domain. spam.example.com finds a regional SIP provider in a small country who, due to its small size and disinterest in spam, accepts any P-Asserted-Identity from its customers without verification. This provider, in turn, connects to a larger, interconnect provider. They do ask each of their customers
以下の例が、この事実を例証するのを助けると考えてください。 それらをspam.example.comと呼びましょう、アイデンティティであると断言された誤ったPとの要求をSIP INVITEに送りたくて、それ自身のドメインの外でユーザを示して。悪意があるドメイン--spam.example.comはスパムのその小型と公平無私のため顧客から検証なしでアイデンティティであると断言されたどんなPも受け入れる小さい国で地方のSIPプロバイダーを見つけます。 このプロバイダーは順番により大きい内部連絡プロバイダーに接続します。 彼らは自分達の顧客各人に尋ねます。
Rosenberg & Jennings Informational [Page 22] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[22ページ]のRFC5039SIPは2008年1月にばらまかれます。
to verify P-Asserted-Identity but have no easy way of enforcing it. This provider, in turn, connects to everyone else. As a consequence, the spam.example.com domain is able to inject calls with a spoofed caller ID. This request can be directed to any recipient reachable through the network (presumably everyone due to the large size of the root provider). There is no way for a recipient to know that this particular P-Asserted-Identity came from this bad spam.example.com domain. As the example shows, even though the central provider's policy is good, the overall effectiveness of P-Asserted-Identity is still only as good as the policies of the weakest link in the chain.
アイデンティティであると断言されたPについて確かめますが、それを実施するどんな簡単な方法も持たないように。 このプロバイダーは順番に他の人皆に接します。 結果として、spam.example.comドメインはだまされた発信者番号を呼び出しに注射できます。 ネットワーク(根のプロバイダーの大判によるおそらく皆)を通して届いているどんな受取人にもこの要求を向けることができます。 受取人がアイデンティティであると断言されたこの特定のPがこの悪いspam.example.comドメインから来たのを知る方法が全くありません。 その例にあるように、主要なプロバイダーの方針が良いのですが、アイデンティティであると断言されたPの総合的な有効性はまだ単にチェーンで最も弱いリンクの方針と同じくらい良いです。
SIP also defines the usage of TLS between domains, using mutual authentication, as part of the base specification. This technique provides a way for one domain to securely determine that it is talking to a server that is a valid representative of another domain.
また、基礎仕様の一部として互いの認証を使用して、SIPはドメインの間のTLSの使用法を定義します。 このテクニックは1つのドメインがそれが別のドメインの有効な代表であるサーバと話していることをしっかりと決定する方法を提供します。
6. Framework for Anti-Spam in SIP
6. 一口における反スパムのための枠組み
Unfortunately, there is no magic bullet for preventing SIP spam, just as there is none for email spam. However, the combination of several techniques can provide a framework for dealing with spam in SIP. This section provides recommendations for network designers in order to help mitigate the risk of spam.
残念ながら、特効薬は、全くメールスパムのためのなにもあるだけではないのでSIPスパムを防ぐためにありません。 しかしながら、いくつかのテクニックの組み合わせはSIPでスパムに対処するのに枠組みを提供できます。 このセクションは、スパムの危険を緩和するのを助けるためにネットワーク設計者のための推薦を提供します。
There are four core recommendations that can be made:
することができる4つのコア推薦状があります:
Strong Identity: Firstly, in almost all of the solutions discussed
above, there is a dependency on the ability to authenticate the
sender of a SIP message inter-domain. Consent, reputation
systems, computational puzzles, and payments at risk, amongst
others, all work best when applied only to new requests, and
successful completion of an introduction results in the placement
of a user on a white list. However, usage of white lists depends
on strong identity assertions. Consequently, any network that
interconnects with others should make use of strong SIP identity
as described in RFC 4474. P-Asserted-Identity is not strong
enough.
強いアイデンティティ: まず第一に、上で議論した解決策のほとんどすべてには、依存がSIPメッセージ相互ドメインの送付者を認証する能力にあります。 同意、新しい要求だけに適用されると、評判システム(他のもので危険なコンピュータのパズル、および支払い)は、すべてうまくいって、序論の無事終了はホワイトリストにおけるユーザのプレースメントをもたらします。 しかしながら、ホワイトリストの使用法は強いアイデンティティ主張によります。 その結果、他のものと共に内部連絡されるどんなネットワークもRFC4474で説明されるように強いSIPのアイデンティティを利用するべきです。 アイデンティティであると断言されたPは十分強くはありません。
White Lists: Secondly, with a strong identity system in place,
networks are recommended to make use of white lists. These are
ideally built off existing buddy lists, if present. If not,
separate white lists can be managed for spam. Placement on these
lists can be manual or based on the successful completion of one
or more introduction mechanisms.
ホワイトは記載します: 第二に、強いアイデンティティシステムが適所にあった状態で、ネットワークがホワイトリストを利用することが勧められます。 存在しているなら、これらは既存の友達リストから理想的に建てられます。 そうでなければ、スパムのために別々のホワイトリストに対処できます。 これらのリストにおけるプレースメントは、手動であり、1つ以上の序論メカニズムの無事終了に基づくことができます。
Solve the Introduction Problem: This in turn leads to the final
recommendation to be made. Network designers should make use of
one or more mechanisms meant to solve the introduction problem.
序論問題を解決してください: これは順番に作られているという最終勧告に通じます。 ネットワーク設計者は序論問題を解決することになっていた1つ以上のメカニズムを利用するべきです。
Rosenberg & Jennings Informational [Page 23] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[23ページ]のRFC5039SIPは2008年1月にばらまかれます。
Indeed, it is possible to use more than one and combine the
results through some kind of weight. A user that successfully
completes the introduction mechanism can be automatically added to
the white list. Of course, that can only be done usefully if
their identity is verified by SIP Identity. The set of mechanisms
for solving the introduction problem, as described in this
document, are based on some (but not all) of the techniques known
and used at the time of writing. Providers of SIP services should
keep tabs on solutions in email as they evolve, and utilize the
best of what those techniques have to offer.
本当に、1つ以上を使用して、ある種の重さを通して結果を結合するのは可能です。 自動的に首尾よく序論メカニズムを完成するユーザはホワイトリストに追加できます。 もちろん、SIP Identityが彼らのアイデンティティについて確かめる場合にだけ、有効にそれができます。 本書では説明されるように序論問題を解決するためのメカニズムのセットはこれを書いている時点で知られて、使用されるテクニックのいくつか(すべてでない)に基づいています。 それらのテクニックが提供しなければならないものに関するベストを発展して、利用するとき、SIPサービスのプロバイダーはメールで解決策を絶えず見守るべきです。
Don't Wait Until It's Too Late: But perhaps most importantly,
providers should not ignore the spam problem until it happens! As
soon as a provider inter-connects with other providers, or allows
SIP messages from the open Internet, that provider must consider
how they will deal with spam.
遅くなり過ぎるまで、待たないでください: しかし、恐らく最も重要に、プロバイダーは起こるまでスパム問題を無視するべきではありません! 他のプロバイダーで内部連絡するか、または開いているインターネットからSIPにメッセージを許容するとすぐに、そのプロバイダーは、それらがどのようにスパムに対処するかを考えなければなりません。
7. Additional Work
7. 追加仕事
Though the above framework serves as a good foundation on which to deal with spam in SIP, there are gaps, some of which can be addressed by additional work that has yet to be undertaken.
上の枠組みはSIPでスパムに対処する良い基礎として機能しますが、ギャップがあります。まだ引き受けられていない追加仕事でその或るものを記述できます。
One of the difficulties with the strong identity techniques is that a receiver of a SIP request without an authenticated identity cannot know whether the request lacked such an identity because the originating domain didn't support it, or because a man-in-the-middle removed it. As a result, transition mechanisms should be put in place to allow these to be differentiated. Without it, the value of the identity mechanism is much reduced.
強いアイデンティティのテクニックにおける困難の1つは由来しているドメインがそれを支持しなかったので要求がそのようなアイデンティティを欠いていたか、または中央の男性がそれを取り除いたので認証されたアイデンティティのないSIP要求の受信機が知ることができないということです。 その結果、変遷メカニズムは、これらが微分されるのを許容するために適所に置かれるべきです。 それがなければ、アイデンティティメカニズムの値は非常に減少します。
8. Security Considerations
8. セキュリティ問題
This document is entirely devoted to issues relating to spam in SIP and references a variety of security mechanisms in support of that goal.
このドキュメントはSIPと参照にその目標を支持してさまざまなセキュリティー対策をばらまくために関係する問題に完全にささげられます。
9. Acknowledgements
9. 承認
The authors would like to thank Rohan Mahy for providing information on Habeas, Baruch Sterman for providing costs on VoIP termination services, and Gonzalo Camarillo and Vijay Gurbani for their reviews. Useful comments and feedback were provided by Nils Ohlmeir, Tony Finch, Randy Gellens, Lisa Dusseault, Sam Hartman, Chris Newman, Tim Polk, Donald Eastlake, and Yakov Shafranovich. Jon Peterson wrote some of the text in this document and has contributed to the work as it has moved along.
作者は、Habeas(提供するためのStermanが彼らのレビューにVoIP終了サービス、ゴンサロ・キャマリロ、およびビジェイGurbaniでかかるバルク書)の情報を提供して頂いて、Rohanマーイに感謝したがっています。 役に立つコメントとフィードバックはニルスOhlmeir、トニーFinch、ランディGellens、リサDusseault、サム・ハートマン、クリス・ニューマン、ティム・ポーク、ドナルド・イーストレーク、およびヤコフShafranovichによって提供されました。 ジョン・ピーターソンは、本書ではテキストのいくつかを書いて、先に進んだとき、仕事に貢献しました。
Rosenberg & Jennings Informational [Page 24] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[24ページ]のRFC5039SIPは2008年1月にばらまかれます。
10. Informative References
10. 有益な参照
[1] Campbell, B., Mahy, R., and C. Jennings, "The Message Session
Relay Protocol (MSRP)", RFC 4975, September 2007.
[1] キャンベル、B.、マーイ、R.、およびC.ジョニングス、「メッセージセッションリレープロトコル(MSRP)」、RFC4975 2007年9月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[3] キャンベル、B.、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[5] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[5] ジョニングス、C.、ピーターソン、J.、およびM.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
[6] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[6] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
[7] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857,
August 2004.
[7] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のためのウォッチャー情報イベントテンプレートパッケージ」、RFC3857、2004年8月。
[8] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004.
[8] ローゼンバーグ、J.、「拡張マークアップ言語(XML)はウォッチャー情報のための形式を基礎づけた」RFC3858、2004年8月。
[9] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[9]FaltstromとP.とM.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。
[10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[10] ローゼンバーグ(J.、「拡張マークアップ言語(XML)構成アクセス・プロトコル(XCAP)」RFC4825)は2007がそうするかもしれません。
[11] Rosenberg, J., "Presence Authorization Rules", RFC 5025,
October 2007.
[11] ローゼンバーグ、J.、「存在認可規則」、RFC5025、2007年10月。
[12] Rosenberg, J., "A Framework for Consent-Based Communications in
the Session Initiation Protocol (SIP)", Work in Progress,
October 2007.
[12] ローゼンバーグ、J.、「セッション開始プロトコル(一口)の同意ベースのコミュニケーションのための枠組み」が進歩、2007年10月に働いています。
[13] Camarillo, G., "A Document Format for Requesting Consent", Work
in Progress, October 2007.
[13] キャマリロ、G.、「同意を要求するためのドキュメント・フォーマット」が進歩、2007年10月に働いています。
Rosenberg & Jennings Informational [Page 25] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[25ページ]のRFC5039SIPは2008年1月にばらまかれます。
[14] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Work in Progress,
October 2005.
[14] ローゼンバーグ、J.、「セッション開始プロトコル(一口)におけるアプリケーション間連携のための枠組み」が進歩、2005年10月に働いています。
[15] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[15] バーガー、E.、およびM.は、「主要なプレス刺激(KPML)のためのセッション開始プロトコル(一口)イベントパッケージ」とドリーに載せて移動させます、RFC4730、2006年11月。
[16] Rosenberg, J., "Applying Loose Routing to Session Initiation
Protocol (SIP) User Agents (UA)", Work in Progress, June 2007.
[16] 「セッション開始プロトコル(一口)ユーザエージェント(UA)にゆるいルート設定を適用し」て、ローゼンバーグ、J.は進歩、2007年6月に働いています。
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[17] ピーターソン、J.、およびC.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
[18] Allman, E. and H. Katz, "SMTP Service Extension for Indicating
the Responsible Submitter of an E-Mail Message", RFC 4405,
April 2006.
[18] オールマン、E.、およびH.キャッツ、「SMTPはメールメッセージの責任があるSubmitterを示すための拡大を修理します」、RFC4405、2006年4月。
[19] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[19] リヨン、J.、およびM.ウォン、「送付者ID:」 「メールを認証します」、RFC4406、2006年4月。
[20] Lyon, J., "Purported Responsible Address in E-Mail Messages",
RFC 4407, April 2006.
[20] リヨン、J.、「メールメッセージの主張された原因となるアドレス」、RFC4407、2006年4月。
[21] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,
April 2006.
[21] ウォンとM.とW.Schlitt、「2006年4月にメール、バージョン1インチ、RFC4408におけるドメインの使用を認可するための送付者方針枠組み(SPF)。」
[22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[22] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[23] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
RFC 4871, May 2007.
[23] オールマン、E.、カラス、J.、ディラニー、M.、リッベイ、M.、フェントン、J.、およびM.トーマス、「DomainKeysはメール(DKIM)署名を特定しました」、RFC4871、2007年5月。
[24] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[24]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[25] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001.
2001年8月の[25] エルキンズとM.とデルTortoとD.とレヴィエン、R.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」RFC3156。
[26] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately
Hard, Memory Bound Functions, NDSS 2003", February 2003.
[26]AbadiとM.と穴とM.とManasse、M.とT.Wobber、「NDSS2003、適度に、一生懸命、メモリは機能を縛りました」。2003年2月の
Rosenberg & Jennings Informational [Page 26] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[26ページ]のRFC5039SIPは2008年1月にばらまかれます。
[27] Abadi, M., Burrows, M., Birrell, A., Dabek, F., and T. Wobber,
"Bankable Postage for Network Services, Proceedings of the 8th
Asian Computing Science Conference, Mumbai, India",
December 2003.
[27] Abadi(M.)は穴を堀ります、M.、ビレル、A.、Dabek、F.とT.Wobber、「ネットワーク・サービスのための確かな送料、第8アジアの電子計算学コンファレンスの議事、ムンバイ、インド」2003年12月。
[28] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work,
Third Annual Workshop on Economics and Information Security",
May 2004.
[28] 「仕事の証拠は働かないと判明して、経済学と情報に関する第3例年のワークショップは保証です」というクレイトン、R.、およびB.ローリーは2004がそうするかもしれません。
Authors' Addresses
作者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコのニュージャージーエディソン(米国)
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
メール: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Cullen Jennings Cisco 170 West Tasman Dr. San Jose, CA 95134 US
カレンジョニングスコクチマス170の西タスマンサンノゼ博士、カリフォルニア95134米国
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 408 421-9990 メールしてください: fluffy@cisco.com
Rosenberg & Jennings Informational [Page 27] RFC 5039 SIP Spam January 2008
ローゼンバーグとジョニングス情報[27ページ]のRFC5039SIPは2008年1月にばらまかれます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Rosenberg & Jennings Informational [Page 28]
ローゼンバーグとジョニングスInformationalです。[28ページ]
一覧
スポンサーリンク
