[要約] RFC 4453は、SIPにおける同意ベースの通信の要件を定めたものです。このRFCの目的は、SIPセッションの開始前に通信の同意を確保するための仕組みを提供することです。
Network Working Group J. Rosenberg
Request for Comments: 4453 Cisco Systems
Category: Informational G. Camarillo, Ed.
Ericsson
D. Willis
Cisco Systems
April 2006
Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)
セッション開始プロトコル（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）The Internet Society（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.
セッション開始プロトコル（SIP）は、リアルタイムオーディオ、ビデオ、テキスト、インスタントメッセージング、存在など、多くのメディアタイプでのコミュニケーションをサポートします。現在の形式では、受信者の明示的な同意を必要とせずに、セッションの招待状、インスタントメッセージ、およびその他の要求をある当事者から別の当事者に配信することができます。そのような同意がなければ、SIPをスパムやサービス拒否攻撃などの悪意のある目的に使用することが可能です。このドキュメントは、同意ベースのコミュニケーションを追加する拡張機能をSIPするための一連の要件を識別します。
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
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.
セッション開始プロトコル（SIP）[1]は、リアルタイムオーディオ、ビデオ、テキスト、インスタントメッセージング、存在など、多くのメディアタイプの通信をサポートしています。この通信は、イニシエーターから受信者へのさまざまなSIPリクエスト（招待やメッセージ[3]など）の送信によって確立され、コミュニケーションが必要です。このような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サービスに向けられた増幅攻撃の発生率は、電子メールサービスに対する同じ攻撃と比較して低くなっています。すすり泣くワーキンググループは、これらの攻撃に積極的に対処する必要があると考えているため、攻撃は電子メールへの攻撃が存在するほど負担になりません。
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に同意フレームワークを追加するための一連の要件を定義します。
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.
RFC 3261 [1]およびRFC 3263 [2]の原則に従って設計されたSIPネットワークでは、インターネット上の誰でもSIPリクエストを作成してSIPリクエストを作成して送信できます。）。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リクエストを受信すると、ユーザーエージェントは通常、メッセージの受信についてユーザーに警告するために何らかの自動化されたアクションを実行します。招待リクエストの場合、これには通常、可聴アラート（たとえば、「電話を鳴らす」）または視覚的なアラート（たとえば、画面ポップアップウィンドウの作成）を配信することが含まれます。これらの指標は、呼び出し者のコールとアイデンティティの対象を頻繁に伝えます。セッションのリアルタイムの性質により、これらのアラートは通常、ユーザーの注意を引くために本質的に破壊的です。
For MESSAGE requests, the content of the message is usually rendered to the user.
メッセージリクエストの場合、メッセージのコンテンツは通常、ユーザーにレンダリングされます。
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]リクエストは、通常、ユーザーのデバイスに居住するユーザーエージェントに配信されません。むしろ、それらは通常、ネットワークベースの状態エージェントによって処理されます。Watcher Information Eventパッケージにより、ユーザーはそのようなリクエストが彼らのために生成されたことを知ることができ、ユーザーはリクエストを承認または拒否する機会を与えます。その結果、購読処理、特に存在感はすでに同意ベースの操作があります。それにもかかわらず、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-Listサービス[5]を提供します。これは、URIリストの各受信者に同じリクエストの新しいコピーを送信します。URI-Listサービスの例は、リソースリスト[6]、ダイヤルアウト会議サーバー[8]、およびメッセージURI-Listサービス[7]へのサブスクリプションです。SIP URI-Listサービスはアンプとして使用でき、単一のSIPリクエストを1つのターゲットホストまたはネットワークにあふれさせることができます。たとえば、ユーザーは100のエントリを持つリソースリストを作成できます。各エントリは、「SIP：識別子@Target-IP」というフォームのURIです。ターゲットIPは、攻撃を指示するIPアドレスです。そのようなリストに単一のSIPサブスクライブリクエストを送信すると、リソースリストサーバーが100のサブスクライブリクエストを生成します。各ターゲットのIPアドレスには、SIPノードである必要さえありません。
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 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.
DOS攻撃の起動に加えて、攻撃者はSIP URI-Listサーバーをアンプとして使用してスパムを配信することもできます。招待リクエストの場合、これは典型的な「テレマーケティング担当者」の呼び出しの形をとります。ユーザーは、通信の終わりのないリクエストのストリームを受け取る場合があり、それぞれがユーザーを混乱させ、注意を要求します。メッセージリクエストの場合、問題はさらに深刻です。ユーザーは、視覚的なアラートの終わりのないストリーム（画面ポップアップウィンドウなど）を受け取る場合があります。
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.
SPAMとDOSに関連する増幅攻撃は、同意ベースの通信フレームワークをSIPに追加することにより、軽減できます。このようなフレームワークにより、サーバーは同意なしにユーザーにメッセージを中継することができません。
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-List Services [5]のフレームワークは、URIリストサービスのコンテキストの問題として増幅攻撃を特定します。そのフレームワークは、同意ベースのコミュニケーションの形式であるオプトインリストの使用を義務付けています。読者は、同意ベースのフレームワークが[9]でスパム関連の問題を軽減するのに役立つ方法についての分析を見つけることができます。
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で同意ベースのコミュニケーションを提供するソリューションの要件を特定します。リレーは、プロキシ、バックツーバックユーザーエージェント（B2BUA）、またはリクエストを受信し、リクエストを1つまたは複数の次のホップURIに変換するハイブリッドであれ、任意のSIPサーバーとして定義されます。リクエストを提供します。
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.
Req 1：ソリューションは、適切に認証されたメッセージを使用して、受信者がリレーの許可を明示的に付与していない限り、リレーが受信者に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.
Req 2：ソリューションは、アウトバウンドリクエストがターゲットにされるリソースによって許可が付与されない限り、インバウンドリクエストに応答して、リレーが複数のアウトバウンドリクエストを生成するのを防ぐものとします。この要件により、同意メカニズム自体が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.
Req 3：許可は、記録アドレス（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.
Req 4：各受信者AORは、メッセージを受信者に転送する各SIPサービスのアクセス許可を個別に指定できる必要があります。たとえば、アリスはドメインAからの彼女への転送を許可するかもしれませんが、ドメインBからではありません。
REQ 5: It shall be possible for a user to revoke permissions at any time.
Req 5：ユーザーがいつでもアクセス許可を取り消すことができます。
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.
Req 6：ユーザーまたはユーザーエージェントが、リレーリソースに以前に付与された許可を取り消すことができるように、情報を保存する必要はありません。
REQ 7: The solution shall work in an inter-domain context, without requiring preestablished relationships between domains.
Req 7：ソリューションは、ドメイン間の事前に確立された関係を必要とせずに、ドメイン間のコンテキストで機能するものとします。
REQ 8: The solution shall work for all current and future SIP methods.
Req 8：ソリューションは、現在および将来のすべてのSIPメソッドに対して機能するものとします。
REQ 9: The solution shall be applicable to forking proxies.
Req 9：ソリューションは、プロキシのフォーキングに適用できます。
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].
Req 10：ソリューションは、リソースリストサーバー[5]、メッセージURIリストサービス[7]、およびダイヤルアウト機能[8]を実行する会議サーバーなどのURIリストサービスに適用できます。
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.
Req 11：SIPでは、URI-ListsをURI-Listサーバーに保存するか、SIPリクエストで提供できます。同意フレームワークは、どちらの場合も機能する必要があります。
REQ 12: The solution shall allow anonymous communications, as long as the recipient is willing to accept anonymous communications.
Req 12：ソリューションは、受信者が匿名のコミュニケーションを受け入れる意思がある限り、匿名のコミュニケーションを許可するものとします。
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.
Req 13：リクエストの受信者が元の送信者に関して匿名であることを望んでいる場合、受信者は、元の送信者が受信者の身元を学習せずに送信者に許可を与えることができる必要があります。
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.
Req 14：ソリューションは、同意の根本的な目標を損なうことを目指す攻撃を防ぐものとします。つまり、システムを「だまし」、実際に許可されていないリクエストを提供することはできません。
REQ 15: The solution shall not require the recipient of the communications to be connected to the network at the time communications are attempted.
Req 15：ソリューションは、通信が試行された時点で、通信の受信者がネットワークに接続することを要求してはなりません。
REQ 16: The solution shall not require the sender of a SIP request to be connected at the time that a recipient provides permission.
Req 16：ソリューションは、受信者が許可を提供する時点で、SIPリクエストの送信者に接続する必要はありません。
REQ 17: The solution should scale to Internet-wide deployment.
Req 17：ソリューションは、インターネット全体の展開にスケーリングする必要があります。
Security has been discussed throughout this document.
このドキュメント全体でセキュリティが議論されています。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[3] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、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] カマリロ、G。およびA.B.Roach、「セッション開始プロトコル（SIP）ユニフォームリソース識別子（URI）リストサービスのフレームワークとセキュリティに関する考慮事項」、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] Roach、A.B.、Rosenberg、J。、およびB. Campbell、「リソースリストのセッション開始プロトコル（SIP）イベント通知拡張機能」、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] Garcia-Martin、M。and G. Camarillo、「セッション開始プロトコル（SIP）での多recipientメッセージ要求」、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] Camarillo、G。およびA. Johnston、「セッション開始プロトコル（SIP）でリクエストコンテッドリストを使用した会議設立」、2006年2月、進行中の作業。
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, July 2005.
[9] Rosenberg、J。、「セッション開始プロトコル（SIP）およびスパム」、2005年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Gonzalo Camarillo (Editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンザロカマリロ（編集者）エリクソンハーサランティ11ジョルバス02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Dean Willis Cisco Systems 2200 E. Pres. George Bush Turnpike Richardson, TX 75082 USA
ディーン・ウィリス・シスコ・システム2200 E. Pres。ジョージブッシュターンパイクリチャードソン、テキサス州75082 USA
EMail: dean.willis@softarmor.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書は、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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。