SIPPING WG E. Shim Internet-Draft S. Narayanan Expires: August 30, 2006 G. Daley Panasonic February 26, 2006 An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP) draft-shim-sipping-p2p-arch-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 August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an architecture for peer-to-peer SIP systems in which a separate and independent peer-to-peer overlay layer provides a distributed resource placement and search service for SIP. It also aims to help identify what should be specified for interoperation. Shim, et al. Expires August 30, 2006 [Page 1] Internet-Draft P2P SIP Use Cases February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Scope of the architecture document . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 4. SIP entity operations . . . . . . . . . . . . . . . . . . . . 8 4.1 P2P UA Behavior . . . . . . . . . . . . . . . . . . . . . 9 4.2 P2P Proxy Behavior . . . . . . . . . . . . . . . . . . . . 9 4.3 P2P Registrar Behavior . . . . . . . . . . . . . . . . . . 10 4.4 Example Call Flows . . . . . . . . . . . . . . . . . . . . 11 4.4.1 Call Flow between P2P UAs . . . . . . . . . . . . . . 11 4.4.2 Call Flow between CS UA and P2P UA within the same domain . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Peer Initiation . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Association and Authentication . . . . . . . . . . . . . . 16 5.3 Association . . . . . . . . . . . . . . . . . . . . . . . 16 5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . 17 5.5 NAT/FW Traversal . . . . . . . . . . . . . . . . . . . . . 17 6. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Becoming a Super Node . . . . . . . . . . . . . . . . . . . . 18 8. Formats of Resource Records for SIP . . . . . . . . . . . . . 19 9. P2P Overlay API . . . . . . . . . . . . . . . . . . . . . . . 20 10. What Needs To Be Specified . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . 23 11.1 Bootstrapping Security . . . . . . . . . . . . . . . . . . 23 11.2 ON/SN Authentication . . . . . . . . . . . . . . . . . . . 23 11.3 Peer Transport Security . . . . . . . . . . . . . . . . . 23 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 24 11.5 Network Address Translators . . . . . . . . . . . . . . . 24 11.6 Registration . . . . . . . . . . . . . . . . . . . . . . . 24 11.7 Session Endpoint Discovery and Security . . . . . . . . . 25 11.8 Ill Behavior of Ordinary Nodes . . . . . . . . . . . . . . 25 11.9 Ill Behavior of Super Nodes . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1 Normative References . . . . . . . . . . . . . . . . . . . 26 13.2 Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 29 Shim, et al. Expires August 30, 2006 [Page 2] Internet-Draft P2P SIP Use Cases February 2006 1. Introduction The Session Initiation Protocol (SIP) [1] has been used largely in the client/server model. In the client/server model, the User Agent nodes, being client nodes, typically use services provided by dedicated server nodes such as SIP Proxy, SIP Registrar, and location server. Those servers are physically different from the nodes with User Agents, statically configured to play their roles, and managed by administrators. In comparison, in the Peer-to-peer (P2P) networking model, the participating nodes, or peers, which are sharing their computing and networking resources, perform all or some of the server functions in a distributed fashion, thus eliminating need for all or some of the dedicated servers. There are two fundamental functions required to realize the P2P networking model. First, the peers, distributed randomly over the physical network, should be able to form an overlay network, which is managed in an automatic and distributed fashion. This function is called herein the P2P overlay management function that mainly handles peers joining and leaving the overlay network. Second, the peers should be able to discover resources that are distributed among the peers, and furthermore, should be able to place resources among the peers when remote peers dynamically create the resources for use. This function is called the P2P Service Function that mainly handles lookup and placement of resources. The above two functions together are referred to as 'the P2P overlay functions'. SIP can be used in the P2P networking model. In particular, the P2P service function can be used to provide a distributed location service for SIP. For convenience of presentation, SIP operating in the P2P networking model is called 'P2P SIP (Peer-to-Peer Session Initiation Protocol)'. 1.1 Scope of the architecture document This document aims to describe an architecture for systems based on P2P SIP. The key characteristic of the P2P SIP architecture is that a separate layer, independent of SIP, provides the P2P overlay functions and SIP is an application using the services of the layer. In this document, the components of the P2P overlay network are identified along with the specification of the overall network architecture of the P2P overlay. This document also defines new P2P SIP logical entities and their behavior corresponding to the logical entities (UA, Proxy, Registrar) defined by the SIP specification. Example call procedures are presented to demonstrate how these new P2P SIP entities will operate to establish SIP signaling. The initiation procedure required for a new peer to become part of the P2P overlay is also specified. This version of the document assumes Shim, et al. Expires August 30, 2006 [Page 3] Internet-Draft P2P SIP Use Cases February 2006 all the peers in the network are well-behaved nodes and thus ignores the possible denial of service problems due to nodes not contributing to the well being of the overlay, in the main text. An initial discussion on this is provided in the Security Considerations Section 11. This is an important problem that will be addressed in future versions of the document. 2. Terminology In this document, words which are normally key words, such as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are used COLLOQUIALLY and are not intended to be interpreted as described in RFC2119 [1]. Peer-to-Peer (P2P) Architecture: An architecture in which nodes (peers) cooperate together to perform tasks. Each node has essentially equal importance and performs the same tasks within the network. Additionally, nodes communicate directly with one another to perform tasks. Occasionally, nodes with better resources (such as not being behind NATs) may have a more significant role. (P2P Overlay) Bootstrapping: Finding a peer already participating in the target P2P overlay network in order to join the P2P overlay network. Bootstrap seed(s): A super node on the P2P overlay network that is used as the first point of contact for new P2P entities coming online. Bootstrap server(s): A server on the network that provides a peer with the address of a node already in the P2P overlay network. Neighbor or Neighboring Peer: A peer whose contact information such as IP address is known and maintained by the local peer. P2P Overlay Entity: An entity in the protocol stack that implements the P2P overlay functions. P2P Overlay Functions: The P2P overlay management function and the P2P service function. P2P Overlay Layer: A protocol layer that handles the P2P overlay functions. P2P Overlay Management Function: Peer initiation and handling join and leave of peers to maintain a P2P overlay network. P2P Proxy: A SIP proxy on a device with the P2P overlay layer. P2P Registrar: A SIP registrar on a device with the P2P overlay layer. P2P Service Function: Placing resources on certain peers and discovering locations of target resources in the P2P overlay network, in short, placement and lookup of resources. Shim, et al. Expires August 30, 2006 [Page 4] Internet-Draft P2P SIP Use Cases February 2006 P2P SIP System: A system in which P2P SIP is used to realize applications such as VoIP, Presence and Instant Messaging. P2P SIP: SIP running over a P2P overlay network in which SIP resources, such as user location information, are managed by a P2P overlay network. P2P UA (P2P User Agent): A SIP UA (user agent) on a device with the P2P overlay layer. Peer Initiation: Bootstrapping and any other tasks necessary for a peer to reach the state in which the peer can perform placement and search in the P2P overlay network. Peer: A network node offering its own resources for other peers and using resources of other peers for its own good. The term 'peer' is used interchangeably with 'node' in the context of peer-to-peer overlay networks. Peer-to-Peer (P2P) Overlay Network: An overlay network formed and self-managed by the participating peers. Resource Record: A record about a resource that may include the resource itself or include just meta-data about the resource. To share a resource, a peer creates a resource record that is accessible to other peers. Looking up a resource is equivalent to looking up a resource record. Distributed Hash Table (DHT): A mechanism in which resources are given a unique key produced by hashing some attribute of the resource, locating them in a hash space (see below). Nodes located in this hash space also have a unique identifier within the hash space. Nodes store information about resources with keys that are numerically similar to the node's identifier in the hash space [13]. Terminology defined in RFC3261 [2] is used without definition. 3. Architecture Overview A peer in the P2P SIP system is comprised of two layers: the P2P overlay layer and the SIP layer. The P2P overlay layer handles all the P2P overlay functions. The P2P overlay layer does not interpret semantic meanings of the resources placed or looked up by the higher layers including SIP. But its design goal is serving SIP and thus SIP-based real-time media applications. That is, other applications may use the P2P overlay layer presented here but the architecture and the algorithm used for this P2P overlay layer may not necessarily be optimal for all applications. From the perspective of SIP, the P2P overlay layer provides mainly a location service for various SIP resources. One of the most important information, or resource, for SIP operation is the user location, i.e., the IP address corresponding to a SIP URI [2]. Typically, the caller precisely knows the SIP URI of the call Shim, et al. Expires August 30, 2006 [Page 5] Internet-Draft P2P SIP Use Cases February 2006 recipient before a call is made. DHT (Distributed Hash Table) based structured P2P networks support efficient search mechanisms when the resource names are precisely known, thus, meets the requirements of P2P SIP well. Therefore, we propose the use of DHT for the P2P overlay layer. P2P overlay networks can be comprised of peers with different amount of physical resources operating in various network environments. The larger a P2P overlay network is, the more significant the heterogeneity of peers will be. Even though every peer is ideally supposed to contribute its physical resources to the services of the P2P overlay network for other peers, peers without proper physical resources had better be exempted from the obligation for better performance of the P2P overlay network in overall. So peers are classified into two types: super nodes (SNs) and ordinary nodes (ONs). For DHT-based P2P overlay networks, super nodes participate in building and maintaining the DHT. Ordinary nodes do not participate in DHT. Super nodes serve search requests by routing the search traffic or generating replies to search requests. To discover a resource from other peers, an ordinary node sends a search request message to a super node. Then the super node routes the search request message in the DHT. In a sense, super nodes comprise a distributed storage and search service network. Either an ordinary node or a super node could use the service provided by the overlay network. Depending on the system requirements, some systems based on P2P SIP may be comprised of only super nodes. A farm of SIP proxies using P2P SIP among themselves is an example of such a system. In this document, unless particularly mentioned, a system is assumed to have the two types of peers. The P2P SIP specification will contain descriptions of the protocols between the ON-SN pair and the SN-SN pair. Since only the super nodes participate in the DHT, the P2P overlay network has a hierarchical structure: the core consisting of super nodes forming a DHT with a periphery of ordinary nodes. Each ordinary node is associated with one or more super nodes. The relationship between the ordinary node and those super nodes is like that of a client and servers or of a host and routers. The ordinary node uses the storage and lookup services of the overlay network core through the associated super nodes. SIP has its own hierarchical structure. SIP proxies form a kind of infrastructure providing call request routing services and SIP UAs use the services. SIP event servers store the event subscription records and distribute event information to the subscribers. In general, the hierarchy of peers in the P2P overlay layer is independent of the hierarchical structure of SIP. A UA with P2P overlay layer is referred to as P2P UA in this Shim, et al. Expires August 30, 2006 [Page 6] Internet-Draft P2P SIP Use Cases February 2006 document, and similarly a proxy or a registrar with P2P overlay layer is referred to P2P Proxy or P2P-Registrar respectively. For example, it is possible to build a P2P VoIP network comprised of only P2P UAs running over a P2P overlay network with the distinction of super nodes and ordinary nodes. It is also possible to run a P2P Proxy process over an ordinary node. Super nodes are good candidates to be P2P-Proxies but not all super nodes in a P2P overlay network have to become a P2P Proxy. The choice of SIP entity on a peer node will depend on the specific system design. Authorization to join the P2P overlay network is based only on user credentials, i.e., a device is authorized based on the credential of the user or the service using the device. A user can change devices freely and use multiple devices simultaneously. Authentication and authorization is provided primarily by a central logical entity named a login serverHow a user subscribes to a login server is out of scope of this document. Out- of-band methods such as web pages can be used. There are four types of entities in the P2P overlay network, a logical view of which is depicted in figure 1. +---------+ +------------+ +----+ | Login | | Bootstrap | | ON | +----+ | Server | | Server | +----+ | ON | +---------+ +------------+ | +----+ | | +----+ V | | ON |--------> +----+ +----+ <--------+ +----+ --+ | SN | ============ | SN | | +----+ === +----+ +----+ <---------+ +----+ | || | SN | || | | ON | +----> +----+ === +----+== +----+ | +----+ -------> | SN | ^ ^ | SN | +----+ +----> +----+ | | +----+ <------- | ON | +----+ | ^ | | ^ +----+ | ON | --+ | +--------+ +-- + | +----+ | | | | +----+ +----+ | ON | | ON | +----+ +----+ Figure 1: A logical view of the P2P overlay network with four types of entities: Ordinary Node, Super Node, Login Server, and Bootstrap Server. Once a node knows one or multiple nodes participating in a P2P overlay network, it can start the process to join the network. A Shim, et al. Expires August 30, 2006 [Page 7] Internet-Draft P2P SIP Use Cases February 2006 bootstrap server is an entity that provides a new node with the information about existing nodes in the target P2P overlay network. The login server and the bootstrap server facilitate formation of a P2P overlay network. When other means become available for their functions, they can be omitted. In this sense, they are optional entities. 4. SIP entity operations The separation of the P2P overlay layer and the SIP layers allows for the possibility of a P2P SIP network that consists of multiple P2P overlay networks with a P2P Proxy routing SIP signaling messages from one overlay to another. These individual P2P overlay networks MAY either correspond to a single SIP domain where every P2P SIP entity on the particular overlay network will be from the same SIP domain, or a P2P overlay network MAY have P2P SIP entities from multiple SIP domains. When a P2P UA tries to establish a call to another P2P UA in the same P2P overlay network, the INVITE message will be sent directly to the destination P2P UA based on a lookup in the P2P overlay network. If a P2P UA tries to establish a call to another P2P UA in a different P2P overlay, the INVITE message will be forwarded to a P2P Proxy of the local overlay network which in turn will route the INVITE message to the final destination through the a P2P Proxy associated with the remote domain. The P2P service function may be used for SIP in various forms, resulting in different network composition scenarios. There are three key logical entities defined by SIP [SIP], a User Agent (UA), a Proxy and a Registrar. Each of these SIP entities could potentially include a P2P overlay layer and become part of the P2P overlay network. These SIP entities with a P2P overlay layer are referred to as P2P UA, P2P Proxy or P2P-Registrar. Different combination of the P2P and Client-Server (CS) SIP entities could be combined to create the network composition of a particular SIP domain. Table 1 summarizes what we consider as meaningful network composition scenarios and the roles of the P2P layer from the SIP perspective. +---+----+-------+---------+----------------------------------------+ | | UA | Proxy |Registrar| Role of P2P Overlay Layer | +---+----+-------+---------+----------------------------------------+ |(a)| P2P| P2P |Not | Replace the Registrar, the location | | | | |Required | database and DNS lookup for local proxy| +---+----+-------+---------+----------------------------------------+ |(b)| CS | P2P | P2P | Replace the location database | +---+----+-------+---------+----------------------------------------+ Shim, et al. Expires August 30, 2006 [Page 8] Internet-Draft P2P SIP Use Cases February 2006 Table 1. Network composition scenarios for a SIP domain In the above table, 'P2P' implies that the corresponding SIP entity is on a peer device participating in the P2P overlay and 'CS' implies a client-server SIP entity. The behavior of each P2P SIP entity is described below. 4.1 P2P UA Behavior The P2P UA uses the P2P service function to store its user location information in the P2P overlay network or to look up user location information for target UAs it may want to contact. So, for user registration, the P2P UA creates a user location record as described in Section 8 and requests its local P2P overlay layer to place the user location record in the overlay network by calling the P2P overlay API functions, either add() or update(). Based on the lifetime set in the user location record, the P2P UA periodically refereshes the user location record. The configuration information required by the P2P UA is one or more of the SIP-URIs by which it can be contacted and the identifier of the overlay network which the P2P UA should join. To make an outgoing call, a P2P UA SHOULD try retrieving the resource record in the following order: - The target UA associated with the callee. - The local Proxy associated with its own domain. It is important to note that these location records should be verifiable by means of some secure signature based on credentials derived from the login server. If both of these lookups fail, the P2P UA MAY try a DNS lookup for the local proxy associated with its own domain. A P2P UA MAY be configured to try the local proxy always. The default behavior described above SHOULD be followed in the absence of such a configured choice. Once the next hop is identified and an INVITE message is sent to that node, the P2P UA behaves the same way as the UA in the client server model. For incoming calls, the P2P UA behaves the same way as the UA in the client server model. 4.2 P2P Proxy Behavior A P2P Proxy plays the role of a gateway between two P2P overlay networks or between a clisent-server SIP domain and a P2P overlay network. Hence, a P2P Proxy MAY be a part of more than one P2P overlay network. Once the local P2P overlay layer completes initiation and joins the P2P overlay network, a P2P proxy generates its location record based on its domain name and requests its local Shim, et al. Expires August 30, 2006 [Page 9] Internet-Draft P2P SIP Use Cases February 2006 P2P overlay layer entity to place the record in the overlay network. Since there can be multiple proxies for the same domain, the P2P proxy uses add() function of the P2P overlay API to place its location record. The P2P Proxy is responsible for keeping the location record on the overlay up-to-date by adding a new record as the old record gets close to expiration. The configuration information required by P2P Proxy is the domain name it is associated with and the overlay identifier that corresponds to the particular domain. Upon receiving an INVITE message, a P2P proxy determines whether the callee's URI belongs to a domain it supports or a remote domain. In the former case, the P2P proxy MUST lookup user location records of the callee in the corresponding overlay network and forwards the INVITE message to the location of the callee. Once having found the location or multiple possible locations of the callee and verifying the authenticity of these location record(s), the P2P proxy behaves the same way as the proxy in the client server model. If the lookup in the P2P overlay fails and it knows a SIP location server for the local domain, the P2P proxy MAY contact the SIP location server for the callee's location. - If the callee's URI belongs to a remote domain, the P2P proxy SHOULD locate the remote proxy associated with the URI using DNS as specified by the client-server SIP specification. The architecture as described in this document allows for the possibility of constructing a transit P2P overlay network among P2P Proxies that can be used to locate the P2P Proxy of the remote domain. In order to achieve this, the overlay identifier corresponding to the transit network must be configured into these P2P Proxies. In such a scenario, the P2P Proxy will try a lookup of the remote proxy on this overlay network before falling back to DNS lookup as a backup to reach other proxies that are not part of this transit overlay network. 4.3 P2P Registrar Behavior When a P2P overlay network is used to store location information of CS UAs (UAs operating in the client server model), the Registrar serving the CS UAs is configured to participate in the P2P overlay network, thus called a P2P Registrar. If a P2P Registrar is configured, it functions as the front of the P2P overlay network. When a SIP registration message is received, the P2P Registrar generates a user location record for the registering UA and requests the P2P overlay layer to place the location record in the overlay network. Shim, et al. Expires August 30, 2006 [Page 10] Internet-Draft P2P SIP Use Cases February 2006 4.4 Example Call Flows The following example call flows provide an indication of the messages required to establish sessions in various environments. Further work is required in this area, and the following is presented for indicative purposes only. 4.4.1 Call Flow between P2P UAs Now let's look at how a simple one-to-one call is established between two P2P UAs. Figure 2 illustrates an example sequence of message transfer during call establishment where both the caller and the callee are P2P UAs and have public IP addresses. Also, both P2P UAs are in the same overlay network. It is assumed that there is no firewall blocking SIP or the P2P overlay protocol between peers. In this scenario, the user on node 1 (an ON) is the caller and the user on node 4 (an ON) is the callee. The user location record of the callee happens to be stored at node 3. With a call establishment command from the application, the UAC is given the SIP URI of the callee. The UAC does not have the location information for the callee, thus generates the resource key for the user location of the callee, and requests the P2P overlay layer to search for the callee's location by calling the P2P overlay API described in Section 9(step 1). Upon receiving the search request, the P2P overlay layer generates a search request message that contains the resource key from the SIP layer and sends it to the associated super node (step 2). The associated super node checks its local storage and forwards the search request message to the next hop according to the DHT routing table (step 3) if it does not have the target resource. The peer who has the target resource sends a search reply message containing the resource, i.e., the callee's user location record in this case (step 4). The search reply message is directly sent back to the SN associated with the caller peer, i.e. the search reply does not retrace the path of the search message. Upon receiving the search reply message, the associated super node forwards the reply to the calling ordinary node (step 5). The P2P overlay layer of the calling peer returns the resource to the SIP layer (step 6). The UAC interprets the user location record and identifies the IP address and the port number for the UAS. Then the UAC generates an INVITE message and sends it to the UAS directly (step 7). From this point, the two UAs can communicate directly with each other. Shim, et al. Expires August 30, 2006 [Page 11] Internet-Draft P2P SIP Use Cases February 2006 +----------------------------------------------------------+ | +----------------------------------------------------+ |200 OK | | INVITE (7) | |(8) V | V | +------------+ +------------+ +------------+ +------------+ |+----------+| |+----------+| | | |+----------+| ||SIP Layer || ||SIP Layer || | | ||SIP Layer || |+----------+| |+----------+| | | |+----------+| | | ^ | | | | | | | | |(1) |(6) | | | | | | | | V | | | | | | | | |+----------+| |+----------+| |+----------+| |+----------+| || P2P ||--> || P2P ||--> || P2P || || P2P || || Overlay ||(2) || Overlay || (3) || Overlay || || Overlay || || Layer || || Layer || || Layer || || Layer || || (ON) || || (SN) || || (SN) || || (SN) || |+----------+| |+----------+| |+----------+| |+----------+| | Node 1 | | Node 2 | | Node 3 | | Node 4 | +------------+ +------------+ +------------+ +------------+ ^ | ^ | | |(5) | |(4) +----------------+ +----------------+ Figure 2: A simple call procedure between two P2P UAs 4.4.2 Call Flow between CS UA and P2P UA within the same domain It is possible to run CS UAs and P2P UAs within the same domain. Such a composition of a network is useful when CS UAs were already deployed and P2P UAs are incrementally deployed. The SIP Registrar is configured to operate as P2P Registrar. The CS UAs sends registration messages to the P2P Registrar. Then the P2P Registrar places the location information of CS UAs in the overlay network via the P2P overlay layer. The P2P UAs place their location information in the overlay network themselves via the P2P overlay layer. Figure 3 illustrates an example sequence of message transfer during call establishment where the caller is a CS SIP UA and the callee is a P2P UA. In this scenario, both have public IP addresses without firewall restrictions on SIP or overlay messages. Note that the overlay network is represented by word 'overlay' and messages between peers in the P2P overlay layer are not depicted. UA1, a CS UA, sends an INVITE message, aiming to establish a call with UA2, to its proxy, which happens to be connected to the P2P overlay network (Step 1). This proxy then resolves location of UA2. Shim, et al. Expires August 30, 2006 [Page 12] Internet-Draft P2P SIP Use Cases February 2006 In this case, the proxy queries the P2P overlay network(Step 2). The reply contains UA2's location record (step 3). Subsequently, the INVITE message is forwarded to the discovered location (Step 4). Upon receiving the INVITE message, UA2 sends a reply message to the proxy (step 5) that, in turn, forwards it to UA1. +----------+ |SIP |add(UA1 location) add(UA2 location) REGISTER |Registrar |-------------> overlay <----------+ /--->|(P2P) | ^ | | / +----------+ | | | / | | | / +---------------------+ | | / | get(UA2 location) (2) | | +----+ / +----------+ <---------------+ +-----+ |UA1 |/ |SIP | UA2 location (3) |UA2 | |(CS)|----------->|Proxy |----------------------------->|(P2P)| | | INVITE(1) |(P2P) | INVITE (4) | | | |<-----------| |<-----------------------------| | +----+ 200 OK(6) +----------+ 200 OK (5) +-----+ | ^ +-----------------------------------------------------------+ ACK (7) Figure 3. A call from a CS UA to a P2P UA When UA2, a P2P UA, calls UA1, a CS UA, UA2 can discover UA1's location from the P2P overlay network (step 1 and 2). After that, UA2 sends an INVITE message to UA1 directly (step 3). In this case, there is no need to go via a Proxy. Figure 4 illustrates this call procedure. Shim, et al. Expires August 30, 2006 [Page 13] Internet-Draft P2P SIP Use Cases February 2006 +----------+ |SIP |add(UA1 location) add(UA2 location) REGISTER |Registrar |----------> overlay <----------------+ /--->|(P2P) | | ^ | / +----------+ | | | / | | | / | +------------------+ | / | get(UA1 location)(1)| | +----+ / +---------------->+-----+ |UA1 |/ UA1 location (2)|UA2 | |(CS)|<-----------------------------------------------------|(P2P)| | | INVITE (3) | | | |----------------------------------------------------->| | +----+ 200 OK (4) +-----+ ^ | +-----------------------------------------------------------+ ACK (5) Figure 4. A call from a P2P UA to a CS UA 5. Peer Initiation When a node decides to participate in the peer-to-peer SIP network, it needs to connect to other nodes, and identify peer super nodes (SN). In order to do this, it starts operation as an ordinary node (ON). After identifying if it is able to contact SN that compose the DHT, a peer may become a SN itself. Below is a summary of the sequence of functions undertaken by a node in joining the peer-to-peer network. This peer initiation must be done independently for each P2P overlay network it is trying to join. Subsections follow describing all of these operations: (1) Bootstrap (2) Association and authentication. (3) NAT/FW traversal (At this stage, outbound sessions are possible). In order to receive inbound calls, the peer will then have to register at least one SIP URI as described in Section 6, and later the peer MAY also want to become a SN as described in Section 7. Once a node is a SN, it agrees to service requests by peer SNs, and allow ONs to connect, register and search through it. 5.1 Bootstrapping A node wishing to join a peer-to-peer overlay network needs to select Shim, et al. Expires August 30, 2006 [Page 14] Internet-Draft P2P SIP Use Cases February 2006 which overlay to join. While a peer may join different overlays, it will be necessary to maintain separate authorization, registration, hash tables, as well as separate lists of bootstrap servers. When discerning which network to join, a node may select to bootstrap only SNs which have one particular overlay identifier, or to use a default identifier. This overlay identifier needs to be exchanged in peer- to-peer messages, as each peer may itself be participating in multiple P2P overlay networks. Bootstrapping the ON requires identification of SNs whom a peer should try to contact initially. Connecting to these SNs provides a mechanism whereby the peer can contact the peer-to-peer network, establish trust within that network and start participating in sessions. Addresses for the initial contact may be gained by methods outlined below. 1. Service location (multicast) 2. Cached addresses 3. Last good address 4. Pre-configured bootstrap server(s). Ordering of attempts to contact SNs is needed for a number of reasons. We RECOMMEND the above order, as described: (1) Service Location A peer can try sending a local multicast request to find if there are other P2P SIP nodes in the same local area network or administrative domain. When P2P SIP is used within a corporate network, this solution for bootstrapping will be able to identify local resources and even in the global scenario, once a single node in the same broadcast/ multicast domain joins the P2P overlay, other nodes can bootstrap locally. As an example, peers may be able use the Service Location Protocol (SLP) to identify SNs participating in the P2P network [3][4]. Where a directory agent is not configured on the network, peers multicast queries to find a SN, which would act as an SLP Service Agent. If an existing directory agent is found, this may provide a list of active SNs. (2) Cached Addresses: A peer may retain information about SNs proposed by its SN during its Shim, et al. Expires August 30, 2006 [Page 15] Internet-Draft P2P SIP Use Cases February 2006 prior connection to the network. The list allows the SN to notify the ON of dynamic changes in service availability, and shows if the ON should first try to use the same SN again. (3) Last Good Address: A peer may attempt to contact its last known SN, with which it had a successful connection. This address may be tried after learned cached addresses, in order to allow for robustness and spreading of ONs between SNs within the network. (4) Preconfigured Bootstrap Server: The IP address or domain name of a server in the Internet that maintains a list of currently available SN addresses could be configured in peers. This server may not participate in the peer-to- peer network, and the protocol to access the server list may be an existing protocol like HTTP. This address is contacted last, as the bootstrap servers are considered potential failure points, and the intention is to reduce the load on these devices. 5.2 Association and Authentication After gathering information about potential SNs, the peer should contact candidates, and attempt to authenticate with one or more of them. 5.3 Association Selection of the transport for contacting the SN is provided through the bootstrap process. As such, where multiple choices exist for a particular IP address or the information about the SN does not specify which protocol and port to contact the SN on, the ON must select amongst the following mechanisms by which to contact the peer. By default, it may be useful to contact the server in the following order: - UDP - TCP - Fallback Transport. UDP is favored, as the SN may need to retain less state for each associated ON. The Fallback Transport may be HTTP based, and potentially proxied, in order to gain access through networks which otherwise would not be Shim, et al. Expires August 30, 2006 [Page 16] Internet-Draft P2P SIP Use Cases February 2006 able to make these lookups. Initial contact should confirm the presence of the SN, and ensure that the SN is functioning in that role. Additional handshakes to perform mutual return reachability tests may also be incorporated. 5.4 Authentication In order to participate in the peer-to-peer network as an ordinary node, credentials MAY be needed to show a node's right to retrieve and update information. After the association Additionally, the ON will wish to authenticate the SN, in order to identify that the connection between the SN and ON is direct, and that the SN has sufficient authority to undertake operations on the ON's behalf in the P2P network. An example authentication scheme is to make use of TLS, in order to authenticate the ON and SN and derive a secured channel for communicating between them [6]. Where UDP based operations are undertaken, the datagram-based version of TLS is used analogously [draft-rescorla-dtls]. In this scenario, each node requires a certificate from a mutually acceptable source, and SNs are guaranteed to already possess one as they would have gone through the initiation procedure themselves. 5.5 NAT/FW Traversal In order to undertake peer-to-peer communications with other nodes on the Internet, SIP messages will need to be exchanged, and media channels set up between end nodes. In order to ensure communications are available at session initiation time, it is necessary to test whether an ON is behind a NAT or a restrictive firewall, which may limit session establishment from that address. Therefore, peers should test reachability, for example, by performing ICE operations, with the SN as the STUN server in order to identify what type of connectivity they possess [11][5]. Additional configuration of relay servers may be necessary, and the SN can identify a TURN server to contact (which may be itself or another SN). Upon completion of this testing, a set of viable derived addresses SHOULD be generated on the ON, for use in session initiation [10]. An ON MAY immediately start retrieving peers' URIs and initiating outbound calls. Shim, et al. Expires August 30, 2006 [Page 17] Internet-Draft P2P SIP Use Cases February 2006 6. Registration In order to receive inbound calls, a peer needs to publish information in the p2p network listing addresses and ports using which it may be contacted. Using the reachability information gained through NAT and Firewall traversal operations, a peer may advertise a set of addresses and ports by instructing the SN to place or replace records in the DHT referring to the ON's own identity. Multiple records may be managed by specifying the preference relationships as described in ICE [11]. The API for managing data on the P2P overlay is presented in Section 9. 7. Becoming a Super Node Super nodes are self-selected dynamically and automatically. In order to become a SN, a node (1) MUST be able to receive messages on predetermined protocols and ports from other SNs on the overlay network. (2) SHOULD be online stably. - This requirement may need a metric to be defined in the future to make it more specific. (3) SHOULD have sufficient physical resources such as CPU power, memory size, and network bandwidth. - This requirement may need a set of metrics to be defined in the future to make it more specific. If a peer wishes to become a SN, it MUST be able to receive P2P overlay management and service function messages from other peers on pre-defined protocols and ports. When a P2P overlay network spans over the global Internet and contains peers private IP addresses as well as peers with public IP addresses, SNs need to perform STUN, and possibly TURN server operations thus it is RECOMMENDED that SNs should be on the public Internet, and publicly addressed [5][10]. If all the peers of a P2P overlay network are in the same address realm, for example, a LAN befind a NAT, SNs don't have to have, or, actually can't have public IP addresses. SN operation requires that the peer reserve space to store a portion of the hash table, and transfer data into and out of its own storage, as it or other devices enter or leave the set of SNs. If SNs stay online only for a short period, signaling traffic to restore the DHT becomes heavy and search performance may degrade significantly. So it is desirable to select nodes that are likely to stay online longer. Different from the first requirement, the second and third requirements provide only relative criteria. Specific threshold values for the metrics of the two requirements should be decided depending on the target system characteristics. Shim, et al. Expires August 30, 2006 [Page 18] Internet-Draft P2P SIP Use Cases February 2006 8. Formats of Resource Records for SIP The peer placing a resource and the peer retrieving the resource via search should use the same format for the resource record and the same algorithm to assign a key to a given resource record. Otherwise, the resource cannot be discovered or interpreted properly. The resource record is specific to the application that creates and uses the resource record. It is opaque to the P2P overlay layer. An example of a user location record is given below. 1.0 user location 19873761ab24 3600 19809832142 user@example.com 178.14.234.21 TCP5060 UDP5060 TCP80 TCP443 192.168.0.100 TCP5060 UDP5060 TCP80 TCP443 The algorithm for resource key generation depends on the type of resource. In general, it has the following form. key = hash(). The resource name is composed as a concatenation of the resource type name and a string identifying the resource instance within the type. For user location information, the user URI can identify the resource instance, and, therefore, the key is generated as follows: key = hash("user location"+), where "user location"+ is a concatenation of "user location" and the value of user_URI element. For the above example Shim, et al. Expires August 30, 2006 [Page 19] Internet-Draft P2P SIP Use Cases February 2006 user location, the input for the key generation function is "user location|user@example.com". Using the concatenation method, the user URI can be used to identify many types of resources. For the hash function, a cryptographic hash function like SHA-1 [12] should be used in order to distribute keys uniformly in the key space. Another type of record is the proxy location record. An example of a proxy location record is given below. 1.0 proxy location 19873761ab24&l;/key> 36000 198023422 example.com 178.14.234.21 TCP5060 UDP5060 TCP80 TCP443 192.168.0.100 TCP5060 UDP5060 TCP80 TCP443 The resource name for a proxy location record is "proxy location"+ . 9. P2P Overlay API The P2P overlay layer provides an API by which requests for resource placement and search over the P2P overlay network can be made. The semantics of the core functions of the API are described below: get(in overlay_id, in key, out records, out error) - action: look up a resource from the P2P overlay network identified by the overlay_id. Shim, et al. Expires August 30, 2006 [Page 20] Internet-Draft P2P SIP Use Cases February 2006 - input parameter overlay_id: An identifier that uniquely identifies a particular overlay the node is a member. key: the key of the target resource. - output parameters records: records of the resources returned from the search. One or multiple records may be included. error: an error code. add(in overlay_id, in key, in record, in lifetime, in option, out error) - action: place a resource in the P2P overlay network. If a resource of the same key exists in the overlay network already, the resource given in the call is added in the network in addition to the existing resource. That is, add() cannot be used to change existing resources in the overlay network. - input parameters overlay_id: An identifier that uniquely identifies a particular overlay the node is a member. key: the key of the resource to be placed. record: the record of the resource to be placed. lifetime: lifetime of the resource to be placed. option: option for placement. NO_UPDATE_OPTION: Indicates that the record is not updatable; Then no credentials to identify the source need to be stored along with record. If updatable, a security credential (likely derived from the security credentials generated during authentication procedure) is associated with the record. - output parameters error: the error code. update(in overlay_id, in key, in record, in lifetime, in option, out error) - action: update a resource in the P2P overlay network and create one with the given record if a resource with the given key does not exist yet. The update operation is allowed for existing resources whose owner (or creator) is the same as the updating user. This is verified based on security credentials. If the stored resource doesn't contain any associated security credentials the update operation will fail. - input parameters overlay_id: An identifier that uniquely identifies a particular overlay the node is a member. key: the key of the resource to be placed. record: the record of the resource to be placed. lifetime: lifetime of the resource to be placed. Shim, et al. Expires August 30, 2006 [Page 21] Internet-Draft P2P SIP Use Cases February 2006 option: option for placement. - output parameters error: the error code. remove(in overlay_id, in key, out error) - action: remove the resources of the given key from the overlay network. Like the update function, this is allowed for existing resources whose owner (or creator) of the resources is the same as the requesting user. If the authentication doesn't succeed or if there is no associated security credentials, the remove operation will fail. - input parameter overlay_id: An identifier that uniquely identifies a particular overlay the node is a member. key: the key of the target resource. - output parameters error: an error code. If anyone is allowed to remove or update location records of other users, it becomes so easy to block or interfere with incoming calls to a particular user. So it is imperative to give the owner of a resource record the authority to set access control policies for the resource record, in particular, about updating and removing the resource record. To support the above API, the P2P overlay layer manages resource records based on the resource key and resource's owner identity. Conceptually the overlay layer stores every resource record with a control information record that includes the resource key, the owner identity, and the access control policy set by the owner. 10. What Needs To Be Specified For interoperation between different devices, the following interfaces MUST be specified: the SN-ON interface, the SN-SN interface, the ON-Login Server interface, the SN-login server interface, and the peer-bootstrap server interface. Since nodes startup as ON and complete bootstrap before changing to a SN, there is only one interface with the bootstrap server. And the formats of resource records for SIP MUST be specified. Section 8 describes two example resource record types and their formats. The API (application program interface) of the P2P overlay layer, like that in Section 9, is not required to be specified in the syntatical level that depend on implementations of the SIP layer and the P2P overlay on each device. However, there MUST be a common set of services the SIP layer can receive from the P2P overlay layer, Shim, et al. Expires August 30, 2006 [Page 22] Internet-Draft P2P SIP Use Cases February 2006 which can be captured in a semantic definition of the P2P overlay API like that in Section 9. 11. Security Considerations Peer-to-peer networks need to balance between providing appropriate trust, and reducing requirements for centralized authority. Particularly, it is important not to aim at solving generalized distributed trust problems but instead to focus on use-cases appropriate to endpoint identification and session establishment. 11.1 Bootstrapping Security Becoming an ordinary node requires use of dynamically configured super node information. Where SN information is received from an untrusted source, or over an unsecured channel, care should be taken in attempting to contact these nodes, so that time and resources are not wasted contacting bogus servers. Additionally, care should be taken not to unduly extend trust to discovered devices, even where the origin of the SN information is trusted. This is important, as there may be a change in the trust of a particular node between the time which SN information was gathered and the time it is used by the ON for bootstrapping. As such, it is important that nodes authenticate peers in order to establish relationships. 11.2 ON/SN Authentication When connecting to the network, a node needs to authenticate that its selected SN is trusted, and that it is talking directly to that node. Similarly, the SN needs to identify that the ON is a valid participant in the network, and that it is authorized to perform lookup, and record update operations for P2P SIP. This authentication needs to occur without constant reference to a single login server, which would limit scalability, introduce a single point of failure and therefore defeat the peer-to-peer paradigm. 11.3 Peer Transport Security Message authentication must be used between one node and another in a peer-to-peer network. Where privacy against non-P2P participants is required, encryption should also be used. Use of encryption suites with key negotiation may achieve not only the requirement for mutual authentication, but also data transport security as well [6][7][8]. Shim, et al. Expires August 30, 2006 [Page 23] Internet-Draft P2P SIP Use Cases February 2006 11.4 Firewalls Firewalls are typically configured by an organization in order to prevent certain classes of traffic passing across administrative boundaries. While application-level gateways exist which control message contents at upper layers, most firewalls control data flows by allowing data transfer on ports assigned to specific services. Any firewall traversal technique that uses an assigned port purely to find an open channel through a gateway is therefore likely to be contravening the security policy of the peer's network. This may particularly be the case where external devices such as tunnel servers allow inbound session initiation through port relay [10]. Additionally, operation of SN services on ports normally preserved for other purposes may expose that node to access or attack from outside the intended boundary of the peer-to-peer network, as such ports may not be blocked by a firewall. 11.5 Network Address Translators Peer-to-peer session establishment through a NAT or firewall may require tunneling assistance from a relay device on the public Internet. If only a small number of relay devices are available, they are a potential single-point of failure, and may be subject to denial of service attacks. Relay devices pose a particular threat in that compromise of a peer's relay may allow packet insertion or modification. As such, message exchanges SHOULD authenticate the peer's credentials, rather than relying entirely on channel security. 11.6 Registration When a SIP entity places a location record in the P2P overlay network to register a URI, the information in the record controls the address at which it can be contacted. Modifications to such information need to be authenticated, in order to ensure communications sessions are not redirected, or subject to man-in-the-middle attacks. This requires that SIP entities generating location recorrds SHOULD sign their own location record updates, and that updates with different credentials do not overwrite each other. Additionally, these signed update messages need to provide a freshness information, in the form of a monotonically increasing number (which may be the origin peer's clock), to ensure that any update operations do not replace newer registrations. Registration of a device's address may also indicate its location in the physical world. Where this is an important consideration, adoption of a derived transport address from a TURN server may allow Shim, et al. Expires August 30, 2006 [Page 24] Internet-Draft P2P SIP Use Cases February 2006 a level of indirection and privacy [10]. 11.7 Session Endpoint Discovery and Security Where no central servers are required to identify endpoints, centralized mechanisms for identifying valid SIP transport and security are no longer applicable [9]. Instead, peers SHOULD use the credential information associated with the other peer to verify the address, port, and preference information for particular SIP URIs advertised in the DHT. The content or origin of get() commands may divulge information about the location or identity of the requester. In order to maintain privacy, a SN may remove identifying information when making a request on another's behalf. Rate limitation of the requests from a source may be performed in order to limit abuse and overload of the P2P network. 11.8 Ill Behavior of Ordinary Nodes Ordinary nodes do not have direct access to the DHT, but they are able to read and place data into it. As such, they gain many of the advantages of being on the overlay, without contributing to its maintenance. As maintaining the DHT requires some bandwidth, computing and storage resources, some ONs may wish to not become SNs, even if this would benefit the overlay network's operation. While nodes are to be encouraged to transform into SNs, it is in practice hard to enforce them to take on the SN role. Any node may place useless or distracting information on the overlay, through generation of update() and add() commands. Unless user credentials are used as the basis of checks to update or add new information, it may be possible to remove other users' legitimate data, which may have further security consequences. If two devices purport to add information pertaining to the same record, both need to be retained, distinguished by their credentials, as the SN performing DHT operations will typically be unable to identify which is correct. As mentioned before, updates of the hash table are likely to be more computationally onerous for SNs, as authenticity checks may be required in order to modify records. As such, it may be possible to deny service on a portion of the hash table by continually sending the SN update() and add() operations. In some DHT systems, knowledge of routing mechanisms may be used to generate get() queries which increase the processing delays across the entire overlay network, or focus additional traffic at a Shim, et al. Expires August 30, 2006 [Page 25] Internet-Draft P2P SIP Use Cases February 2006 particular SN with constrained resources. 11.9 Ill Behavior of Super Nodes A super node is a device with direct ability to change the topology of the overlay network. It is able to receive read-only and modifying operations on the network, and may be able to insert, modify, drop, or selectively transmit the messages it receives. It is responsible for maintaining the data sent to it, and passing a portion of the hash table to its peers upon joining or leaving the network. As such, the SN has a great amount of influence and power within a P2P network, and compromise of an SN (or a collection of SNs) seriously jeopardizes the operation of the network. Therefore, it is very important to use strong authentication and authorization to ensure that participant SNs are valid candidates to join the DHT. Additionally, it is important to maintain additional backups for data that may be under control of an SN that goes bad. Use of origin authentication, integrity and freshness checks may at least ensure that items stored in the DHT are unmodified upon storage. 12. Acknowledgements The authors would like to thank Salman Basset and Henning Schulzrinne for the discussion with them on P2P SIP architecture issues and their comments. Their work provided the authors with valuable information on a large scale P2P Internet telephony system. 13. References 13.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Gutterman, E., Perkins, C., Veizades, J., and M. Day, "SLP: Service Location Protocol, Ver 2", RFC 2608, June 1999. [4] Gutterman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001. [5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP)Through Network Shim, et al. Expires August 30, 2006 [Page 26] Internet-Draft P2P SIP Use Cases February 2006 Address Translators (NATs)", RFC 3489, March 2003. [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [9] Rosenberg, J. and H. Schulzrinne, "IP Encapsulating Security Payload (ESP)", RFC 3263, June 2002. 13.2 Informative References [10] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-07.txt (work in progress), February 2005. [11] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-05.txt (work in progress), July 2005. [12] "Federal Information Processing Standards Publication 180-1 Secure Hash Standard", http://www.itl.nist.gov/fipspubs/fip180-1.htm, April 1995. [13] Baset, S., Schulzrinne, H., Shim, E., and K. Dhara, "Requirements for SIP-based Peer-to-Peer Internet Telephony", draft-baset-sipping-p2preq-00 (work in progress), October 2005. Authors' Addresses Eunsoo Shim Panasonic Digital Networking Laboratory Two Research Way, 3rd Floor Princeton, NJ 08540 USA Email: eunsoo@research.panasonic.com Shim, et al. Expires August 30, 2006 [Page 27] Internet-Draft P2P SIP Use Cases February 2006 Sathya Narayanan Panasonic Digital Networking Laboratory Two Research Way, 3rd Floor Princeton, NJ 08540 USA Email: sathya@research.panasonic.com Greg Daley Panasonic Digital Networking Laboratory Two Research Way, 3rd Floor Princeton, NJ 08540 USA Email: gregd@research.panasonic.com Shim, et al. Expires August 30, 2006 [Page 28] Internet-Draft P2P SIP Use Cases February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shim, et al. Expires August 30, 2006 [Page 29]