REsource LOcation And Discovery (RELOAD)
draft-bryan-p2psip-reload-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 9, 2008.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

This document outlines the motivation, requirements, and architectural design for a extensible and lightweight distributed REsource LOcation And Discovery (RELOAD) protocol. RELOAD is a Peer-to-Peer (P2P) based approach for registration and resource discovery using distributed hash tables maintained with binary messages. This design removes the need for central servers from SIP, while offering full backward compatibility with SIP, allowing reuse of existing clients, and allowing P2P enabled peers to communicate with conventional SIP entities. A basic introduction to the concepts of P2P is presented, backward compatibility issues addressed, and security considerations are discussed.

RELOAD is one possible implementation of the protocols being discussed for creation in the P2PSIP WG. In the context of the work being proposed, this draft represents a concrete proposal for the P2PSIP Peer Protocol. RELOAD uses binary messages, derived as much as possible from the STUN protocol, as the underlying protocol. Note that in order to be as similar to STUN as possible, some text has been re-used verbatim from I-Ds and RFCs describing STUN.

In this architecture, no P2PSIP Client Protocol is needed, rather unmodified SIP is used for access by non-peers. This protocol considers NAT traversal and fragmentation, supports storage of information other than registrations, allows for multiple DHT and hash algorithms, and provides hooks for multiple security schemes. The protocol described here derives from a fully implemented and commercially available system with running code.

Table of Contents

1.  Introduction
    1.1.  Evolution of RELOAD
2.  Terminology
3.  Background
    3.1.  Peer-to-Peer Fundamentals
    3.2.  DHTs and Overlay Structure
    3.3.  P2PSIP
4.  The Architecture of RELOAD
    4.1.  P2P Overlay Structure
    4.2.  Use of Binary Messages in RELOAD
    4.3.  P2PSIP Resources and Resource Registration
    4.4.  RELOAD Messages
    4.5.  Routing in RELOAD
        4.5.1.  RELOAD Operations
    4.6.  Message Fragmentation
    4.7.  Bootstrapping
    4.8.  NAT Traversal
    4.9.  Signatures and Security
5.  Message Syntax
    5.1.  Message Header
    5.2.  Message Attributes
        5.2.1.  RESPONSE-CODE
        5.2.2.  SOURCE-INFO and PEER-INFO
        5.2.3.  RESOURCE and RESOURCE-INFO
        5.2.4.  ROUTE-LOG
        5.2.5.  REDIRECT
        5.2.6.  SIGNATURE
        5.2.7.  SDP
        5.2.8.  APPLICATION
    5.3.  Adding New Attributes
6.  Hash Algorithms and Identifiers
    6.1.  Hash Algorithms
        6.1.1.  Peer-IDs
7.  Message Routing
    7.1.  SIP Session Establishment
8.  Peer and DHT Operations
    8.1.  Peer Registration
        8.1.1.  Constructing a Peer Registration
        8.1.2.  Processing the Peer Registration
    8.2.  Peer Query
        8.2.1.  Constructing a Peer Query Message
        8.2.2.  Processing Peer Query Message
    8.3.  Populating the Joining Peer's Routing Table
    8.4.  Transfering User Registrations
    8.5.  Peers Leaving the Overlay Gracefully
    8.6.  NAT and Firewall Traversal
    8.7.  Handling Failed Requests
9.  Resource Operations
    9.1.  Resource Registrations
    9.2.  Refreshing Resource Registrations
    9.3.  Removing Resource Registrations
    9.4.  Querying Resource Registrations
    9.5.  SIP Session Establishment
    9.6.  Offline Storage
10.  Pluggable DHT Algorithm Requirements
11.  Security Considerations
    11.1.  Threat Model
    11.2.  Protecting the ID Namespace
        11.2.1.  Protection Using ID Hashing
        11.2.2.  Cryptographic Protection
    11.3.  Protecting the resource namespace
    11.4.  Protecting the Routing
    11.5.  Protecting the Signaling
    11.6.  Protecting the Media
    11.7.  Replay Attacks
12.  Open Issues
13.  Acknowledgments
14.  IANA Considerations
15.  Change Log
    15.1.  From draft-bryan-p2psip-reload-00
16.  References
    16.1.  Normative References
    16.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

Peer-to-Peer (P2P) computing has emerged as a mechanism for completely decentralized, server-free implementations of various applications. A substantial P2PSIP usecases document (Bryan, D., Shim, E., and B. Lowekamp, “Use Cases for Peer-to-Peer Session Initiation Protocol (P2PSIP),” November 2005.) [16] has emerged and a concepts and terminology (Willis, D., “Concepts and Terminology for Peer to Peer SIP,” March 2007.) [17] document has helped define a common set of terms. This iteration of this document incorporates the terminology from that draft.

This draft presents RELOAD, a system that uses P2P mechanisms to remove the need for central servers in SIP and SIMPLE based communications systems. While this draft evolved from early work done on the SoSIMPLE (Bryan, D., Jennings, C., and B. Lowekamp, “SOSIMPLE: A Serverless, Standards-based, P2P SIP Communication System,” June 2005.) [18] P2PSIP project, it has changed extensively. This works reflects experience gained in actually building commercially available P2PSIP products (, “SIPeerior Technologies, Inc., Website, www.SIPeerior.com,” .) [19] based on this draft, as well as from extensive work/insight gleaned from the P2PSIP mailing list.

1.1.  Evolution of RELOAD

The dSIP (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) [20] Peer Protocol and its predecessor, based on SOSIMPLE, introduced the P2PSIP concept to the IETF. The earliest version of dSIP transported all messages, including those used to maintain the DHT, using SIP. While the authors feel this mechanism required the least new work for developers to implement, concerns were raised about the "misuse" of SIP messages and the heaviness of the SIP as the P2P peer protocol. To address these concerns, this RELOAD draft presents a binary protocol for the P2PSIP Peer protocol. The RELOAD protocol provides the framework for exchanging P2P messages, and is designed to be extended by pluggable DHT algorithms and security solutions.

The benefit of moving away from SIP as the encoding for the P2PSIP Peer Protocol is the ability to design a new protocol wholly focused on the requirements of P2PSIP. Among the advantages of this protocol are:

• A fixed-length header that can be used for routing the message through the overlay without the contents being parsed (or even visible) by intermediate peers.
• The header includes no information about specific IP addresses because none are needed to route along an overlay. The header only includes source and destination Peer-IDs as well as some minor option and version flags. Clearly separating the header components necessary for routing from the message contents simplifies processing and increases security.
• Although the header uses fixed-length, fixed-offset fields, the content of the message is in STUN-based TLV format, extending a syntax for which many implementers will already have a parser. Furthermore, the flexible contents allows great flexibility in supporting a variety of DHT and security algorithms using the same base peer protocol.
• Support for UDP, TCP, TLS, or SCTP for the underlying transport protocol. Because there is no single universally available and suitable transport protocol, the peer protocol must be flexible in this regard. New transports can be supported trivially.
• Explicit support for fragmentation, required when using UDP. UDP must be supported because we cannot assume that TCP will always be available in the environments this protocol will be deployed in.
• Operations for NAT traversal as part of the base design, including establishing new RELOAD connections and tunneling SIP or other application protocols required by P2PSIP.
• As with dSIP, supports modular DHTs. Specifying a default "must implement" DHT will allow interoperability, while the extensibility allows selection of DHTs optimized for a particular application.
• Hierarchical encoding of message attributes, allowing the creation of composite types and multi-valued attributes.
• Support for security primitives that separates the roles of message sender and resource owner, allowing a single message to contain multiple signatures authenticating different portions of the message content.
• Supports one-to-many registrations. Fully distributing all of the state required to duplicate the functionality of central servers requires information about different types of resources for the same user: primary contact, offline voicemail, security certificate, etc. Furthermore, obtaining a list of the resources available for a particular user requires one-to-many registrations stored in a single location, rather than distributing each type of resource by a separate key.
• Each key to value mapping has an individual expiration time. Thus a single key can have both long-lived and transient registrations.
• Each key to value mapping is individually signed by the registering entity. The protocol supports allowing multiple entities to register under the same key, thus allowing voicemail or other data to be left for another user. Because each message lives as a separate registration, there are no race conditions associated with editing the same file, and no need for elaborate synchronization between peers.
• Each resource registration contains parameters that can be used to specify the type of mapping. We anticipate that most registrations with be either URI to URI mappings or URI to certificate mappings, but there is nothing in the protocol that specifies or restricts the type of data stored in the registration.
• Supports multiple flavors of routing. Iterative, recursive, semi-recursive, and pure forwarding each have their advantages and disadvantages depending on network requirements and the particular design of the DHT being used. This protocol also allows the routing to be unspecified, as an implementation may be able to choose between the various options depending on the network (NAT and firewall characteristics, in particular) connections used between specific peers.
• Recursive routing can be implemented either by storing state in each peer as it routes the message or by making use of ROUTE-LOG attributes that record the route taken by the message as it traverses the overlay. Maintaining state on a peer could otherwise be a significant expense.

OPEN ISSUE: Note that just as the earlier work on dSIP was easily modified to use a binary encoding, RELOAD could similarly be modified to use a lightweight text-based (but non-SIP) protocol. Such a protocol might result in messages that are only slightly larger than binary, but would be word aligned and human readable. A consideration of the trade-offs would be worth while.

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [1].

Terminology defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [2] is used without definition.

We use the terminology and definitions from the Concepts and Terminology for Peer to Peer SIP (Willis, D., “Concepts and Terminology for Peer to Peer SIP,” March 2007.) [17] draft extensively in this document without further definition. Other terms used in this document are defined inline when used and are also defined below for reference.

In this illustrative purposes in this document we sometimes use 10 hexadecimal digit values for SHA-1 hashes. In reality, SHA-1 produces 40 digit values. They are shortened in this document for clarity and typographical considerations only.

3.  Background

3.1.  Peer-to-Peer Fundamentals

The fundamental principle behind Peer-to-Peer (P2P) Architectures is that application services are provided by a number of entities, called peers or nodes working together with each other to accomplish tasks. Each and every peer is responsible for contributing to serving some of the transactions that take place on the network. Contrast this with the more traditional Client-Server Architecture in which a large number of clients communicate only with a small number of central servers responsible for performing tasks.

Each peer provides server-like functionality and services as well as being a client within the system. In this way, the services or resources that would be provided by a centralized entity are instead available in a distributed fashion from the peers of the system. Note that a particular peer may or may not provide a particular service, but some peer does, ensuring that collectively the peers can provide that particular service. The peers form a logical cluster of peers called an overlay or overlay network. The services provided are often said to be provided by the overlay, since collectively the members provide the services. The overlay is so named because they form a new, small sub-network at a higher logical level than lower level network connections.

In many P2P systems peers are assumed to be ephemeral in nature. A peer may join or leave the overlay at any time. The design of algorithms for P2P architectures take this into account. Information is replicated, and the topology of the overlay can be quickly adapted as peers enter and leave.

3.2.  DHTs and Overlay Structure

While very early P2P systems used flood based techniques, most newer P2P systems locate resources using a Distributed Hash Table, or DHT to improve efficiency. Peers are organized using a Distributed Hash Table (DHT) structure. In such a system, every resource has a Resource-ID, which is obtained by hashing some keyword or value that uniquely identifies the resource. Resources can be thought of as being stored in a hash table at the entry corresponding to their Resource-ID. The peers that make up the overlay network are also assigned an ID, called a Peer-ID, in the same hash space as the Resource-IDs. A peer is responsible for storing all resources that have Resource-IDs near the peer's Peer-ID. The hash space is divided up so that all of the hash space is always the responsibility of some particular peer, although as peers enter and leave the system a particular peer's area may change. Messages are exchanged between the peers in the DHT as the peers enter and leave to preserve the structure of the DHT and exchange stored entries. Various DHT implementations may visualize the hash space as a grid, circle, or line.

Peers keep information about the location of other peers in the hash space and typically know about many peers nearby in the hash space, and progressively fewer more distant peers. We refer to this table of other peers as a Routing Table. When a peer wishes to search, it consults the list of peers it is aware of and contacts the peer with the Peer-ID nearest the desired Resource-ID. If that peer does not know how to find the resource, it either returns information about a closer peer it knows about, or forwards the request to a closer peer. In this fashion, the request eventually reaches the peer responsible for the resource, which then replies to the requester.

3.3.  P2PSIP

Unlike a conventional SIP architecture, P2PSIP systems require no central servers. In a conventional SIP architecture many UAs connect to one or more central servers that play a number of roles, including proxy server, registrar, presence server, and redirect server. In a P2PSIP architecture, the peers participating in the overlay not only act as conventional SIP UAs, allowing their users to place and receive calls, but, when viewed collectively with the other peers, perform the roles normally provided by a central server. Each participating peer will maintain some fraction of the information that would normally be maintained by the central servers in a conventional SIP network.

P2PSIP peers provide many functions, more than any single entity in a conventional SIP architecture. Minimally, a participating peer must be an active member of the overlay, participating in storage of resources, routing and providing some SIP "server-like" behaviors as well. In the terminology used in the concepts draft, these peers speak the P2PSIP Peer Protocol to organize among themselves.

The general concepts are more fully explained in the Concepts and Terminology for Peer to Peer SIP (Willis, D., “Concepts and Terminology for Peer to Peer SIP,” March 2007.) [17] draft.

4.  The Architecture of RELOAD

In this section we provide an overview of the architecture of RELOAD and explain how it works in an informative way. Protocol details and syntax are provided in a normative form in the remainder of the document.

RELOAD is a specific proposal for the P2PSIP Peer Protocol proposed in the Concepts and Terminology for Peer to Peer SIP (Willis, D., “Concepts and Terminology for Peer to Peer SIP,” March 2007.) [17] draft, using binary messages as the syntax for encoding the protocol. The function of the P2PSIP Peer Protocol is to provide for mechanisms to maintain the overlay, as well as to store and retrieve information, and to route messages when needed.

RELOAD is modular, allowing for the use of multiple DHTs, including those defined later. DHTs can be negotiated among the peers in much the same way as codecs or features are negotiated in conventional SIP. For compatibility, support for one basic DHT algorithm, Chord, is required. Additional DHTs can be added and supported. This concept was demonstrated by dSIP, and would require only syntax modifications to drafts like the Chord algorithm for dSIP [3] (Zangrilli, M. and D. Bryan, “A Chord-based DHT for Resource Lookup in P2PSIP,” February 2007.) and the Bamboo algorithm for dSIP[4] (Zangrilli, M. and D. Bryan, “A Bamboo-based DHT for Resource Lookup in P2PSIP,” February 2007.). Note that this document does not specify the details of the DHTs, including Chord. DHT algorithms are defined in their own documents, which describe how the basic RELOAD operations and syntax are used to implement that specific DHT algorithms. Because this protocol reserves a portion of the method and attribute space for each DHT protocol version, new DHT algorithms are easy to support, even if they rely on methods or data types not required by any previous DHT algorithms. The flexible TLV format allows support for these new DHT algorithms without modification of the parsing or processing of any other portion of the P2PSIP protocol.

4.1.  P2P Overlay Structure

The P2P overlay in RELOAD consists of peers, which collectively serve as a directory service for locating resources (users, voicemail messages, etc.). Peers are organized using a supported Distributed Hash Table (DHT) P2P structure. RELOAD allows for pluggable DHT algorithms the exact form of which is defined in the DHT algorithm definition.

Each peer is assigned a Peer-ID, and each resource that is stored in the overlay is assigned a Resource-ID. These values must map to the same name space. RELOAD provides for various algorithms to be used to produce these values, although all members of the overlay must use the same algorithm.

The Peer-ID assigned to each peer determines the peer's location in the DHT and the range of Resource-IDs for which it will be responsible. The exact mapping between these is determined by the DHT algorithm used by the overlay. The mechanism for selecting these Peer-IDs depends on the security mechanism being used by the overlay. For example, a simple SHA-1 hash of the IP address and the port of the peer could be used to generate the Peer-IDs or alternatively, a certificate based system in which CAs assign Peer-IDs could be used to obtain the Peer-IDs[5] (Lowekamp, B. and J. Deverick, “Security Extensions for RELOAD,” July 2007.).

Every resource has a Resource-ID, obtained by hashing some keyword that identifies the resource. The Resource-IDs map to the same space as the Peer-IDs. In the case of users, the unique keyword is the userid and the resource is the registration -- a mapping between the user name and a contact. Resources can be thought of as being stored in the distributed hash table at a location corresponding to their Resource-ID. Because entities searching for resources must be able to locate them given the unique keyword, Resource-IDs are produced by hashing, and are never assigned, regardless of the DHT and security algorithms being used.

A resource with Resource-ID k will be stored by the peer with Peer-ID closest to the Resource-ID, as defined by the particular pluggable DHT algorithm being used. As peers enter and leave, resources may be stored on different peers, so the information related to them is exchanged as peers enter and leave. Redundancy is used to protect against loss of information in the event of a peer failure and to protect against compromised or subversive peers.

Since each DHT is defined and functions differently, we generically refer to the table of other peers that the DHT maintains and uses to route requests (neighbors) as a Routing Table. RELOAD defines the syntax for encoding these entries into a message, but leaves the exact form of the data each DHT stores in the table as a decision for the DHT implementation. Peers may additionally maintain a list of peers to which they maintain connections for purposes other than routing, for example NAT traversal or caching. This larger table (usually a superset of the routing table) is referred to as the Connection in Table RELOAD. In this draft, we refer to routing decisions being made from the entries in the routing table, although a peer might choose an entry from the connection table if it is a better match.

When locating a resource with a particular Resource-ID, the peer will send the request to the routing table entry with the Peer-ID closest to the desired Resource-ID, as defined by the particular DHT in use. Since DHTs must converge on the resource, the peer receiving the request is assumed to know of a peer with a Peer-ID closer to the Resource-ID, and responds by suggesting or forwarding the message to this peer, depending on the routing mechanism being used.

4.2.  Use of Binary Messages in RELOAD

The binary protocol encoding is lightweight, both in bandwidth requirements and processing requirements. A message can be routed by intermediate peers looking only at the first few words of the message. The contents of the message following the header are TLV-encoded, which allows a parser to quickly locate and parse those portions of the message that it needs while expending no processing time on those that are not needed. Much of this binary P2P Peer Protocol is modeled after the binary STUN (Rosenberg, J., “Session Traversal Utilities for (NAT) (STUN),” March 2007.) [6] protocol, and where appropriate design of attributes are copied.

The use of a binary protocol for this P2PSIP Peer Protocol also should remove concerns about the misuse of SIP messages and bloating of SIP usage.

4.3.  P2PSIP Resources and Resource Registration

RELOAD resources support a "one-to-many" mapping, with a single key or name (such as a SIP AoR) mapping to multiple resource bodies (registrations), each of which is annotated with a number of parameters indicating its type or other attributes. For example, a resource such as "bob@p2psip.example.org" can have registrations for types such as "voicemail" and "cell". Each resource body has its own expiration, parameters, and signature authenticating the registrations as genuine. A typical user's registration might also include a registration body with their certificate, allowing other users to validate the signatures as appropriate for the security specification used by the overlay.

Resource bodies are given separate expirations because they serve different purposes. An office phone, for example, might only be listed while the user is at their desk and is refreshed frequently by that device, whereas their voicemail registration should be long-lived to allow messages to be left when the user is away from the desk. RELOAD allows invalidation of individual resource bodies as well as mass invalidation of the resource values for a particular resource name.

4.4.  RELOAD Messages

RELOAD Message have a fixed length header. Fixed headers can be faster to process than messages without a fixed header because the headers can be processed by the stack and redirected to the appropriate peer without processing the entire message.

Messages provide three classes of RELOAD methods: Peer, Resource, and Transport. Peer messages are designed to enable peer joins, or registrations, and peer searches. The resource class provides GET, PUT, and TRANSFER messages for resources. Transport messages are designed to help with NAT traversal and the tunneling of both P2PSIP and SIP connections between machines.

RELOAD message bodies can contain information about multiple resources. RELOAD message bodies can contain the keys and bodies for multiple resource registrations, which enables information about multiple resources that a peer is responsible for to be sent in one message.

The transport methods are used to facilitate NAT and firewall traversal. The OPEN transport method provides a control connection that can be used by ICE (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” June 2007.) [7] to establish a direct connection between two peers for future RELOAD messages (or other protocols). The TRANSPORT-TUNNEL method is used to encapsulate SIP (or other protocol) messages in a RELOAD message that is routed across the overlay. TRANSPORT-TUNNEL is most useful for non-recurring messages such as SIP's INVITE, whereas adding a new peer to the routing table or using SIP MESSAGE or SUBSCRIBE/NOTIFY messages will benefit from using OPEN to establish a direct connection. By encoding the SIP client's Peer-ID as a uri-param in a Contact or by encoding the information separately in a P2PSIP resource registration (see below), SIP messages can be routed across the overlay using P2PSIP primitives.

RELOAD messages can contain multiple bodies. For example, a transport OPEN can be sent in the same message as a resource PUT saving both time and the expense of sending an OPEN after the resource registration has completed.

4.5.  Routing in RELOAD

When a peer sends a message within the DHT, it begins by calculating the target ID it is attempting to locate, using the particular algorithm used by the overlay. The target could be another user, a particular resource, or a peer (including itself) for DHT maintenance purposes. It then consults its routing table, and its other neighbor peers, for the closest peer it is aware of to the target ID, as defined by the closeness metric of the DHT in use.

In discussions of P2PSIP, several mechanisms have been discussed for routing. In each case, the initial message is sent from the requester to the peer in the routing table most likely to route correctly, as defined by the DHT algorithm in use. Subsequently, that peer may provide further routing using one of four mechanisms. These three types of routing are:

• Iterative: If the contacted peer is not responsible for the target ID, then the contacted peer issues a 302 redirect response pointing the search peer toward the best match the contacted peer has for the target ID. The searching peer then contact the peer to which it has been redirected and the process iterates until the responsible peer is located.
• Recursive: If the contacted peer is not responsible for the target ID, it will forward the query to the nearest peer to the target that it knows, and the process repeats until the target is reached. The response unwinds and follows the same path on the message return. A mechanism similar to SIP's proxy behavior is used to enable recursive routing.
• Semi-Recursive: Semi-Recursive is the same as Recursive routing on the outbound leg, but the reply "shortcuts" and is directly sent back to the requester. When discussing these techniques, we often just refer to Iterative and Recursive, because of the similarity between recursive and semi-recursive routing.
• Strict-forward: All queries and responses will travel in the same manner around the overlay, such that responses do not traverse the same path the request took. For example in a circular overlay, if the contacted peer is not responsible for the target ID, contacted peer will forward the query to the nearest peer with peer ID larger than its own peer ID. The response does not unwind, but rather continues to propagate in the same direction around the circular overlay until the original request peer receives the response.

Various mechanisms may be used within the same overlay and even within the same search. For example, a search may start as iterative, but if a particular peer receiving the request knows that the requester cannot reach the next hop directly (perhaps due to NAT issues), the search may have recursive and iterative portions.

In general, the messages can be routed using any of these mechanisms, and this draft does not specify which mechanism will be used. The decision as to which mechanism is appropriate may be a factor of security, NAT traversal, or even the properties of the particular DHT being used. We generally refer to the message as being routed through the overlay.

4.5.1.  RELOAD Operations

RELOAD provides mechanisms that are used for a number of operations.

4.5.1.1.  Peer Joining or Registration

When a peer (called the joining peer) wishes to join the overlay, it determines its Peer-ID and sends a JOIN message to a bootstrap peer already in the overlay, requesting to join. Any peer in the DHT may serve as a bootstrap peer. The mechanism for selecting bootstrap peers is application dependent, and discussed in Bootstrapping (Bootstrapping).

Following the iterative routing scheme, the bootstrap peer looks up the peer it knows nearest to the Peer-ID of the joining peer and responds with 302 redirect to this closer peer. The joining peer will repeat this process until it reaches the peer currently responsible for the space it will occupy.

If recursive routing is being used, the bootstrap peer looks up the peer it knows nearest to the Peer-ID of the joining peer and forwards the JOIN message to that peer. This process of forwarding the message repeats until the peer currently responsible for the space the joining peer will occupy is found. When using recursive routing, the reply is from the admitting (responsible) peer is routed back through the overlay to the bootstrap peer, which then forwards the reply to the joining peer.

Once the peer responsible for the joining peer's portion of the namespace is located, the joining peer then exchanges DHT state information with this peer, called the admitting peer, to allow the joining peer to learn about other peers in the overlay (neighbors) and to obtain information about resources the joining peer will be responsible for maintaining. Other DHT maintenance messages will be exchanged later to maintain the overlay as other peers enter and leave, as well as to periodically verify the information about the overlay, but once the initial messages are exchanged, a peer has joined the overlay.

4.5.1.2.  Resource Operations

4.5.1.2.1.  Resource Registration

The peer join does not register the peer's user(s) or other resources with the P2PSIP network -- it has only allowed the peer to join the overlay. Once a peer has joined the overlay, the user that peer hosts must be registered with the system. This process is referred to as resource registration. This registration is analogous to the conventional SIP registration, in which a message is sent to the registrar creating a mapping between a SIP URI and a user's contact. The only difference is that since there is no central registrar, some peer in the overlay will maintain the registration on the users behalf.

Resource registrations are routed similarly to peer registrations. The resource's peer calculates the resource-ID and contacts the peer it is aware of nearest to the resource-ID. This search process continues in either an iterative or recursive manner until the responsible peer is located. This peer then stores the registration for that user and returns a 200 response.

4.5.1.2.2.  Resource Object Storage and Retrieval

A resource registration maps from a key to a value, typically a URL. Larger objects are not necessarily suitable for the same system or protocol, but when stored in the P2PSIP overlay, they must be stored on the responsible peers. RELOAD can be used for these transfers, but is not optimized for large file transfer. An existing mechanism defined for such a purpose, such as HTTP, scp, MSRP or FTP should be used to store and retrieve the resource objects. The specific mechanism being used may vary and need not be the same within the overlay.

Resources are retrieved by performing a resource query to obtain the location of where the resource is being stored.

4.5.1.2.3.  Resource Redundancy

For redundancy, resources should also be registered and stored at additional peers within the overlay. These replicas are located by adding a replica number to the resource name and hashing to identify a new resource-ID for each replica. In this way, replicas are located at unrelated points around the DHT, minimizing the risk of an attacker compromising more than one registration for a single resource.

4.5.1.3.  SIP Session Establishment

SIP Sessions are established by contacting the UA identified by the registration in the DHT. The first step in establishing a session is locating this peer, which is done by searching for a resource in the DHT. The name of the target resource is used to calculate a resource-ID and a resource GET message is sent to the closest known peer to that resource-ID. The search continues until the responsible peer is located. The responsible peer then returns either a 200 OK with the contact information for the resource or a 404 Not Found. If found, the session is then initiated directly with the resource's UA.

4.5.1.4.  DHT Maintenance

In order to keep the overlay stable, peers must periodically perform book keeping operations to take into account peer failures. These DHT maintenance messages are sent using peer messages and the overlay algorithm being used will dictate how often and where these messages are sent.

DHT maintenance messages are routed similarly to peer registrations and resource registrations. The peer calculates the Peer-ID of the peer it wants to exchange DHT information with and contacts the peer it is aware of closest to that Peer-ID. This search process continues until the peer is located at which point the peers exchange DHT maintenance information.

4.6.  Message Fragmentation

Practical issues of deploying RELOAD dictate that there is no one transport protocol that is appropriate for all situations. Device power, the number of connections that must be maintained, durations of typical connections, NAT and firewall policies and capabilities, and message size all influence the choice of transport protocol and frequently lead to different conclusions. Because stream-oriented protocols, such as TCP, cannot always be used, including fragmentation in the RELOAD protocol provides a mechanism for other transport protocols to send large messages.

RELOAD messages that are very large can be sent in multiple fragments or chunks. Each fragment contains one part of the complete message. There is an Frag-Offset header field that indicates the overall position of each fragment. There is also a Frag-Length header field that indicates the total fragments in the complete message. The FRAG header field is a flag that indicates whether the RELOAD message is fragmented or not. The LFRG header field is a flag that indicates whether this is the last fragment of the complete message.

OPEN ISSUE: Should the Frag-Offset be the byte offset of the fragment in the complete message or the fragment number? Likewise should the Frag-Length header field contain the total length of the complete message in bytes or the total number of fragments that make up the complete message?

4.7.  Bootstrapping

When a peer wishes to join an existing overlay, it must first locate some peer that is already participating in the overlay, referred to as the bootstrap peer. Peers may use any method they choose to locate the initial bootstrap peer --- the decision is outside the scope of this specification. The following are a few of the many methods that may be used:

Static Locations:

Some number of peers in the overlay may be persistent and have well know addresses. These addresses could be configured into the peer application or obtained using an out-of-band mechanism such as a web page.

Cached Peers:

While this mechanism cannot be used the first time that a peer runs, on subsequent attempts to join the overlay a peer might attempt to use a previously contacted peer as a bootstrap peer.

Broadcast mechanisms:

Peers can use a broadcast or another local discovery mechanism to locate the initial peer.

DNS

An overlay can list well-known and capable peers in appropriate DNS entries so that current bootstrap peers can be located by any peer when it wishes to join the overlay.

4.8.  NAT Traversal

RELOAD is designed with NAT traversal in mind. The Transport OPEN and TUNNEL messages are designed to be used by peers to ask neighbors for help opening NAT holes and establishing connections that can reliably be used to traverse NATs. OPEN is used to establish new RELOAD connections between peers and serves as a control connection for the exchange of ICE SDP used to facilitate NAT traversal. OPEN is used when establishing new Routing Table entries by both iterative and recursive routing and may be needed for iterative routing when the searching peer is redirected to a peer it cannot directly contact. In this case, the redirecting peer serves as the intermediary, relaying the OPEN message between the two peers while they establish their own connection.

TRANSPORT-TUNNEL is used to encapsulate application messages, such as SIP messages, as they are routed across the overlay. Using encapsulation eliminates the cost of establishing a direct connection (of benefit to short-lived application connections) and provides a way to support applications that do not, themselves, support the capabilities required for using OPEN or ICE directly.

OPEN ISSUE: originally the ROUTE-LOG was designed for NAT traversal, but it proved unnecessary unless certain routing/dht algorithms were used. It might still be useful to some, but seems to add unnecessary complication.

4.9.  Signatures and Security

RELOAD messages provide a SIGNATURE attribute used to provide authentication and integrity over then entire message (excluding the TTL, etc). Furthermore, RELOAD supports signatures in its various component attribute types, such as RESOURCE-INFO and PEER-INFO, so that they may be individually signed by the originating entity. RESOURCE-INFO and PEER-INFO may also contain certificates for these entities.

The term "signature" here encompasses an opaque type that is not defined in this document. These attributes are to be defined by the security mechanism being used by the overlay. In particular, there is no content in the RELOAD message as specified in this document that prevents replay attacks. [5] (Lowekamp, B. and J. Deverick, “Security Extensions for RELOAD,” July 2007.) specifies a shared secret and a public-key security scheme for RELOAD that address replay attacks through careful selection of Transaction IDs and by incuding a timestamp in the SIGNATURE type.

5.  Message Syntax

This section provides normative text explaining the syntax of the RELOAD messages.

This section provides the details of the binary encoding. The RELOAD protocol is a request-response protocol. The messages are encoded using binary fields and is modeled after the binary STUN (Rosenberg, J., “Session Traversal Utilities for (NAT) (STUN),” March 2007.) [6] protocol. All integers are represented in network byte order and are present in base 10, decimal, unless otherwise noted in this draft.

5.1.  Message Header

The RELOAD message contains a 68 byte header.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       R       |       E       |       L       |       O       |
4  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |               |F|L|                           |
   |      TTL      |    Routing    |R|F|x x x x x x x x x x x x x x|
   |               |               |A|R|                           |
   |               |               |G|G|                           |
8  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|             |               |               |               |
   |X|  Version    |      DHT      |     Hash      |    Security   |
   |P|             |               |               |               |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|             |                                               |
   |/|   Method    |                    Length                     |
   |r|             |                                               |
16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       Destination ID                          |
   |                                                               |
36 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Source ID                             |
   |                                                               |
56 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Transaction ID                         |
64 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Overlay                             |
68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first four bytes identify this message as a RELOAD message.

TTL (time-to-live) is an 8 bit field indicating the number of iterations, or hops, a message can experience before it is discarded. The TTL u_int8 number MUST be stored in network byte order and MUST be decremented by one at every hop along the route the message traverses. If the TTL is 0, the message MUST NOT be propagated further and MUST be discarded.

Routing is an 8 bit field that specifies the type of routing the requester would like for the message. The following Routing options MUST be understood:

UNSPECIFIED  : 0x00
PROXY        : 0x01
REDIRECT     : 0x02

If a peer is unable or unwilling to perform the type of routing requested, the peer MUST respond with a 499 error message that indicates its unwillingness to process the message.

FRAG is a 1 bit field used to specify if this message is a fragment.

NOT-FRAGMENT    : 0x0
FRAGMENT        : 0x1

LFRG is a 1 bit field used to specify whether this is the last fragment in a complete message.

NOT-LAST-FRAGMENT    : 0x0
LAST-FRAGMENT        : 0x1

OPEN ISSUE: How should the fragment offset and total length be encoded in the header? Right now we have 14 bits reserved with the intention that they be used for fragmenting, though additional bytes in the header might be needed for fragmentation.

EXP is a 1 bit field that specifies if this protocol is experimental or not. The EXP bit can be set to denote that this version of the protocol is private, in-house. This makes it possible to have private protocol versions that don't collide with IETF standards.

Version is a 7 bit field that indicates the version of the P2PSIP protocol being used.

Version1.0       : 0x1

DHT is an 8 bit field that specifies the DHT algorithm being used. Because of its simplicity, implementations MUST support the Chord DHT algorithm, though other DHT algorithms MAY be used (and likely will be)

Chord1.0       : 0x01
Bamboo1.0      : 0x02

HASH is an 8 bit field that specifies the hash algorithm used to generate IDs. All IDs used for an overlay must be calculated using the same algorithm. Implementations MUST support the SHA-1 algorithm, which produces a 160 bit hash value, though other hash algorithms MAY be used.

SHA-1       : 0x01

Security is an 8 bit field that indicates the security mechanism being used by participants in the overlay.

NONE         : 0x01

R/r is a one bit field used to specify if this is a request or a response.

REQUEST       : 0x0
RESPONSE      : 0x1

Method is a 7 bit field that indicates the message method. There are four types of methods: peer, resource, transport, and DHT specific. DHT specific methods are defined by the DHT algorithm being used. The class of methods are specified by the first two bits:

PEER-METHODS         : 0x0
RESOURCE-METHODS     : 0x1
TRANSPORT-METHODS    : 0x2
DHT-SPECIFIC-METHODS : 0x3

The remaining four bits are used to specify the peer, resource, and transport methods. The following list of methods MUST be understood and are shown with their full 6 bit representations (first two bits are method type, last four specify method):

PEER-JOIN          : 0x00
PEER-SEARCH        : 0x01
RESOURCE-GET       : 0x10
RESOURCE-PUT       : 0x11
RESOURCE-TRANSFER  : 0x12
TRANSPORT-OPEN     : 0x20
TRANSPORT-TUNNEL   : 0x21

The message Length is the count in bytes of the size of the message, not including the header. 24 bits OPEN ISSUE: Should we just pad and use 32 bits here to make it easier to read into an integer?

The Destination ID is a 160 bit identifier (either Peer-Id or Resource-ID) that uniquely identifies destination peer or resource.

The Source ID is a 160 bit identifier (either Peer-ID or Resource-ID) uniquely identifying the sender.Op

OPEN ISSUE: Other length IDs could be supported and parse fine as long as the length is known based on the hash algorithm field. To support this feature it would not be possible to join an overlay without knowing the hash algorithm in advance.

The Transaction ID is a unique 64 bit number that identifies this transaction and also serves as a salt to randomize the request and the response. Responses use the same Transaction ID as the request they correspond to.

The Overlay field is the 32bit checksum/hash of the overlay being used. The CRC-32 checksum MUST be used to convert the variable length string representing the overlay name into a 32bit value. The 32bit Overlay field does not provide a security check, but rather an integrity check. The CRC-32 checksum Overlay field provides a "digital signature" representing the overlay name so that peers can verify that they are interacting with overlay they are intending to interact with.

5.2.  Message Attributes

Following the fixed length header, the message contains 0 or more attributes. Message attributes are TLV (type-length-value) encoded, with 16 bit type, 16 bit length, and variable value:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Type                  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Value                             ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following message attribute types are defined:

RESPONSE-CODE      : 0x0001
SOURCE-INFO        : 0x0002
RESOURCE           : 0x0003
ROUTE-LOG          : 0x0004
REDIRECT           : 0x0005
SIGNATURE          : 0x0006
SDP                : 0x0007
APPLICATION        : 0x0008

OPEN ISSUE: Should we divide the attributes space between optional and mandatory? In STUN, attributes are split between mandatory and optional attributes. Mandatory attributes must be understood -- a client or server can process the message only if it understands the attribute. Optional attributes do not have to be understood -- the client or server can process the message even if it doesn't understand the attribute. STUN uses attributes less than or equal to 0x7fff for mandatory and greater than 0x7fff for optional.

The SIGNATURE attribute MUST be the last attribute within a message when originally sent. ROUTE-LOG attributes may be added following the SIGNATURE.

The attribute type field provides information about how to parse the value. Many of the attribute types listed here are composite types, i.e. the value is itself a set of TLV-encoded attributes. In this case, the length of the parent attribute, such as SOURCE-INFO, is the length of the entire set of member attributes to that SOURCE-INFO, and a parser can skip decoding the entire composite attribute if it is not interested in its contents.

The following tables indicate which attributes appear in which messages. An M indicates that inclusion of the attribute in the message is mandatory, O means its optional, C means it's conditional based on some other aspect of the message, and N/A means that the attribute is not applicable to that message type.

                   Peer   Peer   Peer     Peer
                   Join   Join   Search   Search
Attr.              Req    Resp.  Req.     Resp.
---------------------------------------------------
RESPONSE-CODE      N/A     M     N/A       M
SOURCE-INFO         O      M      O        M
RESOURCE           N/A    N/A    N/A      N/A
ROUTE-LOG           O      O      O        O
REDIRECT           N/A     O     N/A       O
SIGNATURE           O      O      O        O
SDP                O      C      O        C
APPLICATION        N/A    N/A    N/A      N/A

                 Res.  Res.   Res.  Res.   Res.   Res.
                 Get   Get    Put   Put    xfer   xfer
Attr.            Req.  Resp.  Req.  Resp   Req    Resp
----------------------------------------------------------
RESPONSE-CODE    N/A    M    N/A      M    N/A     M
SOURCE-INFO       O     M     O       M     O      M
RESOURCE         N/A    M     M      N/A    M     N/A
ROUTE-LOG         O     O     O       O     O      O
REDIRECT         N/A    O    N/A      O    N/A     O
SIGNATURE         O     O     O       O     O      O
SDP              O     C     O       C     O      C
APPLICATION      N/A   N/A   N/A     N/A   N/A    N/A

                   Tranport  Transport  Transport  Transport
                    OPEN      OPEN      tunnel     tunnel
Attr.               Req       Resp.      Req.       Resp.
-------------------------------------------------------------
RESPONSE-CODE       N/A        M         N/A         M
SOURCE-INFO          O         M          O          M
RESOURCE            N/A       N/A        N/A        N/A
ROUTE-LOG            O         O          O          O
REDIRECT            N/A        O         N/A         O
SIGNATURE            O         O          O          O
SDP                 M         M         N/A        N/A
APPLICATION         N/A       N/A         M          O

The Length refers to the length of the actual useful content of the Value portion of the attribute, measured in bytes. Since STUN aligns attributes on 32 bit boundaries, attributes whose content is not a multiple of 4 bytes are padded with 1, 2 or 3 bytes of padding so that they are a multiple of 4 bytes. Such padding is only needed with attributes that take freeform strings, such as USERNAME and PASSWORD. For attributes that contain more structured data, the attributes are constructed to align on 32 bit boundaries. The value in the Length field refers to the length of the Value part of the attribute prior to padding - i.e., the useful content. Consequently, when parsing messages, implementations will need to round up the Length field to the nearest multiple of four in order to find the start of the next attribute.

5.2.1.  RESPONSE-CODE

The RESPONSE-CODE is based on STUN's (Rosenberg, J., “Session Traversal Utilities for (NAT) (STUN),” March 2007.) [6] ERROR-CODE attribute, and provides the response status code for the message. The RESPONSE-CODE attribute value is a numeric value in the range of 100 to 600 plus a textual reason phrase encoded in UTF-8. The length of the reason phrase is the length prior to padding.

For processing purposes, the class of the error code is encoded separately from the rest of the code.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 XXXXX                   |Class|     Number    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Reason Phrase (variable)                                ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first 21 bits are reserved for pad, as in STUN.

The class represents the hundreds digit of the response code. The class value MUST be between 1 and 7. The number represents the response code modulo 100, and its value MUST be between 0 and 99.

The following response codes and recommended reason phrases (in brackets) are defined at this time:

200 (OK):

Indicates a successful request. The information returned in the response will depend on the request method.

302 (Moved Temporarily):

The requesting peer SHOULD retry the request at the new address specified in the 302 response message.

404 (Not Found):

The resource or peer cannot be found or does not exist.

408 (Request Timeout):

A response to the request has not been received in a suitable amount of time. The requesting peer MAY resend the request at a later time.

498 (Incompatible with Overlay)

A peer receiving the request is using a different overlay, DHT algorithm, or hash algorithm. OPEN ISSUE: What is the best error number and reason phrase to use?

499 (UnWilling To Proxy)

A peer receiving the request is unwilling to support the Routing mechanism specified in the Routing field of the message header. OPEN ISSUE: What is the best error number and reason phrase to use?

5.2.2.  SOURCE-INFO and PEER-INFO

The SOURCE-INFO attribute provides information about the (source) peer sending the request or response.

The SOURCE-INFO attribute is of PEER-INFO type, which itself contains several attributes. Because a number of other attributes are also of type PEER-INFO, they share the same sub-attributes. PEER-INFOs contain the following attributes:

PEER-ID           : 0x0101
PEER-NAME         : 0x0102
PEER-IP-PORT      : 0x0103
PEER-EXPIRATION   : 0x0104
PEER-CERTIFCATE   : 0x0105
PEER-SIGNATURE    : 0x0106

5.2.2.1.  PEER-ID

PEER-ID represents the P2P identifier associate with the peer. The PEER-ID value MUST be 160 bits to support the mandatory SHA-1 hash algorithm. Hash algorithms and ID generation are discussed in more detail in section Hash Algorithms and Identifiers (Hash Algorithms and Identifiers).

5.2.2.2.  PEER-NAME

PEER-NAME indicates a user or implementor defined name associated with the peer. It is optionally present in a PEER-INFO attribute. The PEER-NAME value is variable length, and the encoded value length is the length of the PEER-NAME prior to padding.

A PEER-INFO may contain multiple PEER-NAME attributes.

5.2.2.3.  PEER-IP-PORT

PEER-IP-PORT is based on STUN's (Rosenberg, J., “Session Traversal Utilities for (NAT) (STUN),” March 2007.) [6] MAPPED-ADDRESS attribute, and provides IP address and port pairs that can be used to contact the peer. PEER-IP-PORTS consist of an eight bit address family, and a sixteen bit port, followed by a variable length value representing the IP Address.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x|    Family     |           Port                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Address (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first 8 bits are used for alignment and are ignored. The family is 0x01 for IPv4 and 0x02 for IPV6. The port is the mapped port represented by a 16 bit network byte order number. If the family is IPV4, the Address is 32 bits. For IPV6, the address is 128 bits (again, in network byte order).

OPEN ISSUE: This attribute is identical to the STUN attribute, but in this case we need to include a representation of the transport protocol in use. We propose to use the reserved octet at the beginning to include the IANA number for the protocol Section 5.2.4.2 (ROUTE-LOG.TRANSPORT), but another option is to extend the attribute by an additional word in between the first word and the Address.

A PEER-INFO may contain multiple PEER-IP-PORT values. The meanings and uses of these values are not defined by this specification. Reliable communication in environments with NATs or firewalls can only be established through the use of ICE as provided by the OPEN method.

5.2.2.4.  PEER-EXPIRATION

The PEER-EXPIRATION attribute value provides the amount of time in seconds the peer information should be considered valid. The value MUST be a numeric value representing the relative time in seconds at which the peer will expire. The value SHOULD be 32bits and MUST be encoded in network byte order.

5.2.2.5.  PEER-CERT

The PEER-CERT attribute contains the security certificate used to authenticate the peer. This optional attribute is defined by the security mechanism being used.

5.2.2.6.  PEER-SIGNATURE

The PEER-SIGNATURE attribute value contains the signature of the message. This optional PEER-INFO attribute is defined by the security mechanism being used. The PEER-SIGNATURE MUST be the last attribute in the PEER-INFO and is applied to all preceding attributes in the PEER-INFO.

5.2.3.  RESOURCE and RESOURCE-INFO

The RESOURCE attribute provides information about resources and resource registrations.

The RESOURCE attribute type is a RESOURCE-INFO, which itself contains several attributes. RESOURCE-INFO contain the following attributes.

RESOURCE-INFO.KEY        : 0x0201
RESOURCE-INFO.BODY       : 0x0202

5.2.3.1.  RESOURCE-INFO.KEY

The RESOURCE-INFO.KEY attribute represents the hashable string that uniquely identifies a resource. It MUST be present in an RESOURCE-INFO attribute. The RESOURCE-INFO.KEY value is variable length value and the encoded length is its length prior to padding.

5.2.3.2.  RESOURCE-INFO.BODY

The RESOURCE-INFO.BODY attribute provides information about all of the resource types. At least one RESOURCE-INFO.BODY attribute MUST be present in a RESOURCE-INFO. Additional RESOURCE-INFO.BODY attributes MAY be added to the RESOURCE-INFO. The RESOURCE-INFO.BODY attribute value consists of several attributes.

RESOURCE-INFO.BODY.ENTRY          : 0x0303
RESOURCE-INFO.BODY.PARAMETER      : 0x0304
RESOURCE-INFO.BODY.EXPIRATION     : 0x0305
RESOURCE-INFO.BODY.SIGNATURE      : 0x0306
RESOURCE-INFO.BODY.PEER-INFO      : 0x0307
RESOURCE-INFO.BODY.CERTIFICATE    : 0x0308

5.2.3.3.  RESOURCE-INFO.BODY.ENTRY

The RESOURCE-INFO.BODY.ENTRY attribute contains the resource information. It MUST be present in the RESOURCE-INFO.BODY attribute and only one RESOURCE-INFO.BODY.ENTRY can be specified in each RESOURCE-INFO.BODY. The RESOURCE-INFO.BODY.ENTRY attribute is variable length and its encoded length is its length prior to padding..

5.2.3.4.  RESOURCE-INFO.BODY.PARAMETER

RESOURCE-INFO.BODY.PARAMETER provides type parameters for each RESOURCE-INFO.BODY. For example, a RESOURCE-INFO.BODY.PARAMETER might indicate that the RESOURCE-INFO.BODY.ENTRY is of type "voicemail". 0 or more RESOURCE-INFO.BODY.PARAMETERs MAY be specified in a RESOURCE-INFO.BODY. RESOURCE-INFO.BODY.PARAMETER specifies characteristics of the RESOURCE-INFO.BODY. RESOURCE-INFO.BODY.PARAMETER consist of a name, an operator, and a value.

RESOURCE-INFO.BODY.PARAMETER.NAME    : 0x0309
RESOURCE-INFO.BODY.PARAMETER.OP      : 0x030A
RESOURCE-INFO.BODY.PARAMETER.VALUE   : 0x030B

RESOURCE-INFO.BODY.PARAMETER.NAME is the textual description of the resource type encoded in UTF-8. The length of the description is encoded as its length prior to padding. The RESOURCE-INFO.BODY.PARAMETER.NAME MUST be specified in the RESOURCE-INFO.BODY.PARAMETER..

RESOURCE-INFO.BODY.PARAMETER.OP is the operator defining the relationship between the RESOURCE-INFO.BODY.PARAMETER.NAME and the RESOURCE-INFO.BODY.PARAMETER.VALUE. It MUST be specified in the RESOURCE-INFO.BODY.PARAMETER. It is an 8 bit numeric value with the following operators defined:

=   :  0x1
!=  :  0x2
>   :  0x3
>=  :  0x4
<   :  0x5
<=  :  0x6

RESOURCE-INFO.BODY.PARAMETER.VALUE is the textual right hand side of the operator encoded in UTF-8. It MUST be specified in the RESOURCE-INFO.BODY.PARAMETER attribute.

5.2.3.5.  RESOURCE-INFO.BODY.EXPIRATION

The RESOURCE-INFO.BODY.EXPIRATION attribute value provides the amount of time in seconds the RESOURCE-INFO.BODY information should be considered valid. The value MUST be a numeric value representing the relative time in seconds at which the RESOURCE-INFO.BODY will expire. The value SHOULD be 32bits and MUST be encoded in network byte order

5.2.3.6.  RESOURCE-INFO.BODY.SIGNATURE

The RESOURCE-INFO.BODY.SIGNATURE attribute contains the signature of the message. This optional RESOURCE-INFO.BODY attribute is defined by the security mechanism being used.

5.2.3.7.  RESOURCE-INFO.BODY.PEER-INFO

The RESOURCE-INFO.BODY.PEER-INFO attribute contains information about the peer that is storing the resource and how to access the physical resource stored on that peer. RESOURCE-INFO.BODY.PEER-INFO is a type PEER-INFO attribute, see the SOURCE-INFO and PEER-INFO section (SOURCE-INFO and PEER-INFO) for syntax details, and it is an optional RESOURCE-INFO.BODY attribute.

PEER-INFO might be included in a resource registration to provide information on how to contact a particular device through the overlay (using TRANSPORT-TUNNEL) rather with a traditional URL. This information might also be included as a uri-param or other protocol-specific method embedded in the RESOURCE-INFO.BODY.ENTRY.

5.2.4.  ROUTE-LOG

ROUTE-LOG provides diagnostic information about the path taken by the request so far and in this manner it is similar in function to SIP's (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [2] Via header field. At each hop peers MUST append their P2PSIP implementation version, transport protocol, and PEER-INFOs in a new ROUTE-LOG attribute. The order of the ROUTE-LOGs in the message is used to determine the order of the peers were traversed along the path. The first ROUTE-LOGs attribute corresponds to the peer at the first hop along the path, and each subsequent ROUTE-LOG attribute corresponds to the peer at the next hop along the path.

ROUTE-LOG.P2PSIP-VERSION       : 0x0400
ROUTE-LOG.TRANSPORT            : 0x0401
ROUTE-LOG.PEER-INFO            : 0x0402

5.2.4.1.  ROUTE-LOG.P2PSIP-VERSION

ROUTE-LOG.P2PSIP-VERSION contains the protocol and version of the P2PSIP implementation used at each hop along the path. The value of ROUTE-LOG.P2PSIP-VERSION is a variable length value. Its encoded length is its length prior to padding.

5.2.4.2.  ROUTE-LOG.TRANSPORT

ROUTE-LOG.TRANSPORT specifies the transport protocol being used at each hop along the path. ROUTE-LOG.TRANSPORT values are integers numbers and the following transport protocol values MUST be understood:

ROUTE-LOG.TRANSPORT.TCP       : 0x0006
ROUTE-LOG.TRANSPORT.UDP       : 0x0011
ROUTE-LOG.TRANSPORT.TLS       : 0x0038
ROUTE-LOG.TRANSPORT.SCTP      : 0x0084

TLS means, TLS over TCP. The hex numbers specified are taken from IANA's assigned Internet Protocol Numbers, which are used to fill in the "Protocol" and "Next Header" fields in IPv4 and IPv6, respectively.

5.2.4.3.  ROUTE-LOG.PEER-INFO

ROUTE-LOG.PEER-INFO provides information about the peer at each hop along the path. The syntax of ROUTE-LOG.PEER-INFO is identical to the PEER-INFO syntax described above in the SOURCE-INFO and PEER-INFO section (SOURCE-INFO and PEER-INFO)

5.2.5.  REDIRECT

The REDIRECT attribute is intended to be used to specify a new peer to contact and is only present in response messages. The REDIRECT attribute value is a PEER-INFO, the syntax of which is described in the SOURCE-INFO and PEER-INFO section (SOURCE-INFO and PEER-INFO).

5.2.6.  SIGNATURE

The SIGNATURE attribute is a signature of the header fields. The SIGNATURE is applied to the entire message from the 8th byte of the header to the end of the attribute preceding the SIGNATURE. The SIGNATURE MUST be the last attribute of the message except for ROUTE-LOGs appended subsequently. The SIGNATURE attribute value is dependent on the security mechanism being used as indicated in the Security header field. See [5] (Lowekamp, B. and J. Deverick, “Security Extensions for RELOAD,” July 2007.) for more information.

5.2.7.  SDP

The SDP attribute is used in a TRANSPORT-OPEN to establish a direct connection between peers. All RELOAD PEERs MUST provide an ICE implementation (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” June 2007.) [7]. This implementation SHOULD be a Full ICE implementation, rather than a Lite implementation. The SDP describes the type of connection that will be established. "application/reload" and "application/sip" are the two primary connections that a P2PSIP peer will need, but others such as "application/http" and "application/msrp" may be used as well. Both regular ICE and ICE-TCP (Rosenberg, J., “TCP Candidates with Interactive Connectivity Establishment (ICE,” March 2007.) [8] may be used for RELOAD connections. OPEN ISSUE: do changes need to be made to ICE to support the other transport protocols?

A TRANSPORT-OPEN message indicates a desire for a direct connection between the source and destination peers. The TRANSPORT-OPEN message itself is routed along the established overlay network and is used as a control connection for the ICE negotiation. The peers may already be exchanging messages over the overlay, and one may decide to open the connection to improve efficiency. Many times the TRANSPORT-OPEN will be used when a peer is updating its routing table and discovers a peer that should be in its routing table based on its DHT algorithm.

TRANSPORT-OPEN is not required to be used for every connection. A PEER-INFO may contain multiple PEER-IP-PORT attributes for a particular peer and a connection may be attempted with those without use of TRANSPORT-OPEN. The exact decision of when to use TRANSPORT-OPEN is not specified by this document. OPEN-ISSUE: probably need to specify what to do if multiple connections are established between the same pair of peers.

Support for ICE mandates that all RELOAD peers MUST implement STUN on their ports and multiplex between RELOAD and STUN traffic. Peers must also support keepalives on their ports.

The straightforward mechanism described here works quite well for a single offer-answer exchange. OPEN ISSUE: Because RELOAD does not require the various mid-session media changes that are required for SIP, we may not need to support subsequent offer/answer exchanges to update or improve the same session.

Peers may continue to exchange RELOAD messages over the overlay until the connection is established. Note that this only applies to recursive routing.

An example of using a similar mechanism to open control connections is found in dsip-nat-traversal (Matthews, P., Cooper, E., Bryan, D., and B. Lowekamp, “NAT Traversal for dSIP,” February 2007.) [21].

5.2.8.  APPLICATION

The APPLICATION attribute is used to tunnel application-specific messages between peers in TRANSPORT-TUNNEL messages. APPLICATION attribute has three sub-attributes, each of which MUST be included in an APPLICATION attribute:

APPLICATION.NAME          : 0x0403
APPLICATION.BODY          : 0x0404
APPLICATION.DIALOG        : 0x0405

Each has a type of string. APPLICATION.NAME should contain the name of the protocol, i.e. "sip", "http", or "reload". OPEN ISSUE: should there be support for a "port number" concept, or just protocol name?

APPLICATION.BODY contains the actual message to be delivered to the application.

APPLICATION.DIALOG contains a 32-bit integer that uniquely identifies the dialog the current message is a part of. It is intended to help identify request/response pairs and its specific meaning is particular to the protocol being tunneled.

Multiple methods are possible for electing when to tunnel SIP traffic. In particular, the SIP UA portion of the P2PSIP peer may not wish to be aware of whether its traffic is being sent directly, routed over a TUNNEL, or sent through a connection opened with TRANSPORT-OPEN. OPEN ISSUE: What methods should be specified by a P2PSIP protocol and what methods are up to the implementor? Should we add a "peerid" and "overlay" uri-param to SIP Contacts to facilitate tunneling or should such information be considered out-of-band to the SIP UA?

The response to a TRANSPORT-TUNNEL message MAY contain an APPLICATION attribute. If an application does not produce a response message or takes too long, the peer SHOULD produce a response with a 200 response code indicating the message was received. Subsequent responses will be sent in their own TRANSPORT-TUNNEL request with the same APPLICATION.DIALOG as previous messages.

5.3.  Adding New Attributes

This specification is designed to allow future revisions of this protocol and pluggable DHT algorithms to add new attributes. DHT algorithms SHOULD define attributes that specify how to exchange DHT Routing Table, Connection Table, and Neighbor information. The exact details and syntax of these attributes is left to the DHT algorithms.

Attributes numbering from 0x0600 to 0x06FF are reserved for the pluggable DHT algorithms. Each DHT algorithm may use any attributes in this range. Because the DHT algorithm in use is specified in the header, there are no concerns about collisions between two different DHT algorithms: they may each use the same attribute for different purposes. The pluggable security algorithms may use attributes from 0x0800 to 0x08FF subject to the same rules.

6.  Hash Algorithms and Identifiers

6.1.  Hash Algorithms

All IDs used for an overlay must be calculated using the same hash algorithm. Implementations MUST support the SHA-1 algorithm, which produces a 160 bit hash value. The hash algorithm used is specified in the HASH field of the message header, described in the Message Header (Message Header) section.

6.1.1.  Peer-IDs

Peer-IDs MUST be acquired or generated in the same manner for all peers in the overlay. Peer-IDs MAY be generated by a peer hashing information specific to that peer, such as the IP address and port number, a peer creating a UUID, or a central authority assigning Peer-IDs to peers. For example, the particular DHT algorithm being used MAY specify an alternate mechanism for determining Peer-ID. Similarly, some security models may assign Peer-IDs from a central authority.

Hashing the IP address and Port number to create a Peer-ID provides minimal security, but only if the Peer-ID can be used to verify the IP address of the peer. This is limited security in that it limits the number of Peer-IDs a malicious user could obtain to the number of IP addresses that user controls. In the case of an administrator or IPv6 addresses a user could obtain a large number of Peer-IDs. Furthermore, NATs make it challenging to verify the IP addresses of peers. Hashing IP addresses and port numbers (possibly along with some other peer specific information) MAY be used to create unique Peer-IDs, but SHOULD NOT be used to provide security for the overlay.

If the security mechanism does not define how Peer-IDs are generated, UUIDs SHOULD be created by peers and used as their Peer-IDS. The system constructs a version 1 UUID according to RFC 4122 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [1]. If the application cannot guarantee that the timestamp obtained for the UUID is globally unique (i.e. there is no system-wide shared stable store for the generator state), it MUST append to the UUID ";", the protocol ("udp" or "tcp"), ";", and the port number allocated for use by the application. The resulting string is then hashed to generate a Peer-ID. UUIDs provide unique identifiers, but with no pretense of security.

The security mechanism being used by the overlay MAY define how Peer-IDs are generated or acquired. For example, a certificate authority can be responsible for assigning Peer-IDs to all of the peers in the overlay. Security algorithms are not discussed in detail in this draft.

7.  Message Routing

When a peer sends a message within the DHT, it begins by calculating the target ID it is attempting to locate, which might be its own location in the DHT, or a user's registration, for which it hashes the user's URI to obtain the appropriate Resource-ID. It then consults its routing table, and its other neighbor peers, for the closest peer it is aware of to the target ID.

The messages in the overlay MAY be routed either iteratively or recursively. The Routing as described in Section 5.1 (Message Header) SHOULD be used to indicate if the next node should process the message using a recursive or iterative mechanism. If the header is omitted, the receiving peer may process the message either recursively or iteratively. If the receiving peer cannot or does not want to route the message in the manner specified in the Routing header field, a 499 Unwilling to Proxy message SHOULD be returned to the requesting peer. OPEN ISSUE: What if it is unwilling to redirect?

If the Routing header is iterative, the contacted peer MUST determine if it is responsible for that target ID. If it is not, then the contacted peer MUST issue a 302 redirect pointing the search peer toward the best match the contacted peer has for the target ID. The searching peer then contact the peer to which it has been redirected and the process iterates until the responsible peer is located.

In recursive routing, the peer sends a message to the peer it knows that is nearest to the target. If the contacted peer is not responsible for the target ID, it MUST forward the query to the nearest peer to the target that it knows, and the process repeats until the target is reached. This process follows standard proxy behavior in RFC 3261.

At each step, the contacted peer must only examine the first 12 bytes to ensure version compatibility, type of routing requested, and R/r, then look at the source or destination ID to determine how to route the message. Parsing the body of the message or the other headers is not required unless the contacted peer is responsible for the destination ID.

[21] (Matthews, P., Cooper, E., Bryan, D., and B. Lowekamp, “NAT Traversal for dSIP,” February 2007.) provides an analysis of the tradeoffs between iterative and recursive routing. Although that analysis is based on dSIP, the functionality and message count of RELOAD is very similar.

7.1.  SIP Session Establishment

If the peer needs to have the SIP session establishment routed through the overlay, it MAY use the TRANSPORT-OPEN or TRANSPORT-TUNNEL messages to request either that a new connection be established or that intermediate nodes proxy the INVITE over the overlay on their behalf. OPEN ISSUE: Should this draft specify selection of the appropriate method of direct connection, TRANSPORT-OPEN, or TRANSPORT-TUNNEL for establishing SIP sessions?

8.  Peer and DHT Operations

8.1.  Peer Registration

After a peer has located an initial bootstrap peer, the process of joining the overlay is started by constructing a PEER-JOIN message and sending it to the bootstrap peer. Third party registration MAY NOT be used for registering peers into the overlay, and attempts to do so MUST be rejected by the peer receiving such a request (although third party registrations are used for other purposes, as described below). The peer MUST construct according to the rules outlined below.

8.1.1.  Constructing a Peer Registration

The Method field in the message MUST be set to PEER-JOIN, 0x00, and the R/r bit field in the message header MUST be set to 0x0.

The Source ID field of the header MUST include only the 160bit identifier that specifies the joining peer's Peer-ID. The Destination ID header for a PEER-JOIN MUST also be set to the joining peer's Peer-ID.

The joining peer MAY leave the Overlay header field set to 0x0 for its initial registration message, but MUST set this parameter to the checksum of the name of the overlay it is joining as soon as it receives a response from the bootstrap peer.

The joining peer MUST set the DHT header field to the name of the DHT it will be using and MUST set the Version header field to be 0x01 for this version of the protocol.

The joining peer MUST set the Hash header field to the name of the Hash algorithm it will use and as soon as it receives a response from the bootstrap peer.

The joining peer MAY leave the Security header field set to 0x0 for its initial registration message, but MUST set this parameter to the security type of the overlay it is joining as soon as it receives a response from the bootstrap peer.

The joining peer SHOULD also list its peer information in a SOURCE-INFO attribute in the body of the message. See section SOURCE-INFO and PEER-INFO (SOURCE-INFO and PEER-INFO) for details on the syntax of this attribute.

Assume that a peer running on IP address 10.4.1.2 on port 5060 attempts to join the network by contacting a bootstrap peer. Further assume that the overlay is using IP:port hashing to determine PeerIDs and that 10.4.1.2 hashes to 463ac4b449 under SHA-1 (using a 10 digit hash for example simplicity), and the least significant bits are replaced with the port number, yielding 463ac413c4 and that the overlay name is chat and the DHT is dhtalg1.0. An example message would look like this:

Version: 0x01
Method: 0x00
DHT: 0x0
Security: 0x0
Hash: 0x0
Source ID: 463ac413c4
Destination ID: 463ac413c4
------Attributes----
SOURCE-INFO:
   PEER-ID: 463ac413c4
   PEER-IP-PORT: 10.4.1.2:5060
   PEER-EXPIRATION: 300

8.1.2.  Processing the Peer Registration

If the peer examines the overlay parameters and determines that this is not an overlay the peer participates in, the peer MUST reject the message with a 497 Incompatible With Overlay response. Likewise if the peer examines the DHT field determines that the algorithm specified is not compatible with its algorithm, the peer MUST reject the message with a 488 Incompatible With Overlay.

8.1.2.1.  Routing the Peer Registration

The bootstrap peer SHOULD verify that the Peer-ID corresponds to the peer listed in the URI by validating the peer's credentials, if any are present. If these do not match, the message SHOULD be rejected with a response of 493 Undecipherable. The bootstrap peer examines the Peer-ID to determine if it corresponds to the portion of the overlay the bootstrap peer is responsible for. If it does, the peer will handle the PEER-JOIN request itself. If not, the bootstrap peer will either provide the joining peer with information about a peer closer to the area of the overlay where the joining peer's Peer-ID is stored (iterative routing) or forward the request along the closest peer it knows about (recursive routing). If a Routing header is set to proxy, the peer MUST use a recursive routing mechanism, and if it is set to redirect, the peer MUST use an iterative routing mechanism. If the peer is unwilling to use this routing mechanism, it MUST reject the message with a 499 response. In the event that the Routing header is set to unspecified, the peer may choose either mechanism.

In the case of iterative routing, if the receiving peer is not responsible for the area of the hash table where Peer-ID should be stored, the peer SHOULD generate a 302 message. The receiving peer MUST look in its list of neighbors or in the routing table to find the peer with Peer-ID nearest the to joining peer's Peer-ID, and use it to create a Redirect attribute in the form of a PEER-INFO, as specified in the REDIRECT (REDIRECT) section. The response MUST also contain a SOURCE-INFO attribute. The Source ID and Destination ID of the reply MUST NOT be changed. This response is sent to the joining peer.

In the case of recursive routing, if the receiving peer is not responsible for the area of the hash table where the Peer-ID should be stored, the receiving peer should forward the request to the peer it knows about that is closest to the Peer-ID. When using recursive routing, the reply from the admitting (responsible) peer is routed back through the overlay to the bootstrap peer, which then forwards the reply to the joining peer. A receiving peer receiving a join request from the joining peer and proxying that request MUST route that message to the admitting peer in a TRANSPORT-TUNNEL message with an APPLICATION attribute whose APPLICATION.NAME is "reload". This technique is necessary because RELOAD must support both reliable authentication and NAT-traversal for routing its initial join messages. If the initial join is routed directly to the admitting peer, there is no way for the reply to be routed back to the joining peer because the joining peer is not yet properly placed in the overlay. The reply must be routed through the bootstrap peer, because it is the only peer known to have a connection to the joining peer. Using a TRANSPORT-TUNNEL for the transaction allows the joining peer to authenticate the message properly but encapsulates it so that a reply can be routed back to the bootstrap peer. A recursive join request MUST also include a TRANSPORT-OPEN to establish a direct connection with the admitting peer.

A peer MUST NOT add a new peer to its routing table or redirect requests to that new peer until it has successfully established a connection with that peer itself. By redirecting a message to another peer, the contacted peer indicates that it believes that peer to be alive and that it is willing to route messages to it for NAT and Firewall traversal purposes.

TODO show example of redirect.

8.1.2.2.  Admitting the Joining Peer

The admitting peer recognizes that it is presently responsible for this region of the hash space -- that is, it is currently the peer storing the information that this Peer-Id will eventually be responsible for. The admitting peer knows this because the joining peer's Peer-ID is closest to its own Peer-ID. The admitting peer is responsible for helping the joining peer become a member of the overlay and the admitting peer MAY perform additional security checks. Once any challenge has been met, the admitting will reply with a 200 OK message to the joining peer.

The admitting peer MUST reply with a 200 response if the admitting peer's Peer-ID is the closest to the joining peer's Peer-ID. Each DHT algorithm MAY choose to define closest however they want, but the DHT algorithm MUST be able to deterministically find the closest Peer-ID. The admitting peer must populate any DHT-SPECIFIC attributes with all values required by the DHT routing protocol so that the joining peer can initialize its neighbors and routing table entries or sent additional DHT-SPECIFIC messages. Additionally, the admitting peer MUST include its peer information in the SOURCE-INFO attribute of the response.

8.2.  Peer Query

8.2.1.  Constructing a Peer Query Message

The peer looks for the routing table entry or neighbor peer that is closest to the ID they are searching for. If the routing table has not yet been filled, then the peer may send the request to any peer it has available, including their other neighbor peers or even some bootstrap peer. While these initial searches may be less efficient, they will succeed.

The Method field in the message MUST be set to PEER-SEARCH, 0x01, and the R/r bit field in the message header MUST be set to 0x0.

The Source ID field of the header MUST include only the 160bit identifier that specifies the searching peer's Peer-ID. The Destination ID header for a PEER-SEARCH MUST be set to the Peer-ID that is being searched for.

The searching peer MUST set the Overlay header field to the name of the overlay it is participating in.

The searching peer MUST set the DHT header field to the name of the DHT it is using using and MUST set the Version header field to be 0x01 for this version of the protocol.

The searching peer MUST set the Hash header field to the name of the Hash algorithm it is using.

The searching peer MUST set the Security field to the security type of the overlay.

The searching peer SHOULD also list its peer information in a SOURCE-INFO attribute in the body of the message. See section SOURCE-INFO and PEER-INFO (SOURCE-INFO and PEER-INFO) for details on the syntax of this attribute.

Assume that a peer wants to determine who is responsible for Peer-ID 4823affe45. Further assume that the peer uses SHA-1 (using a 10 digit hash for example simplicity), and that the overlay name is chat. An example message would look like this (Note that there is no indication of the source or destination IP addresses or ports, which allows this message to be routed, unchanged, to its destination):

Version: 0x01
Method: 0x01
Source ID: 463ac413c4
Destination ID: 4823affe45
------Attributes----
SOURCE-INFO:
   PEER-ID: 463ac413c4
   PEER-IP-PORT: 10.4.1.2:5060
   PEER-EXPIRATION: 300

8.2.2.  Processing Peer Query Message

If the peer examines the overlay, hash, and DHT fields overlay the peer participates in or that the algorithms are incompatible, the peer MUST reject the message with a 498 Incompatible With Overlay response.

8.2.2.1.  Routing the Peer Query Message

The receiving peer SHOULD NOT alter any of its internal values such as successor or predecessor in response to this message, since it is a query. This decision was made for security reasons -- the peer should only learn about other peers it has directly queried. Otherwise, the message is processed and routed as a peer registration (Routing the Peer Registration) until the responsible peer is reached.

8.2.2.2.  Responding to the Peer Query Message

If the receiving peer is responsible for the region that the search key lies within, it MUST respond to the query. If the receiving peer's Peer-ID exactly matches the search key, it MUST respond with a 200 OK message. If it is responsible for that region, but its Peer-ID is not the search key, it MUST respond with a 404 Not Found message.

8.3.  Populating the Joining Peer's Routing Table

Once admitted, the joining peer SHOULD populate its routing table and locate neighbors by sending DHT-SPECIFIC messages or by issuing queries for peers with the appropriate identifiers. If the admitting peer provided neighbor or routing table information in its response, the joining peer MAY use this information to construct a temporary routing table and neighbor information and use this temporary table in the queries to populate the table.

8.4.  Transfering User Registrations

When a new peer joins, it splits the area in the hash space the admitting peer is responsible for. Some portion of the resources the admitting peer was responsible for may now be the responsibility of the joining peer, and these resources are handed to the joining peer by means of RESOURCE-TRANSFER messages.

8.5.  Peers Leaving the Overlay Gracefully

Peers MUST send their registrations to their closest peer before leaving the overlay, as described in the section above. Additionally, peers MUST unregister themselves with their symmetric neighbors (if the DHT routing algorithm uses symmetric neighbors in any form). These graceful exit messages are constructed exactly the same as one used to join, with the following exceptions. The PEER-EXPIRATION of the SOURCE-INFO MUST be set to 0.

8.6.  NAT and Firewall Traversal

The filtering properties of NATs and firewalls can lead to non-transitive connectivity. Typically this will manifest itself in a peer receiving a 302 redirecting it to another peer that it cannot contact, most likely because address dependent filtering is occurring. In that case, the peer SHOULD use a TRANSPORT-OPEN message routed to the target peer through an established RELOAD connection to open a RELOAD connection with the target peer.

8.7.  Handling Failed Requests

When a request sent to another peer fails, the peer MUST perform searches to update its pointers. If the failed request was sent to a peer in the routing table or a neighbor peer, then DHT-SPECIFIC message should be sent or the searches discussed in Populating the Joining Peer's Routing Table (Populating the Joining Peer's Routing Table) should be performed.

9.  Resource Operations

The most important element of resource operations within the P2PSIP DHT is that they are performed essentially the same as if using a conventional SIP registrar, except that the registrar responsibilities are distributed among the DHT members using the RELOAD protocol.

9.1.  Resource Registrations

When a peer is in the overlay, it must register the contacts for users and other resources for which it is responsible into the overlay. This differs from the registrations described above in that these registrations are responsible for entering a resource name to resource body mapping into the overlay as data, rather than joining a peer into the overlay. Resources are registered in the overlay by sending a RESOURCE-PUT message.

The Method field in the message MUST be set to RESOURCE-PUT, 0x11, and the R/r bit field in the message header MUST be set to 0x0.

The Destination ID field of the header MUST be set to the 160bit identifier that specifies the Resource-ID of the resource body being registered. The Source ID header MUST be set to the Peer-ID of the peer doing the RESOURCE-PUT.

The RESOURCE-PUT request SHOULD also include a SOURCE-INFO attribute in the body of the message. See section SOURCE-INFO and PEER-INFO (SOURCE-INFO and PEER-INFO) for details on the syntax of this attribute.

The resource registration MUST include at least one RESOURCE-INFO attribute, with at least one RESOURCE-INFO.BODY attribute in the body of the RESOURCE-PUT message. The RESOURCE-INFO.KEY specifies the name of the resource and the RESOURCE-INFO.BODY specifies one of the key to resource body (registrations) mappings. If more than one RESOURCE-INFO.BODY is in the RESOURCE-INFO attribute, there is a one to many mapping between resource key and resource body values. Each RESOURCE-INFO.BODY MUST have an expires value specified in the RESOURCE-INFO.BODY.EXPIRATION attribute. EXPIRATION set to zero will be used to remove resource bodies.

The message is routed in a fashion exactly analogous to that described in the section on peer registration (Peer Registration). In iterative routing algorithms, 302 messages are sent to indicate that the message is to be redirected to another peer. In recursive routing algorithms, the receiving peer SHOULD forward the request to the peer in its routing table that is closest to the Resource-ID. Once the message arrives at a destination that is responsible for that portion of the hash namespace, the peer responds with a 200 indicating a successful registration.

OPEN ISSUE: Can a resource registration fail?

TODO: specify the resource response message details

TODO: example of resource registration/ resource-put

The registering peer SHOULD construct and register replica registrations.

9.2.  Refreshing Resource Registrations

Resource registrations are refreshed exactly as described in RFC 3261, Section 10. Responsible peers should send a new registration with a valid expiration time prior to the time that the registration is set to expire.

Agents MAY cache the address where they previously registered and attempt to send refreshes to this peer, but they are not guaranteed success, as a new peer may have registered and may now be responsible for this area of the space. In such a case if iterative routing is being used, the peer will receive a 302 from the peer with which they previously registered, and should follow the same procedure for locating the peer they used in the initial registration.

9.3.  Removing Resource Registrations

Resource registrations are removed exactly as described in RFC 3261, Section 10. Responsible peers MUST send a registration with expiration time of zero.

If it registered replica registrations, the sending peer MUST construct replica unregister messages and use these to unregister the replicas.

9.4.  Querying Resource Registrations

Querying peers should send a RESOURCE-GET message to the peer in its routing table with Peer-ID closest to the Resource-ID of the resource being searched for.

TODO: describe Resource-GET message, show example, and explain/describe/example of response to query message.

The 200 response to a RESOURCE-GET MUST provide a RESOURCE-INFO with information about the requested resource. The RESOURCE-INFO.BODY MAY specify how to acquire the resource instead of containing the resource itself. For example, if the resource being searched for is a large voicemail file, the RESOURCE-INFO.BODY might contain a URL that can be used to fetch the resource. After obtaining the RESOURCE-INFO.BODY from the RESOURCE-GET response message, it is the responsibility of the UA to acquire the resource from the peer specified in the RESOURCE-INFO.BODY.

A P2P environment can do little to protect against an individual peer compromising the registrations it is responsible for. Accordingly, a UA cannot trust a response from a single peer, whether it indicates a successful search or an error. In the absence of other methods of verifying the response (such as having a certificate of the user being searched for and a signed registration that can be verified with the certificate) a UA should search for the primary registration and at least one replica. Because the locations the replicas are stored are unrelated to the location of the primary registration, a single attacker is unlikely to be able to compromise both entries. As the overlay gains more peers and more replicas are searched for, the odds of a compromise are reduced. Better protection for registrations is discussed in [5] (Lowekamp, B. and J. Deverick, “Security Extensions for RELOAD,” July 2007.).

9.5.  SIP Session Establishment

When a caller wishes to send a SIP message (such as an INVITE, MESSAGE or SUBSCRIBE), the caller must first locate the peer where this callee's information resides using the resource search procedure described in the section titled Resource Location. (Querying Resource Registrations)

Establishing a session is done entirely in the normal SIP fashion after the user is located using the P2P resource query. Once the peer responsible for the Resource-ID is located, it will provide either a 200, providing a contact for the users UA, or will provide a 404 if the user is not registered. If a 200 with a valid contact is received, the call will then be initiated directly with the UAS of the called using the standard RFC 3261 fashion. If necessary for NAT traversal, the INVITE can be processed by routing it through the overlay using TRANSPORT-TUNNEL or through a connection established with TRANSPORT-OPEN.

9.6.  Offline Storage

Delivery of messages to offline users, or voicemail for voice applications, requires storing that information for later retrieval. Storing user configuration information in a format accessible from the network also will allow a user to retrieve their profile from any computer. Cao et al. (Cao, F., Bryan, D., and B. Lowekamp, “Providing Secure Services in Peer-to-Peer Communications Networks with Central Security Server,” February 2006.) [22] describe an approach that separates the storage of resource location information from the actual storage of the offline resource. We believe that this approach is in agreement with the approach taken by the rest of this document, which relies on the DHT overlay to store the registrar's location information, but relies on external, conventional methods for the actual connection. For offline storage, it also allows the use of other standard protocols to store and retrieve the offline information, keeping the P2PSIP scope restricted to storing resource mappings.

10.  Pluggable DHT Algorithm Requirements

All RELOAD peers MUST support the Chord pluggable DHT algorithm for compatibility. They MAY support additional pluggable algorithms. The requirements for new pluggable algorithms are defined in this section.

Pluggable algorithm MUST use Peer-IDs and Resource-IDs as defined in Hash Algorithms and Identifiers (Hash Algorithms and Identifiers) Pluggable algorithms are free to define what hash algorithms they support, but they MUST clearly specify what they are.

A resource with Resource-ID k will be stored by the peer with Peer-ID closest to the Resource-ID. The definition of closeness may vary in different DHT algorithms, but each DHT algorithm MUST guarantee Resource-ID searches converge to exactly one peer responsible for that portion of the namespace. As peers enter and leave, resources may be stored on different peers, so the information related to them is exchanged as peers enter and leave. Redundancy is used to protect against loss of information in the event of a peer failure.

Each new DHT algorithm MUST define a value for the DHT 8 bit field to be used in the DHT field of the RELOAD message header, defined in Message Header Syntax (Message Header).

Each new DHT algorithm MUST define DHT-SPECIFIC Methods and any DHT-SPECIFIC attributes that are to be used and understood in RELOAD messages.

11.  Security Considerations

The goal of P2PSIP is to scale gracefully from ad hoc groups of a few people to an overlay of millions of peers across the globe. As such, there is no one security model that fits the needs of all envisioned environments; for the small network establishing a certificate chain is ludicrously difficult, while for a global network the unrestricted ability to insert resources and devise useful Peer IDs is a clear invitation to insecurity. Any P2PSIP protocol must offer a range of security models that can be selected according to the needs of the overlay.

11.1.  Threat Model

Without other security, the attacker is able to generate an ID and become a valid peer in the system. They can see other peers and process certain queries. Attackers may wish to receive communications intended for other participants, prevent other users from receiving their messages, prevent large portions of the users from receiving messages, or send messages that appear to be from others. Users would like to be sure they are communicating with the same person they have previously talked to, to be able to verify identity via some out of band mechanism. Attackers may try to squat on all the good names. Users would like names that are meaningful to them. Attackers may have computers that are many times faster than the average user's. Attackers may be able to DOS other particular peers and make them fail. To make a robust DHT, many peers need to store information on behalf of the community. Peers may lie about this and not store the information. Attackers may wish to see who is communicating with whom and how much data is getting communicated.

Many of the threats to P2PSIP are also threats to conventional SIP. As such, P2PSIP imports much of its security from conventional SIP. However, because conventional SIP generally relies on secure servers to maintain the integrity of the system, modifications to those techniques are required to maintain the same level of security.

11.2.  Protecting the ID Namespace

The fundamental protection that P2PSIP relies on is protecting the ID namespace. In particular, many of the attacks on P2PSIP require identifying a particular portion of the ID space and acquiring control of that space. This is a common vector both for attacks on a particular user, by obtaining control of the location in the overlay where the user is registered, and on the overlay itself, by means of a Sybil (Douceur, J., “The Sybil Attack,” March 2002.) [23] attack when one is able to insert multiple identities at different locations on the ring.

The P2PSIP ID Namespace is considered protected when an attacker is not able to select an arbitrary Peer-ID and insert a peer at the location by convincing other peers to route traffic to them. This protects against hijacking and DoS attacks. The ID Namespace may also be protected by restricting admission to the overlay to some authorized (and trusted) set of individuals.

11.2.1.  Protection Using ID Hashing

One method for determining Peer-IDs is hashing the peer's IP address and appending the port number. The security of this scheme depends on the ease with which an attacker can choose their own Peer-ID. Because the port number is only appended to the Peer-ID, an attacker gains nothing by selecting different ports on the same node. Assuming that the SHA1 hash used to calculate the Peer-ID is reliably random, the attacker's ability to succeed depends on the number of separate IP addresses that they are able to obtain from which to launch their attacks.

In the current predominantly IPV4 Internet, few attackers have access to more than a handful of IP addresses, perhaps a few hundred at worst. For a large-scale P2P system, this is unlikely to provide the ability to hijack a particular user ID or control a sufficient portion of the network to affect other peers, in particular when registrations are replicated at independent peers. Ultimately, however, a sufficiently skilled and provisioned attacker can compromise this scheme.

As the Internet migrates to IPV6, however, it is unclear that the assumption that few attackers have access to a significant range of IP addresses will remain true. Therefore, hashing IP addresses to Peer-IDs is assumed to provide a diminishing amount of security in the future.

Even in the IPV4 Internet, however, it is frequently impossible to verify another peer's IP address. Because of the common use of NAT in the modern Internet, IP addresses are not necessarily transitive or reflexive. Therefore, a peer cannot generate a valid Peer ID for its IP address as seen by all other peers on the Internet. This problem makes hashed Peer-IDs essentially unverifiable in many situations.

Due to these shortcomings, we recommend UUIDs as the default technique for generating Peer IDs in the absence of other security schemes. While not offering any level of security, they do a better job of ensuring uniqueness than allowing multiple peers behind NATs to claim the PeerID corresponding to 192.168.1.100:5060.

11.2.2.  Cryptographic Protection

Stronger protection guarantees are possible by relying on cryptographic techniques to restrict the generation of peer IDs, either through requiring knowledge of a shared secret to calculate a valid hash or by issuing certificates through a central authority. These techniques are further described in Security for dSIP (Lowekamp, B. and J. Deverick, “Security Extensions for RELOAD,” July 2007.) [5].

11.3.  Protecting the resource namespace

The two primary vectors of attacks on resources in a P2PSIP overlay are inserting illegitimate resources into the overlay and corrupting the registrations for which a compromised peer is responsible.

For overlays that do not rely on certificates, once a peer has joined the overlay there are no restrictions on its ability to register resources. In an unsecured network, multiple peers can register the same resource (username) in the overlay. However, self-signed certificates (Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP),” March 2007.) [9] can be used to authenticate a user as the same user previously contacted with that certificate. Unless a conventional SIP authentication server is available, however, establishing identity upon initial contact is still a problem. One potential solution is for an overlay that is expected to persist over long time-frames to store the credentials of previous users for verification of a new registration. These techniques are beyond the scope of this document.

The second form of resource attack, which is really an ID attack, concerns the attacks that are possible when a peer has legitimately inserted itself into the overlay and is now responsible for storing resource registrations. Such an attack could occur through a corrupted peer or by an attacker who convinces the CA to issue them a certificate for a Peer-ID. In this case, the peer can corrupt any resource that is assigned to it. In the absence of certificates, the primary means of defense of such attacks is relying on replication. By storing replicas of each registration on multiple peers and performing parallel searches for resource lookup, the searching peer protects itself from a single peer trying to corrupt the namespace.

Further protection from each attack vector is achieved by relying on certificates for resource authentication [5] (Lowekamp, B. and J. Deverick, “Security Extensions for RELOAD,” July 2007.).

11.4.  Protecting the Routing

The DHT forms a complex routing table. When a peer joins, it may contact a subversive peer that lies about the finger table information it provides. The subversive peer could do this to try to trick the joining peer to route all the traffic to a subversive group of peers. Prevention of this attack relies on protecting the namespace and (for hashed namespaces) identifying trusted bootstrap peers to use when joining.

Resource searches are protected from a single subversive peer through the use of parallel searches on replicated registrations. Similar protection could be achieved through performing parallel searches using multiple bootstrap peers for initial join, but such specification is beyond the scope of this draft. When possible, securing the namespace is a better solution.

11.5.  Protecting the Signaling

The goal here is to stop an attacker from knowing who is signaling what to whom. An attacker being able to observe the activities of a specific individual is unlikely given the randomization of IDs and routing based on the present peers discussed above. Furthermore, because messages can be routed using only the header information, the actual body of the RELOAD message can be encrypted during transmission.

11.6.  Protecting the Media

As with conventional SIP, all the media SHOULD be encrypted. Negotiating encryption for an end-to-end media session should be performed in the same manner for P2PSIP communications.

11.7.  Replay Attacks

Defense against replay attacks is discussed in [5] (Lowekamp, B. and J. Deverick, “Security Extensions for RELOAD,” July 2007.).

12.  Open Issues

There are certainly many open issues. Here are a few.

OPEN ISSUE: Would just using a text-based (but very light -- not SIP or XML or SOAP) make better sense than binary?

OPEN ISSUE: is a SIP record-route concept needed to support NAT traversal?

OPEN ISSUE: Should the Frag-Offset be the byte offset of the fragment in the complete message or the fragment number? Likewise should the Frag-Length header field contain the total length of the complete message in bytes or the total number of fragments that make up the complete message?

OPEN ISSUE: It is possible to indicate what type of routing using the TTL field. If TTL is 0, assume iterative, otherwise assume recursive. Do we want to do this?

OPEN ISSUE: What are the best error numbers and reason phrases to use?

OPEN ISSUE: Can a resource registration fail?

OPEN ISSUE: Should we use 32 bits rather than 24 for length?

OPEN ISSUE: Is unwilling to proxy a good name for the 499 error? Something can also refuse to redirect...

OPEN ISSUE: Should we divide the attributes space between optional and mandatory? In STUN, attributes are split between mandatory and optional attributes. Mandatory attributes must be understood -- a client or server can process the message only if it understands the attribute. Optional attributes do not have to be understood -- the client or server can process the message even if it doesn't understand the attribute. STUN uses attributes less than or equal to 0x7fff for mandatory and greater than 0x7fff for optional.

OPEN ISSUE: The PEER-IP-PORT attribute is identical to the STUN attribute, but in this case we need to include a representation of the transport protocol in use. We propose to use the reserved octet at the beginning to include the IANA number for the protocol Section 5.2.4.2 (ROUTE-LOG.TRANSPORT), but another option is to extend the attribute by an additional word in between the first word and the Address.

OPEN ISSUE: do changes need to be made to ICE to support the other transport protocols?

OPEN ISSUE: Because RELOAD does not require the various mid-session media changes that are required for SIP, we we may not need to support subsequent offer/answer exchanges to update or improve the same session.

OPEN ISSUE: should there be support for a "port number" concept, or just protocol name?

OPEN ISSUE: What methods for identifying how to establish a SIP session should be specified by a P2PSIP protocol and what methods are up to the implementor? Should we add a "peerid" and "overlay" uri-param to SIP Contacts to facilitate tunneling or should such information be considered out-of-band to the SIP UA?

OPEN ISSUE: Should this draft specify selection of the appropriate method of direct connection, TRANSPORT-OPEN, or TRANSPORT-TUNNEL for establishing SIP sessions?

13.  Acknowledgments

Thanks to the P2PSIP community. A conversation with Jonathan Rosenberg resulted in the idea of drawing extensively from STUN for a binary protocol. As mentioned earlier, because many structures are the same as STUN, extensive work and even text has been incorporated in this document. The authors of this draft would like to thank the STUN authors.

14.  IANA Considerations

This document would require registering the several structures, types and numbers. The specific IANA considerations will be listed as the draft progresses.

15.  Change Log

15.1.  From draft-bryan-p2psip-reload-00

• Added descriptions of TRANSPORT methods for NAT traversal
• Fixed attribute ranges and specified reserved ranges for dht and security algorithms.
• Changes to align with security draft.

16.  References

16.1. Normative References

16.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).