[要約] RFC 5039は、SIPとスパムの関係について説明しており、SIPベースのスパム攻撃の問題を解決するためのガイドラインを提供しています。目的は、SIPベースの通信におけるスパムの脅威を理解し、対策を講じることです。
Network Working Group J. Rosenberg
Request for Comments: 5039 C. Jennings
Category: Informational Cisco
January 2008
The Session Initiation Protocol (SIP) and Spam
セッション開始プロトコル（SIP）とスパム
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.
バルクの未承諾メッセージの送信として定義されたスパムは、インターネットメールを悩ませています。残念ながら、スパムは電子メールに限定されません。ユーザー間通信を可能にするシステムに影響を与える可能性があります。セッション開始プロトコル（SIP）は、ユーザー間マルチメディア通信のシステムを定義します。したがって、電子メールと同じように、スパムの影響を受けやすいです。このドキュメントでは、SIPのスパムの問題を分析します。最初に、問題が同じである方法と、電子メールとは異なる方法を特定します。次に、電子メールについて議論されているさまざまなソリューションを調べ、SIPへの適用性を検討します。
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
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.
セッション開始プロトコル（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のために定義されているプロトコルメカニズムを特定し、実装者に推奨するプロトコルメカニズムを特定することにより、これらの目標を達成するのに役立ちます。
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.
コールスパム：このタイプのスパムは、セッション開始の試みのバルクの未承諾セット（つまり、招待リクエスト）として定義され、音声、ビデオ、インスタントメッセージング[1]、またはその他のタイプの通信セッションを確立しようとします。ユーザーが答える必要がある場合、スパマーはリアルタイムメディアでメッセージを中継します。これは、SIPに適用される古典的なテレマーケティングスパムです。これは、多くの場合、IPテレフォニーまたはスピット上のスパムと呼ばれます。
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スパム：このタイプのスパムは電子メールに似ています。これは、スパマーが伝えようとしているというメッセージが含まれているコンテンツには、インスタントメッセージの一括未満のセットとして定義されます。IMスパムは、SIPメッセージ[3]リクエストを使用して最も自然に送信されます。ただし、ユーザーのディスプレイにコンテンツを自動的に表示する他のリクエストでも十分です。これには、大規模なサブジェクトヘッダーによる招待リクエスト（被験者がユーザーにレンダリングされる場合があるため）、またはテキストまたはHTMLボディを使用してリクエストを招待することが含まれます。これは、多くの場合、インスタントメッセージングまたはSPIMでスパムと呼ばれます。
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スパムに似ています。これは、順番にユーザーの「バディリスト」または「ホワイトリスト」にアクセスしようとして、存在イベントパッケージ[6]の登録要求[4]）の存在要求のバルクの未承諾セット（つまり、プレゼンスイベントパッケージ[4]）として定義されます。それらを送信するか、他の形式のコミュニケーションを開始します。これは、プレゼンスプロトコルまたはSPPPを介したスパムと呼ばれることがあります。
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メッセージがあります。ただし、他のほとんどの場合、ユーザーにコンテンツが配信されることも、ユーザーからの入力を求めません。むしろ、彼らはオートマトンによって答えられます。オプションはこの良い例です。ユーザーエージェントサーバー（UAS）によって自動的に回答されるため、Spammerがオプションリクエストを送信する際にはほとんど価値がありません。ユーザーに配信されるコンテンツはありませんが、相談されません。
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スパムの可能性を検討します。これは、大まかなコスト分析によって行われます。これらの分析はすべて近似しており、問題の大きさの大まかな感覚を与えるだけであることに注意する必要があります。
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.
コールスパムは発生しますか？それは答えるべき重要な質問です。明らかに、それは既存の電話ネットワークで、テレマーケティング担当者の呼び出しの形で発生します。これらの呼び出しは迷惑ですが、電子メールスパムと同じ種類のボリュームで到着しません。違いはコストです。スパマーが電子メールを送信するよりも電話をかけるのに多くの費用がかかります。このコストは、テレマーケティング担当者の呼び出しを実行できるシステムのコスト、および通話ごとのコストの観点から現れます。
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ユーザーエージェントです。コールが接続された場合、スパムアプリケーションは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) are even more expensive than inbound trunks due to the reciprocal termination charges that a provider pays and receives.
通話ごとのコストも大幅に削減されます。通常の住宅用電話回線では、一度に1つのコールを配置できます。追加の行が必要な場合は、ユーザーはより高価な接続を購入する必要があります。通常、大量のテレマーケティングサービスにはT1またはT3が必要になります。そのようなアクセスは非常に高価であり、平均的なユーザーの手の届かないところにあります。T1ラインは、月額約250米ドル、通話の場合は1分あたり約1.5セントです。アウトバウンドコール（この場合など）にのみ使用されるT1ラインは、プロバイダーが支払い、受け取る相互終了料金により、インバウンドトランクよりもさらに高価です。
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の通話試行を想定します。大量の呼び出しでは、1分間の料金はT1の定額料金をはるかに上回ります。その結果、10秒のコンテンツを想定して、スパム配達が成功するたびに250,000マイクロセントのコストがかかります。
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では、このコストは大幅に削減されます。500 kbpsのアップストリーム帯域幅を提供する典型的なブロードバンドインターネット接続を使用したスパマーを検討してください。通話を開始するには、単一の招待メッセージが必要です。簡単にするために、これは1 kbであると仮定すると、500 kbpsの上流DSLまたはケーブルモデム接続により、1秒あたり約62のコール試行が可能になります。通話を成功させるには、メッセージを受信機に送信するのに十分な帯域幅が必要です。低い圧縮コーデック（5.3 kbpsでのG.723.1など）を仮定すると、これにはRTP、UDP、およびIPオーバーヘッドの後に約16 kbpsが必要です。500 kbpsの上流帯域幅では、これは31回も同時にコールが進行することを意味します。通話ごとに10秒のコンテンツを使用すると、1秒あたり3.1の成功した通話試行が可能になります。ブロードバンドアクセスが月額約50ドルの場合、成功した音声スパムあたりのコストはそれぞれ約6.22マイクロセントです。これは、通話が1日24時間、月に30日間行うことができると仮定していますが、そうでない場合があります。
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.
ゾンビの問題を無視しても、このコストの削減は、国際的な呼び出しに対してさらに増幅されます。現在、国際的な国境を越えてテレマーケティングの呼びかけはほとんどありません。これは、主に国際的な呼び出しのコストが多いためです。これは、テレマーケティング担当者が呼び出すことができない米国の国家リストである「コールリスト」が「リストしない」が効果的である理由の1つです。法律は米国企業にのみ影響しますが、ほとんどのテレマーケティングの呼び出しは国内であるため、効果的でした。残念ながら（そして幸いなことに）、IPネットワークはこれらの種類の境界を提供せず、世界中のどこからでもSIP URIへの呼び出しが可能です。これにより、大幅に削減されたコストで国際的なスパムが可能になります。
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、ディスク、または終了コストではなく、アクセス帯域幅であると想定しています。終了費用はさらに議論に値します。現在、ほとんどのVoice over IP（VOIP）コールは、公開された電話ネットワーク（PSTN）で終了しており、この終了はコールマネーの発信者にコストがかかります。これらのコストは、T1の1分間のレートに似ています。ボリュームやその他の要因に応じて、1分あたり0.5セントから3セントの範囲です。ただし、機器のコスト、トレーニング、およびその他の要因は、SIPベースの終了の場合はT1よりもはるかに低く、コストは回路の接続よりもまだ低くなっています。さらに、VoIPシステムの現在の傾向は、PSTNに触れないコール、つまり実際のSIPエンドポイントへの呼び出しに対して終了を無料にすることです。したがって、ますます多くのSIPエンドポイントがオンラインになると、終了コストはおそらく低下します。それまでは、SIPスパムは、通常のPSTNエンドポイントで行われた、従来のテレマーケティング担当者のコールの低コスト形式のために、終了サービスと協調して使用できます。
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 kb、500 kbpsの上流リンクを想定すると、スパマーは毎秒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.
スパムのコストの別の部分は、住所を収集することです。スパマーは、時間の経過とともに、スパムが指示されているフォームユーザー@ドメインのそれぞれの電子メールアドレスの計り知れないリストを構築しています。SIPは同じ形式のアドレス指定を使用しているため、電子メールアドレスを有効なSIPアドレスに簡単に変えることができる可能性があります。電話番号は、有効なSIPアドレスも表しています。終了プロバイダーとの協調では、スパマーは従来のPSTNデバイスでSIPコールを監督できます。電子メールスパマーがWebスイープを実行するときに電話番号を収集しているかどうかは明らかではありませんが、おそらくそうするのは難しくありません。さらに、電子メールアドレスとは異なり、電話番号は有限のアドレススペースであり、かなり密集したアドレススペースです。その結果、電話番号を順番に順番に進めると、かなり高いヒット率が生じる可能性があります。したがって、スパマーがスパムを指示できる多数のSIPアドレスを取得するには、コストが比較的低いようです。
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のメッセージと500 kbpsの上流帯域幅を仮定します。つまり、1秒あたり62.5メッセージです。月額50ドルで、結果はメッセージあたり.31マイクロセントです。これは音声スパムよりも少ないですが、実質的には低くはありません。コストはおそらく電子メールスパムと同等です。しかし、私は電子メールよりもはるかに邪魔になります。今日のシステムでは、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.
IMシステムには2つの異なるタイプのIMシステムがあることを指摘することが重要です：ページモードとセッションモード。ページモードIMシステムは、電子メールと同じように機能し、各IMが個別のメッセージとして送信されます。セッションモードIMでは、セッションを確立するためのコミュニケーションの前にシグナル伝達があり、その後、IMSはセッションの一部として、おそらくポイントツーポイントを交換します。モダリティは、適用できるスパムテクニックの種類に影響を与えます。電子メールの手法はページモードIMに同じように適用できますが、セッションモードIMはテレフォニーに似ており、多くのテクニック（コンテンツフィルタリングなど）を適用するのが難しいです。
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 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.
興味深いことに、これはユーザーに情報を伝える手段を提供します。SIP：please-buy-my-product@spam.example.comなどのアイデンティティからサブスクライブリクエストを生成することにより、送信者がプレゼンスにアクセスする許可を持たず、受信しない場合でも、簡単なメッセージをユーザーに伝えることができます。そのため、プレゼンススパムは、伝達されるコンテンツの量が限られているIMスパムの形式と見なすことができます。制限は、許可システムを介してユーザーに伝えられるウォッチャーによって生成された情報の量に等しくなります。
This type of spam also shows up in consent frameworks used to prevent call spam, as discussed in Section 3.4.
このタイプのスパムは、セクション3.4で説明したように、コールスパムを防ぐために使用される同意フレームワークにも表示されます。
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固有のソリューションも検討します。
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つの理由があります。まず、ユーザーが通話に応答する場合、コンテンツが配信される前にユーザーがすでに確立され、ユーザーは注意を払っています。ユーザーがそれを見る前に、スパムを分析することはできません。次に、ユーザーがアクセスする前にコンテンツが保存されている場合（たとえば、ボイスメールで）、コンテンツは録画されたオーディオまたはビデオの形式になります。音声およびビデオ認識技術は、コンテンツを分析し、スパムであるかどうかを判断するのに十分ではない可能性があります。確かに、システムがそのような分析を実行するために録音で音声認識を実行しようとした場合、スパマーはバックグラウンドノイズ、不十分な文法、さまざまなアクセントで呼び出しを簡単に行うことができます。。ビデオ認識はさらに困難であり、主に研究分野のままです。
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スパムで直接機能します。
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.
ブラックリストは、スパムフィルターがスパマーを識別するアドレスのリストを維持するアプローチです。これらのアドレスには、username（spammer@example.com）とドメイン全体（example.com）の両方が含まれます。純粋なブラックリストは、2つの理由で電子メールではあまり効果的ではありません。まず、電子メールアドレスは簡単にスプーフィングできるため、送信者が他の誰かのふりをすることが簡単になります。送信者が送信するアドレスを変化させると、ブラックリストはほぼ完全に役に立たなくなります。2番目の問題は、送信者が住所からの断熱をしなくても、電子メールアドレスがほぼ無限の供給であることです。各ドメインには、電子メールアドレスの無限の供給が含まれており、新しいドメインは非常に低コストで取得できます。さらに、ユーザーがほとんど無料でアイデンティティを取得できるようにするパブリックプロバイダーが常に存在します（たとえば、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スパムでも効果がない可能性があります。ドメイン間のメカニズム電子メールとSIPの認証されたアイデンティティについては、セクション4およびセクション5で説明します。これらのメカニズムが使用され、ドメイン間通信で有効化されていると仮定すると、送信者アドレスを偽造することが困難になります。ただし、住所のほぼ無限の供給を取得することはまだ安いままです。
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.
ただし、ユーザーが白いリストに明示的に置かれていない人から電子メールを受信できることを禁止することを禁止するため、それらは完全な解決策ではありません。その結果、白いリストには「紹介問題」の解決策が必要です。初めて誰かに会う方法を決定し、白いリストに配置する必要があるかどうかを決定します。導入の問題に加えて、Whiteは、管理するユーザーからの需要時間をリストします。
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.
ユーザーのコンピューターが侵害され、ゾンビを使用している場合、そのコンピューターは通常、ユーザーを白いリストに載せた人にスパムを送信するために使用できます。
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がユーザーBのWhiteまたはBlackリストに載っていない場合、ユーザー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システムのほとんどは、単一の管理ドメイン内の通信のみを許可するため、送信者のアイデンティティを認証できます。電子メールは、多くの場合、メーリングリストに同様の同意ベースのシステムを使用します。ユーザーがそのアドレスでメールを受信できることを確認するために、Cookieをメールアドレスに送信することに基づいて、認証の形式を使用します。
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.
この種の同意ベースのコミュニケーションは、Watcher Information Eventパッケージ[7]とデータ形式[8]を使用して、SIPで存在するためにSIPで標準化されています。これにより、ユーザーは誰かが購読していることを確認できます。次に、XML構成アクセスプロトコル（XCAP）[10]と、ユーザーが通信する許可を提供するためのXML形式[11]とともに使用されます。
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用語で爆発者として知られる「メーリングリスト」にユーザーを追加することを許可することに焦点を当てています。スパマーは通常、そのような爆発者機能を使用していますが、おそらくスパマーによって実行されたものはこの手法を使用しません。したがって、この同意フレームワークは、スパムの問題に直接適用できません。ただし、白いリストを管理するためのツールとして便利です。パブリッシュメカニズムを通じて、ユーザーは特定の送信者からの着信コールのみを受け入れることを示す許可ドキュメント[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のユーザー部分は、限られた無料のフォームテキストを許可するため、簡単なメッセージを伝えるために使用できます。たとえば、「sip：please-buy-my-product-this-product-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.
そのため、本当の問題は、同意システムがユーザーが非スパンマーに同意を与え、スパンマーを拒否することを可能にするかどうかです。認証されたアイデンティティが役立ちます。企業のユーザーは、たとえば、同じ業界の他の企業の送信者に同意することを知っています。ただし、消費者スペースでは、sip：bob@example.comがユーザーと通信しようとする場合、そのユーザーはボブがスパマーであるか、高校の長い友人かをどのように判断しますか？アイデンティティだけに基づいた方法はありません。そのような場合、有用な手法は、ボブがコミュニケーションをとる許可を付与することですが、許可が非常に限られていることを確認することです。
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語以下のテキストを送信する許可が与えられる場合があります。これは、自分自身を識別するために使用できるため、ユーザーは許可が適切かどうかを判断できます。自動化されたシステムが、この最初の短いメッセージで何らかの形のコンテンツ分析を実行できる可能性もあります。ただし、スパマーがメッセージを伝えるのに十分なテキストであるこのテキストでは、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の問題を完全に解決することはできないようですが、それは役立つようです。
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.
評判システムは、白または黒のリストと組み合わせて使用されます。ユーザーAがユーザーBのホワイトリストに載っていないと仮定し、AはユーザーBに連絡しようとします。同意ベースのシステムを使用した場合、Bは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.
従来、評判システムは、高度に集中化されたメッセージングアーキテクチャに実装されています。今日のメッセージングで最も広範な評判システムは、モノリシックインスタントメッセージングプロバイダーによって展開されています（ただし、高度なインタラクティブ性を持つ多くのWebサイトでは、非常に類似した評判の概念を採用しています）。評判は、ユーザーフィードバックに基づいて計算されます。たとえば、メッセージングクライアントのユーザーインターフェイスのボタンは、特定のユーザーが虐待的であることをシステムに通知できるようにする可能性があります。もちろん、単一のユーザーの入力は自分の評判を台無しにするには不十分である必要がありますが、一貫した否定的なフィードバックは虐待的なユーザーに負の評判スコアを与えます。
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システムを実行する大規模なインスタントメッセージングプロバイダーが含まれます。まず第一に、そのコントロールはユーザーに比較的強力なIDアサーションを提供します（すべてのユーザーが共通のプロバイダーを信頼し、共通のプロバイダーは認証とIDのアービターであるため）。第二に、評判を管理できる単一の場所を提供します。
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 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.
したがって、肯定的な評判システムはネガティブな評判システムよりも優れていますが、完璧とはほど遠いものです。しかし、興味深いことに、存在ベースのシステムと評判システムを組み合わせると、興味深い融合が生まれます。存在の「バディリスト」の概念は、実際には白いリストであり、バディリストのユーザーがあなたが「賞賛している」人々であると推測できます。これにより、「賞賛」ボタンの使用におけるユーザー慣性の問題がなくなり、評判の最初の確立が自動化されます。
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.
ユーザーマシンが侵害され、ゾンビに変わった場合、これによりスパムが送信され、否定的な方法で評判に影響を与える可能性があります。彼らの評判が低下すると、前向きな評判を再確立することは非常に困難になります。
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".
スパマーは、Webサイトやその他の公開情報源からメールアドレスを収集することにより、スパムリストを作成します。スパムを最小限に抑える1つの方法は、住所を困難または不可能にすることです。スパムボットは通常、「user@domain」という形式のページでテキストを探し、そのフォームのすべてが電子メールアドレスであると仮定します。このようなスパムボットから隠れるために、多くのWebサイトは最近、人間に使用できるが、オートマトンが電子メールアドレスとして読むのは難しい形でメールアドレスの配置を開始し始めました。例には、「DOT COMの例のユーザー」や「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.
アドレスのソースはWebサイトである必要はないことに言及する価値があります。アドレスを含む公開されているサービスで十分です。その結果、列挙[9]は、スパマーの潜在的な金鉱山として引用されています。これにより、スパマーはE164.ARPAでツリーを通過し、データをマイニングすることにより、SIPや他のURIを収集できます。この問題は、実際の数値とは対照的に、数字のプレフィックスのみがDNSに表示される場合、部分的に軽減されます。ただし、その場合でも、スパマーがより安価な直接SIP接続を通じてどの電話番号に到達できるかを学ぶための手法を提供します。
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.
難読化に対処するための関連する手法は、限られた使用アドレスです。この手法では、ユーザーには多数の電子メールアドレスが自由に使用されており、それぞれが適用可能性に制約があります。限られた使用アドレスは、定期的に期限切れになるように時間帯になる可能性があります。または、各特派員に別のメールアドレスを与えることができます。その特派員からスパムが到着すると、与えられた限られた使用アドレスが終了します。別のバリエーションでは、いくつかのプロパティを共有する複数のユーザーに同じ限定使用アドレスが与えられます。たとえば、すべての同僚、さまざまな企業のすべての同僚、すべての小売業者など。スパムがアドレスの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つは、人々があなたに到達するのが難しくなることです。友達に配布するメールアドレスがスパムされた場合、それを変更するには、友人に新しいアドレスを知らせる必要があります。SIPは、存在を使用することにより、この問題を部分的に解決するのに役立ちます[6]。
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.
あなたのメールアドレスを友達に配る代わりに、あなたはあなたの存在感を配るでしょう。友人があなたにメールを送信したいとき、彼らはあなたの存在を購読します（実際、彼らはバディリストアプリケーションから継続的に購読される可能性があります）。存在データには、到達できるメールアドレスを含めることができます。このメールアドレスは難読化され、単一使用することができます。これは、あなたの存在を要求するバディごとに異なります。これらの変更はあなたの仲間に直接プッシュされるため、それらは絶えず変更することもできます。ある意味では、バディリストは自動的に更新されたアドレス帳を表しているため、問題を排除します。
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.
別のアプローチは、すべての特派員に別のアドレスを提供することです。そうすることで、アドレスを変更する必要があることを「良い」ユーザーに伝える必要はありません。これは、使い捨てアドレスの極端な形式であり、単一使用アドレスと呼ぶことができます。メカニズムは、単一使用アドレスの無限の供給である[16]の生成のためにSIPで利用できます。ただし、難しい部分は、これらのアドレスの配布と管理のための有用なメカニズムのままです。
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としても知られています（完全に自動化されたパブリックチューリングテストは、コンピューターと人間を伝えるために）。パズルが正しく回答された場合、送信者はユーザーの白いリストに配置されます。これらのパズルは、多くのバックグラウンドノイズを備えた画像内の単語または数字のシーケンスを認識するという形を頻繁に取ります。テストは、Automataが単語または数字のシーケンスを抽出するために必要な画像認識を簡単に実行できないように設計する必要がありますが、通常は人間のユーザーができます。画像処理と人工知能が継続的に進行しているため、このようなテストの設計は容易ではありません。その結果、キャプチャの有効性は、スパマーが自動的に解決するためのアルゴリズムを思い付くか、取得できるかどうかに関連しています。
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 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を呼び出し、ユーザーBのホワイトまたはブラックリストにはありません。ユーザーAは、インタラクティブな音声応答（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]。このフレームワークにより、クライアントデバイスはネットワーク内のアプリケーションと対話することができます。この場合、このような相互作用は、キーパッド（キーパッドマークアップ言語[15]でサポートされている）を含む刺激シグナリングで行われますが、Webブラウザー、音声認識なども含まれます。このフレームワークにより、アプリケーションはデバイス（またはユーザーが障害者の場合）のメディア機能を決定し、適切にやり取りできます。
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.
音声の場合、チューリングテストを発信者の言語で実行する必要があります。これは、Accect-Languageヘッダーフィールドを使用してSIPで可能ですが、これは現時点では広く使用されておらず、メディアストリームではなく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.
音声チューリングテストの主な問題は、電子メールテストと同じです。テストをオートマトンに処理する代わりに、スパマーはテストを受けるために安い労働者に支払うことができます。貧しい国での安価な労働が1時間あたり約60セントで得られると仮定して、30秒の期間のチューリングテストを想定すると、これはテストあたり約0.50セント、したがってメッセージあたり0.50セントで、IMスパムを送信します。労働率の低下はこれをさらに減らすでしょう。ここで引用されている数字は、このタイプの実際の作業のために作られた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.
これらの制限により、チューリングテストは問題を完全に解決することは決してないかもしれません。
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速度は約50 MHzですが、ハイエンドPCは5 GHzに近づきます。これは、ほぼ2桁の違いを表しています。したがって、テストが携帯電話が実行されるのが妥当であるように設計されている場合、ハイエンドマシンでスパマーを実行する方が2桁安くなります。最近の研究では、CPUのみとは対照的に、CPU/メモリ帯域幅に挑戦する計算パズルの定義に焦点を当てています[26]。デバイス間の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に使用できる可能性があります。
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 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.
このアプローチは電子メール[27]のために提案されています。ユーザーAがユーザーBにメールを送信すると、ユーザーAはユーザーBのアカウントに少量のお金（たとえば1ドル）を入金します。ユーザーBがメッセージがスパムではないと判断した場合、ユーザーBはこのお金をユーザーAに返します。メッセージがスパムの場合、ユーザーBはお金を維持します。この手法では、AからBからBからBへの転送とAへの転送を完了するために2つのトランザクションが必要です。いくつかのメッセージで「保留中の支払い」の再利用を避けるために、メッセージを受信する前に最初の転送を行う必要があります。ソリューションのユーティリティを排除します。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.
この手法は、スパムとイムスパムを呼び出すのと同じように、スパムに電子メールを送信するのと同じように表示されます。他の多くのテクニックと同様に、この交換はあなたが人々と初めて話すときにのみ起こります。したがって、その適切な操作には、適切に認証されたアイデンティティインフラストラクチャが必要です。
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.
この手法には、あらゆる種類のスパムを送信するために任意に高価にする可能性があります。ただし、インターネット上の安価なマイクロペイメントテクニックに依存しています。インターネットの支払いの従来のコストは、トランザクションあたり約25セントであり、おそらく法外なものです。ただし、最近のプロバイダーは、1セントほどの小規模取引に対してトランザクションの15％を請求する意思があります。このコストは、システムのユーザーが担当する必要があります。ユーザーごとに担当する必要があるコストは、受信された未知の送信者（つまり、白いリストに載っていない送信者）からのメッセージの数に等しくなります。忙しいユーザーの場合、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.
マイクロペイメントインフラストラクチャが存在すると仮定すると、リスクの支払いのもう1つの問題は、送信者と受信者の間で通貨の価値に強い不平等がある場合に有効性を失うことです。たとえば、第三世界の国の貧しい人は、スパムであるかどうかに関係なく、各メールメッセージにお金を維持するかもしれません。同様に、貧しい人は、受取人がそれを維持するのではないかと恐れて、たとえ合法であっても、電子メールにお金を含めることをいとわないかもしれません。これらの問題に対処するために金額を下げた場合、スパマーがそれを使う余裕があるほど十分に小さくなる可能性があります。
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.
この解決策では、国々はスパムを禁止する法律を通過します。これらの法律は、電子メールスパムに適用できるのと同じくらい簡単にスパムを呼び出すことができます。これらの法律がスパムを防ぐのに本当に効果的であるかどうかについては、多くの議論があります。
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 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>ヘッダーに資料を挿入して、適切なライセンスなしでスパマーによって挿入された場合、スパマーは米国の著作権法と商標法、おそらく相互の法律に違反すると言われています。、および多くの国で同様の法律。
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.
このモデルでは、ドメインのグループ（たとえば、企業のセット）がすべて集まります。彼らはお互いの間で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からメッセージが受信されることを知ることができます。これは、相互に認証された輸送レベルセキュリティ（TLS）[22]の使用によって容易に提供されます。SIPアイデンティティ[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?
この種の手法は、小さなドメインまたは小さなプロバイダーのセットに適しています。これらのポリシーは簡単に実施できます。しかし、それがどれだけうまくいくかは不明です。非常に大きなドメインは、ユーザーのスパムを本当に妨げる可能性がありますか？どの時点で、ネットワークはスパムを送信して罰金を支払う価値があるほど十分に大きくなりますか？小規模および大規模なドメインの両方が参加できるように、価格設定はどのように構成されますか？
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 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.
この手法は、セクション3.12で説明されている信頼のサークルのバリエーションです。少数のプロバイダーが「ドメイン間SIPプロバイダー」として確立されます。これらのプロバイダーは、PSTNの交換間キャリアと同等のSIPとして機能します。すべてのエンタープライズ、コンシューマーSIPプロバイダー、またはその他のSIPネットワーク（これらをローカルSIPプロバイダーと呼ぶ）は、これらのドメイン間プロバイダーの1つに接続します。地元の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メッセージを交換し、互いに双方管協定を結成します。これらの契約では、各ドメイン間プロバイダーが、自分の顧客に最低出見あたりの料金を請求する責任を負う必要があります。これを検証するために、広範な監査手順を導入できます。そのような契約に加えて、ドメイン間プロバイダー間に資金の流れがある場合とそうでない場合があります。
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には比較的少ないスパムがあるため（電子メールと比較して！）、この種の配置が機能するという証拠があります。ただし、これらは、プロトコルが排除することを目的としている複雑さと独占的構造の多くをすすり返すため、これらが意図的に避けられているため、集中化されたアーキテクチャが避けられます。
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.
それ自体が反スパムの形式ではありませんが、認証または検証可能なアイデンティティは、他のアンチスパムメカニズムを機能する重要な部分です。上記の手法の多くは、白または黒のリストと組み合わせると最も効果的です。それ自体には、強力な形式のアイデンティティが必要です。
In email, two types of authenticated identity have been developed - sender checks and signature-based solutions.
電子メールでは、2種類の認証されたアイデンティティが開発されました - 送信者チェックと署名ベースのソリューション。
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]の有効なメッセージ転送エージェント（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つのドメインのみがあります。これは、発信者が存在する場所と受信ドメインです。これらの手法については、RFC 3261 [2]のセクション26.3.2.2で説明しています。転送状況では、仮定はもはや保持されず、これらの手法は機能しなくなりました。ただし、セクション5で説明されているSIPの認証されたアイデンティティメカニズムは、より複雑なネットワーク構成で機能し、アイデンティティのかなり強力な主張を提供します。
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.
ドメインキーは、メール（DKIM）の署名[23]（およびそれに先行するいくつかの非標準技術）を識別しました。送信ドメインに電子メールに署名できるようにし、受信MTAまたはメールユーザーエージェント（受信メカニズム）を提供することにより、強力なIDアサーションを提供します。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]。
Other signature-based approaches for email include S/MIME[24] and OpenPGP[25].
電子メールのその他の署名ベースのアプローチには、S/MIME [24]およびOpenPGP [25]が含まれます。
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 ID [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は、Core SIP仕様の一部としてHTTP Digest認証を提供し、すべてのクライアントとサーバーをサポートする必要があります。実際、DigestはSIP用に広く展開されています。ただし、Digestのみに既知の脆弱性、特にオフラインの辞書攻撃があります。これらの脆弱性はすべて、各クライアントにサーバーへの永続的なTLS接続を維持させることにより解決されます。クライアントは、TLSを使用してサーバーのIDを検証し、TLSを介したDigest Exchangeを使用してサーバーに認証します。RFC 3261にも文書化されているこの手法は、非常に安全ですが、まだ広く展開されていません。長期的には、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].
ドメインがユーザーのIDを認証すると、そのユーザーから別のドメインにメッセージを中継すると、送信ドメインは送信者のIDを主張し、そのアサーションを検証するための署名を含めることができます。これは、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-Asserted-Identityヘッダーフィールド[5]を使用して、より弱い形式のアイデンティティアサーションが可能ですが、この手法にはすべてのドメインの間で相互信頼が必要です。残念ながら、相互接続されたドメインの数が増加するにつれて、これは指数関数的に提供するのが難しくなります。それが起こると、アイデンティティアサーションの価値は、最も信頼できるドメインの信頼性と等しくなります。スパムは受信ドメインが送信ドメインを信頼して送信スパムを送信するためにホストを許可できないという結果であるため、SPAMを導入する相互接続性のまったく同じレベルの相互接続性でP-Asserted-Identity技術は効果がなくなります。
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 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.
この事実を説明するために、次の例を考えてください。悪意のあるドメイン - それらをspam.example.comと呼びましょう。誤ったp asserted-Identityを使用してSIP招待状リクエストを送信し、独自のドメイン外のユーザーを示します。spam.example.comは、スパムのサイズと無関心のために、検証なしで顧客からのP容認されたアイデンティティを受け入れる小さな国で、地域のSIPプロバイダーを見つけます。このプロバイダーは、より大きい相互接続プロバイダーに接続します。彼らは、各顧客にP asserted-Identityを確認するように依頼しますが、それを実施する簡単な方法はありません。このプロバイダーは、他のすべての人に接続します。結果として、spam.example.comドメインは、スプーフィングされた発信者IDを使用して通話を注入できます。このリクエストは、ネットワークを介して到達可能な受信者に送信できます（おそらく、ルートプロバイダーのサイズが大きいため）。受信者が、この特定のp-asserted-Identityがこの悪いspam.example.comドメインから来たことを知る方法はありません。例に示されているように、中央プロバイダーのポリシーは良好ですが、P-Asserted-Identityの全体的な有効性は、チェーン内の最も弱いリンクのポリシーと同じくらい良いだけです。
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の使用を定義します。この手法は、あるドメインが別のドメインの有効な代表者であるサーバーと話していることを安全に判断する方法を提供します。
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メッセージ間ドメインの送信者を認証する能力に依存しています。同意、評判システム、計算パズル、およびリスクのある支払いなど、とりわけ、新しいリクエストのみに適用される場合はすべて最適に機能し、導入が正常に完了し、ユーザーがホワイトリストに配置されます。ただし、白いリストの使用は強力なアイデンティティの主張に依存します。その結果、他の人と相互接続するネットワークは、RFC 4474で説明されているように強力な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つ以上のメカニズムを利用する必要があります。
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.
実際、複数の使用を使用して、何らかの重量を使用して結果を組み合わせることができます。導入メカニズムを正常に完了するユーザーは、白いリストに自動的に追加できます。もちろん、それはSIPアイデンティティによってアイデンティティが検証された場合にのみ有用に行うことができます。このドキュメントで説明されているように、導入問題を解決するための一連のメカニズムは、執筆時に既知および使用されている手法の一部（すべてではありませんが）に基づいています。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することを許可するとすぐに、そのプロバイダーはスパムへの対処方法を検討する必要があります。
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要求の受信者が、リクエストにそのようなアイデンティティが欠けているかどうかを知ることができないことです。削除しました。その結果、遷移メカニズムを導入して、これらを区別できるようにする必要があります。それがなければ、アイデンティティメカニズムの値は大幅に減少します。
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のスパムに関連する問題に完全に専念しており、その目標をサポートするさまざまなセキュリティメカニズムを参照しています。
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に関する情報を提供してくれたRohan Mahy、VoIP終了サービスの費用を提供してくれたBaruch Sterman、Gonzalo CamarilloとVijay Gurbaniのレビューに感謝したいと思います。有用なコメントとフィードバックは、Nils Ohlmeir、Tony Finch、Randy Gellens、Lisa Dusseault、Sam Hartman、Chris Newman、Tim Polk、Donald Eastlake、Yakov Shafranovichによって提供されました。ジョン・ピーターソンは、このドキュメントにテキストの一部を書き、それが動いたときにこの作業に貢献しました。
[1] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[1] Campbell、B.、Mahy、R。、およびC. Jennings、「メッセージセッションリレープロトコル（MSRP）」、RFC 4975、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、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] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[6] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[7] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[7] Rosenberg、J。、「セッション開始プロトコル（SIP）のウォッチャー情報イベントテンプレートパッケージ」、RFC 3857、2004年8月。
[8] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[8] Rosenberg、J。、「ウォッチャー情報用の拡張可能なマークアップ言語（XML）ベースの形式」、RFC 3858、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。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[10] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[10] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[11] Rosenberg, J., "Presence Authorization Rules", RFC 5025, October 2007.
[11] Rosenberg、J。、「プレゼンス認証ルール」、RFC 5025、2007年10月。
[12] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", Work in Progress, October 2007.
[12] Rosenberg、J。、「セッション開始プロトコル（SIP）における同意ベースのコミュニケーションのフレームワーク」、2007年10月の作業。
[13] Camarillo, G., "A Document Format for Requesting Consent", Work in Progress, October 2007.
[13] Camarillo、G。、「同意を要求するためのドキュメント形式」、2007年10月、進行中の作業。
[14] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
[14] Rosenberg、J。、「セッション開始プロトコル（SIP）におけるアプリケーションインタラクションのフレームワーク」、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] Burger、E。and M. Dolly、「キープレス刺激用のセッション開始プロトコル（SIP）イベントパッケージ（KPML）」、RFC 4730、2006年11月。
[16] Rosenberg, J., "Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)", Work in Progress, June 2007.
[16] Rosenberg、J。、「セッション開始プロトコル（SIP）ユーザーエージェント（UA）への緩いルーティングの適用」、2007年6月、進行中の作業。
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[17] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、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] Allman、E。およびH. Katz、「電子メールメッセージの責任ある提出者を示すためのSMTPサービス拡張」、RFC 4405、2006年4月。
[19] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[19] Lyon、J。およびM. Wong、「送信者ID：認証電子メール」、RFC 4406、2006年4月。
[20] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[20] Lyon、J。、「電子メールメッセージの責任ある住所」、RFC 4407、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] Wong、M。およびW. Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）」、RFC 4408、2006年4月。
[22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[22] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[23] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[23] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J。、およびM. Thomas、「Domainkeys Idefied Mail（DKIM）署名」、RFC 4871、2007年5月。
[24] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[24] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[25] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[25] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「OpenPGPのMIMEセキュリティ」、RFC 3156、2001年8月。
[26] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately Hard, Memory Bound Functions, NDSS 2003", February 2003.
[26] Abadi、M.、Burrows、M.、Manasse、M.、およびT. Wobber、「適度に硬いメモリバウンド関数、NDSS 2003」、2003年2月。
[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.、Burrows、M.、Birrell、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] Clayton、R。およびB. Laurie、「仕事の証明は、経済学と情報セキュリティに関する第3回年次ワークショップではないことを証明しています」、2004年5月。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコエジソン、ニュージャージー州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Cullen Jennings Cisco 170 West Tasman Dr. San Jose, CA 95134 US
Cullen Jennings Cisco 170 West Tasman Dr. San Jose、CA 95134 US
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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への情報をお問い合わせください。