はじめに
- この文書は RFC6593 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) （ドメイン偽名システムの Hide-and-Go-Seek を使用したサービスの隠ぺい）
- Independent Submission
- Request for Comments: 6593
- Category: Experimental
- ISSN: 2070-1721
- C. Pignataro
- J. Clarke
- G. Salgueiro
- Cisco Systems
- 1 April 2012
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.
サービス発見技術の普及に伴い、好奇心旺盛なクライアントは、サービスを探す際に表示されるサービスインスタンスやオプションの過負荷に直面することが多くなっている。
典型的なドメインには、ウェブサーバー、リモートデスクトップサーバー、プリンター、ファイルサーバー、ビデオコンテンツサーバー、オートマトン、人工知能を使った PoP (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.
このメモでは、ドメイン偽名システム (Domain Pseudonym System; DPS) を利用した、この目的のための新しい実験的プロトコルを説明し、その実装と展開を成功させるための戦略について論じる。
Status of This Memo（このメモの位置づけ）
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
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.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.
この文書はインターネット標準化過程の仕様ではなく、検討、実験的な実装、評価のために公開されるものである。
この文書は、インターネットコミュニティのための実験的なプロトコルを定義する。
この文書は、他のいかなる RFC ストリームとも無関係に、RFC シリーズに貢献するものである。
RFC エディターは自らの裁量でこの文書の公開を選択し、その実装や配備の価値について何ら表明するものではない。
RFC エディターによって発行が承認された文書は、どのレベルのインターネット標準の候補にもならない。RFC 5741 の 2 章を参照のこと。
この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、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.
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.
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
1. Introduction（序論）
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.
今日のドメインでは、選択的に、広告されないこと、匿名であることを好むサービスが存在する。
しかし、プロトコルはこのようなサービスのニーズに対応していない。
これを解決するために、発見されたくないサービスのための新しいパラダイムであるサービス hide-and-go-seek（訳注：かくれんぼ）を提案する。
クライアントはあるサービスを探しているかもしれないが、無気力なサービス、遊び心のあるサービス、圧倒されるサービス、シャイなサービスは、直接姿を見せるのではなく、隠したり、ヒントを出したりする関わり方を好むかもしれない。
1.1. Scope（スコープ）
This document is unscoped, as the scoping service cannot be found.
この文書は、スコープサービスが見つからないため、スコープされていない。
2. Procedures Using the Domain Pseudonym System（ドメイン偽名システムを利用した手続き）
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.
ある種のサービスは、おそらくクライアントに見つからないように意図して、自分自身を隠すだろう。
卑劣なサービスを見つけようとするクライアントを「seeker（探索者）」、より正確には「it」と呼ぶ（訳注：かくれんぼの「鬼」のこと）。
隠されているサービスは「hider（潜伏者）」と呼ぶ。
hide-and-go-seek を利用したサービスの隠ぺいのプロセスは、ドメイン偽名システム（DPS）を利用して実現され、サービスインスタンスは架空の、虚偽の、あるいは剽窃的な名前の後ろに隠れることができる。
例えば、音楽ストリーミングサービスは、税金の徴収機関のウェブサイトとして宣伝することができる。
2.1. Count to Live (CTL) for IPv4 and Count Limit (CL) for IPv6（IPv4 の CTL と IPv6 の CL）
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.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".
hide-and-go-seek サービスは、サービスの「ready or not」（もーいいかい？）シーケンスから始まり、「it」はデフォルトの CTL (Count to Live) または CL (Count Limit) である 50 までカウントアップする。
潜伏中のサービスは、「it」が見ていない間に潜伏名を変更することができる、そうすると、その CTL (または CL) は1つ減らされる。
「it」は CTL または CL に到達するまで1つずつカウントする (count++) ことが必要不可欠である。
「it」がカウントを飛ばそうとし、それが発見された場合、そのカウントはゼロにリセットされる。
もしクライアント(「it」)が CTL に到達する前にサービスのリストを覗こうとすると、「it」は「タイムアウト」状態になり、潜伏者は「it」が懲りたと思うまですべてのサービスへのアクセスが拒否される。
「it」が「timeout」になっている間、他のサービスは「it」を模倣することを選ぶかもしれない。
2.2. Implicit and Explicit Hiding（暗黙的と明示的な潜伏）
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.
サービス潜伏者は、「it」 (go-seeker; 「鬼」) に見つからないようにするために、様々な戦略を用いることができる。
暗黙的戦略は最も一般的でありながら非常に効果的であり、SiaaS (Silence-as-a-Service; 黙っていること) を採用することである。
一方、明示的戦略は、「私はここにいない」という主張が最も良い例である。
"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" などのサービス名は、最もよく明示的に隠れるために使われるものの一つである。
2.3. Timeout State and Finite State Machine for Misbehaving Clients（いたずらするクライアントのためのタイムアウト状態と有限状態マシン）
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)と「通信管理上禁止」(13) のコードで応答する。
また、IPv6 サービスでは、ICMPv6 Destination Unreachable メッセージタイプ(3)と「管理上禁止されている宛先との通信」(1) のコードで応答する。
サービスは、「it」が教訓を得たと感じるまで、このようなメッセージで応答し続ける。
「タイムアウト」期間中、サービスは「it」に対してランダムに ICMP 侮辱メッセージを送信することもできる。
ICMPv4 タイプ 253 (実験用に予約済み [RFC4727])はメッセージの「Insult」クラスを指定するために使用され、ICMPv6 タイプ 200 (実験用に予約済み [RFC4443])は同じ目的のために使用されている。
それぞれのタイプの中に、3 つの実験的なコードがある。
LOSER (code 0): The service wishes to convey that "it" is incapable of winning
DORK (code 1): The service wants to imply that "it" is stupid or silly
TODAY IS SPECIAL (code 2): The service intends to respond to the question "are you always this stupid or is today a special occasion?"
- LOSER (code 0): サービスは「it」が勝つことができないことを伝える
- DORK (code 1): サービスは「it」がバカまたはマヌケであることを暗示する
- TODAY IS SPECIAL (code 2): サービスは「あなたはいつもこれほど愚かなのか、それとも今日は特別なのか？」という質問に答えさせることを目的としている。
2.4. Echo
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 の小文字であることを保証する。
潜伏者は、「鬼」のリクエストをそのまま「鬼」にエコーバックすることを選択することもできる。
2.5. Service-as-a-Service (SaaS) Method
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 節参照)。
2.6. Foobar, Mononymous, and other Disguises（Foobar、単称、その他の変装）
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.
一般的に、サービスには１単語の名称 (mononym; 単称) の使用が採用される。
実際、ブラジルの偉大なスポーツ選手や有名なミュージシャン、例えばプリンス (または「the-service-formally-known-as-Prince」) のような単称をサービスとして使用する例が記録されている。
これらは、サービスを隠すためにプロトコル定義で認められている技術である。
同様に、メタ構文のサービス名 (例えば、foo、bar、foobar、baz、その他のエイリアス) は、最も進化した隠蔽技術の一つである。
逆に、短縮名 (愛称) はサービスを隠蔽せず、一般的に混乱を招く。
政府レベルのセキュリティを必要とする潜伏者は、単に "service-name-redacted" と応答し、本質的にサービス名があるべき場所に黒いバー（訳注：黒い塗りつぶし？）を 「鬼」に提示することがある。
2.7. Hinting（潜伏）
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 で応答して、「鬼」が利用できるサービスを特定するのに近づいたかどうかを示すことができる。
例えば、「鬼」はウェブサービスを要求し、ハイダーは 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
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
FREEZING : The seeker is remotely close to identifying an available service
COLD : The seeker is somewhat close to identifying an available service
WARM : The seeker is fairly close to identifying an available service
HOT : The seeker is very close to identifying an available service
BURNING-UP : The seeker is extremely close and is on the verge of identifying an available service
- ABSOLUTE-ZERO（絶対零度） : 利用可能なサービスを見つけることができない。
- FREEZING（凍っている） : 利用可能なサービスの特定にわずかに近づいている。
- COLD（冷たい） : 利用可能なサービスの特定にやや近い。
- WARM（暖かい） : 利用可能なサービスの特定にかなり近づいている。
- HOT（熱い） : 利用可能なサービスの特定に非常に近い。
- BURNING-UP（燃え上がる） : 利用可能なサービスの特定に非常に近づいており、その寸前である。
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 タイプによる拡張が可能である。
例えば、"COLDER THAN A FREEZER IN ANTARCTICA" のような HINT がある。
新しい HINT タイプの登録は必要ない。
2.8. Truth or Dare as Disambiguation（曖昧性解消のための「真実か挑戦」）
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.
ヒントは、「真実か挑戦」とは異なり、「it」はサービスリストを入手するために推測を行う以外に、何らかの課題をクリアする必要はない。
また、「it」は潜伏者に個人的な質問をすることは禁じられている。
3. Protocol Definition（プロトコルの定義）
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]。
4. Security Considerations（セキュリティに関する考慮事項）
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] ではパケットの悪意と非悪意を定義しているだけなので、この文書は Evil Bit に「よくわからない」という追加値を割り当てることを提案している。
この追加状態の意図的な曖昧さは、バイナリビットの第 3 の値として最適である。
5. IANA Considerations（IANA に関する考慮事項）
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 を使用し、それぞれ「LOSER」(0),「DORK」(1),「TODAY IS SPECIAL」(2) の 3 つの実験コードを使用する。
実験段階の後、「gone-fishing」、「foobar」、「service-name-redacted」などのよく知られた隠語や、この文書に記載されている他のすべての隠語が予約される可能性がある。
有名な芸名や3文字略語 (TLA) [RFC5513] も予約される可能性がある。
最後に、IANA には Evil Bit のための「よくわからない」値を予約するよう懇願する。
6. Acknowledgments（謝辞）
The authors of this memo and all their pseudonyms do not make any claims on the originality of the ideas herein described.
このメモの著者およびすべての偽名は、ここに記述されたアイデアのオリジナリティを主張するものではありません。
7. Informative References
[RFC0862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
[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.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5841] Hay, R. and W. Turkal, "TCP Option to Denote Packet Mood",
RFC 5841, April 1 2010.
Authors' Addresses
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
EMail: jclarke@cisco.com
Gonzalo Salgueiro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
EMail: gsalguei@cisco.com