Proposed Improvements for REsource LOcation And Discovery (RELOAD)Stonyfishmarc@stonyfish.com
RAI
P2PSIP
This document proposes some improvements for .
This document presents some extensions to RELOAD.
The RELOAD authors are free to take whatever they want in this document.
Anything else will be either proposed as separate extensions or in reload-bis after RELOAD is published as an RFC.
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 .Section 3.2.1 of describes how a client can connect to an overlay, either to its responsible peer or to an arbitrary peer, but does not describes the case where the client just wants to connect to a bootstrap node with a certificate containing multiple Node-IDs.This documents permits this, by having the client immediately sending a Ping with a wildcard Node-ID, and the bootstrap node waiting for receiving the Ping if the (D)TLS connection contains a remote certificate with multiple Node-IDs.Section 10.2 of uses a Service Name of "p2psip-enroll" and a path of "/.well-known/p2psip-enroll".RELOAD is now a generic P2P protocol, no longer tied to SIP so this document defines the Service Name "p2p-enroll" as an alias for "p2psip-enroll" and "/.well-known/p2p-enroll" as an alias for "/.well-known/p2psip-enroll".Section 10.3.1 does not define an algorithm to create self-signed certificates that contain multiple Node-IDs.This document permits to create self-signed certificates by prepending the index (from 1 to the number of Node-IDs needed) as a 4 bytes big endian integer to the public key of the user before applying the digest.Section 10.5 explains that the enrollment server must return certificates that contain Node-IDs that are cryptographically random, preventing the possibility to provide new certificates for Node-IDs already assigned, for example because a certificate will expire soon.
This documents permits to extend the lifetime of a Node-ID by reissuing new certificates.
This is done by sending the old certificate in the request to the enrollment server instead of the certificate signing request.
The enrollment server MUST still check that the username and password are consistent with the certificate.
If the nodeids parameter is different from the value used when issuing the previous certificate, then the number of Node-IDs in the new certificate must be adjusted, by either removing Node-IDs or by assigning new Node-IDs.
This mechanism does not permit to change the RSA keys and keep the same Node-ID(s), but this is consistent with the self-signed certificates mechanism that does not permit this either.
Some of the data structures defined by new Kinds contains on one form or another the Resource Name that is used to generate the Resource-ID used to store this kind.
This is because the information in the Resource Name is lost during this convertion.
Examples of this are the TURN-SERVICE Kind, the REDIR Kind and all Kinds implementing the shared resource mechanism in ShaRe.
This document modifies the StoreReq structure by adding the Resource Name:This document also modifies the FetchAns structure by adding the Resource Name:TBDTBDThis document was written with the xml2rfc tool described in .Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their 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
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
REsource LOcation And Discovery (RELOAD) Base ProtocolNOTE: This version address some, but not all, of the comments received during IESG review. The authors are still working on addressing many more of the comments but as the draft deadline for IETF 82 arrives, this represents the modification made so far. This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.Writing I-Ds and RFCs using XMLInvisible Worlds, Inc.660 York StreetSan FranciscoCA94110US+1 415 695 3975mrose@not.invisible.nethttp://invisible.net/
General
RFCRequest for CommentsI-DInternet-DraftXMLExtensible Markup LanguageThis memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.Service Discovery Usage for REsource LOcation And Discovery (RELOAD)REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism.A Usage for Shared Resources in RELOAD (ShaRe)This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required.This section must be removed before publication as an RFC.Added section about storage of Resource Name.