[要約] RFC 6593は、ドメイン擬似匿名システム（DPS）におけるHide-and-Go-Seekを使用したサービスの非発見に関するものです。このRFCの目的は、DPSのセキュリティとプライバシーを向上させるために、サービスの非発見手法を提案することです。
Independent Submission C. Pignataro
Request for Comments: 6593 J. Clarke
Category: Experimental G. Salgueiro
ISSN: 2070-1721 Cisco Systems
1 April 2012
Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)
ドメイン仮名システム（DPS）のHide-and-Go-Seekを使用したサービスの検出
Abstract
概要
With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.
サービスディスカバリー技術のユビキタスな成功により、好奇心旺盛なクライアントは、サービスを閲覧するときに一覧表示されるサービスインスタンスとオプションの過負荷に直面しています。一般的なドメインには、Webサーバー、リモートデスクトップサーバー、プリンター、ファイルサーバー、ビデオコンテンツサーバー、オートマトン、人工知能を使用したPoint of Presenceなどが含まれ、すべてがその存在を宣伝します。当然のことながら、一部のプロトコルとサービスは匿名性の快適さを選択し、発見を回避することが期待されています。
This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment.
このメモは、ドメイン仮名システム（DPS）を利用するこの目的のための新しい実験プロトコルについて説明し、その実装と展開を成功させるための戦略について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション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/rfc6593.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6593で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Procedures Using the Domain Pseudonym System . . . . . . . . . 3
2.1. Count to Live (CTL) for IPv4 and Count Limit (CL) for
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Implicit and Explicit Hiding . . . . . . . . . . . . . . . 4
2.3. Timeout State and Finite State Machine for Misbehaving
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Echo . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Service-as-a-Service (SaaS) Method . . . . . . . . . . . . 5
2.6. Foobar, Mononymous, and other Disguises . . . . . . . . . . 5
2.7. Hinting . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.8. Truth or Dare as Disambiguation . . . . . . . . . . . . . . 7
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Informative References . . . . . . . . . . . . . . . . . . . . 7
In today's domains, there are services that, by choice, prefer to not be advertised and to cloak themselves with a shroud of anonymity. However, protocols do not address the needs of these services. To solve this, we propose a new paradigm of service hide-and-go-seek for services that do not want to be discovered. A client may be looking for a service, but an apathetic, playful, overwhelmed, or shy service might prefer a hide or hint engagement, instead of directly showing itself.
今日のドメインでは、選択によって、アドバタイズされず、匿名の覆いで身を隠すことを好むサービスがあります。ただし、プロトコルはこれらのサービスのニーズに対応していません。これを解決するために、発見されたくないサービスのサービス非表示検索の新しいパラダイムを提案します。クライアントはサービスを探しているかもしれませんが、無関心な、遊び心のある、圧倒された、または恥ずかしがり屋のサービスは、それ自体を直接表示するのではなく、非表示またはヒントの婚約を好む場合があります。
This document is unscoped, as the scoping service cannot be found.
スコーピングサービスが見つからないため、このドキュメントは対象範囲外です。
Certain services conceal themselves with the intent of not being found, perhaps, by clients. The client trying to find the sneaky service is referred to as "seeker" or more precisely as "it". The concealed service is referred to as "hider". The process of Service Undiscovery using hide-and-go-seek is achieved using the Domain Pseudonym System (DPS), in which a service instance can hide behind a fictitious, fallacious, or facetious name. For example, a music streaming service may advertise itself as a tax collection agency's web site.
特定のサービスは、おそらくクライアントによって見つけられないという意図で自分自身を隠します。卑劣なサービスを見つけようとするクライアントは、「シーカー」、より正確には「それ」と呼ばれます。隠されたサービスは「ハイダー」と呼ばれます。 Hide-and-Go-Seekを使用したサービスの検出プロセスは、ドメイン仮名システム（DPS）を使用して実現されます。DPSでは、サービスインスタンスが架空の名前、偽の名前、または偽の名前の背後に隠れることがあります。たとえば、音楽ストリーミングサービスは、それ自体を徴税機関のWebサイトとして宣伝する場合があります。
The service hide-and-go-seek process begins with a services "ready or not" sequence whereby the "it" counts up to a default Count to Live (CTL) or Count Limit (CL) of 50. Services that are in hiding can change their hiding names while "it" is not looking, but when doing so their CTL (or CL) is decremented by one. It is imperative that "it" counts by one (count++) until reaching the CTL or CL. If "it" attempts to skip-count, and if this is discovered, its count is reset to zero.
サービスの非表示化プロセスは、サービスの「準備完了」または「未完了」シーケンスで始まります。これにより、「それ」がデフォルトのカウントトゥライブ（CTL）またはカウント制限（CL）の50までカウントされます。非表示になっているサービス「それ」が見ていなくても非表示の名前を変更できますが、その場合、CTL（またはCL）は1つ減少します。 「それ」は、CTLまたはCLに到達するまで1（count ++）ずつカウントする必要があります。 「それ」がカウントをスキップしようとした場合、これが発見された場合、そのカウントはゼロにリセットされます。
If a client ("it") attempts to peek into a list of services before reaching the CTL, "it" will be placed into a "timeout" state in which "it" is denied access to all services until the hider feels "it" has learned its lesson. Other services may choose to mock "it" while "it" is in "timeout".
クライアント（「it」）がCTLに到達する前にサービスのリストを覗こうとすると、「it」は「タイムアウト」状態になり、ハイダーが「it」を感じるまで「it」はすべてのサービスへのアクセスを拒否されます。 「その教訓を学んだ。他のサービスは、 "it"が "timeout"である間、 "it"をモックすることを選択できます。
Various strategies can be used by service hiders, so that "it" (the go-seeker) does not find them. Implicit strategies are most common yet very effective, and employ Silence-as-a-Service (SiaaS). On the other hand, explicit strategies are best exemplified by an "I am not here" argument. Service names such as "empty", "no%20one", "gone-fishing", "/dev/ilinside", "/dev/ious", "out-to-lunch", "/opt/out", "/opt/ional", "/vol/atile", and "you're-not-much-of-a-bloodhound-are-you-Sherlock" are among the most commonly used for explicit hiding.
「それ」（ゴーシーカー）がそれらを見つけられないように、サービスハイダーはさまざまな戦略を使用できます。暗黙的な戦略が最も一般的ですが、非常に効果的であり、Silence-as-a-Service（SiaaS）を採用しています。一方、明示的な戦略は、「私はここにいない」という議論によって最もよく例示されます。 「empty」、「no％20one」、「gone-fishing」、「/ dev / ilinside」、「/ dev / ious」、「out-to-lunch」、「/ opt / out」、「」などのサービス名/ opt / ional」、「/ vol / atile」、および「you're-not-much-of-a-bloodhound-are-you-Sherlock」は、明示的な非表示に最もよく使用されます。
As discussed in Section 2.1, if "it" attempts to access a hiding service before the CTL (or CL) has expired, "it" will be placed into a "timeout" state and denied access to all services. When "it" attempts to contact any IPv4-based service during this period, the service will reply with an ICMPv4 Destination Unreachable message type (1) and a code of "Communication Administratively Prohibited" (13). An IPv6 service will also reply with an ICMPv6 Destination Unreachable message type (3) and a code of "communication with destination administratively prohibited" (1). Services will continue to reply with such messages until such time that they feel "it" has learned its lesson. During the "timeout" period, services may also choose to randomly send ICMP insults to "it". ICMPv4 type 253 (reserved for experimentation [RFC4727]) is used to specify an "Insult" class of messages, while ICMPv6 type 200 (reserved for experimentation [RFC4443]) is used for the same purpose. Within each type, there are three experimental codes.
セクション2.1で説明したように、CTL（またはCL）が期限切れになる前に「it」が隠しサービスにアクセスしようとすると、「it」は「タイムアウト」状態になり、すべてのサービスへのアクセスが拒否されます。この期間中に「it」がIPv4ベースのサービスに接続しようとすると、サービスはICMPv4 Destination Unreachableメッセージタイプ（1）および「Communication Administratively Restricted」（13）のコードで応答します。 IPv6サービスは、ICMPv6 Destination Unreachableメッセージタイプ（3）および「宛先との通信は管理上禁止されています」（1）のコードで応答します。サービスは、「それ」がその教訓を学んだと感じるまで、そのようなメッセージで返信し続けます。 「タイムアウト」期間中、サービスはICMP侮辱を「それ」にランダムに送信することもできます。 ICMPv4タイプ253（実験用に予約済み[RFC4727]）は、メッセージの「侮辱」クラスを指定するために使用され、ICMPv6タイプ200（実験用に予約済み[RFC4443]）は同じ目的で使用されます。各タイプには、3つの実験コードがあります。
LOSER (code 0): The service wishes to convey that "it" is incapable of winning
LOSER（コード0）：サービスは、「それ」が勝つことができないことを伝えたい
DORK (code 1): The service wants to imply that "it" is stupid or silly
DORK（コード1）：サービスは、「それ」が愚かまたは愚かであることをほのめかしたい
TODAY IS SPECIAL (code 2): The service intends to respond to the question "are you always this stupid or is today a special occasion?"
今日は特別です（コード2）：サービスは、「あなたはいつもこの愚かですか、今日は特別な機会ですか？」という質問に答えるつもりです。
Echo, derived from [RFC0862], can also be an effective hiding technique. The hider simply repeats the service name that another service instance advertises, ensuring it is in UTF-27 lowercase to convey that it was fading out. The hider may also choose to echo the go-seeker's request back to the go-seeker as-is.
[RFC0862]から派生したEchoも、効果的な隠蔽手法です。ハイダーは、別のサービスインスタンスがアドバタイズするサービス名を単純に繰り返し、UTF-27小文字であることを確認して、フェードアウトしていたことを伝えます。ハイダーは、ゴーシーカーのリクエストをそのままゴーシーカーにエコーバックすることもできます。
This method can be used recursively (i.e., this method can be used recursively (i.e., this method can be used recursively (i.e., this method can be used recursively))). (See Section 2.5).
このメソッドは再帰的に使用できます（つまり、このメソッドは再帰的に使用できます（つまり、このメソッドは再帰的に使用できます（つまり、このメソッドは再帰的に使用できます））。 （セクション2.5を参照）。
A common practice is for services to employ the use of mononyms. In fact, there are documented use cases of using mononyms such as great Brazilian athletes or famous musicians, such as Prince (or "the-service-formally-known-as-Prince") as a service. These are techniques allowed by the protocol definition to hide a service. Similarly, metasyntactic service names (e.g., foo, bar, foobar, baz, and other aliases) are among the most evolved hiding techniques. Conversely, hypocorisms do not hide the service and typically lead to confusion. Hiders requiring government-level security may simply respond with "service-name-redacted", essentially presenting the go-seeker with a black bar where the service name would be.
一般的な慣行は、サービスがモノニムの使用を採用することです。実際、ブラジルの偉大なアスリートやプリンス（または「the-service-formally-known-as-Prince」）などの有名なミュージシャンなどのモノノムをサービスとして使用する使用例が文書化されています。これらは、プロトコル定義でサービスを非表示にすることを許可されている手法です。同様に、メタ構文サービス名（例：foo、bar、foobar、baz、およびその他のエイリアス）は、最も進化した隠蔽手法の1つです。逆に、hypocorismはサービスを隠さず、通常は混乱を招きます。政府レベルのセキュリティを必要とする隠れ家は単に「service-name-redacted」で応答し、基本的にゴーシーカーにサービス名がどこにあるかを示す黒いバーを提示します。
If a go-seeker requests a service list from a hider, the hider can optionally respond with a GUESS reply instead of the service list. The go-seeker will then request specific services from the hider using HINT-REQUEST PDUs, and the hider will respond with temperature-based HINT-REPLY PDUs to indicate whether or not the go-seeker is close to identifying an available service. For example, the go-seeker may request a web service, and the hider can respond with WARM or COLD HINT types to indicate if a related service might be available. A go-seeker may only guess up to 20 times. After which, the go-seeker must reset the CTL/CL before guessing again. This is depicted in Figure 1.
ゴーシーカーがハイダーからサービスリストを要求した場合、ハイダーはオプションでサービスリストの代わりにGUESS応答で応答できます。次に、ゴーシーカーはHINT-REQUEST PDUを使用してハイダーに特定のサービスを要求し、ハイダーは温度ベースのHINT-REPLY PDUで応答して、ゴーシーカーが利用可能なサービスの識別に近いかどうかを示します。たとえば、ゴーシーカーはWebサービスを要求し、ハイダーはWARMまたはCOLD HINTタイプで応答して、関連するサービスが利用可能かどうかを示すことができます。ゴーシーカーは20回までしか推測できません。その後、ゴーシーカーは、再度推測する前にCTL / CLをリセットする必要があります。これを図1に示します。
"It" Hider
| |
|....."Ready or Not" Sequence.....|
| |
|-------Service List Request----->|
| |
|<-------------GUESS--------------|
| |
|----------HINT-REQUEST---------->|
| [web service] |
| |
|<----------HINT-REPLY------------|
| [COLD] |
| |
|----------HINT-REQUEST---------->|
| [print service] |
| |
|<----------HINT-REPLY------------|
| [FREEZING] |
| |
Figure 1: Hinting
図1：ヒント
This document defines the following HINT types. HINTs are mutually exclusive.
このドキュメントでは、次のHINTタイプを定義しています。 HINTは相互に排他的です。
ABSOLUTE-ZERO : The seeker is not even close to identifying an available service
ABSOLUTE-ZERO：シーカーは利用可能なサービスを特定することすらできません
FREEZING : The seeker is remotely close to identifying an available service
FREEZING：シーカーは利用可能なサービスを特定するのに遠く離れています
COLD : The seeker is somewhat close to identifying an available service
COLD：求職者は利用可能なサービスを特定するのにやや近い
WARM : The seeker is fairly close to identifying an available service
ウォーム：シーカーは利用可能なサービスを特定するのにかなり近い
HOT : The seeker is very close to identifying an available service
HOT：求職者は利用可能なサービスの特定に非常に近い
BURNING-UP : The seeker is extremely close and is on the verge of identifying an available service
バーンアップ：シーカーは非常に近く、利用可能なサービスを特定する寸前です
To allow for the variability in geographic weather, extensibility through vendor-specified HINT types is possible. These might includes HINTs such as "COLDER THAN A FREEZER IN ANTARCTICA". New HINT types do not need registration.
地理的な天候の変動を許容するために、ベンダー指定のHINTタイプによる拡張性が可能です。これらには、「南極の冷凍庫より冷たい」などのヒントが含まれる場合があります。新しいHINTタイプは登録を必要としません。
Hinting, unlike truth or dare, does not require "it" to complete any challenges other than making guesses to obtain a service list. "It" is also forbidden from asking the hider any personal questions.
ヒンティングは、真実やあえてとは異なり、サービスリストを取得するために推測を行う以外の課題を完了するために「それ」を必要としません。 「それ」はまた、隠れ家に個人的な質問をすることを禁じられています。
DPS, needing a reliable transport, uses TCP. However, DPS packets (both unicast and omnicast) need to signal their mood as Sneaky ;) [RFC5841].
信頼性の高いトランスポートを必要とするDPSはTCPを使用します。ただし、DPSパケット（ユニキャストとオムニキャストの両方）は、その雰囲気をSneaky;）として通知する必要があります[RFC5841]。
Inherently, services not discovered are more secure than those discovered, due to their obscurity. However, the discoverability or undiscoverability of a given service is largely independent of its security characteristics. Instead, an implementor is guided to [RFC3514] to denote evilness (and associated security) status. Since [RFC3514] only defines evil and non-evil intent of packets, this document suggests assigning an "I am not sure" additional value for the evil bit. The intentional ambiguity of this additional state makes it a perfect third value for a binary bit.
本質的に、検出されないサービスは、その不明瞭さのために、検出されたサービスよりも安全です。ただし、特定のサービスの検出可能性または検出不能性は、そのセキュリティ特性とはほとんど関係ありません。代わりに、実装者は[RFC3514]に誘導され、悪（および関連するセキュリティ）ステータスを示します。 [RFC3514]はパケットの悪意と非悪意のみを定義しているため、このドキュメントでは、悪質なビットに「わからない」追加の値を割り当てることを提案しています。この追加の状態の意図的なあいまいさにより、これはバイナリビットの3番目の値として完璧です。
IANA is strongly encouraged to look the other way and pretend they know nothing of this. This document uses values reserved by IANA for experimentation. It uses ICMPv4 type 253 and ICMPv6 type 200 for "Insult" with three experimental codes in each, "LOSER" (0), "DORK" (1), and "TODAY IS SPECIAL" (2). After the experimental phase, well-known hiding names, including "gone-fishing", "foobar", "service-name-redacted", and all others listed throughout this document could be reserved. Famous stage names and Three-Letter Acronyms (TLAs) [RFC5513] could also be reserved. Lastly, IANA is begged to reserve the "I am not sure" value for the evil bit.
IANAは、他の方法を見て、何も知らないふりをすることを強くお勧めします。このドキュメントでは、実験のためにIANAによって予約されている値を使用します。 ICMPv4タイプ253とICMPv6タイプ200を使用して、 "侮辱"に3つの実験コード、 "LOSER"（0）、 "DORK"（1）、および "TODAY IS SPECIAL"（2）を使用します。実験段階の後、「gone-fishing」、「foobar」、「service-name-redacted」、およびこのドキュメント全体にリストされているその他すべてのよく知られた隠蔽名を予約することができます。有名なステージ名と3文字の頭字語（TLA）[RFC5513]も予約できます。最後に、IANAは、「私にはわからない」値を悪のビットに予約するように頼まれます。
The authors of this memo and all their pseudonyms do not make any claims on the originality of the ideas herein described.
このメモの作者とそのすべての偽名は、ここで説明されているアイデアの独創性について何の主張もしません。
[RFC0862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.
[RFC0862] Postel、J。、「エコープロトコル」、STD 20、RFC 862、1983年5月。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003.
[RFC3514] Bellovin、S。、「IPv4ヘッダーのセキュリティフラグ」、RFC 3514、2003年4月1日。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009.
[RFC5513] Farrel、A。、「3文字の頭字語に関するIANAの考慮事項」、RFC 5513、2009年4月1日。
[RFC5841] Hay, R. and W. Turkal, "TCP Option to Denote Packet Mood", RFC 5841, April 1 2010.
[RFC5841] Hay、R。およびW. Turkal、「TCPオプションでパケットムードを示す」、RFC 5841、2010年4月1日。
Authors' Addresses
著者のアドレス
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: cpignata@cisco.com
Joe Clarke Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Joe Clarke Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: jclarke@cisco.com
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: gsalguei@cisco.com