wdiff rfc7304.original rfc7304.txt

Network Working Group
Independent Submission W. Kumari
Internet-Draft
Request for Comments: 7304 Google
Intended status:
Category: Informational November 22, 2013
Expires: May 26, July 2014
ISSN: 2070-1721

A method Method for mitigating namespace collisions
draft-wkumari-dnsop-defense-collision-mitigate-03 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 Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not a candidate for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list
Standard; see Section 2 of RFC 5741.

Information about the current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 26, 2014.
http://www.rfc-editor.org/info/rfc7304.

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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction / Background Introduction/Background . . . . . . . . . . . . . . . . . . . 2
2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Implementation / Disclaimers . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . Implementation/Disclaimers . . . . . . . . . . . . . . . . . 3
5.
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6.
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4

1. Introduction / Background Introduction/Background

Collisions in the DNS occur in multiple ways; one ways. One common case is
that an organization has used an sub-domain a subdomain (foo) of their its primary domain
(example.com) for corporate infrastructure, and then the string "foo" 'foo'
is delegated as a TLD. 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 these, this and similar
cases.

Implementation of these methods are this method is not recommended; they are it is documented
here to explain some of the pitfalls with approaches like
these. such an approach.

2. Mitigation

The mitigation described in this document involves presenting the
multiple options to the user, user and allowing them to indicate which of
the names is the one they were are trying to reach.

The mitigation would lookup look up the name in multiple namespaces. When if 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 for the mitigation to cache the user's
choice, and / or 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 entirelyT entirely

o Integrating this type of mitigation into applications (some web
browsers already do something similar to this)
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 requests) 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.) etc.).

o The human / user human/user may have no idea which is the correct choice,
especially in the case of a phishing attackor attack or other malicious
intent
intent.

o The additional latency introduced may cause the originating
application to time out out.

o The user experience would be time consuming to for users as they must
select each site and subsite intended (www.intranet, (e.g., www.intranet,
images.intranet, etc.) etc.).

o Caching the responses could lead to problems when the user changes
location (internal sites would fail when offsite, offsite or otherwise lead
to incorrect sites being loaded) loaded).

For these and other reasons, implementation of this technique is not
recommended.

3. Implementation / Disclaimers 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. We This is a very slight mitigation, and we do
not recommend that this it be viewed as a solution to the namespace
collision problem.

This is a very slight mitigation. It should not be viewed as a
solution to the "namespace collision" issue.

4. IANA Considerations

This document contains no IANA considerations.

5. 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 (secret-project.corp.example.com), (e.g., secret-project.corp.example.com), users
being tricked into selecting the incorrect choice when trying to
disambiguate answers, etc.

For these reasons, it is not recommended that this solution be
deployed.

5. Acknowledgements

The authors wish author wishes to thank some folk, including 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 Levine, and Ted Lemon,

7. References

Appendix A. Changes / Author Notes.

[RFC Editor: Please remove this section before publication.]

From -00 to -01.

o Nothing changed in the template.

from -01 to -02

o Rewrite. Less flippant.

From -02 to -03:

o Changed to Informational. Suggestion from ISE:"I see only one
remaining thing - you've changed its Intended Status to
Experimental. I think Informational would be better, since
'Experimental' implies that you have an implementation and are
publishing the document so that others can try it too. " Lemon.

Author's Address

Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US

Email:

EMail: warren@kumari.net