Network Working Group J. Rosenberg
Request for Comments: 5039 C. Jennings
Category: Informational Cisco
January 2008
The Session Initiation Protocol (SIP) and Spam
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to-user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.
スパムは、大量の迷惑メッセージの送信として定義され、インターネットの電子メールを悩ませてきました。残念ながら、スパムメールに限定されるものではありません。これは、ユーザー間のコミュニケーションを可能にする任意のシステムに影響を与えることができます。セッション開始プロトコル（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.
スパムは、大量の迷惑メールの送信として定義され、インターネットの電子メールシステム上のペストとなっています。多くのソリューションは、文書化され、問題に対処するために配備されています。これらのソリューションはいずれも理想的ではありません。しかし、一つのことは明確である：問題が広範囲になる前に解決策が普遍的に配備されていたスパム問題はそれほど重要になります。
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]、または通信セッションの他のタイプを確立しようと、セッション開始の試行（即ち、INVITE要求）のバルク迷惑集合として定義されます。ユーザーが答える必要がある場合は、スパマーは、リアルタイムメディア上で自分のメッセージを中継するように進みます。これは、SIPに適用される古典的なテレマーケティングスパム、です。これは、多くの場合、IPテレフォニー、またはSPITを超えるスパムと呼ばれています。
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]要求を使用して送信されます。しかし、コンテンツは自動的にユーザーのディスプレイに表示されるようになり、他の要求にも十分です。それは大きな件名ヘッダを持つINVITE要求を含めることができます（件名は時々、ユーザーにレンダリングされるので）、またはテキストまたはHTML機関とのINVITE要求。これは、多くの場合、インスタントメッセージング、または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] SUBSCRIBE要求）プレゼンス要求のバルク迷惑セットとして定義されそれらをIM送信または通信の他の形態を開始します。これは、時折プレゼンスプロトコル、または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メッセージがあります。しかし、他のもののほとんどは、ユーザーに配信されるコンテンツにはなりません、また彼らは、ユーザからの入力を求めます。むしろ、彼らはオートマトンによって回答されています。 OPTIONSはこの良い例です。それはユーザエージェントサーバ（UAS）によって自動的に応答しているのでOPTIONS要求を送信におけるスパマーのために少し値は、あります。いかなるコンテンツがユーザーに配信されていない、と彼らは参照されません。
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.
コールあたりのコストも大幅に低減されます。通常の住宅の電話回線は一つだけコールが一度に配置することができます。追加の行が必要な場合、ユーザーは、より高価な接続を購入する必要があります。典型的には、T1またはT3は、大容量のテレマーケティングサービスのために必要とされるであろう。アクセスのようなものは非常に高価でも平均的なユーザーの手の届かないところです。 T1回線は約米国月額$ 250との通話のために毎分約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回の同時コール、および各コール試行、毎秒約2.4コールの試行のために約10秒を仮定します。大量の通話では、毎分率がはるかにT1のための月額料金を超えています。その結果、コンテンツの10秒を想定し、各成功したスパム配信のための25万microcentsのコストです。
With SIP, this cost is much reduced. Consider a spammer using a typical broadband Internet connection that provides 500 Kbps of upstream bandwidth. Initiating a call requires just a single INVITE message. Assuming, for simplicity's sake, that this is 1 KB, a 500 Kbps upstream DSL or cable modem connection will allow about 62 call attempts per second. A successful call requires enough bandwidth to transmit a message to the receiver. Assuming a low compression codec (say, G.723.1 at 5.3 Kbps), this requires approximately 16 Kbps after RTP, UDP, and IP overheads. With 500 Kbps upstream bandwidth, this means as many as 31 simultaneous calls can be in progress. With 10 seconds of content per call, that allows for 3.1 successful call attempts per second. If broadband access is around $50/month, the cost per successful voice spam is about 6.22 microcents each. This assumes that calls can be made 24 hours a day, 30 days a month, which may or may not be the case.
SIPでは、このコストが大幅に削減されます。アップストリーム帯域幅の500 Kbpsのを提供する典型的なブロードバンドインターネット接続を使用して、スパマーを考えます。通話を開始すると、単に1つのINVITEメッセージが必要です。これは1キロバイト、500 Kbpsの上流DSLやケーブルモデム接続は毎秒約62コールの試行を許可することで、簡単のため、と仮定。成功したコールは、受信機にメッセージを送信するために十分な帯域幅が必要です。低圧縮コーデック（たとえば、5.3 kbpsでG.723.1）を仮定すると、これはRTP、UDP、およびIPのオーバーヘッド後の約16 Kbpsのが必要です。 500 Kbpsのアップストリーム帯域幅を使用すると、これは、多くの31として同時コールが進行中であることを意味することができます。コールあたりのコンテンツの10秒で、それは毎秒3.1成功したコールの試行が可能になります。ブロードバンドアクセスは約$ 50 /月の場合は、成功した音声スパムあたりのコストを約6.22 microcentsそれぞれです。これは、呼び出しが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.
でもゾンビの問題を無視して、コストのこの減少は、さらに多くの国際通話のために増幅されます。現在は、主に国際電話をかけるの大きなコストに国境を越えて、いくつかのセールス電話は、あります。有効であった - これは、「呼び出すことはありませんリスト」、勧誘電話を呼び出すことはできません数字の米国国家のリストが理由の一つです。法律は唯一の米国企業に影響を与えますが、ほとんどのセールス電話は、国内なので、それが有効でした。残念ながら（と幸い）、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、ディスク、または終了コストであることを前提としています。解約コストはさらなる議論に値します。公衆交換電話網（PSTN）、およびこの終了は、コールお金の発信元をコストに現在、ほとんどのボイスオーバーIP（VoIP）の呼び出しが終了します。これらの費用は、T1のあたりの分率に類似しています。これは、ボリュームや他の要因に応じて、毎分3セントにどこでも半分セントの範囲です。しかし、設備コスト、トレーニング、およびその他の要因は、回路の接続よりもコストは依然として低くなって、T1よりもSIPベースの終了のためのはるかに低いです。さらに、VoIPシステムにおける現在の傾向はつまり、実際のSIPエンドポイントに呼び出して、PSTNには絶対に触れない通話の終了を無料にすることです。より多くの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は毎秒約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.
スパムのコストの別の部分は、アドレスを収集しています。スパマーは、時間をかけて、スパム指向する電子メールアドレス、user @ domain形式のそれぞれの巨大なリストを、築いてきました。 SIPは、それはおそらく電子メールアドレスを簡単に有効なSIPアドレスに変換することができますことを作り、対処するのと同じ形式を使用しています。電話番号は、有効なSIPアドレスを表します。終了プロバイダと協調して、SIPを指示することができますスパマーは、従来のPSTNデバイスで呼び出します。彼らは彼らのウェブスイープを行うと、電子メールスパマーはまた、電話番号を収集してきたかどうかは明らかではないが、そうするだろう難しいことではありません。さらに、電子メールアドレスとは異なり、電話番号はかなり密に充填された有限のアドレス空間と一つです。その結果、電話番号を順番に行くのはかなり高いヒット率を生成する可能性があります。このように、スパマーは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スパムは、スパムを展開して生成するためのコストの面で、非常に多くの電子メールのようなものです。仮定すると、引数のために、1キロバイトメッセージが送信されると、アップストリーム帯域幅の500 Kbpsのは、それは、毎秒62.5メッセージです。 $ 50 /月で、その結果は、メッセージごとに0.31 microcentsです。これは、音声スパム未満が、実質的に少ないではありません。コストは、電子メールスパムに匹敵すると考えられます。しかし、IMは、はるかに侵入電子メールを超えています。今日のシステムでは、IMSが自動的にポップアップし、利用者に自分自身を提示します。メールは、当然のことながら、意図的に選択して表示する必要があります。しかし、最も人気のIMシステムは、送信者がホワイトリスト上にある場合のみ、IMが配信されるように可能にする、ホワイトリストを採用しています。このように、IMスパムが有用であろうかどうかは、ネットワークが開かれるようシステムの性質に多くを依存しているようです。彼らは普遍的にホワイトリストへのアクセスに配備されている場合は、IMスパムの値が低くなる可能性があります。
It is important to point out that there are two different types of IM systems: page mode and session mode. Page mode IM systems work much like email, with each IM being sent as a separate message. In session mode IM, there is signaling in advance of communication to establish a session, and then IMs are exchanged, perhaps point-to-point, as part of the session. The modality impacts the types of spam techniques that can be applied. Techniques for email can be applied identically to page mode IM, but session mode IM is more like telephony, and many techniques (such as content filtering) are harder to apply.
ページモードとセッションモード：IMシステムの二種類があることを指摘することは重要です。ページモードのIMシステムは、各IMが別々のメッセージとして送信されると、多くの電子メールのように動作します。セッションモードIMでは、セッションを確立するために、通信に先立って存在シグナリングされ、その後のIMセッションの一部として、おそらく、ポイント・ツー・ポイントを交換しています。モダリティの影響を適用することができますスパム技術の種類。電子メールのための技術は、ページモードの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.
上記で定義したように、プレゼンススパムが大量の迷惑SUBSCRIBEメッセージの生成です。同じコストの見積もりは、ここで使用することができますので、このコストは、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などのアイデンティティからの要求SUBSCRIBE生成することにより：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つの理由があります。まず、ユーザがコールに応答する場合には、コールがすでに確立されていると、コンテンツが配信される前に、ユーザーは注意を払っています。ユーザーがそれを見る前にスパムを分析することはできません。ユーザがそれにアクセスする前に、コンテンツ（例えば、ボイスメールで）格納されている場合に、第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.
ブラックリストは、スパムフィルタは、スパム送信者を特定するアドレスのリストを管理することによりアプローチです。これらのアドレスは、ユーザ名（spammer@example.com）全体ドメイン（example.com）の両方を含みます。ピュアブラックリストは、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.
ホワイトリストは、ブラックリストの逆です。これは、ユーザーからのメールを受け入れて喜んで有効な送信者のリストです。ブラックリストとは異なり、スパマーは、ホワイトリストを回避するためのIDを変更することはできません。ホワイトリストは、なりすましに対処するために影響を受けやすいが、強力なアイデンティティ認証メカニズムは、その問題を防ぐことができます。 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.
彼らはこれまで明示的にホワイトリストに入れていなかった誰かからのメールを受信することができることからユーザーを禁止するので、しかし、彼らは、完全なソリューションではありません。その結果、ホワイトリストは、「導入の問題」の解決策を必要と - 初めて誰かに会うと、彼らはホワイトリストに置かれるべきかどうかを決定する方法。導入の問題に加えて、ホワイトリストは、管理するために、ユーザからの時間を必要としています。
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の白または黒のリストに載っていない、ユーザー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システムのほとんどは、単一の管理ドメイン内の通信のみを許可しているので、送信者の身元を認証することができます。メールは、多くの場合、メーリングリストのための同様の同意ベースのシステムを使用しています。彼らは、ユーザーがそのアドレスでメールを受信できることを確認したメールアドレスにクッキーを送信するに基づく認証の形式を使用します。
This kind of consent-based communications has been standardized in SIP for presence, using the watcher information event package [7] and data format [8], which allow a user to find out that someone has subscribed. Then, the XML Configuration Access Protocol (XCAP) [10] is used, along with the XML format for presence authorization [11] to provide permission for the user to communicate.
ユーザは、誰かが加入していることを見つけることができ、この同意ベースの通信の種類ウォッチャ情報イベントパッケージを使用して、存在についてSIPに標準化されている[7]、データフォーマット[8]。次に、XMLコンフィギュレーションアクセスプロトコル（XCAP）[10]通信する権限をユーザに提供するために、[11]プレゼンス認可用のXMLフォーマットと共に使用されます。
A consent framework has also been developed that is applicable to other forms of SIP communications [12]. However, this framework focuses on authorizing the addition of users to "mailing lists", known as exploders in SIP terminology. Though spammers typically use such exploder functions, presumably one run by a spammer would not use this technique. Consequently, this consent framework is not directly applicable to the spam problem. It is, however, useful as a tool for managing a white list. Through the PUBLISH mechanism, it allows a user to upload a permission document [13] that indicates that they will only accept incoming calls from a particular sender.
同意フレームワークはまた、SIP通信[12]の他の形態に適用可能であることが開発されています。しかし、このフレームワークは、SIP用語で発破として知られているユーザーには、「メーリングリスト」の追加を許可に焦点を当てています。スパマーは通常、エクスプローダ機能を使用していますが、おそらくスパマーずつ実行は、この技術を使用することはありません。したがって、この同意フレームワークは、スパム問題に直接適用することはできません。それは、しかし、ホワイトリストを管理するためのツールとして有用です。 PUBLISH機構を介して、ユーザは、彼らが唯一の特定の送信者からの着信を受け入れることを示し許可書[13]をアップロードすることができます。
Can a consent framework, like the ones used for presence, help solve call spam? At first glance, it would seem to help a lot. However, it might just change the nature of the spam. Instead of being bothered with content, in the form of call spam or IM spam, users are bothered with consent requests. A user's "communications inbox" might instead be filled with requests for communications from a multiplicity of users. Those requests for communications don't convey much useful content to the user, but they can convey some. At the very least, they will convey the identity of the requester. The user part of the SIP URI allows for limited free form text, and thus could be used to convey brief messages. One can imagine receiving consent requests with identities like "sip:please-buy-my-product-at-this-website@spam.example.com", for example. Fortunately, it is possible to apply traditional content filtering systems to the header fields in the SIP messages, thus reducing these kinds of consent request attacks.
同意フレームワークは、存在のために使用されるもののように、コール・スパムの解決に役立つことはできますか？一見すると、多くのことを助けるように思われます。しかし、それだけでスパムの性質を変更する場合があります。代わりに、コールスパムやIMスパムの形で、コンテンツに煩わされるのは、ユーザーが同意要求に悩まされています。ユーザの「通信の受信トレイ」が代わりにユーザーの多様からの通信の要求を満たしている可能性があります。通信のためのこれらの要求は、ユーザーに多くの有用な内容を伝えていないが、彼らはいくつかを伝えることができます。少なくとも、彼らが依頼者の身元を伝えます。 SIP URIのユーザ部分は、限られた自由形式のテキストを可能にし、したがって、簡単なメッセージを伝えるために使用することができます。例えば、：一つは「please-buy-my-product-at-this-website@spam.example.com一口」のようなアイデンティティと同意のリクエストを受けて想像することができます。幸いなことに、このように同意要求攻撃のこれらの種類を減らし、SIPメッセージのヘッダーフィールドに、伝統的なコンテンツ・フィルタリング・システムを適用することが可能です。
In order for the spammer to convey more extensive content to the user, the user must explicitly accept the request, and only then can the spammer convey the full content. This is unlike email spam, where, even though much spam is automatically deleted, some percentage of the content does get through, and is seen by users, without their explicit consent that they want to see it. Thus, if consent is required first, the value in sending spam is reduced, and perhaps it will cease for those spam cases where consent is not given to spammers.
スパマーがユーザーへのより広範な内容を伝えるようにするためには、ユーザーが明示的に要求を受け入れなければならない、とだけにしてスパマーは、完全な内容を伝えることができます。これは非常に迷惑メールが自動的に削除されていても、コンテンツのいくつかの割合が通り抜けるんし、ユーザーによって見られている、彼らはそれを見たいと思って自分の明示的な同意なしに、スパムメールとは異なります。同意が最初に必要とされる場合にこのように、スパムを送信における値が減少し、おそらくそれは、同意がスパマーに与えられていないものをスパム例のために中止されます。
As such, the real question is whether or not the consent system would make it possible for a user to give consent to non-spammers and reject spammers. Authenticated identity can help. A user in an enterprise would know to give consent to senders in other enterprises in the same industry, for example. However, in the consumer space, if sip:bob@example.com tries to communicate with a user, how does that user determine whether Bob is a spammer or a long-lost friend from high school? There is no way based on the identity alone. In such a case, a useful technique is to grant permission for Bob to communicate but to ensure that the permission is extremely limited.
そのため、本当の問題は同意システムは、それが可能なユーザーが非スパマーに同意を与え、スパマーを拒否するためになるだろうかどうかです。認証されたアイデンティティは助けることができます。企業内のユーザは、例えば、同じ業界の他の企業での送信者に同意を与えることを知っているだろう。しかし、一口消費者空間で、場合：bob@example.comは、ユーザーと通信しようと、どのようにそのユーザは、ボブがスパマーや高校からの長い間行方不明の友人であるかどうかを判断するのでしょうか？単独のアイデンティティに基づく方法はありません。このような場合に、有用な技術は、ボブが通信するための許可を付与するが、許可が極めて限られていることを保証することです。
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のユーザ部分でそれを伝える可能性があると同じように自分のメッセージを伝えるためにためしかし、テキストのこの200本の言葉は十分かもしれません。
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サイトが評判の非常によく似たコンセプトを採用しても）メッセージングで最も広く普及しているレピュテーションシステム今日は、モノリシックインスタント・メッセージング・プロバイダーによって展開されています。評判は、ユーザーからのフィードバックに基づいて計算されます。例えば、メッセージングクライアントのユーザーインターフェース上のボタンは、特定のユーザが虐待であるシステムに通知するために、ユーザーに権限を与えるかもしれません。もちろん、任意の単一のユーザーの入力が1の評判を台無しにするには不十分である必要がありますが、一貫性の負のフィードバックは、虐待的なユーザーに負のレピュテーションスコアを与えるだろう。
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.
レピュテーションシステムは資源の集中（ユーザーID、認証など）と、モノリシック制御が支配システムで成功しています。これらの例は、他の管理ドメインとメッセージを交換していないIMシステムを実行する大規模なインスタント・メッセージング・プロバイダーが含まれます。 （すべてのユーザが共通のプロバイダを信頼するので、共通のプロバイダは、認証と同一のアービタである）まずその制御は、ユーザのために比較的強い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.
負の評判を持っていることの効果的な結果は、あなたがブラックリストに載っているということであるので、負のレピュテーションスコアに基づいてレピュテーションシステムは、ブラックリストと同じ問題の多くに苦しみます。アイデンティティが取得するのは非常に簡単であれば、負の評判を持つユーザーは、単純に新しいアイデンティティを取得します。悪用される可能性がプロセス - また、負の評判は警告]ボタンをクリックして、十分に悩まされるようにユーザーが必要とする、tattlingによって生成されます。いくつかのレピュテーションシステムでは、多数のユーザーから成る「評判のマフィアは」日常の犠牲者に否定的な評判を与えることを総称して脅しによって、被害者をいじめたり強要します。
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.
ユーザーが良好ではなく、悪いことのためにお互いにtattlingお互いを賞賛ポジティブな評判に基づいて、評判システムは、いくつかの同様の欠点を持っています。スパマーの集団、または多数のIDを取得し、ちょうど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.
ユーザーのマシンが妥協してゾンビになっている場合は、これはSPAMが送信されると、否定的な方法で自分の評判に影響を与える可能性があることができます。彼らの評判が低下したら、それはポジティブな評判を再確立することは非常に困難になります。
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サイトや情報の他の公共の情報源からの電子メールアドレスを収集することによって、そのスパムリストを構築します。スパムを最小限にする一つの方法は、収集するあなたのアドレスが困難または不可能にすることです。スパムボットは、通常はフォーム「ユーザー@ドメイン」のページ内のテキストを探し、そのフォームの何かが電子メールアドレスであることを前提としています。こうしたスパムボットから非表示にするには、多くのWebサイトでは、最近のメールアドレスとして読み込むためのオートマトンのために、ヒトに使用できるが、困難な難読化形式で電子メールアドレスを置く始めています。例としては、 "COMドット例において、ユーザ" または "J d個のR O S E N T EはE、D、O、T、C、O M MのP Lを×"。ような形態を含みます
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] ENUMは、スパマーのための潜在的な金鉱として引用されています。これは、スパマーが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.
難読化に対処するための関連技術が限定使用アドレスです。この技術では、ユーザーは、その適用上の制約があり、それぞれが、彼らの処分で多数のメールアドレスを持っています。それは一定期間後に期限切れになるように、限定使用アドレスは、時間が結合することができます。または、別のメールアドレスには、各対応に与えることができます。スパムはその通信員から到着すると、彼らは与えられた限定使用アドレスが終了されます。別の変形例では、同一の限定使用アドレスは、いくつかのプロパティを共有する複数のユーザに与えられます。例えば、すべての職場の同僚、さまざまな企業からのすべての同僚、すべての小売業者など。スパムアドレスのいずれかに到着し始める必要があり、それは、限定使用のアドレスを受け取った他の誰からの通信を防止すること、無効化されます。
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.
代わりに、お友達にメールアドレスを配って、あなたはあなたの存在URIを配るでしょう。友人はあなたに電子メールを送信したい場合には、彼らはあなたの存在を購読する（実際、彼らは継続的にバディリストアプリケーションから加入する可能性があります）。プレゼンスデータは、あなたが到達することができる電子メールアドレスを含めることができます。このメールアドレスは難読化と、一回の使用のあなたの存在を要求し、各バディごとに異なることができます。これらの変更は、あなたの仲間に直接プッシュされて彼らはまた、常に、変更することができます。ある意味では、バディリストが自動的に更新されたアドレス帳を表し、したがって、問題を排除します。
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.
電子メールでは、チューリングテストは、メッセージの送信者が人間だけが（チューリングテストは、ビデオやオーディオのパズルに依存していることから、彼らは時々、ハンディキャップを持つ個人では解決することはできません）回答できるパズルや課題のいくつかの種類を、与えられていることにより、メカニズムがあります。これらのテストは、CAPTCHAの（別にコンピュータと人間を伝えるために完全に自動化された公開チューリングテスト）として知られています。パズルに正しく答えている場合は、送信者は、ユーザーのホワイトリストに入れています。これらのパズルは、頻繁にバックグラウンドノイズの多い画像に数字の単語または配列を認識する形をとります。テストは簡単に単語や数字列を抽出するために必要な画像認識を行うことができないようにオートマトンを設計する必要はなく、人間のユーザは通常できます。画像処理や人工知能での継続的な進歩が継続的にバーを上げるため、このようなテストを設計することは、容易ではありません。その結果、CAPTCHAのの有効性は、スパマーが思い付くか、自動的にそれらを解決するためのアルゴリズムを得ることができるかどうかに関連付けられています。
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.
音声の場合には、チューリングテストは、呼び出し元の言語で実行させることが必要となります。これは広く現時点で使用され、SIPメッセージの構成要素ではなく、メディアストリームの言語のために意図されていないが、これは、Accept-Languageヘッダーフィールドを使用して、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.
音声チューリングテストでの主な問題は、電子メールのテストが持っているものと同じである：代わりにオートマトンプロセスにテストを有していると、スパマーは、テストを取るために安価な労働者を支払うことができます。貧しい国の安い労働力を仮定すると、これはIMのスパムを送信するために、テストあたり約0.50セント、メッセージごとのように0.50セントで、時間あたり約60セントで得た、と30秒の期間のチューリングテストを仮定することができます。人件率は、これをさらに低減するであろう。ここで引用された件数は、このタイプの実際の仕事のために作られた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.
技術の問題点の一つは、合法的に通信する可能性のあるさまざまなクライアントの計算能力には大きなばらつきがあるということです。ハイエンドPCが5 GHz帯に近づく一方で、ローエンドの携帯電話上のCPUの速度は、約50 MHzです。これは、大きさの差のほぼ二桁を表します。テストが携帯電話が実行するために合理的であるように設計される場合、ハイエンドマシン上スパマーに対して実行する二桁安価です。ちょうどCPU [26]とは対照的に最近の研究では、CPU /メモリの帯域幅に挑戦計算パズルを明確にすることに集中しました。デバイス間でCPU /メモリ帯域幅が少なく、様々な大きさの約単一の注文があるようです。
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の口座にお金を少量（例えば、1ドル）、ユーザBにユーザAの預金を電子メールを送信するとき。ユーザBはメッセージがスパムでないことを決定した場合、ユーザーBの払い戻しバックユーザAへのメッセージがスパムである場合は、このお金は、ユーザBは、お金を保持します。 、AからBへの転送、およびバックAにBからの転送最初の転送は、メッセージが複数のメッセージを横切る「保留支払い」の再使用を回避するために受信される前に発生することがあります。この技術は、完了するために2つのトランザクションを必要としますその解決策の有用性を排除するであろう。もう一つは、メッセージがスパムでないと発見された場合に発生する必要があります。
This technique appears just as applicable to call spam and IM spam as it is to email spam. Like many of the other techniques, this exchange would only happen the first time you talk to people. Its proper operation therefore requires a good authenticated identity infrastructure.
この技術は、スパムメールを送信することであるとして、スパムとIMのスパムを呼び出すために同じように適用されます。他の技術の多くと同様、この交換は、あなたが人々に話を初めて起こるでしょう。その適正な動作は、したがって、優れた認証済みのIDインフラストラクチャを必要とします。
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％を充電するために喜んでされています。このコストは、システムのユーザによって背負っしなければならないであろう。ユーザごと肩する必要がコストが受信された未知の送信者からのメッセージの数（つまり、ホワイトリスト上の送信者ではない）に等しいです。忙しいユーザーのために、一日あたり約10個の新しい送信者を想定しています。デポジットは5セントであれば、トランザクションプロバイダは0.75セントを取り、4.25セントを提供します。送信者が許可されている場合、受信者は、プロバイダが0.64セントを取り、4.25セントを返し、3.6セントを返します。それは正当だった場合、これは、送信者各トランザクションに0.65セントの費用がかかります。一日あたり10の新しい受信者がある場合は、それが比較的安価である月額$ 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.
少額決済インフラが存在すると仮定すると、支払・アット・リスクを持つ別の問題は、送信者と受信者の間の通貨の価値の強い不公平がある場合、それは有効性を失うということです。例えば、第三世界の国の貧しい人は関係なく、それがスパムであるかどうかの、各メールメッセージにお金を維持することがあります。同様に、貧しい人も、正当な場合には、恐怖のために受信者がそれを維持する可能性があることを、電子メールでお金を含めることをいとわないかもしれません。お金の量は、これらの問題に対処を助けるために低下した場合は、スパマーはそれを費やす余裕ができることを十分に小さくなる場合があります。
In this solution, countries pass laws that prohibit spam. These laws could apply to IM or call spam just as easily as they could apply to email spam. There is a lot of debate about whether these laws would really be effective in preventing spam.
このソリューションでは、国は、スパムを禁止する法律を渡します。これらの法律は、IMに適用したり、同じように簡単に彼らは電子メールスパムに適用できるようにスパムを呼び出すことができます。これらの法律は実際にスパムを防止するのに有効であるかどうかについての議論がたくさんあります。
As a recent example in the US, "do not call" lists seem to be effective. However, due to the current cost of long-distance phone 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.
スパムが送信された場合は、スパム対策法以外の法律が壊れて原因方式もあります。これは、本質的にSPAMを減らすことはありませんが、それはより多くの法的な選択肢がスパマーを圧迫するためにもたらされることを可能にします。例えば、人身保護<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は、メッセージがSIPのドメイン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
この技術は、セクション3.12で説明した信頼の円のバリエーションです。プロバイダの数が少ない「ドメイン間のSIPプロバイダー」として確立します。これらのプロバイダは、SIP-同等のPSTNにおけるエクスチェンジキャリアへの役割を果たします。すべての企業、消費者
SIP provider, or other SIP network (call these the local SIP providers) connects to one of these inter-domain providers. The local SIP providers only accept SIP messages from their chosen inter-domain provider. The inter-domain provider charges the local provider, per SIP message, for the delivery of SIP messages to other local providers. The local provider can choose to pass on this cost to its own customers if it so chooses.
SIPプロバイダ、または他のSIPネットワークは、（これらのローカルSIPプロバイダを呼び出す）これらのドメイン間のプロバイダの一つに接続します。ローカルSIPプロバイダーは、自分が選んだドメイン間のプロバイダからのSIPメッセージを受け入れます。ドメイン間のプロバイダは、他のローカルプロバイダにSIPメッセージの配信のために、SIPメッセージごとに、ローカルプロバイダを充電します。ローカルプロバイダは、それがそう選択した場合、自身の顧客にこのコストに渡すように選択することができます。
The inter-domain SIP providers then form bi-lateral agreements with each other, exchanging SIP messages according to strict contracts. These contracts require that each of the inter-domain providers be responsible for charging a minimum per-message fee to their own customers. Extensive auditing procedures can be put into place to verify this. Besides such contracts, there may or may not be a flow of funds between the inter-domain providers.
ドメイン間のSIPプロバイダは次に、厳密な契約に従ってSIPメッセージを交換し、互いにバイラテラル協定を形成します。これらの契約は、ドメイン間のプロバイダのそれぞれが自分の顧客に最小限のメッセージごとの料金を課金する責任があることが必要です。豊富な監査手続は、これを確認するために所定の場所に置くことができます。当該契約のほかに、またはドメイン間プロバイダ間の資金の流れがあってもなくてもよいです。
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のための場所で、今日1とほぼ同じであり、PSTN上の比較的少ないスパムがあるので（電子メールと比べて！）、この種の構成は、働くことができるといういくつかの証拠があります。彼らは、プロトコルを排除することを目的と複雑さと独占構造の多くのSIPに戻ししかし、これらのような集中型のアーキテクチャは、意図的に避けています。
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.
電子メールでは、DNSリソースレコードは、送信者が[18] [19] [20] [21]送信元ドメインの有効なメッセージ転送エージェント（MTA）であることを確認するためのメッセージを受け取るドメインを許可するように定義されています。彼らは、自分たちで迷惑メールを防ぐことはできませんが、偽装された電子メールを防ぐのに役立つかもしれません。何度か言及したように、強力な認証されたアイデンティティの形式は、他の多くのアンチスパム技術を機能させるに重要です。
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は、ドメイン間使用することができます。メッセージを受信したプロバイダは、メッセージの送信者のアサートされたIDと一致していないドメインからの任意のメッセージを拒否することができます。発信者が存在する場所であり、送信ドメイン、受信ドメイン - そのようなポリシーは、任意の呼び出しにのみ2つのドメインが存在することにより、SIPの「台形」モデルで動作します。これらの技術は、RFC 3261のセクション26.3.2.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]（及びそれに先行いくつかの非標準的な技術）、電子メールに署名する送信ドメインを可能にし、その後のメカニズムを提供することにより、強力なIDアサーションを提供することにより、受信MTAまたはメールユーザエージェント（ MUA）が署名を検証することができます。
Unfortunately, when used with blacklists, this kind of authenticated identity is only as useful as the fraction of the emails that utilize it. This is partly true for white lists as well; if any unauthenticated email is accepted for an address on a white list, a spammer can spoof that address. However, a white list can be effective with limited deployment of DKIM if all the people on the white list are those whose domains are utilizing the mechanism, and the users on that white list aren't zombies.
ブラックリストで使用する場合残念ながら、認証されたアイデンティティのこの種のは、それを利用電子メールの一部としてのみとして有用です。これは、同様にホワイトリストのために、部分的に真です。任意の認証されていないメールがホワイトリスト上のアドレスのために受け入れられた場合、スパマーはそのアドレスを偽装することができます。ホワイトリスト上のすべての人々がそのドメインのメカニズムを利用しているものであり、そのホワイトリスト上のユーザーがゾンビでない場合は、ホワイトリストは、DKIMの限られた展開で有効であることができます。
This kind of identity mechanism is also applicable to SIP, and is in fact, exactly what is defined by SIP's authenticated identity mechanism [17].
アイデンティティメカニズムのこの種はまた、SIPに適用可能であり、およびSIPの認証されたアイデンティティメカニズム[17]によって定義されるまさに、実際にはあります。
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.
上記の解決策の多くの重要な部品の一つが確実にSIPメッセージの送信者を識別するための能力です。 SIPは、SIPアイデンティティ[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は、HTTPコアSIP仕様の一部としてダイジェスト認証を提供し、すべてのクライアントとサーバーは、それをサポートする必要があります。確かに、ダイジェストは広くSIPのために展開されています。しかし、一人でダイジェスト最も顕著な多くの既知の脆弱性、オフライン辞書攻撃を持っています。これらの脆弱性はすべて、各クライアントがサーバへの持続的なTLS接続を維持することによって解決されます。クライアントはTLSを使用して、サーバーの身元を確認した後、TLS経由ダイジェスト交換を使用してサーバーに自分自身を認証します。また、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].
ドメインは、ユーザーの身元を認証したら、それは別のドメインにそのユーザーからのメッセージを中継する際、送信ドメインは、送信者の身元を主張し、その主張を検証するための署名を含めることができます。これは、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.
IDアサーションの弱い形態[5] P-Asserted-Identityヘッダフィールドを使用可能であるが、この手法は、すべてのドメイン間の相互信頼関係を必要とします。残念ながら、これは、相互接続されたドメインの数の成長に合わせて提供するために、指数関数的に難しくなります。それが起こるように、IDアサーションの値は、少なくとも信頼できるドメインの信頼性と等しくなります。スパムが受信ドメインがスパムを送信するために送信してホストを許可しないように、送信ドメインを信頼することができないの結果であるので、P-アサート・アイデンティティ技術は、スパムを導入相互関連のまったく同じレベルで無効になります。
Consider the following example to help illustrate this fact. A malicious domain -- let us call them spam.example.com, would like to send SIP INVITE requests with false P-Asserted-Identity, indicating users outside of its own domain. spam.example.com finds a regional SIP provider in a small country who, due to its small size and disinterest in spam, accepts any P-Asserted-Identity from its customers without verification. This provider, in turn, connects to a larger, interconnect provider. They do ask each of their customers to verify P-Asserted-Identity but have no easy way of enforcing it. This provider, in turn, connects to everyone else. As a consequence, the spam.example.com domain is able to inject calls with a spoofed caller ID. This request can be directed to any recipient reachable through the network (presumably everyone due to the large size of the root provider). There is no way for a recipient to know that this particular P-Asserted-Identity came from this bad spam.example.com domain. As the example shows, even though the central provider's policy is good, the overall effectiveness of P-Asserted-Identity is still only as good as the policies of the weakest link in the chain.
この事実を説明するのを助けるために、次の例を考えてみましょう。悪質なドメイン - 独自のドメイン外のユーザーを示し、偽P-アサート-アイデンティティとのINVITE要求をSIPを送りたい、私たちはspam.example.comそれらを呼びましょう。 spam.example.comが原因スパムでその小さなサイズと無関心に、検証せずに顧客から任意のP-アサート・アイデンティティを受け入れ、小さな国の地域SIPプロバイダを見つけました。このプロバイダは、順番に、より大きな、相互接続プロバイダに接続します。彼らは、P-アサート・アイデンティティを確認するために、顧客のそれぞれを頼むんが、それを強制する簡単な方法がありません。このプロバイダは、順番に、他の皆に接続します。その結果、spam.example.comドメインは、偽装された発信者IDを持つ呼び出しを注入することができます。この要求は、ネットワークを介して到達可能な任意の受信者（ルート・プロバイダの大きなサイズに起因し、おそらく皆）に向けることができます。受信者は、この特定のP-アサート-アイデンティティは、この悪いspam.example.comドメインから来たことを知ってする方法はありません。例が示すように、中央のプロバイダの政策が良いにもかかわらず、P-アサート - アイデンティティの全体的な効果はまだチェーンの最も弱いリンクの政策と同じくらい良いです。
SIP also defines the usage of TLS between domains, using mutual authentication, as part of the base specification. This technique provides a way for one domain to securely determine that it is talking to a server that is a valid representative of another domain.
SIPはまた、基本仕様の一部として、相互認証を使用して、ドメイン間のTLSの使用を定義します。この技術はしっかりとそれは別のドメインの有効な代表であるサーバーに話していることを判断する一つのドメインのための方法を提供します。
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メッセージのドメイン間の送信者を認証する能力に依存性があります。唯一の新しい要求、およびホワイトリスト上のユーザの配置で導入結果が正常に完了に適用されたときに同意、評判システム、計算パズル、およびリスクの支払いは、とりわけ、すべてが最高の仕事します。しかし、ホワイトリストの使用方法は、強力なアイデンティティのアサーションに依存します。 P-アサート-アイデンティティが十分に強くないRFC 4474.に記載されその結果、他の人と相互接続するネットワークは、強力なSIPアイデンティティの使用をしなければなりません。
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.
はじめに問題を解決：これは、順番に行われるために、最終的な提言につながります。ネットワーク設計者は、導入の問題を解決するためのもの一の以上のメカニズムを利用する必要があります。
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.
強いアイデンティティ技術と難しさの一つは、認証されたアイデンティティのないSIPリクエストの受信機は元のドメインがそれをサポートしていなかったので、要求は、そのようなアイデンティティを欠いていたかどうかを知ることができないということである、または理由のman-in-the-middleそれを削除しました。その結果、移行メカニズムは、これらを区別することができるようにする場所に配置する必要があります。それがなければ、アイデンティティ機構の値が大幅に減少しています。
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.
作者は彼らのレビューのためのVoIP終了サービスのコストを提供するための人身保護、バルークStermanに関する情報を提供し、ゴンサロ・カマリロとビジェイGurbaniためロハンマーイに感謝したいと思います。便利なコメントやフィードバックはニルスOhlmeir、トニー・フィンチ、ランディGellens、リサDusseault、サム・ハートマン、クリス・ニューマン、ティムポーク、ドナルドイーストレイク、およびヤコフShafranovichによって提供されました。ジョンピーターソンは、この文書でテキストの一部を書き、それに沿って移動しているような作業に貢献してきました。
[1] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[1]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]キャンベル、B.、ローゼンバーグ、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]ローチ、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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[6]ローゼンバーグ、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]ローゼンバーグ、J.、RFC 3857、2004年8月 "セッション開始プロトコル（SIP）のためのウォッチャー情報イベントテンプレート・パッケージ"。
[8] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[8]ローゼンバーグ、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.及び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]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
[11] Rosenberg, J., "Presence Authorization Rules", RFC 5025, October 2007.
[11]ローゼンバーグ、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]ローゼンバーグ、J.、進歩、2007年10月ワーク「セッション開始プロトコル（SIP）に同意ベースの通信のためのフレームワーク」。
[13] Camarillo, G., "A Document Format for Requesting Consent", Work in Progress, October 2007.
[13]カマリロ、G.、「同意を要求するためのドキュメントフォーマット」、進歩、2007年10月の作業。
[14] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
[14]ローゼンバーグ、J.、進歩、2005年10月ワーク「セッション開始プロトコル（SIP）でのアプリケーションの対話のためのフレームワーク」。
[15] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[15]バーガー、E.およびM.ドリー、 "Aセッション開始プロトコル（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]ローゼンバーグ、J.、進歩、2007年6月に仕事 "セッション開始プロトコル（SIP）ユーザエージェント（UA）にルースルーティングの適用"。
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[17]ピーターソン、J.とC.ジェニングス、 "セッション開始プロトコル（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]オールマン、E.およびH.カッツ、「電子メールメッセージの責任提出者を示すためのSMTPサービス拡張」、RFC 4405、2006年4月。
[19] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[19]リヨン、J.とM.ウォン、 "送信者ID：認証の電子メール"、RFC 4406、2006年4月。
[20] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[20]リヨン、J.、 "Eメールメッセージで主張責任アドレス"、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.
"Eメール、バージョン1でのドメインの認可使用のためのSPF（Sender Policy Framework）を" [21]ウォン、M.およびW. Schlitt、RFC 4408、2006年4月。
[22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[22]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]オールマン、E.、カラス、J.、デラニー、M.、リビー、M.、フェントン、J.、およびM.トーマス、 "ドメインキーを識別メール（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.、 "/セキュア多目的インターネットメール拡張（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]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "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]アバディ、M.、バローズ、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]アバディ、M.、バローズ、M.、ビレル、A.、Dabek、F.、およびT. Wobber、 "ネットワークサービスのための確かな切手、8日のアジアコンピューティング科学会議、ムンバイ、インドの議事録"、12月2003。
[28] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work, Third Annual Workshop on Economics and Information Security", May 2004.
[28]クレイトン、R.とB.ローリー、「仕事の証明が機能していない証明し、経済学と情報セキュリティ上の第3回ワークショップ」、2004年5月。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサン・ローゼンバーグシスコエジソン、NJ US
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net
Cullen Jennings Cisco 170 West Tasman Dr. San Jose, CA 95134 US
カレン・ジェニングスのCisco 170西タスマン博士サンノゼ、CA 95134米国
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
電話：+1 408 421-9990 Eメール：fluffy@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。