summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6593.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6593.txt')
-rw-r--r--doc/rfc/rfc6593.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6593.txt b/doc/rfc/rfc6593.txt
new file mode 100644
index 0000000..7b980e7
--- /dev/null
+++ b/doc/rfc/rfc6593.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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)
+
+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.
+
+ 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.
+
+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.
+
+
+
+
+
+
+
+
+
+Pignataro, et al. Experimental [Page 1]
+
+RFC 6593 Service Hide-and-Go-Seek 1 April 2012
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al. Experimental [Page 2]
+
+RFC 6593 Service Hide-and-Go-Seek 1 April 2012
+
+
+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.
+
+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.
+
+2.1. Count to Live (CTL) for IPv4 and Count Limit (CL) for IPv6
+
+ 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".
+
+
+
+
+
+
+
+
+Pignataro, et al. Experimental [Page 3]
+
+RFC 6593 Service Hide-and-Go-Seek 1 April 2012
+
+
+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.
+
+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.
+
+ 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?"
+
+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.
+
+
+
+
+Pignataro, et al. Experimental [Page 4]
+
+RFC 6593 Service Hide-and-Go-Seek 1 April 2012
+
+
+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.6. Foobar, Mononymous, and other Disguises
+
+ 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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al. Experimental [Page 5]
+
+RFC 6593 Service Hide-and-Go-Seek 1 April 2012
+
+
+ "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.
+
+ 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.
+
+
+
+Pignataro, et al. Experimental [Page 6]
+
+RFC 6593 Service Hide-and-Go-Seek 1 April 2012
+
+
+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.
+
+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].
+
+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.
+
+5. IANA Considerations
+
+ 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.
+
+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.
+
+
+
+Pignataro, et al. Experimental [Page 7]
+
+RFC 6593 Service Hide-and-Go-Seek 1 April 2012
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al. Experimental [Page 8]
+