Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)
RFC 6593

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]