RFC4453 日本語訳

Network Working Group                                       J. Rosenberg
Request for Comments: 4453                                 Cisco Systems
Category: Informational                                G. Camarillo, Ed.
                                                                Ericsson
                                                               D. Willis
                                                           Cisco Systems
                                                              April 2006

コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4453年のシスコシステムズカテゴリ: エド情報のG.キャマリロ、エリクソンD.ウィリスシスコシステムズ2006年4月

             Requirements for Consent-Based Communications
                in the Session Initiation Protocol (SIP)

セッション開始プロトコルの同意ベースのコミュニケーションのための要件(一口)

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   The Session Initiation Protocol (SIP) supports communications across
   many media types, including real-time audio, video, text, instant
   messaging, and presence.  In its current form, it allows session
   invitations, instant messages, and other requests to be delivered
   from one party to another without requiring explicit consent of the
   recipient.  Without such consent, it is possible for SIP to be used
   for malicious purposes, including spam and denial-of-service attacks.
   This document identifies a set of requirements for extensions to SIP
   that add consent-based communications.

Session Initiationプロトコル(SIP)はリアルタイムのオーディオ、ビデオ、テキスト、インスタントメッセージング、および存在を含む多くのメディアタイプの向こう側にコミュニケーションをサポートします。 現在のフォームでは、それはセッション招待状、インスタントメッセージ、および1回のパーティーから別のパーティーまで受取人の明白な同意を必要としないで提供されるという他の要求を許します。 そのような同意がなければ、スパムとサービス不能攻撃を含んでいて、SIPが悪意の目的に使用されるのは、可能です。 このドキュメントは同意ベースのコミュニケーションを加えるSIPに拡大のための1セットの要件を特定します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Problem Statement ...............................................2
   3. Requirements ....................................................4
   4. Security Considerations .........................................5
   5. References ......................................................6
      5.1. Normative References .......................................6
      5.2. Informational References ...................................6

1. 序論…2 2. 問題声明…2 3. 要件…4 4. セキュリティ問題…5 5. 参照…6 5.1. 標準の参照…6 5.2. 情報の参照…6

Rosenberg, et al.            Informational                      [Page 1]

RFC 4453                  Consent Requirements                April 2006

ローゼンバーグ、他 情報[1ページ]のRFC4453は要件2006年4月に同意します。

1.  Introduction

1. 序論

   The Session Initiation Protocol (SIP) [1] supports communications
   across many media types, including real-time audio, video, text,
   instant messaging, and presence.  This communication is established
   by the transmission of various SIP requests (such as INVITE and
   MESSAGE [3]) from an initiator to the recipient, with whom
   communication is desired.  Although a recipient of such a SIP request
   can reject the request, and therefore decline the session, a SIP
   network will deliver a SIP request to the recipient without their
   explicit consent.

Session Initiationプロトコル(SIP)[1]は多くのメディアタイプの向こう側にコミュニケーションをサポートします、リアルタイムのオーディオ、ビデオ、テキスト、インスタントメッセージング、および存在を含んでいて。 (創始者から受取人までのINVITEやMESSAGE[3])などのように。このコミュニケーションは様々なSIP要求の伝達で確立されます。(コミュニケーションはその受取人と共に望まれています)。 そのようなSIP要求の受取人は、要求を拒絶して、したがって、セッションを断ることができますが、SIPネットワークは彼らの明白な同意なしでSIP要求を受取人に提供するでしょう。

   Receipt of these requests without explicit consent can cause a number
   of problems in SIP networks.  These include amplification attacks.
   These problems have plagued email.  At the time of this writing, most
   SIP services are not interconnected, so the incidence of
   amplification attacks directed at SIP services is low compared to the
   same attacks on email services.  The SIPPING working group believes
   it is necessary to address these attacks proactively so the attacks
   do not become as burdensome as attacks on email have become.

明白な同意のないこれらの要求の領収書はSIPネットワークにおける多くの問題を引き起こす場合があります。 これらは増幅攻撃を含んでいます。 これらの問題はメールを苦しめました。 この書くこと時点でほとんどのSIPサービスがインタコネクトされないので、メールサービスに対する同じ攻撃と比べて、SIPサービスが向けられた増幅攻撃の発生は低いです。 SIPPINGワーキンググループが、これらの攻撃が予測することであると扱うのが必要であると信じているので、攻撃はメールに対する攻撃がなったのと同じくらい重荷になるようになりません。

   This document elaborates on the problems posed by the current open
   model in which SIP was designed, and then goes on to define a set of
   requirements for adding a consent framework to SIP.

このドキュメントは、SIPが設計された現在の開放モデルによって引き起こされた問題について詳しく説明して、次に、同意フレームワークをSIPに加えるための1セットの要件を定義し続けます。

2.  Problem Statement

2. 問題声明

   In SIP networks designed according to the principles of RFC 3261 [1]
   and RFC 3263 [2], anyone on the Internet can create and send a SIP
   request to any other SIP user, by identifying that user with a SIP
   Uniform Resource Identifier (URI).  The SIP network will usually
   deliver this request to the user identified by that URI.  It is
   possible, of course, for network services, such as call screening, to
   block such messaging from occurring, but this is not widespread and
   certainly not a systematic solution to the problem under
   consideration here.

RFC3261[1]とRFC3263[2]の原則によると、設計されたSIPネットワークでは、インターネットのだれでも、いかなる他のSIPユーザにもSIP要求を作成して、送ることができます、SIP Uniform Resource Identifier(URI)とそのユーザを同一視することによって。 通常、SIPネットワークはそのURIによって特定されたユーザにこの要求を提供するでしょう。 呼び出し選別などのネットワーク・サービスには、それはそのようなメッセージングが現れるのを妨げるためにもちろん可能ですが、これは、広範囲でなくて、また確かに、ここでの考慮での問題への系統的な解決ではありません。

   Once the SIP request is received by the recipient, the user agent
   typically takes some kind of automated action to alert the user about
   receipt of the message.  For INVITE requests, this usually involves
   delivering an audible alert (e.g., "ringing the phone"), or a visual
   alert (e.g., creating a screen pop-up window).  These indicators
   frequently convey the subject of the call and the identity of the
   caller.  Due to the real-time nature of the session, these alerts are
   typically disruptive in nature, so as to get the attention of the
   user.

SIP要求が受取人によっていったん受け取られると、ユーザエージェントは、メッセージの領収書でユーザを警告するためにある種の自動化された行動を通常取ります。 INVITE要求のために、通常、これは、聞きとれる警戒(例えば、「電話を鳴らす」)、または視覚警戒(例えば、スクリーンポップアップウィンドウを作成する)を提供することを伴います。 これらのインディケータは頻繁に呼び出しの対象と訪問者のアイデンティティを伝えます。 セッションの瞬時性のために、これらの警戒は現実に通常破壊的です、ユーザの注意を得るために。

Rosenberg, et al.            Informational                      [Page 2]

RFC 4453                  Consent Requirements                April 2006

ローゼンバーグ、他 情報[2ページ]のRFC4453は要件2006年4月に同意します。

   For MESSAGE requests, the content of the message is usually rendered
   to the user.

MESSAGE要求において、通常、メッセージの内容をユーザに提供します。

   SUBSCRIBE [4] requests do not normally get delivered to the user
   agents residing on a user's devices.  Rather, they are normally
   processed by network-based state agents.  The watcher information
   event package allows a user to find out that such requests were
   generated for them, affording the user the opportunity to approve or
   deny the request.  As a result, SUBSCRIBE processing, and most
   notably presence, already has a consent-based operation.
   Nevertheless, this already-existing consent mechanism for SIP
   subscriptions does not protect network agents against denial-of-
   service (DoS) attacks.

[4] 登録、要求はそうしません。通常、ユーザのデバイスで住みながら、ユーザエージェントに提供させてください。 むしろ、通常、それらはネットワークベースの州のエージェントによって処理されます。 ユーザは、ウォッチャー情報イベントパッケージでそのような要求がそれらのために生成されたのを見つけることができます、要求を承認するか、または否定する機会をユーザに提供して。 aとして、なってください、登録。処理、および最も著しく存在には、同意ベースの操作が既にあります。 それにもかかわらず、SIP購読のためのこの既に既存の同意メカニズムは-サービスでは、(DoS)が攻撃するという否定に対してネットワークエージェントを保護しません。

   A problem that arises when requests can be delivered to user agents
   directly, without their consent, is amplification attacks.  SIP
   proxies provide a convenient relay point for targeting a message to a
   particular user or IP address and, in particular, forwarding to a
   recipient that is often not directly reachable without usage of the
   proxy.  Some SIP proxy servers forward a single request to several
   instances or contacts for the same user or resource.  This process is
   called "forking".  Another type of SIP server provides the SIP URI-
   list service [5], which sends a new copy of the same request to each
   recipient in the URI-list.  Examples of URI-list services are
   subscriptions to resource lists [6], dial-out conference servers [8],
   and MESSAGE URI-list services [7].  A SIP URI-list service could be
   used as an amplifier, allowing a single SIP request to flood a single
   target host or network.  For example, a user can create a resource
   list with 100 entries, each of which is a URI of the form
   "sip:identifier@target-IP", where target-IP is the IP address to
   which the attack is to be directed.  Sending a single SIP SUBSCRIBE
   request to such a list will cause the resource list server to
   generate 100 SUBSCRIBE requests, each to the IP address of the
   target, which does not even need to be a SIP node.

彼らの同意なしでユーザエージェントに要求を直接提供できるとき起こる問題は増幅攻撃です。 SIPプロキシは特定のユーザかIPアドレスにメッセージを狙うのに便利なリレーポイントを提供します、そして、それを受取人に特に送るのはプロキシの使用法なしでしばしば直接届いているというわけではありません。 いくつかのSIPプロキシサーバが同じユーザかリソースのためにいくつかのインスタンスか接触にただ一つの要求を転送します。 このプロセスは「分岐」と呼ばれます。 別のタイプのSIPサーバはSIP URIリストサービス[5]を提供します。(それは、新しいコピーの同じ要求をURIリストの各受取人に送ります)。 URIリストサービスの例はリソースリスト[6]、ダイヤルアウト会議サーバ[8]、およびMESSAGE URI-リストサービス[7]の購読です。 アンプとしてSIP URI-リストサービスを利用できました、独身の目標ホストかネットワークをあふれさせるというただ一つのSIP要求を許して。 例えば、ユーザは100のエントリーでリソースリストを作成できます。それはそれぞれフォーム「一口: identifier@target-IP 」のURIです。そこでは、目標IPが向けられる攻撃がことであるIPアドレスです。 独身のSIP SUBSCRIBEを送るのは、登録ようリストがリソースリストサーバに100を生成させるそのようなものに要求します。それぞれ目標(SIPノードである必要がしてさえいないもの)のIPアドレスへの要求。

      Note that the target-IP does not need to be the same in all the
      URIs in order to attack a single machine.  For example, the
      target-IP addresses may all belong to the same subnetwork, in
      which case the target of the attack would be the access router of
      the subnetwork.

IPを狙うのが単一マシンを攻撃するためにすべてのURIで同じである必要はないことに注意してください。 例えば、IPを狙っているアドレスはすべて、同じサブネットワークに属すかもしれません、その場合、攻撃の目標がサブネットワークのアクセスルータでしょう。

   In addition to launching DoS attacks, attackers could also use SIP
   URI-list servers as amplifiers to deliver spam.  For INVITE requests,
   this takes the form of typical "telemarketer" calls.  A user might
   receive a stream of never-ending requests for communications, each of
   them disrupting the user and demanding their attention.  For MESSAGE

また、DoS攻撃に着手することに加えて、提供するアンプがばらまかれるとき、攻撃者はSIP URI-リストサーバを使用できました。 INVITE要求のために、これは典型的な「テレマーケティングをする人」呼び出しの形を取ります。 ユーザはそれらのそれぞれがユーザを混乱させて、彼らの注意を要求することであるコミュニケーションに関する果てしない要求のストリームを受けるかもしれません。 メッセージのために

Rosenberg, et al.            Informational                      [Page 3]

RFC 4453                  Consent Requirements                April 2006

ローゼンバーグ、他 情報[3ページ]のRFC4453は要件2006年4月に同意します。

   requests, the problem is even more severe.  The user might receive a
   never-ending stream of visual alerts (e.g., screen pop-up windows)
   that deliver unwanted, malicious, or otherwise undesired content.

要求であり、問題はさらに厳しいです。 ユーザは求められていないか、悪意があるか、そうでなければ、望まれない内容を提供する視覚警戒(例えば、スクリーンポップアップウィンドウ)の果てしないストリームを受けるかもしれません。

   Both amplification attacks related to spam and DoS can be alleviated
   by adding a consent-based communications framework to SIP.  Such a
   framework keeps servers from relaying messages to users without their
   consent.

同意ベースのコミュニケーションフレームワークをSIPに加えることによって、ばらまくために関係づけられた増幅攻撃とDoSの両方を軽減できます。 そのようなフレームワークは、サーバが彼らの同意なしでユーザにメッセージをリレーするのを妨げます。

      The framework for SIP URI-list services [5] identifies
      amplification attacks as a problem in the context of URI-list
      services.  That framework mandates the use of opt-in lists, which
      are a form of consent-based communications.  The reader can find
      an analysis on how a consent-based framework helps alleviate
      spam-related problems in [9].

SIP URI-リストサービス[5]のためのフレームワークは、増幅攻撃がURIリストサービスの文脈の問題であると認識します。 そのフレームワークはオプトインリストの使用を強制します。(それは、同意ベースのコミュニケーションのフォームです)。 読者は同意ベースのフレームワークが、[9]でスパム関連の問題を軽減するのをどう助けるかに関する分析を見つけることができます。

3.  Requirements

3. 要件

   The following identify requirements for a solution that provides
   consent-based communications in SIP.  A relay is defined as any SIP
   server, be it a proxy, Back-to-Back User Agent (B2BUA), or some
   hybrid, that receives a request and translates the request URI into
   one or more next-hop URIs to which it then delivers a request.

以下はSIPの同意ベースのコミュニケーションを提供するソリューションのための要件を特定します。 リレーがどんなSIPサーバとも定義されて、それは、プロキシBackから後部へのUserエージェント(B2BUA)か何らかのハイブリッドであることにかかわらず要求を受け取って、次にそれが要求を提供する1つ以上の次のホップURIに要求URIを翻訳します。

   REQ 1:  The solution must keep relays from delivering a SIP request
      to a recipient unless the recipient has explicitly granted
      permission to the relay using appropriately authenticated
      messages.

REQ1: ソリューションは、受取人が適切に認証されたメッセージを使用することで明らかにリレーに許可を与えていない場合リレーがSIP要求を受取人に提供するのを妨げなければなりません。

   REQ 2:  The solution shall prevent relays from generating more than
      one outbound request in response to an inbound request, unless
      permission to do so has been granted by the resource to whom the
      outbound request was to be targeted.  This requirement avoids the
      consent mechanism itself becoming the focus of DoS attacks.

REQ2: ソリューションは、リレーが本国行きの要求に対応して1つ以上の外国行きの要求を生成するのを防ぐものとします、そうする許可が狙う外国行きの要求がことであったリソースによって与えられていない場合。 この要件はDoS攻撃の焦点になる同意メカニズム自体を避けます。

   REQ 3:  The permissions shall be capable of specifying that messages
      from a specific user, identified by a SIP URI that is an Address-
      of-Record (AOR), are permitted.

REQ3: 許容は、記録のAddress(AOR)であるSIP URIによって特定された特定のユーザからのメッセージが受入れられると指定できるでしょう。

   REQ 4:  Each recipient AOR must be able to specify permissions
      separately for each SIP service that forwards messages to the
      recipient.  For example, Alice may authorize forwarding to her
      from domain A, but not from domain B.

REQ4: それぞれの受取人AORは別々にメッセージを受取人に転送するそれぞれのSIPサービスに許容を指定できなければなりません。 例えば、アリスは、ドメインAから彼女に送るのを認可しますが、ドメインBから認可するかもしれないというわけではありません。

   REQ 5:  It shall be possible for a user to revoke permissions at any
      time.

REQ5: ユーザがいつでも許容を取り消すのは、可能でしょう。

Rosenberg, et al.            Informational                      [Page 4]

RFC 4453                  Consent Requirements                April 2006

ローゼンバーグ、他 情報[4ページ]のRFC4453は要件2006年4月に同意します。

   REQ 6:  It shall not be required for a user or user agent to store
      information in order to be able to revoke permissions that were
      previously granted for a relay resource.

REQ6: ユーザかユーザエージェントが以前にリレーリソースのために承諾された許容は取り消すことができるように情報を保存するように、それを必要としないものとします。

   REQ 7:  The solution shall work in an inter-domain context, without
      requiring preestablished relationships between domains.

REQ7: ドメインの間の前設立された関係を必要としないで、ソリューションは相互ドメイン文脈で働いているものとします。

   REQ 8:  The solution shall work for all current and future SIP
      methods.

REQ8: ソリューションはすべての現在の、そして、将来のSIPメソッドのために働いているものとします。

   REQ 9:  The solution shall be applicable to forking proxies.

REQ9: ソリューションはプロキシを分岐させるのに適切になるでしょう。

   REQ 10:  The solution shall be applicable to URI-list services, such
      as resource list servers [5], MESSAGE URI-list services [7], and
      conference servers performing dial-out functions [8].

REQ10: ソリューションはURIリストサービスに適切になるでしょう、リソースリストサーバ[5]や、MESSAGE URI-リストサービス[7]や、ダイヤルアウト機能[8]を実行する会議サーバなどのように。

   REQ 11:  In SIP, URI-lists can be stored on the URI-list server or
      provided in a SIP request.  The consent framework must work in
      both cases.

REQ11: SIPでは、URIリストをURIリストサーバに保存するか、またはSIP要求に提供できます。 同意フレームワークはどちらの場合も、働かなければなりません。

   REQ 12:  The solution shall allow anonymous communications, as long
      as the recipient is willing to accept anonymous communications.

REQ12: 受取人が、匿名のコミュニケーションを受け入れても構わないと思っている限り、ソリューションは匿名のコミュニケーションを許容するものとします。

   REQ 13:  If the recipient of a request wishes to be anonymous with
      respect to the original sender, it must be possible for the
      recipient to grant permission for the sender without the original
      sender learning the recipient's identity.

REQ13: 要求の受取人が元の送り主に関して匿名になりたがっているなら、元の送り主が受取人のアイデンティティを学ばないで受取人が送付者のために許可を与えるのは、可能であるに違いありません。

   REQ 14:  The solution shall prevent attacks that seek to undermine
      the underlying goal of consent.  That is, it should not be
      possible to "fool" the system into delivering a request for which
      permission was not, in fact, granted.

REQ14: ソリューションは同意の基本的な目標を弱体化させようとする攻撃を防ぐものとします。 すなわち、システムが事実上、許可が与えられなかった要求を提供するのに「だます」であることは可能であるべきではありません。

   REQ 15:  The solution shall not require the recipient of the
      communications to be connected to the network at the time
      communications are attempted.

REQ15: ソリューションは、接続されて、時間コミュニケーションにおけるネットワークが試みられるということになるように受取人にコミュニケーションを要求しないものとします。

   REQ 16:  The solution shall not require the sender of a SIP request
      to be connected at the time that a recipient provides permission.

REQ16: ソリューションは受取人が許可を提供する時に接続されるというSIP要求を送付者に要求しないものとします。

   REQ 17:  The solution should scale to Internet-wide deployment.

REQ17: ソリューションはインターネット全体の展開に比例するべきです。

4.  Security Considerations

4. セキュリティ問題

   Security has been discussed throughout this document.

このドキュメント中でセキュリティについて議論しました。

Rosenberg, et al.            Informational                      [Page 5]

RFC 4453                  Consent Requirements                April 2006

ローゼンバーグ、他 情報[5ページ]のRFC4453は要件2006年4月に同意します。

5.  References

5. 参照

5.1.  Normative References

5.1. 引用規格

   [1]  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.

[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [2]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

[2] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。

   [3]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
        D. Gurle, "Session Initiation Protocol (SIP) Extension for
        Instant Messaging", RFC 3428, December 2002.

[3] キャンベル、B.、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。

5.2.  Informational References

5.2. 情報の参照

   [4]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

[4] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。

   [5]  Camarillo, G. and A.B. Roach, "Framework and Security
        Considerations for Session Initiation Protocol (SIP) Uniform
        Resource Identifier (URI)-List Services", Work in Progress,
        January 2006.

[5] 「セッション開始プロトコル(一口)Uniform Resource Identifier(URI)のためのフレームワークとセキュリティ問題はサービスを記載する」というキャマリロ、G.、およびA.B.ローチは進行中(2006年1月)で働いています。

   [6]  Roach, A.B., Rosenberg, J., and B. Campbell, "A Session
        Initiation Protocol (SIP) Event Notification Extension for
        Resource Lists", Work in Progress, January 2005.

[6] ローチ、A.B.、ローゼンバーグ、J.、およびB.キャンベル、「リソースリストのためのセッション開始プロトコル(一口)イベント通知拡張子」は進行中(2005年1月)で働いています。

   [7]  Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
        Requests in the Session Initiation Protocol (SIP)", Work in
        Progress, February 2006.

[7] 「セッション開始プロトコル(一口)における複数の受取人メッセージ要求」というガルシア-マーチン、M.、およびG.キャマリロは進歩、2006年2月に働いています。

   [8]  Camarillo, G. and A. Johnston, "Conference Establishment Using
        Request-Contained Lists in the Session Initiation Protocol
        (SIP)", Work in Progress, February 2006.

[8] 「セッション開始プロトコル(一口)に要求で含まれたリストを使用するコンファレンス設立」というキャマリロ、G.、およびA.ジョンストンは進行中(2006年2月)で働いています。

   [9]  Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam",
        Work in Progress, July 2005.

[9] ローゼンバーグと、J.と、「セッション開始プロトコル(一口)とスパム」は進歩、2005年7月に働いています。

Rosenberg, et al.            Informational                      [Page 6]

RFC 4453                  Consent Requirements                April 2006

ローゼンバーグ、他 情報[6ページ]のRFC4453は要件2006年4月に同意します。

Authors' Addresses

作者のアドレス

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)

   Phone: +1 973 952-5000
   EMail: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net

   Gonzalo Camarillo (Editor)
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロ・キャマリロ(エディタ)エリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

   Dean Willis
   Cisco Systems
   2200 E. Pres. George Bush Turnpike
   Richardson, TX  75082
   USA

ディーンウィリスシスコシステムズ2200E.Pres。 ジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)

   EMail: dean.willis@softarmor.com

メール: dean.willis@softarmor.com

Rosenberg, et al.            Informational                      [Page 7]

RFC 4453                  Consent Requirements                April 2006

ローゼンバーグ、他 情報[7ページ]のRFC4453は要件2006年4月に同意します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Rosenberg, et al.            Informational                      [Page 8]

ローゼンバーグ、他 情報[8ページ]