Independent Submission C. Pignataro
Request for Comments: 6593 J. Clarke
Category: Experimental G. Salgueiro
ISSN: 2070-1721 Cisco Systems
1 April 2012
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）的隐藏搜索进行服务发现
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服务器、远程桌面服务器、打印机、文件服务器、视频内容服务器、自动机、使用人工智能的存在点等，所有这些都在宣传它们的存在。不出所料，一些协议和服务会选择匿名，避免被发现。
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.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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
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.
某些服务隐藏自己，可能是为了不被客户发现。试图找到偷偷摸摸的服务的客户被称为“搜索者”，或者更准确地说是“it”。隐蔽服务被称为“隐藏”。使用hide-and-go-seek进行服务秘密发现的过程是使用域假名系统（DPS）实现的，在该系统中，服务实例可以隐藏在虚构、错误或滑稽的名称后面。例如，音乐流媒体服务可能会将自己宣传为税收机构的网站。
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.
服务隐藏和查找过程以服务“就绪或未就绪”序列开始，“it”计数最多为默认生存计数（CTL）或计数限制（CL）50。处于隐藏状态的服务可以在“it”不查看时更改其隐藏名称，但这样做时，它们的CTL（或CL）将减少1。在到达CTL或CL之前，“It”必须计数1（计数++）。如果“It”试图跳过计数，并且如果发现此情况，其计数将重置为零。
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”处于“超时”状态时，其他服务可能会选择模拟“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.
服务隐藏者可以使用各种策略，以便“it”（搜索者）无法找到它们。隐式策略是最常见但非常有效的策略，并且使用沉默即服务（SiaaS）。另一方面，明确的策略最好用“我不在这里”的论点来说明。诸如“empty”、“no%20one”、“gone fishing”、“gone fishing”、“/dev/ilinside”、“out to sunch”、“out to sunch”、“opt/out”、“national”、“vol/atile”和“you-not-of-a-hound-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节所述，如果“it”试图在CTL（或CL）过期之前访问隐藏服务，“it”将进入“超时”状态，并拒绝访问所有服务。当“it”在此期间尝试联系任何基于IPv4的服务时，该服务将使用ICMPv4目标不可访问消息类型（1）和“通信管理禁止”代码（13）进行回复。IPv6服务还将使用ICMPv6目的地不可访问消息类型（3）和代码“与目的地的通信管理禁止”（1）进行回复。服务部门将继续回复此类消息，直到他们感觉“it”吸取了教训。在“超时”期间，服务还可以选择随机向“it”发送ICMP侮辱。ICMPv4类型253（保留用于实验[RFC4727]）用于指定消息的“侮辱”类别，而ICMPv6类型200（保留用于实验[RFC4443]）用于相同目的。在每种类型中，有三种实验代码。
LOSER (code 0): The service wishes to convey that "it" is incapable of winning
失败者（代码0）：服务希望传达“它”无法获胜
DORK (code 1): The service wants to imply that "it" is stupid or silly
DORK（代码1）：该服务想要暗示“it”是愚蠢或愚蠢的
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]的回波也可以是一种有效的隐藏技术。隐藏器只是重复另一个服务实例发布的服务名称，确保它使用UTF-27小写字母表示它正在淡出。隐藏者也可以选择按原样将go-seeker的请求回显给go-seeker。
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.
一种常见的做法是服务使用单音词。事实上，有记录在案的使用单名词的案例，如伟大的巴西运动员或著名音乐家，如Prince（或“正式称为Prince的服务”）作为服务。协议定义允许使用这些技术隐藏服务。类似地，元语法服务名称（例如，foo、bar、foobar、baz和其他别名）也是最先进的隐藏技术之一。相反，hypoorism不会隐藏服务，通常会导致混淆。需要政府级安全的隐藏者可以简单地用“服务名称编辑”来响应，本质上是在服务名称所在的位置为go-seeker提供一个黑条。
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.
如果go-seeker向隐藏者请求服务列表，隐藏者可以选择使用猜测回复而不是服务列表进行响应。然后，go-seeker将使用提示请求PDU从hider请求特定服务，hider将使用基于温度的提示回复PDU进行响应，以指示go-seeker是否接近识别可用服务。例如，go-seeker可能会请求web服务，而hider可以使用温暖或寒冷提示类型进行响应，以指示相关服务是否可用。探索者最多只能猜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] |
| |
"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.
本文档定义了以下提示类型。暗示是相互排斥的。
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
燃烧：导引头离目标非常近，接近确定可用服务的边缘
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.
为了考虑地理气候的变化，可以通过供应商指定的提示类型进行扩展。这些可能包括诸如“比南极洲的冰柜还冷”之类的暗示。新的提示类型不需要注册。
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”来完成任何挑战，只需要通过猜测来获得服务列表。“它”也被禁止问隐藏者任何私人问题。
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数据包（单播和全播）需要将其情绪表示为鬼鬼祟祟的；）[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]仅定义数据包的邪恶和非邪恶意图，因此本文档建议为邪恶位分配一个“我不确定”附加值。这个附加状态的故意歧义使得它成为二进制位的完美第三个值。
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来表示“侮辱”，每个代码中有三个实验代码，“失败者”（0）、“呆子”（1）和“今天是特别的”（2）。在实验阶段之后，可以保留著名的隐藏名称，包括“Goe fishing”、“foobar”、“服务名称已编辑”以及本文档中列出的所有其他名称。著名的舞台名称和三字母缩写（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，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，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.，“三字母首字母缩写词的IANA考虑”，RFC5513，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 58412010年4月1日。
Authors' Addresses
作者地址
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
卡洛斯·皮格纳塔罗思科系统7200-12美国北卡罗来纳州基特克里克路研究三角公园，邮编27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Joe Clarke Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
乔·克拉克思科系统7200-12美国北卡罗来纳州基特克里克路研究三角公园，邮编27709
EMail: jclarke@cisco.com
EMail: jclarke@cisco.com
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Gonzalo Salgueiro思科系统7200-12美国北卡罗来纳州Kit Creek Road研究三角公园，邮编27709
EMail: gsalguei@cisco.com
EMail: gsalguei@cisco.com