P2PSIP D. Bryan
Internet-Draft M. Zangrilli
Intended status: Standards Track SIPeerior Technologies, Inc.
Expires: January 9, 2008 B. Lowekamp
SIPeerior; William & Mary
July 8, 2007
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 (C) 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
Bryan, et al. Expires January 9, 2008 [Page 1]
Internet-Draft RELOAD July 2007
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.
Bryan, et al. Expires January 9, 2008 [Page 2]
Internet-Draft RELOAD July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Evolution of RELOAD . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Peer-to-Peer Fundamentals . . . . . . . . . . . . . . . . 8
3.2. DHTs and Overlay Structure . . . . . . . . . . . . . . . . 8
3.3. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. The Architecture of RELOAD . . . . . . . . . . . . . . . . . . 9
4.1. P2P Overlay Structure . . . . . . . . . . . . . . . . . . 10
4.2. Use of Binary Messages in RELOAD . . . . . . . . . . . . . 11
4.3. P2PSIP Resources and Resource Registration . . . . . . . . 12
4.4. RELOAD Messages . . . . . . . . . . . . . . . . . . . . . 12
4.5. Routing in RELOAD . . . . . . . . . . . . . . . . . . . . 13
4.5.1. RELOAD Operations . . . . . . . . . . . . . . . . . . 14
4.6. Message Fragmentation . . . . . . . . . . . . . . . . . . 17
4.7. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 17
4.8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18
4.9. Signatures and Security . . . . . . . . . . . . . . . . . 18
5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Message Attributes . . . . . . . . . . . . . . . . . . . . 23
5.2.1. RESPONSE-CODE . . . . . . . . . . . . . . . . . . . . 25
5.2.2. SOURCE-INFO and PEER-INFO . . . . . . . . . . . . . . 26
5.2.3. RESOURCE and RESOURCE-INFO . . . . . . . . . . . . . . 28
5.2.4. ROUTE-LOG . . . . . . . . . . . . . . . . . . . . . . 31
5.2.5. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.6. SIGNATURE . . . . . . . . . . . . . . . . . . . . . . 32
5.2.7. SDP . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.8. APPLICATION . . . . . . . . . . . . . . . . . . . . . 33
5.3. Adding New Attributes . . . . . . . . . . . . . . . . . . 34
6. Hash Algorithms and Identifiers . . . . . . . . . . . . . . . 34
6.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 34
6.1.1. Peer-IDs . . . . . . . . . . . . . . . . . . . . . . . 34
7. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. SIP Session Establishment . . . . . . . . . . . . . . . . 36
8. Peer and DHT Operations . . . . . . . . . . . . . . . . . . . 36
8.1. Peer Registration . . . . . . . . . . . . . . . . . . . . 37
8.1.1. Constructing a Peer Registration . . . . . . . . . . . 37
8.1.2. Processing the Peer Registration . . . . . . . . . . . 38
8.2. Peer Query . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2.1. Constructing a Peer Query Message . . . . . . . . . . 40
8.2.2. Processing Peer Query Message . . . . . . . . . . . . 41
8.3. Populating the Joining Peer's Routing Table . . . . . . . 42
8.4. Transfering User Registrations . . . . . . . . . . . . . . 42
8.5. Peers Leaving the Overlay Gracefully . . . . . . . . . . . 42
8.6. NAT and Firewall Traversal . . . . . . . . . . . . . . . . 42
Bryan, et al. Expires January 9, 2008 [Page 3]
Internet-Draft RELOAD July 2007
8.7. Handling Failed Requests . . . . . . . . . . . . . . . . . 42
9. Resource Operations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Resource Registrations . . . . . . . . . . . . . . . . . . 43
9.2. Refreshing Resource Registrations . . . . . . . . . . . . 44
9.3. Removing Resource Registrations . . . . . . . . . . . . . 44
9.4. Querying Resource Registrations . . . . . . . . . . . . . 44
9.5. SIP Session Establishment . . . . . . . . . . . . . . . . 45
9.6. Offline Storage . . . . . . . . . . . . . . . . . . . . . 45
10. Pluggable DHT Algorithm Requirements . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 46
11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 47
11.2. Protecting the ID Namespace . . . . . . . . . . . . . . . 47
11.2.1. Protection Using ID Hashing . . . . . . . . . . . . . 48
11.2.2. Cryptographic Protection . . . . . . . . . . . . . . . 48
11.3. Protecting the resource namespace . . . . . . . . . . . . 49
11.4. Protecting the Routing . . . . . . . . . . . . . . . . . . 49
11.5. Protecting the Signaling . . . . . . . . . . . . . . . . . 50
11.6. Protecting the Media . . . . . . . . . . . . . . . . . . . 50
11.7. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 50
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 50
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 52
15.1. From draft-bryan-p2psip-reload-00 . . . . . . . . . . . . 52
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
16.1. Normative References . . . . . . . . . . . . . . . . . . . 52
16.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 56
Bryan, et al. Expires January 9, 2008 [Page 4]
Internet-Draft RELOAD July 2007
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 [16] has
emerged and a concepts and terminology [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 [18] P2PSIP project, it has changed extensively.
This works reflects experience gained in actually building
commercially available P2PSIP products [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 [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:
o 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.
o 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.
Bryan, et al. Expires January 9, 2008 [Page 5]
Internet-Draft RELOAD July 2007
o 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.
o 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.
o 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.
o 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.
o 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.
o Hierarchical encoding of message attributes, allowing the creation
of composite types and multi-valued attributes.
o 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.
o 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.
o Each key to value mapping has an individual expiration time. Thus
a single key can have both long-lived and transient registrations.
o 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.
o 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
Bryan, et al. Expires January 9, 2008 [Page 6]
Internet-Draft RELOAD July 2007
registration.
o 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.
o 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 [1].
Terminology defined in RFC 3261 [2] is used without definition.
We use the terminology and definitions from the Concepts and
Terminology for Peer to Peer SIP [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
Bryan, et al. Expires January 9, 2008 [Page 7]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 8]
Internet-Draft RELOAD July 2007
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 [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 [17] draft,
Bryan, et al. Expires January 9, 2008 [Page 9]
Internet-Draft RELOAD July 2007
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] and the
Bamboo algorithm for dSIP[4]. 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].
Bryan, et al. Expires January 9, 2008 [Page 10]
Internet-Draft 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
Bryan, et al. Expires January 9, 2008 [Page 11]
Internet-Draft RELOAD July 2007
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 [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
Bryan, et al. Expires January 9, 2008 [Page 12]
Internet-Draft RELOAD July 2007
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 [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:
o 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.
Bryan, et al. Expires January 9, 2008 [Page 13]
Internet-Draft RELOAD July 2007
o 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.
o 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.
o 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
(Section 4.7).
Following the iterative routing scheme, the bootstrap peer looks up
Bryan, et al. Expires January 9, 2008 [Page 14]
Internet-Draft RELOAD July 2007
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.
Bryan, et al. Expires January 9, 2008 [Page 15]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 16]
Internet-Draft RELOAD July 2007
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.
Bryan, et al. Expires January 9, 2008 [Page 17]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 18]
Internet-Draft RELOAD July 2007
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] 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 [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.
Bryan, et al. Expires January 9, 2008 [Page 19]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 20]
Internet-Draft RELOAD July 2007
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.
Bryan, et al. Expires January 9, 2008 [Page 21]
Internet-Draft RELOAD July 2007
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)
Bryan, et al. Expires January 9, 2008 [Page 22]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 23]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 24]
Internet-Draft RELOAD July 2007
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 [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.
Bryan, et al. Expires January 9, 2008 [Page 25]
Internet-Draft RELOAD July 2007
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:
Bryan, et al. Expires January 9, 2008 [Page 26]
Internet-Draft RELOAD July 2007
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 (Section 6).
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 [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
Bryan, et al. Expires January 9, 2008 [Page 27]
Internet-Draft RELOAD July 2007
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, 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
Bryan, et al. Expires January 9, 2008 [Page 28]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 29]
Internet-Draft RELOAD July 2007
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
(Section 5.2.2) 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
Bryan, et al. Expires January 9, 2008 [Page 30]
Internet-Draft RELOAD July 2007
(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
[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.
Bryan, et al. Expires January 9, 2008 [Page 31]
Internet-Draft RELOAD July 2007
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 (Section 5.2.2)
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 (Section 5.2.2).
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] 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 [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
[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
Bryan, et al. Expires January 9, 2008 [Page 32]
Internet-Draft RELOAD July 2007
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 [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.
Bryan, et al. Expires January 9, 2008 [Page 33]
Internet-Draft RELOAD July 2007
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 (Section 5.1) 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
Bryan, et al. Expires January 9, 2008 [Page 34]
Internet-Draft RELOAD July 2007
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 [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 SHOULD be used
to indicate if the next node should process the message using a
Bryan, et al. Expires January 9, 2008 [Page 35]
Internet-Draft RELOAD July 2007
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] 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
Bryan, et al. Expires January 9, 2008 [Page 36]
Internet-Draft RELOAD July 2007
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 (Section 5.2.2) 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
Bryan, et al. Expires January 9, 2008 [Page 37]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 38]
Internet-Draft RELOAD July 2007
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 (Section 5.2.5) 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
Bryan, et al. Expires January 9, 2008 [Page 39]
Internet-Draft RELOAD July 2007
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.
Bryan, et al. Expires January 9, 2008 [Page 40]
Internet-Draft RELOAD July 2007
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 (Section 5.2.2) 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
(Section 8.1.2.1) 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.
Bryan, et al. Expires January 9, 2008 [Page 41]
Internet-Draft RELOAD July 2007
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 (Section 8.3) should be performed.
Bryan, et al. Expires January 9, 2008 [Page 42]
Internet-Draft RELOAD July 2007
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
(Section 5.2.2) 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 (Section 8.1). 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
Bryan, et al. Expires January 9, 2008 [Page 43]
Internet-Draft RELOAD July 2007
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
Bryan, et al. Expires January 9, 2008 [Page 44]
Internet-Draft RELOAD July 2007
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].
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. (Section 9.4)
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. [22] describe an approach that separates the
storage of resource location information from the actual storage of
Bryan, et al. Expires January 9, 2008 [Page 45]
Internet-Draft RELOAD July 2007
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 (Section 6) 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 (Section 5.1).
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
Bryan, et al. Expires January 9, 2008 [Page 46]
Internet-Draft RELOAD July 2007
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 [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.
Bryan, et al. Expires January 9, 2008 [Page 47]
Internet-Draft RELOAD July 2007
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 [5].
Bryan, et al. Expires January 9, 2008 [Page 48]
Internet-Draft RELOAD July 2007
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 [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].
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
Bryan, et al. Expires January 9, 2008 [Page 49]
Internet-Draft RELOAD July 2007
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].
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?
Bryan, et al. Expires January 9, 2008 [Page 50]
Internet-Draft RELOAD July 2007
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, 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
Bryan, et al. Expires January 9, 2008 [Page 51]
Internet-Draft RELOAD July 2007
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
o Added descriptions of TRANSPORT methods for NAT traversal
o Fixed attribute ranges and specified reserved ranges for dht and
security algorithms.
o Changes to align with security draft.
16. References
16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Zangrilli, M. and D. Bryan, "A Chord-based DHT for Resource
Lookup in P2PSIP", Internet
Draft draft-zangrilli-p2psip-dsip-dhtchord-00, February 2007.
[4] Zangrilli, M. and D. Bryan, "A Bamboo-based DHT for Resource
Lookup in P2PSIP", Internet
Draft draft-zangrilli-p2psip-dsip-dhtbamboo-00, February 2007.
[5] Lowekamp, B. and J. Deverick, "Security Extensions for RELOAD",
Internet Draft draft-lowekamp-p2psip-reload-security-01,
July 2007.
[6] Rosenberg, J., "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-06 (work in progress), March 2007.
Bryan, et al. Expires January 9, 2008 [Page 52]
Internet-Draft RELOAD July 2007
[7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in
progress), June 2007.
[8] Rosenberg, J., "TCP Candidates with Interactive Connectivity
Establishment (ICE", draft-ietf-mmusic-ice-tcp-03 (work in
progress), March 2007.
[9] Jennings, C., "Certificate Management Service for The Session
Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in
progress), March 2007.
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[12] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[13] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[14] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[15] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in
progress), March 2007.
16.2. Informative References
[16] Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer-to-
Peer Session Initiation Protocol (P2PSIP)", Internet
Draft draft-bryan-sipping-p2p-usecases-00, November 2005.
[17] Willis, D., "Concepts and Terminology for Peer to Peer SIP",
draft-willis-p2psip-concepts-04 (work in progress), March 2007.
[18] Bryan, D., Jennings, C., and B. Lowekamp, "SOSIMPLE: A
Serverless, Standards-based, P2P SIP Communication System",
Proceedings of the 2005 International Workshop on Advanced
Architectures and Algorithms for Internet Delivery and
Applications (AAA-IDEA) '05, June 2005.
Bryan, et al. Expires January 9, 2008 [Page 53]
Internet-Draft RELOAD July 2007
[19] "SIPeerior Technologies, Inc., Website, www.SIPeerior.com".
[20] Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P Approach
to SIP Registration and Resource Location", Internet
Draft draft-bryan-p2psip-dsip-00, February 2007.
[21] Matthews, P., Cooper, E., Bryan, D., and B. Lowekamp, "NAT
Traversal for dSIP", Internet
Draft draft-matthews-p2psip-dsip-nat-traversal-00,
February 2007.
[22] Cao, F., Bryan, D., and B. Lowekamp, "Providing Secure Services
in Peer-to-Peer Communications Networks with Central Security
Server", Internation Conference on Internet and Web
Applications and Services (ICIW) '06, February 2006.
[23] Douceur, J., "The Sybil Attack", IPTPS '02, March 2002.
Authors' Addresses
David A. Bryan
SIPeerior Technologies, Inc.
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: dbryan@sipeerior.com
Marcia Zangrilli
SIPeerior Technologies, Inc.
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone:
Email: marcia@sipeerior.com
Bryan, et al. Expires January 9, 2008 [Page 54]
Internet-Draft RELOAD July 2007
Bruce B. Lowekamp
SIPeerior; William & Mary
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: lowekamp@sipeerior.com
Bryan, et al. Expires January 9, 2008 [Page 55]
Internet-Draft RELOAD July 2007
Full Copyright Statement
Copyright (C) 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).
Bryan, et al. Expires January 9, 2008 [Page 56]