doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc7304.txt b/doc/rfc/rfc7304.txt
new file mode 100644
index 0000000..5cc47b5
--- /dev/null
+++ b/doc/rfc/rfc7304.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Independent Submission                                         W. Kumari
+Request for Comments: 7304                                        Google
+Category: Informational                                        July 2014
+ISSN: 2070-1721
+
+
+              A Method for Mitigating Namespace Collisions
+
+Abstract
+
+   This document outlines a possible, but not recommended, method to
+   mitigate the effect of collisions in the DNS namespace by providing a
+   means for end users to disambiguate the conflict.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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/rfc7304.
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+
+
+
+
+
+
+
+
+
+Kumari                        Informational                     [Page 1]
+
+RFC 7304                DNS Collision Mitigation               July 2014
+
+
+Table of Contents
+
+   1.  Introduction/Background . . . . . . . . . . . . . . . . . . .   2
+   2.  Mitigation  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  Implementation/Disclaimers  . . . . . . . . . . . . . . . . .   3
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
+
+1.  Introduction/Background
+
+   Collisions in the DNS occur in multiple ways.  One common case is
+   that an organization has used a subdomain (foo) of its primary domain
+   (example.com) for corporate infrastructure, and then the string 'foo'
+   is delegated as a Top-Level Domain (TLD).  When an employee of the
+   organization enters 'www.foo', is the goal to reach a machine in the
+   internal namespace (www.foo.example.com) or the hostname 'www' in the
+   'foo' TLD?
+
+   This document describes a means of disambiguating this and similar
+   cases.
+
+   Implementation of this method is not recommended; it is documented
+   here to explain some of the pitfalls with such an approach.
+
+2.  Mitigation
+
+   The mitigation described in this document involves presenting
+   multiple options to the user and allowing them to indicate which of
+   the names is the one they are trying to reach.
+
+   The mitigation would look up the name in multiple namespaces.  If a
+   conflict is detected, it would then provide a means for the user to
+   indicate which one of the colliding names they wish to connect to,
+   and return the disambiguated answer to the application.  An
+   additional feature of mitigation could be to cache the user's choice
+   and/or provide a means to set priorities.
+
+   This could be accomplished in a number of ways, including:
+
+   o  Intercepting the resolution requests from the application in a
+      "shim" type library
+
+   o  Replacing the resolver library entirely
+
+   o  Integrating this type of mitigation into applications (some web
+      browsers already do something similar to this)
+
+
+
+
+
+Kumari                        Informational                     [Page 2]
+
+RFC 7304                DNS Collision Mitigation               July 2014
+
+
+   o  Proxying the request to a server that provides an interstitial
+      page that allows the user to indicate the intended name (for
+      applications such as HTTP)
+
+   There are a number of issues with this solution, including but not
+   limited to:
+
+   o  There may not be a human available to disambiguate the answer
+      (unattended machines, mail servers, etc.).
+
+   o  The human/user may have no idea which is the correct choice,
+      especially in the case of a phishing attack or other malicious
+      intent.
+
+   o  The additional latency introduced may cause the originating
+      application to time out.
+
+   o  The experience would be time consuming for users as they must
+      select each site and subsite intended (e.g., www.intranet,
+      images.intranet, etc.).
+
+   o  Caching the responses could lead to problems when the user changes
+      location (internal sites would fail when offsite or otherwise lead
+      to incorrect sites being loaded).
+
+   For these and other reasons, implementation of this technique is not
+   recommended.
+
+3.  Implementation/Disclaimers
+
+   This document does not reference an implementation.  Due to the
+   numerous issues described above, we do not recommend that this
+   solution be implemented.  This is a very slight mitigation, and we do
+   not recommend that it be viewed as a solution to the namespace
+   collision problem.
+
+4.  Security Considerations
+
+   While this method may make some users more aware of which version of
+   a name they are going to use (and so careful users may avoid some
+   phishing attacks), the security risks described above outweigh this
+   potential benefit.
+
+   There are numerous security implications in this approach, including
+   leaking internal names (e.g., secret-project.corp.example.com), users
+   being tricked into selecting the incorrect choice when trying to
+   disambiguate answers, etc.
+
+
+
+
+Kumari                        Informational                     [Page 3]
+
+RFC 7304                DNS Collision Mitigation               July 2014
+
+
+   For these reasons, it is not recommended that this solution be
+   deployed.
+
+5.  Acknowledgements
+
+   The author wishes to thank the following individuals: Fred Baker, Bob
+   Braden, Carsten Bormann, Nevil Brownlee, Eric Burger, Brian
+   Carpenter, Benoit Claise, Keith Drage, Martin J. Duerst, David
+   Harrington, Paul Hoffamn, John Levine, and Ted Lemon.
+
+Author's Address
+
+   Warren Kumari
+   Google
+   1600 Amphitheatre Parkway
+   Mountain View, CA  94043
+   US
+
+   EMail: warren@kumari.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumari                        Informational                     [Page 4]
+