Infrastructure Overlay
draft-petithuguenin-dispatch-unique-overlay-02

Abstract

This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet.

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 September 11, 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. 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.

This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1. Introduction
• 1.1. VIPR Infrastructure Overlay
• 1.2. Bitcoin-like Infrastructure Overlay
• 1.3. BOINC-like Infrastructure Overlay
• 2. Terminology
• 3. Requirements
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Proposal
• Appendix B. Release notes
• Appendix B.1. Modifications between -02 and -01
• Appendix B.2. Modifications between -01 and -00
• Author's Address

1. Introduction

[RELOAD] is a peer to peer protocol developed by the P2PSIP Working Group. Each RELOAD instance has a unique name, which is used by the process in section 10.2 of this specification to find the configuration servers, enrollment servers and bootstrap servers needed to join the overlay. The process assumes that the RELOAD instance name is a FQDN, and uses the process in [RFC2782] (SRV RR) to find the IP address of the HTTPS server that serves the configuration document for this overlay.

This process is adequate when the management of the overlay does not need to be distinguished from the owner of the FQDN used as the instance name, which is the case most of the time. But there is a special class of overlays that, by definition, requires to be unique on the Internet and for which having the possibility of create instances would defeat their very purpose. This specification calls the kind of overlays that are not domain specific, but application specific "infrastructure overlays".

1.1. VIPR Infrastructure Overlay

[VIPR] is a technology that is being standardized in the VIPR Working Group and that aims to build bridges between SIP islands by automatically provision SIP routes after the "ownership" of a PSTN phone number has been verified by an actual PSTN phone call. This technology uses an RELOAD overlay as a distributed database where mappings between phone numbers and servers responsible for the validation process are stored. The promise of VIPR to bridge these SIP islands cannot be fulfilled if there is more than one distributed database storing these mappings.

1.2. Bitcoin-like Infrastructure Overlay

The existing Bitcoin protocol is using an IRC channel to find the initial peer servers, but one can imagine a Bitcoin-like Internet currency that built on top of RELOAD. If such Internet currency is ever implemented on top of RELOAD, it would also require a unique RELOAD instance.

1.3. BOINC-like Infrastructure Overlay

BOINC is a software for volunteer computing and grid computing, which is used for donating computer resources for projects as diverse as SETI@Home, Malariacontrol.net and LHC@Home. This kind of research benefiting humanity as a whole could probably be better served if implemented on a unique overlay.

2. Terminology

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].

3. Requirements

The following requirements can be identified as a starting point for the discussion about infrastructure overlays:

REQ-1:

The mechanism used to find the configuration servers of the infrastructure overlay MUST require as little administrative overhead as possible.

REQ-2:

The mechanism MUST NOT require that one entity must shoulder the burden for administratively supporting the overlay.

REQ-3:

The mechanism MUST ensure that no one can capture the overlay for its own gain.

4. Security Considerations

TBD

5. IANA Considerations

This document requires no IANA actions.

6. Acknowledgements

Jon Peterson and Gonzalo Camarillo suggested to write this document, with Jon Peterson providing some of the ideas.

This document was written with the xml2rfc tool described in [RFC2629].

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Proposal

One possible way to implement infrastructure overlay is to do something similar to [RFC3404] and [RFC3405], by defining a .arpa subdomain named "reload". The overlay name as defined in a standard track document then becomes a subdomain of "reload.arpa.", so if for instance the name of an infrastructure overlay is "Quetzalcoatl", the standard track document defining this overlay is also a request to create a "Quetzalcoatl.reload.arpa." domain.

Because there is no way to clearly differentiate between a standard overlay and an infrastructure overlay simply by looking at the instance-name, especially since ICANN accepts applications for new top-level domains, this proposal would also redefine the reload URI in section 13.15 of [RELOAD], by prepending a '&' symbol to the name of the overlay to signal that the name following the symbol is the name of an infrastructure overlay. A RELOAD implementation supporting infrastructure overlay can then use the procedure defined in [RELOAD] section 10.2 by using the "reload.arpa." subdomain instead of the instance name directly.

Appendix B. Release notes

This section must be removed before publication as an RFC.

Appendix B.1. Modifications between -02 and -01

• The proposal cares about the RELOAD URI, not the instance-name in the configuration file.

Appendix B.2. Modifications between -01 and -00

• Added a proposal.

Author's Address