Internet DRAFT - draft-grothoff-iesg-special-use-p2p-i2p
draft-grothoff-iesg-special-use-p2p-i2p
Internet Engineering Task Force C. Grothoff
Internet-Draft INRIA
Intended status: Informational M. Wachs
Expires: December 26, 2015 Technische Universitaet Muenchen
H. Wolf, Ed.
GNU consensus
J. Appelbaum
L. Ryge
Tor Project Inc.
June 30, 2015
Special-Use Domain Names for I2P
draft-grothoff-iesg-special-use-p2p-i2p-00
Abstract
This document registers a Special-Use Domain Name for use with the
I2P Peer-to-Peer system, as per RFC6761.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents 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 December 26, 2015.
Copyright Notice
Copyright (c) 2015 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. Code Components extracted from this document must
Grothoff, et al. Expires December 26, 2015 [Page 1]
Internet-Draft Special-Use I2P Names June 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Conventions Used in This Document . . . . . . 3
4. The "I2P" Addressbook pTLD . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Domain Name System (DNS) is primarily used to map human-memorable
names to IP addresses, which are used for routing but generally not
meaningful for humans.
The Invisible Internet Project (I2P) Peer-to-Peer (P2P) system uses a
specific decentralized mechanism to allocate, register, manage, and
resolve names. The I2P Name System operates entirely outside of DNS,
independently from the DNS root and delegation tree.
As compatibility with applications using domain names is desired, the
I2P overlay network defines an exclusive alternative Top-Level Domain
to avoid conflict between the I2P namespace and the DNS hierarchy.
In order to avoid interoperability issues with DNS as well as to
address security and privacy concerns, this document registers the
"I2P" Special-Use Domain Names for use with the I2P systems.
I2P uses this pTLD to realize fully-decentralized and censorship-
resistant naming.
2. Applicability
[RFC6761] Section 3 states:
"[I]f a domain name has special properties that affect the way
hardware and software implementations handle the name, that apply
universally regardless of what network the implementation may be
connected to, then that domain name may be a candidate for having
Grothoff, et al. Expires December 26, 2015 [Page 2]
Internet-Draft Special-Use I2P Names June 2015
the IETF declare it to be a Special-Use Domain Name and specify
what special treatment implementations should give to that name.
On the other hand, if declaring a given name to be special would
result in no change to any implementations, then that suggests
that the name may not be special in any material way, and it may
be more appropriate to use the existing DNS mechanisms [RFC1034]
to provide the desired delegation, data, or lack-of-data, for the
name in question. Where the desired behaviour can be achieved via
the existing domain name registration processes, that process
should be used. Reservation of a Special-Use Domain Name is not a
mechanism for circumventing normal domain name registration
processes."
The Special-Use Domain Name for the I2P System (pTLDs) reserved by
this document meets this requirement, as it has the following
specificities:
o The "I2P" pTLD is not manageable by some designated
administration. Instead, it is managed according to various
alternate strategies as described in the I2P documentation.
o The "I2P" pTLD does not depend on the DNS context for its
resolution. It uses I2P-specific logic for name resolution,
covered by the respective system documentation.
o To resolve "I2P" names, the implementation MUST intercept queries
for the pTLD to ensure I2P names cannot leak into the DNS.
o The appropriate resolution procedure can be implemented in
existing software libraries and APIs to extend regular DNS
operation and enable I2P name resolution. However, the default
hierarchical DNS response to any request to any pTLD MUST be
NXDOMAIN.
o Finally, in order to maximally protect the security and privacy
expectation of I2P users, this document specifies desirable
changes in existing DNS software and DNS operations.
3. Terminology and Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The word "peer" is used in the meaning of a individual system on the
network.
Grothoff, et al. Expires December 26, 2015 [Page 3]
Internet-Draft Special-Use I2P Names June 2015
The abbreviation "pTLD" is used in this document to mean a pseudo
Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761]
reserved to P2P Systems in this document. A pTLD is mentioned in
capitals, and within double quotes to mark the difference with a
regular DNS gTLD.
In this document, ".tld" (lowercase, with quotes) means: any domain
or hostname within the scope of a given pTLD, while .tld (lowercase,
without quotes) refers to an adjective form. For example, a
collection of ".i2p" peers in "I2P", but an .i2p URL. [TO REMOVE: in
the IANA Considerations section, we use the simple .tld format to
request TLD reservation for consistency with previous RFCs].
The word "NXDOMAIN" refers to an alternate expression for the "Name
Error" RCODE as described in section 4.1.1 of [RFC1035]. When
referring to "NXDOMAIN" and negative caching [RFC2308] response, this
document means an authoritative (AA=1) name error (RCODE=3) response
exclusively.
4. The "I2P" Addressbook pTLD
"I2P" provides accessibility to hidden services within the I2P
network [zzz2009]. I2P is a scalable, self-organizing, resilient
packet switched anonymous network layer, upon which any number of
different anonymity or security-conscious applications can operate,
using any protocol.
I2P hidden services and clients are identified by Destinations,
anonymous analogues of IP addresses. The "I2P" pTLD, chosen in 2003
[I2P-CHOICE], houses two methods for looking up Destinations:
A local table called the addressbook stores a map of .i2p
addresses to Destinations. Each user maintains their own mappings
that can be shared with others, allowing them to "discover" new
names by importing published addressbooks of peers, and they can
emulate traditional DNS by choosing to treat these peers as name
servers. The comparison however stops here, as only local
uniqueness is mandated. As the system is decentralized,
"example.i2p" may resolve differently for different peers
depending on the state of their respective addressbooks.
To address globally unique names, the I2P developers dedicated the
"B32.I2P" subdomain to hold Base32-encoded [RFC4648] references to
Destinations. Like .onion addresses, .b32.i2p addresses are self-
authenticating. The details of the encoding are out of scope for
this document, and documented in [I2P-NAMING]. The purpose of
.b32.i2p addresses is similar to ".zkey", that is to enable
Grothoff, et al. Expires December 26, 2015 [Page 4]
Internet-Draft Special-Use I2P Names June 2015
(reverse) mapping for a globally unique hidden service that may
not have a defined entry in the local addressbook.
The "I2P" domain is special in the following ways:
1. Users can use these names as they would other domain names,
entering them anywhere that they would otherwise enter a
conventional DNS domain name.
Since there is no central authority responsible for assigning
.i2p names, and that the ultimate mapping is decided by the local
peer, users need to be aware of that specificity.
2. Application software SHOULD recognize .i2p domains as special and
SHOULD NOT use them as they would other domains.
Applications SHOULD NOT pass requests for .i2p domains to DNS
resolvers and libraries.
As mentioned in points 4 and 5 below, regular DNS resolution is
expected to respond with NXDOMAIN. Therefore, if it can
differentiate between DNS and P2P name resolution, application
software can expect such a response, and can choose to treat
other responses from resolvers and libraries as errors.
3. Name resolution APIs and libraries SHOULD either respond to
requests for .i2p names by resolving them via the I2P protocol,
or respond with NXDOMAIN.
4. Caching DNS servers SHOULD recognize .i2p names as special and
SHOULD NOT attempt to look up NS records for them, or otherwise
query authoritative DNS servers in an attempt to resolve .i2p
names. Instead, caching DNS servers SHOULD generate immediate
negative responses for all such queries.
5. Authoritative DNS servers are not expected to treat .i2p domain
requests specially. In practice, they MUST answer with NXDOMAIN,
as "I2P" is not available via global DNS resolution, and not
doing so MAY put users' privacy at risk (see item 6).
Grothoff, et al. Expires December 26, 2015 [Page 5]
Internet-Draft Special-Use I2P Names June 2015
6. DNS server operators SHOULD be aware that .i2p names are reserved
for use with I2P, and MUST NOT override their resolution (e.g.,
to redirect users to another service or error information).
7. DNS registries/registrars MUST NOT grant any request to register
.i2p names. This helps avoid conflicts [SAC45]. These names are
defined by the I2P protocol specification, and they fall outside
the set of names available for allocation by registries/
registrars.
5. Security Considerations
Specific software performs the resolution of the I2P Special-Use
Domain Names presented in this document; this resolution process
happens outside of the scope of DNS. Leakage of requests to such
domains to the global operational DNS can cause interception of
traffic that might be misused to monitor, censor, or abuse the user's
trust, and lead to privacy issues with potentially tragic
consequences for the user.
This document reserves these Top-Level Domain names to minimize the
possibility of confusion, conflict, and especially privacy risks for
users.
In the introduction of this document, there's a requirement that DNS
operators do not override resolution of the I2P Names. This is a
regulatory measure and cannot prevent such malicious abuse in
practice. Its purpose is to limit any information leak that would
result from incorrectly configured systems, and to avoid that
resolvers make unnecessary contact to the DNS Root Zone for such
domains. Verisign, Inc., as well as several Internet service
providers (ISPs) have notoriously abused their position to override
NXDOMAIN responses to their customers in the past
[SSAC-NXDOMAIN-Abuse]. For example, if a DNS operator would decide
to override NXDOMAIN and send advertising to leaked .onion sites, the
information leak to the DNS would extend to the advertising server,
with unpredictable consequences. Thus, implementors should be aware
that any positive response coming from DNS must be considered with
extra care, as it suggests a leak to DNS has been made, contrary to
user's privacy expectations.
The reality of X.509 Certificate Authorities (CAs) creating
misleading certificates for I2P pTLDs due to ignorance stresses the
need to document their special use. Given the nature of "B32.I2P",
Grothoff, et al. Expires December 26, 2015 [Page 6]
Internet-Draft Special-Use I2P Names June 2015
X.509 Certificate Authorities MAY create certificates for such
domains given CSRs signed with the respective private keys
corresponding to the respective names.
6. IANA Considerations
The Internet Assigned Numbers Authority (IANA) reserved the following
entries in the Special-Use Domain Names registry [RFC6761]:
.i2p
[TO REMOVE: the assignement URL is https://www.iana.org/assignments/
special-use-domain-names/ ]
7. Acknowledgements
The authors thank the I2P and Namecoin developers for their
constructive feedback, as well as Mark Nottingham for his proof-
reading and valuable feedback. The authors also thank the members of
DNSOP WG for their critiques and suggestions.
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013.
8.2. Informative References
[I2P-CHOICE]
Hacker, J. and The I2P Community, "I2P Dev Meeting 059",
September 2003, <https://geti2p.net/en/meetings/059>.
Grothoff, et al. Expires December 26, 2015 [Page 7]
Internet-Draft Special-Use I2P Names June 2015
[I2P-NAMING]
Hacker, J. and The I2P Community, "Naming in I2P and
Addressbook", April 2014, <https://geti2p.net/en/docs/
naming>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[SAC45] ICANN Security and Stability Advisory Committee, "Invalid
Top Level Domain Queries at the Root Level of the Domain
Name System", November 2010,
<http://www.icann.org/en/groups/ssac/documents/
sac-045-en.pdf>.
[SSAC-NXDOMAIN-Abuse]
ICANN Security and Stability Advisory Committee,
"Redirection in the COM and NET Domains", July 2004,
<http://www.icann.org/committees/security/
ssac-report-09jul04.pdf>.
[zzz2009] The I2P Project and L. Schimmer, "Peer Profiling and
Selection in the I2P Anonymous Network", January 2009,
<https://geti2p.net/_static/pdf/I2P-PET-CON-2009.1.pdf>.
Authors' Addresses
Christian Grothoff
INRIA
Equipe Decentralisee
INRIA Rennes Bretagne Atlantique
263 avenue du General Leclerc
Campus Universitaire de Beaulieu
Rennes, Bretagne F-35042
FR
Email: christian@grothoff.org
Matthias Wachs
Technische Universitaet Muenchen
Free Secure Network Systems Group
Lehrstuhl fuer Netzarchitekturen und Netzdienste
Boltzmannstrasse 3
Technische Universitaet Muenchen
Garching bei Muenchen, Bayern D-85748
DE
Email: wachs@net.in.tum.de
Grothoff, et al. Expires December 26, 2015 [Page 8]
Internet-Draft Special-Use I2P Names June 2015
Hellekin O. Wolf (editor)
GNU consensus
Email: hellekin@gnu.org
Jacob Appelbaum
Tor Project Inc.
Email: jacob@appelbaum.net
Leif Ryge
Tor Project Inc.
Email: leif@synthesize.us
Grothoff, et al. Expires December 26, 2015 [Page 9]