RFC 8165 - Design Considerations for Metadata Insertion 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8165
タイトル : RFC 8165 - メタデータ挿入の設計上の考慮事項
翻訳編集 : 自動生成

[要約] RFC 8165は、メタデータ挿入の設計に関する考慮事項をまとめたものであり、メタデータの効果的な挿入方法についてのガイドラインを提供しています。このRFCの目的は、ネットワーク上でのメタデータの利用を最適化し、ネットワークパフォーマンスやセキュリティの向上を図ることです。

Internet Engineering Task Force (IETF)                         T. Hardie
Request for Comments: 8165                                      May 2017
Category: Informational
ISSN: 2070-1721

Design Considerations for Metadata Insertion

メタデータ挿入の設計上の考慮事項

Abstract

概要

The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.

IABは、インターネット通信に対する広範囲にわたる攻撃のいくつかの暴露に対応してRFC 7624を公開しました。このドキュメントでは、メタデータを暗号化されたフローに関連付けるプロトコル設計の影響について検討します。特に、ホストでの明示的なアクションによってのみメタデータを共有する設計は、ミドルボックスがメタデータを挿入する設計よりも好ましいと主張しています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8165.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8165で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Design Pattern ..................................................2
   4. Advice ..........................................................3
   5. Deployment Considerations .......................................4
   6. IANA Considerations .............................................5
   7. Security Considerations .........................................5
   8. References ......................................................6
      8.1. Normative References .......................................6
      8.2. Informative References .....................................6
   Acknowledgements ...................................................7
   Author's Address ...................................................7

1. Introduction

1. はじめに

To minimize the risks associated with pervasive surveillance, it is necessary for the Internet technical community to address the vulnerabilities exploited in the attacks documented in [RFC7258] and the threats described in [RFC7624]. The goal of this document is to address a common design pattern that emerges from the increase in encryption: explicit association of metadata that would previously have been inferred from the plaintext protocol.

広範囲にわたる監視に関連するリスクを最小限に抑えるには、インターネット技術コミュニティが、[RFC7258]で文書化されている攻撃で悪用される脆弱性と[RFC7624]で説明されている脅威に対処する必要があります。このドキュメントの目的は、暗号化の増加から現れる一般的な設計パターンに対処することです。以前はプレーンテキストプロトコルから推測されていたメタデータの明示的な関連付け。

2. Terminology

2. 用語

This document makes extensive use of standard security and privacy terminology; see [RFC4949] and [RFC6973]. Readers should be familiar with the terms defined in [RFC6973], including "Eavesdropper", "Observer", "Initiator", "Intermediary", "Recipient", "Attack" (in a privacy context), "Correlation", "Fingerprint", "Traffic Analysis", and "Identifiability" (and related terms). Readers should also be familiar with terms that are specific to the attacks discussed in [RFC7624], including "Pervasive Attack", "Passive Pervasive Attack", "Active Pervasive Attack", "Observation", "Inference", and "Collaborator".

このドキュメントでは、標準のセキュリティとプライバシーの用語を幅広く使用しています。 [RFC4949]と[RFC6973]を参照してください。読者は、[RFC6973]で定義されている用語、「盗聴者」、「監視者」、「開始者」、「仲介者」、「受信者」、「攻撃」（プライバシーのコンテキスト）、「相関」、「フィンガープリント」に精通している必要があります。「、トラフィック分析」、「識別可能性」（および関連用語）。また、読者は、[RFC7624]で説明されている攻撃に固有の用語（「広域攻撃」、「受動的広域攻撃」、「能動的広域攻撃」、「観察」、「推論」、「協力者」など）にも精通している必要があります。

3. Design Pattern

3. デザインパターン

One of the core mitigations for the loss of confidentiality in the presence of pervasive surveillance is data minimization, which limits the amount of data disclosed to those elements absolutely required to complete the relevant protocol exchange. When data minimization is in effect, some information that was previously available may be removed from specific protocol exchanges. The information may be removed explicitly (for example, by a browser suppressing cookies during private modes) or by other means. As noted in [RFC7624], some topologies that aggregate or alter the network path also act to reduce the ease with which metadata is available to eavesdroppers.

広範囲にわたる監視の存在下で機密性が失われるための中心的な緩和策の1つは、データの最小化です。これにより、関連するプロトコル交換を完了するために絶対に必要な要素に開示されるデータの量が制限されます。データの最小化が有効な場合、以前は利用可能だった一部の情報が、特定のプロトコル交換から削除される場合があります。情報は明示的に（たとえば、ブラウザーがプライベートモード中にCookieを抑制することによって）、または他の方法で削除される場合があります。 [RFC7624]で述べられているように、ネットワークパスを集約または変更する一部のトポロジは、盗聴者がメタデータを簡単に利用できるようにする役割も果たします。

In some cases, other actors within a protocol context will continue to have access to the information that has been thus withdrawn from specific protocol exchanges. If those actors attach the information as metadata to those protocol exchanges, the confidentiality effect of data minimization is lost.

場合によっては、プロトコルコンテキスト内の他のアクターは、特定のプロトコル交換から取り消された情報に引き続きアクセスできます。それらのアクターがそれらのプロトコル交換にメタデータとして情報を添付する場合、データ最小化の機密性の効果は失われます。

Restoring information is particularly tempting at systems not primarily deployed to increase confidentiality. A proxy providing compression, for example, may wish to restore the identity of the requesting party; similarly, a VPN system used to provide channel security may believe that the origin IP should be restored. Actors considering restoring metadata may believe that they understand the relevant privacy considerations or believe that, because the primary purpose of the service was not privacy-related, none exist. Examples of this design pattern include [RFC7239] and [RFC7871].

情報の復元は、機密性を高めるために主に展開されていないシステムでは特に魅力的です。たとえば、圧縮を提供するプロキシは、要求側のIDを復元したい場合があります。同様に、チャネルセキュリティを提供するために使用されるVPNシステムは、元のIPを復元する必要があると考えている場合があります。メタデータの復元を検討しているアクターは、関連するプライバシーの考慮事項を理解していると信じるか、サービスの主な目的がプライバシー関連ではなかったため、存在しないと信じるかもしれません。この設計パターンの例には、[RFC7239]と[RFC7871]が含まれます。

4. Advice

4. 助言

Avoid inserting metadata to restore information that would otherwise be unavailable to later participants in a protocol exchange. It contributes to the overall loss of confidentiality for the Internet and trust in the Internet as a medium. Do not add metadata to flows at intermediary devices unless a positive affirmation of approval for restoration has been received from the actor whose data will be added.

メタデータを挿入して、それ以外の場合はプロトコル交換の参加者が使用できない情報を復元しないでください。これは、インターネットの機密性の全体的な喪失と、媒体としてのインターネットへの信頼に貢献します。データが追加されるアクターから復元の承認の肯定的な確認を受け取らない限り、中間デバイスのフローにメタデータを追加しないでください。

Instead, design the protocol so that the actor can add such metadata themselves so that it flows end to end, rather than requiring the action of other parties. In addition to improving privacy, this approach ensures consistent availability between the communicating parties, no matter what path is taken. (Note that this document does not attempt to describe how an actor sets policies on providing this metadata, as the range of systems that might be implied is very broad).

代わりに、アクターがそのようなメタデータを追加して、他の当事者のアクションを要求するのではなく、エンドツーエンドで流れるようにプロトコルを設計します。プライバシーを改善することに加えて、このアプローチは、どのような経路をとっても、通信する当事者間の一貫した可用性を保証します。（暗示される可能性のあるシステムの範囲は非常に広いため、このドキュメントでは、このメタデータの提供に関するアクターのポリシーの設定方法については説明していません）。

As an example, RFC 7871 describes a method that had already been deployed and notes that it is unlikely that a clean-slate design would result in this mechanism. If a clean-slate design were built to follow the advice in this document, that design would likely not use a core element of RFC 7871: rather than adding metadata at a proxy, it would provide facilities for end systems to add it to their initial queries. In the case of RFC 7871, the relevant metadata is relatively easy for an end system to derive, as Session Traversal Utilities for NAT (STUN) [RFC5389] provides a method for learning the reflexive transport address from which a client subnet could be derived. This would allow clients to populate this data themselves, thus affirming their consent and providing data at a granularity with which they were comfortable. As in RFC 7871, the addition of this data would require confirmation that the upstream DNS resolver understands what to do with it, but the same negotiation mechanism, an Extension Mechanisms for DNS (EDNS(0)) option [RFC6891], could be used. Because of this negotiation, there would be a new variability in responses that would change the caching behavior for data supplied by participating servers. This is not a major change from the current design, however, as the same considerations set out in Sections 7.3.2 and 7.5 of RFC 7871 would apply to client-supplied subnets as well as to proxy-supplied subnets.

例として、RFC 7871はすでに展開されている方法を説明しており、白紙の状態で設計するとこのメカニズムになる可能性は低いと述べています。クリーンスレートデザインがこのドキュメントのアドバイスに従うように構築されている場合、そのデザインはRFC 7871のコア要素を使用しない可能性があります。プロキシでメタデータを追加するのではなく、エンドシステムが初期に追加する機能を提供します。クエリ。 RFC 7871の場合、NATのセッショントラバーサルユーティリティ（STUN）[RFC5389]はクライアントサブネットの派生元となる再帰トランスポートアドレスを学習する方法を提供するため、関連メタデータはエンドシステムで比較的簡単に取得できます。これにより、クライアントはこのデータを自分で入力できるため、クライアントの同意を確認し、快適な粒度でデータを提供できます。 RFC 7871と同様に、このデータを追加するには、上流のDNSリゾルバーがそれをどうするかを理解していることの確認が必要ですが、同じ交渉メカニズムであるDNSの拡張メカニズム（EDNS（0））オプション[RFC6891]を使用できます。。このネゴシエーションが原因で、参加サーバーから提供されたデータのキャッシュ動作を変更する応答に新しいばらつきが生じます。ただし、これは現在の設計からの大きな変更ではありません。RFC7871のセクション7.3.2および7.5で説明されている同じ考慮事項が、クライアントが提供するサブネットとプロキシが提供するサブネットに適用されるためです。

From a protocol perspective, in other words, this approach would be a minor change from RFC 7871, would be as fully featured, and would provide better privacy properties than the on-path update mechanism RFC 7871 provides. The next section examines why, despite this, deployment considerations have sometimes trumped cleaner designs.

プロトコルの観点から、言い換えると、このアプローチはRFC 7871からのマイナーな変更であり、完全に機能し、RFC 7871が提供するパス上の更新メカニズムよりも優れたプライバシープロパティを提供します。次のセクションでは、それにもかかわらず、展開の考慮事項がクリーンな設計よりも優先されることがある理由を検討します。

5. Deployment Considerations

5. 導入に関する考慮事項

There are a few common tensions associated with the deployment of systems that restore metadata. The first is the trade-off in speed of deployment for different actors. The Forwarded HTTP Extension in [RFC7239] provides an example of this. When used with a proxy, it restores information related to the original requesting party, thus allowing a responding server to tailor responses according to the original party's region, network, or other characteristics associated with the identity. It would, of course, be possible for the originating client to add this data itself, after using STUN [RFC5389] or a similar mechanism to first determine the information to declare. This would require, however, full specification and adoption of this mechanism by the end systems. It would not be available at all during this period and would thereafter be limited to systems that have been upgraded to include it. The long tail of browser deployments indicates that many systems might go without upgrades for a significant period of time. The proxy infrastructure, in contrast, is commonly under more active management and represents a much smaller number of elements; this impacts both the general deployment difficulty and the number of systems that the origin server must trust.

メタデータを復元するシステムの展開に関連するいくつかの一般的な緊張があります。 1つ目は、さまざまなアクターの展開速度のトレードオフです。 [RFC7239]のForwarded HTTP Extensionは、この例を提供します。プロキシと一緒に使用すると、元の要求側に関連する情報が復元されるため、応答サーバーは、元の側の地域、ネットワーク、またはIDに関連付けられたその他の特性に従って応答を調整できます。もちろん、最初に宣言する情報を決定するためにSTUN [RFC5389]または同様のメカニズムを使用した後、発信元クライアントがこのデータ自体を追加することは可能です。ただし、これには、エンドシステムによるこのメカニズムの完全な仕様と採用が必要です。この期間中はまったく利用できなくなり、その後、それを含むようにアップグレードされたシステムに限定されます。ブラウザの展開の長いテールは、多くのシステムがかなりの期間、アップグレードなしで動作する可能性があることを示しています。対照的に、プロキシインフラストラクチャは通常、よりアクティブな管理下にあり、はるかに少ない数の要素を表します。これは、一般的な展開の難しさと、オリジンサーバーが信頼する必要のあるシステムの数の両方に影響します。

The second common tension is between metadata minimization and the desire to tailor content responses. For origin servers whose content is common across users, the loss of metadata may have limited impact on the system's functioning. For other systems, which commonly tailor content by region or network, the loss of metadata may imply a loss of functionality. Where the user desires this functionality, restoration can commonly be achieved by the use of other identifiers or login procedures. Where the user does not desire this functionality, but it is a preference of the server or a third party, adjustment is more difficult. At the extreme, content blocking by network origin may be a regulatory requirement. Trusting a network intermediary to provide accurate data is, of course, fragile in this case, but it may be a part of the regulatory framework.

2番目の共通の緊張は、メタデータの最小化とコンテンツの応答を調整したいという欲求の間です。ユーザー間でコンテンツが共通しているオリジンサーバーの場合、メタデータの損失によるシステムの機能への影響は限定的です。地域またはネットワークごとにコンテンツを調整する他のシステムの場合、メタデータの損失は機能の損失を意味する場合があります。ユーザーがこの機能を必要とする場合、通常、他の識別子またはログイン手順を使用して復元を実行できます。ユーザーがこの機能を望まないが、それがサーバーまたはサードパーティの設定である場合、調整はより困難になります。極端な場合、ネットワークの発信元によるコンテンツのブロックは規制上の要件になる場合があります。この場合、ネットワーク仲介者を信頼して正確なデータを提供することはもちろん脆弱ですが、規制フレームワークの一部である可能性があります。

There are also tensions with latency of operation. For example, where the end system does not initially know the information that would be added by on-path devices, it must engage the protocol mechanisms to determine it. Determining a public IP address to include in a locally supplied header might require a STUN exchange, and the additional latency of this exchange discourages deployment of host-based solutions. To minimize this latency, engaging those mechanisms may need to be done in parallel with or in advance of the core protocol exchanges with which this metadata would be supplied.

また、操作の待ち時間には緊張があります。たとえば、エンドシステムがオンパスデバイスによって追加される情報を最初に知らない場合は、プロトコルメカニズムを使用して決定する必要があります。ローカルに提供されるヘッダーに含めるパブリックIPアドレスを決定するには、STUN交換が必要になる場合があり、この交換のレイテンシが増えると、ホストベースのソリューションの展開が妨げられます。このレイテンシを最小限に抑えるために、これらのメカニズムの関与は、このメタデータが提供されるコアプロトコル交換と並行して、またはその前に行う必要がある場合があります。

These tensions do not change the basic recommendation, but they suggest that the parties who are introducing encryption and data minimization for existing protocols consider carefully whether the work also implies introducing mechanisms for the end-to-end provisioning of metadata when a user has actively consented to provide it.

これらの緊張は基本的な推奨事項を変更しませんが、既存のプロトコルに暗号化とデータ最小化を導入する当事者は、ユーザーが積極的に同意した場合に、メタデータのエンドツーエンドプロビジョニングのメカニズムを導入することも意味するかどうかを慎重に検討することを提案しますそれを提供する。

6. IANA Considerations

6. IANAに関する考慮事項

This document makes no request of IANA.

このドキュメントは、IANAの要求を行いません。

7. Security Considerations

7. セキュリティに関する考慮事項

This memorandum describes a design pattern emerging from responses to the attacks described in [RFC7258]. Continued use of this design pattern, which uses mid-flow devices to restore metadata, lowers the impact of mitigations to that attack.

この覚書は、[RFC7258]で説明されている攻撃への対応から生まれた設計パターンを説明しています。ミッドフローデバイスを使用してメタデータを復元するこの設計パターンを継続して使用すると、その攻撃に対する緩和策の影響が軽減されます。

Note that some emergency service recipients, notably PSAPs (Public Safety Answering Points) may prefer data provided by a network to data provided by an end system, because an end system could use false data to attack others or consume resources. While this has the consequence that the data available to the PSAP is often more coarse than that available to the end system, the risk of false data being provided involves a risk to the lives of those targeted.

エンドシステムは偽のデータを使用して他のシステムを攻撃したりリソースを消費したりする可能性があるため、緊急サービスの受信者、特にPSAP（Public Safety Answering Point）は、エンドシステムが提供するデータよりもネットワークが提供するデータを好む場合があります。これは、PSAPで利用可能なデータがエンドシステムで利用可能なデータよりも粗いことが多いという結果をもたらしますが、誤ったデータが提供されるリスクには、対象となる人々の生活へのリスクが伴います。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.

[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.

[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.

[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/info/rfc7624>.

[RFC7624] Barnes、R.、Schneier、B.、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C。、およびD. Borkmann、「広範囲にわたる監視に直面した場合の機密性：脅威モデルand Problem Statement」、RFC 7624、DOI 10.17487 / RFC7624、2015年8月、<http://www.rfc-editor.org/info/rfc7624>。

8.2. Informative References

8.2. 参考引用

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.

[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。

[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>.

[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<http：// www.rfc-editor.org/info/rfc6891>。

[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, DOI 10.17487/RFC7239, June 2014, <http://www.rfc-editor.org/info/rfc7239>.

[RFC7239] Petersson、A。およびM. Nilsson、「Forwarded HTTP Extension」、RFC 7239、DOI 10.17487 / RFC7239、2014年6月、<http://www.rfc-editor.org/info/rfc7239>。

[RFC7687] Farrell, S., Wenning, R., Bos, B., Blanchet, M., and H. Tschofenig, "Report from the Strengthening the Internet (STRINT) Workshop", RFC 7687, DOI 10.17487/RFC7687, December 2015, <http://www.rfc-editor.org/info/rfc7687>.

[RFC7687] Farrell、S.、Wenning、R.、Bos、B.、Blanchet、M。、およびH. Tschofenig、「Reporting the Strengthening the Internet（STRINT）Workshop」、RFC 7687、DOI 10.17487 / RFC7687、12月2015、<http://www.rfc-editor.org/info/rfc7687>。

[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <http://www.rfc-editor.org/info/rfc7871>.

[RFC7871] Contavalli、C.、van der Gaast、W.、Lawrence、D。、およびW. Kumari、「DNSクエリのクライアントサブネット」、RFC 7871、DOI 10.17487 / RFC7871、2016年5月、<http：// www .rfc-editor.org / info / rfc7871>。

Acknowledgements

謝辞

This document is derived in part from the work initially done on the perpass mailing list and at the STRINT workshop [RFC7687]. The text was originally developed by the IAB's Privacy and Security Program before submission to the IETF. The document also benefited from an extensive review by Mohamed Boucadair.

この文書の一部は、最初にperpassメーリングリストとSTRINTワークショップ[RFC7687]で行われた作業から派生しています。このテキストは、IETFに提出する前に、IABのプライバシーおよびセキュリティプログラムによって最初に開発されました。この文書は、Mohamed Boucadairによる広範なレビューからも恩恵を受けました。

Author's Address

著者のアドレス

Ted Hardie

テッド・ハーディ

   Email: ted.ietf@gmail.com