Imported debug from /usr/lib/site-python/debug.pyc draft-bryan-p2psip-reload-00 - REsource LOcation And Discovery (RELOAD)
[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 draft-ietf-p2psip-reload

P2PSIP                                                          D. Bryan
Internet-Draft                                              M. Zangrilli
Intended status: Standards Track            SIPeerior Technologies, Inc.
Expires: December 22, 2007                                   B. Lowekamp
                                               SIPeerior; William & Mary
                                                           June 20, 2007


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

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 December 22, 2007.

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 December 22, 2007               [Page 1]


Internet-Draft                   RELOAD                        June 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 December 22, 2007               [Page 2]


Internet-Draft                   RELOAD                        June 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  . . . . . . . . . . . . . . . . . . . . . . 30
       5.2.5.  REDIRECT . . . . . . . . . . . . . . . . . . . . . . . 31
       5.2.6.  SIGNATURE  . . . . . . . . . . . . . . . . . . . . . . 31
     5.3.  Adding New Attributes  . . . . . . . . . . . . . . . . . . 31
   6.  Hash Algorithms and Identifiers  . . . . . . . . . . . . . . . 31
     6.1.  Hash Algorithms  . . . . . . . . . . . . . . . . . . . . . 32
       6.1.1.  Peer-IDs . . . . . . . . . . . . . . . . . . . . . . . 32
   7.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 33
     7.1.  Session Establishment  . . . . . . . . . . . . . . . . . . 33
   8.  Peer and DHT Operations  . . . . . . . . . . . . . . . . . . . 34
     8.1.  Peer Registration  . . . . . . . . . . . . . . . . . . . . 34
       8.1.1.  Constructing a Peer Registration . . . . . . . . . . . 34
       8.1.2.  Processing the Peer Registration . . . . . . . . . . . 35
     8.2.  Peer Query . . . . . . . . . . . . . . . . . . . . . . . . 37
       8.2.1.  Constructing a Peer Query Message  . . . . . . . . . . 37
       8.2.2.  Processing Peer Query Message  . . . . . . . . . . . . 38
     8.3.  Populating the Joining Peer's Routing Table  . . . . . . . 38
     8.4.  Transfering User Registrations . . . . . . . . . . . . . . 39
     8.5.  Peers Leaving the Overlay Gracefully . . . . . . . . . . . 39
     8.6.  NAT and Firewall Traversal . . . . . . . . . . . . . . . . 39
     8.7.  Handling Failed Requests . . . . . . . . . . . . . . . . . 39
   9.  Resource Operations  . . . . . . . . . . . . . . . . . . . . . 39



Bryan, et al.           Expires December 22, 2007               [Page 3]


Internet-Draft                   RELOAD                        June 2007


     9.1.  Resource Registrations . . . . . . . . . . . . . . . . . . 39
     9.2.  Refreshing Resource Registrations  . . . . . . . . . . . . 41
     9.3.  Removing Resource Registrations  . . . . . . . . . . . . . 41
     9.4.  Querying Resource Registrations  . . . . . . . . . . . . . 41
     9.5.  SIP Session Establishment  . . . . . . . . . . . . . . . . 42
     9.6.  Offline Storage  . . . . . . . . . . . . . . . . . . . . . 42
   10. Pluggable DHT Algorithm Requirements . . . . . . . . . . . . . 42
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 43
     11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 43
     11.2. Protecting the ID Namespace  . . . . . . . . . . . . . . . 44
       11.2.1. Protection Using ID Hashing  . . . . . . . . . . . . . 44
       11.2.2. Cryptographic Protection . . . . . . . . . . . . . . . 45
     11.3. Protecting the resource namespace  . . . . . . . . . . . . 45
     11.4. Protecting the Routing . . . . . . . . . . . . . . . . . . 46
     11.5. Protecting the Signaling . . . . . . . . . . . . . . . . . 46
     11.6. Protecting the Media . . . . . . . . . . . . . . . . . . . 47
     11.7. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 47
   12. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 47
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 48
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 48
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 48
     15.2. Informative References . . . . . . . . . . . . . . . . . . 49
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
   Intellectual Property and Copyright Statements . . . . . . . . . . 51


























Bryan, et al.           Expires December 22, 2007               [Page 4]


Internet-Draft                   RELOAD                        June 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 [17] has
   emerged and a concepts and terminology [18] 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 [19] P2PSIP project, it has changed extensively.
   This works reflects experience gained in actually building
   commercially available P2PSIP products [20] based on this draft, as
   well as from extensive work/insight gleaned from the P2PSIP mailing
   list.

1.1.  Evolution of RELOAD

   The dSIP [1] 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 December 22, 2007               [Page 5]


Internet-Draft                   RELOAD                        June 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 December 22, 2007               [Page 6]


Internet-Draft                   RELOAD                        June 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 [2].

   Terminology defined in RFC 3261 [3] is used without definition.

   We use the terminology and definitions from the Concepts and
   Terminology for Peer to Peer SIP [18] 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 December 22, 2007               [Page 7]


Internet-Draft                   RELOAD                        June 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 December 22, 2007               [Page 8]


Internet-Draft                   RELOAD                        June 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 [18] 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 [18] draft,



Bryan, et al.           Expires December 22, 2007               [Page 9]


Internet-Draft                   RELOAD                        June 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 [4] and the
   Bamboo algorithm for dSIP[5].  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.  The concept of using a certificate based was



Bryan, et al.           Expires December 22, 2007              [Page 10]


Internet-Draft                   RELOAD                        June 2007


   described in[6].

   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



Bryan, et al.           Expires December 22, 2007              [Page 11]


Internet-Draft                   RELOAD                        June 2007


   message.  The contents of the message following the header are TLV-
   encoded, which allows a parser to quickly locate and parse those
   portions of the message that it needs while expending no processing
   time on those that are not needed.  Much of this binary P2P Peer
   Protocol is modeled after the binary STUN [7] 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.




Bryan, et al.           Expires December 22, 2007              [Page 12]


Internet-Draft                   RELOAD                        June 2007


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

   The transport methods are used to facilitate NAT and firewall
   traversal.  The OPEN transport method provides a control connection
   that can be used by ICE [8] to establish a direct connection between
   two peers for future RELOAD messages (or other protocols).  The
   TUNNEL method is used to encapsulate SIP (or other protocol) messages
   in a RELOAD message that is routed across the overlay.  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 December 22, 2007              [Page 13]


Internet-Draft                   RELOAD                        June 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 December 22, 2007              [Page 14]


Internet-Draft                   RELOAD                        June 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 December 22, 2007              [Page 15]


Internet-Draft                   RELOAD                        June 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 December 22, 2007              [Page 16]


Internet-Draft                   RELOAD                        June 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.
   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.




Bryan, et al.           Expires December 22, 2007              [Page 17]


Internet-Draft                   RELOAD                        June 2007


   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.

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

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

4.9.  Signatures and Security

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

   The term "signature" here encompasses an opaque type that is not
   defined in this document.  These attributes are to be defined by the
   security mechanism being used by the overlay.  In particular, there
   is no content in the RELOAD message as specified in this document
   that prevents replay attacks.  Therefore, a basic security mechanism



Bryan, et al.           Expires December 22, 2007              [Page 18]


Internet-Draft                   RELOAD                        June 2007


   is likely to include at least a signature and timestamp in the
   SIGNATURE type it specifies.


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 [7]
   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 December 22, 2007              [Page 19]


Internet-Draft                   RELOAD                        June 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       d       |       S       |       I       |       P       |
   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 December 22, 2007              [Page 20]


Internet-Draft                   RELOAD                        June 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.

   SHA-1       : 0x01

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



Bryan, et al.           Expires December 22, 2007              [Page 21]


Internet-Draft                   RELOAD                        June 2007


   NONE         : 0x01

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

   REQUEST       : 0x0
   RESPONSE      : 0x1

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

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

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

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

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

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

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

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

   The Transaction ID is a unique 64 bit number that identifies this
   transaction and also serves as a salt to randomize the request and



Bryan, et al.           Expires December 22, 2007              [Page 22]


Internet-Draft                   RELOAD                        June 2007


   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

   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.




Bryan, et al.           Expires December 22, 2007              [Page 23]


Internet-Draft                   RELOAD                        June 2007


   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


                    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


                      Tranport  Transport  Transport  Transport
                      invite    invite     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



Bryan, et al.           Expires December 22, 2007              [Page 24]


Internet-Draft                   RELOAD                        June 2007


   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 [7] ERROR-CODE attribute, and
   provides the response status code for the message.  The RESPONSE-CODE
   attribute value is a numeric value in the range of 100 to 600 plus a
   textual reason phrase encoded in UTF-8.  The length of the reason
   phrase is the length prior to padding.

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

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

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

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

   The following response codes and recommended reason phrases (in
   brackets) are defined at this time:
   200 (OK):  Indicates a successful request.  The information returned
      in the response will depend on the request method.
   302 (Moved Temporarily):  The requesting peer SHOULD retry the
      request at the new address specified in the 302 response message.






Bryan, et al.           Expires December 22, 2007              [Page 25]


Internet-Draft                   RELOAD                        June 2007


   404 (Not Found):  The resource or peer cannot be found or does not
      exist.
   408 (Request Timeout):  A response to the request has not been
      received in a suitable amount of time.  The requesting peer MAY
      resend the request at a later time.
   498 (Incompatible with Overlay)  A peer receiving the request is
      using a different overlay, DHT algorithm, or hash algorithm.  OPEN
      ISSUE: What is the best error number and reason phrase to use?
   499 (UnWilling To Proxy)  A peer receiving the request is unwilling
      to support the Routing mechanism specified in the Routing field of
      the message header.  OPEN ISSUE: What is the best error number and
      reason phrase to use?

5.2.2.  SOURCE-INFO and PEER-INFO

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

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

   PEER-ID           : 0x07D1
   PEER-NAME         : 0x07D2
   PEER-IP-PORT      : 0x07D3
   PEER-EXPIRATION   : 0x07D4
   PEER-CERTIFCATE   : 0x07D5
   PEER-SIGNATURE    : 0x07D6

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.






Bryan, et al.           Expires December 22, 2007              [Page 26]


Internet-Draft                   RELOAD                        June 2007


5.2.2.3.  PEER-IP-PORT

   PEER-IP-PORT is based on STUN's [7] 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).

   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



Bryan, et al.           Expires December 22, 2007              [Page 27]


Internet-Draft                   RELOAD                        June 2007


   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        : 0x0BB9
   RESOURCE-INFO.BODY       : 0x0BBA

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          : 0x0BBB
   RESOURCE-INFO.BODY.PARAMETER      : 0x0BBC
   RESOURCE-INFO.BODY.EXPIRATION     : 0x0BBD
   RESOURCE-INFO.BODY.SIGNATURE      : 0x0BBE
   RESOURCE-INFO.BODY.PEER-INFO      : 0x0BBF

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



Bryan, et al.           Expires December 22, 2007              [Page 28]


Internet-Draft                   RELOAD                        June 2007


   "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    : 0x0BC0
   RESOURCE-INFO.BODY.PARAMETER.OP      : 0x0BC1
   RESOURCE-INFO.BODY.PARAMETER.VALUE   : 0x0BC2

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

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

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

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

5.2.3.5.  RESOURCE-INFO.BODY.EXPIRATION

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

5.2.3.6.  RESOURCE-INFO.BODY.SIGNATURE

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






Bryan, et al.           Expires December 22, 2007              [Page 29]


Internet-Draft                   RELOAD                        June 2007


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
   (using 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
   [3] 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       : 0x0FA0
   ROUTE-LOG.TRANSPORT            : 0x0FA1
   ROUTE-LOG.PEER-INFO            : 0x0FA2

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



Bryan, et al.           Expires December 22, 2007              [Page 30]


Internet-Draft                   RELOAD                        June 2007


   ROUTE-LOG.TRANSPORT.SCTP      : 0x0084

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

5.2.4.3.  ROUTE-LOG.PEER-INFO

   ROUTE-LOG.PEER-INFO provides information about the peer at each hop
   along the path.  The syntax of ROUTE-LOG.PEER-INFO is identical to
   the PEER-INFO syntax described above in the SOURCE-INFO and PEER-INFO
   section (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.

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.

   TODO: split up the attribute space so we can specify which range of
   attribute values (hex numbers) can be used by pluggable DHT
   algorithms.


6.  Hash Algorithms and Identifiers






Bryan, et al.           Expires December 22, 2007              [Page 31]


Internet-Draft                   RELOAD                        June 2007


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





Bryan, et al.           Expires December 22, 2007              [Page 32]


Internet-Draft                   RELOAD                        June 2007


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

7.1.  Session Establishment

   If the peer needs to have the session establishment routed through
   the overlay, it MAY use the TRANSPORT-OPEN or TRANSPORT-TUNNEL
   messages to request that intermediate nodes proxy the invite over the
   overlay on their behalf.  This is particularly critical for NAT
   traversal [9].




Bryan, et al.           Expires December 22, 2007              [Page 33]


Internet-Draft                   RELOAD                        June 2007


8.  Peer and DHT Operations

8.1.  Peer Registration

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

8.1.1.  Constructing a Peer Registration

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

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

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

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

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

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

   The joining peer SHOULD also list its peer information in a SOURCE-
   INFO attribute in the body of the message.  See section SOURCE-INFO
   and PEER-INFO (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



Bryan, et al.           Expires December 22, 2007              [Page 34]


Internet-Draft                   RELOAD                        June 2007


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

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

8.1.2.  Processing the Peer Registration

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

8.1.2.1.  Routing the Peer Registration

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



Bryan, et al.           Expires December 22, 2007              [Page 35]


Internet-Draft                   RELOAD                        June 2007


   In the case of iterative routing, if the receiving peer is not
   responsible for the area of the hash table where Peer-ID should be
   stored, the peer SHOULD generate a 302 message.  The receiving peer
   MUST look in its list of neighbors or in the routing table to find
   the peer with Peer-ID nearest the to joining peer's Peer-ID, and use
   it to create a Redirect attribute in the form of a PEER-INFO, as
   specified in the REDIRECT (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 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.  A receiving peer receiving a join
   request from the joining peer and proxying that request MUST TUNNEL
   the message to the destination ID.  This ensures that the reply can
   be routed back to the bootstrap peer, which is the only peer known to
   have an establish connection with the joining peer.  A recursive join
   request SHOULD also include an OPEN.

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

   TODO show example of redirect.

8.1.2.2.  Admitting the Joining Peer

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

   The admitting peer MUST reply with a 200 response if the admitting
   peer's Peer-ID is the closest to the joining peer's Peer-ID.  Each
   DHT algorithm MAY choose to define closest however they want, but the



Bryan, et al.           Expires December 22, 2007              [Page 36]


Internet-Draft                   RELOAD                        June 2007


   DHT algorithm MUST be able to deterministically find the closest
   Peer-ID.  The admitting peer must populate any DHT-SPECIFIC
   attributes with all values required by the DHT routing protocol so
   that the joining peer can initialize its neighbors and routing table
   entries or sent additional DHT-SPECIFIC messages.  Additionally, the
   admitting peer MUST include its peer information in the SOURCE-INFO
   attribute of the response.

8.2.  Peer Query

8.2.1.  Constructing a Peer Query Message

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

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

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

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

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

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

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

   The searching peer SHOULD also list its peer information in a SOURCE-
   INFO attribute in the body of the message.  See section SOURCE-INFO
   and PEER-INFO (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



Bryan, et al.           Expires December 22, 2007              [Page 37]


Internet-Draft                   RELOAD                        June 2007


   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.

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.



Bryan, et al.           Expires December 22, 2007              [Page 38]


Internet-Draft                   RELOAD                        June 2007


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.  We discuss mechanisms to address these problems in [9].

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.


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



Bryan, et al.           Expires December 22, 2007              [Page 39]


Internet-Draft                   RELOAD                        June 2007


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





Bryan, et al.           Expires December 22, 2007              [Page 40]


Internet-Draft                   RELOAD                        June 2007


9.2.  Refreshing Resource Registrations

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

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

9.3.  Removing Resource Registrations

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

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

9.4.  Querying Resource Registrations

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

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

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

   A P2P environment can do little to protect against an individual peer
   compromising the registrations it is responsible for.  Accordingly, a
   UA cannot trust a response from a single peer, whether it indicates a
   successful search or an error.  In the absence of other methods of



Bryan, et al.           Expires December 22, 2007              [Page 41]


Internet-Draft                   RELOAD                        June 2007


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

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 TUNNEL. [9].

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. [21] describe an approach that separates the
   storage of resource location information from the actual storage of
   the offline resource.  We believe that this approach is in agreement
   with the approach taken by the rest of this document, which relies on
   the DHT overlay to store the registrar's location information, but
   relies on external, conventional methods for the actual connection.
   For offline storage, it also allows the use of other standard
   protocols to store and retrieve the offline information, keeping the
   P2PSIP scope restricted to storing resource mappings.


10.  Pluggable DHT Algorithm Requirements

   All RELOAD peers MUST support the Chord pluggable DHT algorithm for
   compatibility.  They MAY support additional pluggable algorithms.



Bryan, et al.           Expires December 22, 2007              [Page 42]


Internet-Draft                   RELOAD                        June 2007


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



Bryan, et al.           Expires December 22, 2007              [Page 43]


Internet-Draft                   RELOAD                        June 2007


   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 [22] attack when one is able to insert multiple identities at
   different locations on the ring.

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

11.2.1.  Protection Using ID Hashing

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

   In the current predominantly IPV4 Internet, few attackers have access
   to more than a handful of IP addresses, perhaps a few hundred at
   worst.  For a large-scale P2P system, this is unlikely to provide the



Bryan, et al.           Expires December 22, 2007              [Page 44]


Internet-Draft                   RELOAD                        June 2007


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

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 [10] 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



Bryan, et al.           Expires December 22, 2007              [Page 45]


Internet-Draft                   RELOAD                        June 2007


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

11.4.  Protecting the Routing

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

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

11.5.  Protecting the Signaling

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





Bryan, et al.           Expires December 22, 2007              [Page 46]


Internet-Draft                   RELOAD                        June 2007


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


12.  Open Issues

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

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

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

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

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

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

   OPEN ISSUE: Can a resource registration fail?

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

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

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



Bryan, et al.           Expires December 22, 2007              [Page 47]


Internet-Draft                   RELOAD                        June 2007


   0x7fff for mandatory and greater than 0x7fff for optional.


13.  Acknowledgments

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


14.  IANA Considerations

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


15.  References

15.1.  Normative References

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

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

   [4]   Zangrilli, M. and D. Bryan, "A Chord-based DHT for Resource
         Lookup in P2PSIP", Internet
         Draft draft-zangrilli-p2psip-dsip-dhtchord-00, February 2007.

   [5]   Zangrilli, M. and D. Bryan, "A Bamboo-based DHT for Resource
         Lookup in P2PSIP", Internet
         Draft draft-zangrilli-p2psip-dsip-dhtbamboo-00, February 2007.

   [6]   Lowekamp, B. and J. Deverick, "Authenticated Identity
         Extensions to dSIP", Internet
         Draft draft-lowekamp-p2psip-dsip-security-00, February 2007.

   [7]   Rosenberg, J., "Session Traversal Utilities for (NAT) (STUN)",



Bryan, et al.           Expires December 22, 2007              [Page 48]


Internet-Draft                   RELOAD                        June 2007


         draft-ietf-behave-rfc3489bis-06 (work in progress), March 2007.

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

   [9]   Cooper, E., Matthews, P., Bryan, D., and B. Lowekamp, "NAT
         Traversal for dSIP", Internet
         Draft draft-matthews-p2psip-dsip-nat-traversal-00,
         February 2007.

   [10]  Jennings, C., "Certificate Management Service for The Session
         Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in
         progress), March 2007.

   [11]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
         Preferences for the Session Initiation Protocol (SIP)",
         RFC 3841, August 2004.

   [12]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [13]  Leach, P., Mealling, M., and R. Salz, "A Universally Unique
         IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

   [14]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
         RFC 3174, September 2001.

   [15]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation Protocol (SIP)",
         RFC 4474, August 2006.

   [16]  Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
         Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in
         progress), March 2007.

15.2.  Informative References

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

   [18]  Willis, D., "Concepts and Terminology for Peer to Peer SIP",
         draft-willis-p2psip-concepts-04 (work in progress), March 2007.

   [19]  Bryan, D., Jennings, C., and B. Lowekamp, "SOSIMPLE: A
         Serverless, Standards-based, P2P SIP Communication System",



Bryan, et al.           Expires December 22, 2007              [Page 49]


Internet-Draft                   RELOAD                        June 2007


         Proceedings of the 2005 International Workshop on Advanced
         Architectures and Algorithms for Internet Delivery and
         Applications (AAA-IDEA) '05, June 2005.

   [20]  "SIPeerior Technologies, Inc., Website, www.SIPeerior.com".

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

   [22]  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


   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 December 22, 2007              [Page 50]


Internet-Draft                   RELOAD                        June 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 December 22, 2007              [Page 51]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/