P2PSIP XingFeng. Jiang Internet-Draft Huawei Tech. Intended status: Standards Track June 20, 2007 Expires: December 22, 2007 A mechanism to discover STUN/TURN nodes in P2PSIP draft-jiang-p2psip-stun-turn-discovery-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 draft proposes a lightweight method used to discover P2PSIP peers or clients distributed throughout Peer-to-Peer overlay that provide Network Address Translator-traversal functionality. Jiang Expires December 22, 2007 [Page 1] Internet-Draft P2PSIP STUN TURN June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview and concept . . . . . . . . . . . . . . . . . . . . . 4 3.1. Problem statement . . . . . . . . . . . . . . . . . . . . 5 3.2. Use case and assumptions . . . . . . . . . . . . . . . . . 6 3.2.1. Assumption . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2. Use case . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Procedure to discover STUN/TURN server candidate . . . . . 7 3.3.1. Construction of STUN/TURN candidate table . . . . . . 7 3.3.2. Discovery procedure . . . . . . . . . . . . . . . . . 9 3.3.3. Success ratio of discovery operations . . . . . . . . 9 4. NATed peer joins the overlay . . . . . . . . . . . . . . . . . 10 4.1. Joining peer's behavior . . . . . . . . . . . . . . . . . 10 4.2. Intermediate peers' behavior . . . . . . . . . . . . . . . 10 5. NATed peer routine maintenance . . . . . . . . . . . . . . . . 11 5.1. NATed peer's behavior . . . . . . . . . . . . . . . . . . 11 5.2. Intermediate peers' behavior . . . . . . . . . . . . . . . 11 6. NATed nodes get/put resource . . . . . . . . . . . . . . . . . 12 6.1. NATed node's behavior . . . . . . . . . . . . . . . . . . 12 6.2. Behavior of peers processing the request . . . . . . . . . 12 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Ackknowlegement . . . . . . . . . . . . . . . . . . . . . . . 12 10. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informational References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Jiang Expires December 22, 2007 [Page 2] Internet-Draft P2PSIP STUN TURN June 2007 1. Introduction The P2PSIP working group intends to make use of Peer-to-peer (P2P) technology to provide distributed location service. A P2PSIP overlay is comprised of P2PSIP peers, each of which provides transport and storage service for other nodes in the overlay. Therefore critically-important messages will be transported through the overlay between peers which may not know each other's existence and location in advance. For a variety of reasons described in [RFC4787], NATs may cause the communication between peers to fail. Similarly, applications residing on the peers or clients experience the same problem. According to the data from [Illuminati], 74% PCs on the Internet are behind NAT. The methods used to make applications traverse NAT are complicated because of diversity of NAT implementations, also described in [RFC4787]. In IETF, there are a suite of proposals to address this issue, named STUN/TURN/ICE. The essence of these protocols is to make a well-known server with public address to help nodes behind NAT learn the mappings on the NATs or on the TURN server, then follow ICE process to negotiate a workable address pair. STUN/TURN servers play a very important role for the successful communication in environments where NATs are located between communication endpoints, but this also imposes significant demand on the processing capability of STUN/TURN servers. In use cases where the demand is to be met by deploying centralized STUN/TURN servers, carriers will incur expensive investment on these servers and the resulting system will not scale well. Fortunately, there are a great number of peers and clients with public address in the overlay which could take the role of STUN/TURN server if network operators (or network users) are willing to equip these nodes with STUN/TURN server functions and are willing to help nodes behind NAT and their contributed processing power could help satisfy the demand for computing and network resources. The general service discovery mechanism in DHT encodes the service first and puts contact information of the service provider into the overlay under the key K computed by applying hash function to the encoded service. When a node wants to get one or more service providers, it will send a GET message keyed by K and get the service nodes finally. But this method will cause the admitting peer for Key K overwhelmed with huge numbers of requests and it will also be subject to DOS attack. This draft proposes a lightweight method to discover peers or clients with STUN/TURN server functionality distributed through the overlay. Jiang Expires December 22, 2007 [Page 3] Internet-Draft P2PSIP STUN TURN June 2007 2. Definition 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 [RFC2119]. Terms defined in [concept] are re-used without further definition in this document. Some new concepts are defined in this section. o Sending node: It identifies the node, either a peer or a client, who sends a request. o Intermediate peers: it identify all peers on the path from the sending node to the message destination, including the peer which is the message destination. o STUN/TURN server candidates: The nodes which are willing to play the STUN/TURN server role. Various types of nodes could be the candidate, including peer, client. Short form of name: server candidate. o STUN/TURN candidate table: It stores information about STUN/TURN server candidates. Every peer MUST have this table, but the number of entry in the candidate table may be zero because of distribution of server candidates in the overlay. Each entry of the table is learned dynamically. Peers in the routing table or neighbor table or connection table which are willing to be server candidates MUST be filled into the table. The peer which is ready to provide STUN/TURN service SHOULD include its own information in the table. Clients which are associated with the peers and ready to provide STUN/TURN service SHOULD be also filled. The information about each candidate includes the candidate's transport address at least. Short form of name: candidate table. o STUN/TURN candidate set: It is often carried in messages at the request of the sending node. It will be returned to the sending node of this message. Its content includes server candidates which are chosen and put into the candidate set. Short form of name: candidate set. o NATed node: refer to peers or clients which are behind NAT. They need STUN/TURN servers' help to traverse NAT. NATed peers and NATed clients are refer to peers and clients who are behind NAT. o routing table, routing state: In this document, routing means overlay level routing, not IP network level routing. 3. Overview and concept This section provides a non-normative description of the procedure used to select STUN/TURN server candidates. It also describes the Jiang Expires December 22, 2007 [Page 4] Internet-Draft P2PSIP STUN TURN June 2007 STUN/TURN candidate table saved in every peer whose content could be learned from routing table, neighbor table or some other sources, for example, client's characteristics. Normative text is found in the subsequent sections. 3.1. Problem statement The existence of NAT in the Internet challenges P2P communications. In P2PSIP case, both peer protocol and other applications which invoke services provided by P2PSIP overlay have to deal with NAT traversal issue. As for NAT traversal for peer protocol, [bootstrap] and [dSIP-NAT] have proposed some mechanisms. It makes use of bootstrap server to introduce joining peer to bootstrap peer and finally to admitting peer. Peers on the path between the joining peer and the admitting peer play the role of the rendezvous server to help two peers wishing to communicate with each other exchange their candidate addresses in order to obtain a workable candidate address pair in the following ICE process. Because the joining peer hasn't joined the overlay at that time, STUN/TURN server could be chosen in several ways, either among centralized servers configured statically or in the results from the enrollment procedure which may return addressing information that points to some stable peers with STUN/TURN server function. As for other applications beyond the peer protocol, they often look up necessary information, for example other SIP UA's contact address in VoIP application, then communicate with each other after getting the results stored in the overlay. This kind of potential communication requires that these applications should work even if NATs are between them, so they should find out STUN/TURN servers to help them. These servers could be obtained in various ways, including mechanisms described above. But taking distributed processing power of the overlay into account, choosing nodes, either clients or peers, in the overlay with STUN/TURN server capability is also a good choice. How do the peers discover the STUN/TURN server candidates? Certainly, general service discovery mechanism is a viable option, but the peer being responsible for storing the associated key with the service potentially has to serve a large number of requests in some deployment scenarios and is subject to DOS attack. So a lightweight discovery method which makes use of routine traffic, for example, JOIN, GET, PUT, or some routing state maintenance message, to do this work is preferable over the general service discovery mechanism. Certainly, this method makes some assumptions and couldn't guarantee success for each discovery operation. But it Jiang Expires December 22, 2007 [Page 5] Internet-Draft P2PSIP STUN TURN June 2007 could complement to the general service discovery mechanism or similiar methods. 3.2. Use case and assumptions In this section, we will present some assumptions for this proposals first, then give some scenarios which are chosen from the [USE CASE], and explain why this proposal is more suited in these scenarios. 3.2.1. Assumption There are some assumptions for this proposal described in the following text. 1. In many deployments, there should be some peers or clients who have public addresses and are willing to share their processing resource, mainly including CPU cycles, bandwidth, to help NATed nodes to traverse the NAT to communicate with others in the ovelay. The ratio of the number of this kinds of nodes ( which would play the STUN/TURN role ) to the number of the all nodes in the overlay could be as low as possible. From our analysis in the following section, even the ratio which is as low as 1% could make the successful discovery with high probability. 2. Peers/clients SHOULD know whether it is NATed or not before the communication begins. It could be achieved after they get their server-reflexive candidates using STUN protocol. If the server- reflexive candidate does not equal to one of its own local interface address, we could conclude that there is at least a NAT between them and the public Internet. But how peers/clients learn this information will not be discussed in this document. 3.2.2. Use case P2PSIP intends to work in several scenarios which are proposed in [USE CASE]. Here we will present two use cases which is more appropriate place for the proposed discovery mechanism to be used. 1. Open global P2P VoIP network. This is a global P2P VoIP network in which there is no central authority such as a single service provider. So, there are often no centralized servers in the overlay except bootstrap servers which will help joining node, either peers or clients, participate in the overlay. It is a good scenario to make full use of various resources, for example, bandwidth, CPU cycles, etc, distributed among each participants. With the help from participants who are able and willing to be the STUN/TURN servers, participants in the overlay could succeed to communicate with each other even in the presence of the NAT. Jiang Expires December 22, 2007 [Page 6] Internet-Draft P2PSIP STUN TURN June 2007 2. Impeded access. Certain groups may have their ability to communicate impeded. These users should be able to communicate without the need to connect to any centralized servers, which may be blocked by providers upstream of the user. A fully decentralized system cannot be completely disconnected without removing connectivity at the basic Internet level. Likely, no centralized servers exist in this scenario. The possible method in this case for participants to communicate with each other in the presence of NAT is to choose some participants to take on the STUN/TURN task. Besides the two above cases, there are a few scenarios where some participants, which are eligible STUN/TURN servers, could be chosen to help NATed nodes. Usually, some centralized STUN/TURN servers MAY be deployed for NAT traversal. These servers MAY fail simultaneously or could not serve new requests due to limit on the processing power. So these eligible participants distributed in the overlay could be the last resort for NATed nodes to get STUN/TURN service. 3.3. Procedure to discover STUN/TURN server candidate In this section, we will give a overview of the procedure for discovering STUN/TURN server candidates with a lightweight method which will make full use of existing techniques in the P2PSIP. There are a great number of messages routed through the overlay in recursive or iterative mode. These messages comprise of JOIN, PUT, GET, etc. Most of requests will be relayed peer by peer until it reaches its destination. It is the right time for the peers the request has traversed to collect information on STUN/TURN server candidates for the sending node. If the sending node, either a peer or a client, is behind NAT, it could indicate its willingness in the requests that server candidates are needed. When intermediate peers receive the request, they examine whether the sending node wants to collect server candidates first. If it does, the intermediate peers MUST look up its STUN/TURN candidate table, and put the server candidates chosen according to specific criteria into the candidate set in the response or request, which depends on routing mode, for example, iterative or recursive. Finally candidate set MUST be returned to the sending node. So the discovery work could be done in a piggyback mode which hardly bring any bad effect on the P2PSIP overlay. 3.3.1. Construction of STUN/TURN candidate table Intermediate peers look up the STUN/TURN candidate table. In the current proposal, the following sources are explored to select server Jiang Expires December 22, 2007 [Page 7] Internet-Draft P2PSIP STUN TURN June 2007 candidates. In the future, there may be other sources due to richer information of Peers. 1. Routing state. It includes routing table, neighbor table and connection table. Either in dSIP or in P2PP, two proposal for peer protocol, routing state SHOULD keep other peers' transport addresses to allow further communication. Usually, information about the sending peers is carried in the peer protocol message, which is required in either [dSIP] or [P2PP]. P2PP uses Peer- Info to achieve this goal and dSIP uses DHT-PeerID header. Each peer could indicate to other peers whether it is willing to be a STUN/TURN server . So it is easily for the peer to store other peers' features with the routing state. Every peer MUST include peers which show their willingness to be a STUN/TURN server into candidate table by examing every peer in the routing state. 2. Peer's feature. Every peer knows whether it is willing to be a STUN/TURN server. If it is, it SHOULD be put into the STUN/TURN candidate table. 3. Associated clients' feature. In P2PSIP architecture, a client need peer's help to access overlay, i,e, GET/PUT/REMOVE operations. Although the interaction between the peer and the client has not been agreed in WG discussions, it is easy for the peer to learn the feature of its associated clients. So the peer will know whether the client is willing to be a STUN/TURN server. Peers SHOULD also add the clients which are willing to be a STUN/ TURN server into the candidate table. The peer may prioritize the resulting server candidates according its source. For example, routing state may has the highest priority, and associated clients have the lowest, because peers is often more powerful than the clients. In order to make the service load distributed through the candidates, peer could choose candidates for sending nodes according to some algorithms, for example, choose the candidates randomly. We have listed three sources in the peer, but the source list is not exhaustive. New sources may be added in the future. Each entry of the candidate table may include the following parameters: o transport address: transport address for STUN/TURN service. o Role of this candidate in the overlay: peers or clients. o Priority: used in choosing the candidate. The priority for each server candidate may change according to a specific algorithm to balance load among these server candidates. o Some performance parameters: it will be a criteria for peers to choose the server candidate. They may include their CPU processing power, bandwidth,etc. Jiang Expires December 22, 2007 [Page 8] Internet-Draft P2PSIP STUN TURN June 2007 3.3.2. Discovery procedure NATed nodes needs STUN/TURN server candidates to address NAT traversal issue, then initiated discovery procedure in a piggyback mode. There are several messages which could be used to piggyback to discover STUN/TURN server candidate. In this draft, we suggest three types of messages to collect STUN/ TURN server candidate: JOIN message, periodical maintenance message and GET/PUT message. The reason for choosing these messages is that they are common used message in the overlay and routed through the overlay, so using them does not bring extra traffic in the overlay. The procedure while using different messages is almost identical. The following text shows the simple procedure. Although this procedure is more helpful to NATed nodes, non-NATed nodes could also execute this procedure to discover server candidates, which may be passed to other NATed nodes. 1. NATed nodes send the message and set associated options to express their demand for STUN/TURN server candidate in the message. 2. Intermediate peers check the sending node's demand for server candidate. If associated option is set, peers look up their STUN/TURN candidate table and put the results into the candidate set carried in the request or response which depends on routing mode. If recursive mode is used, candidate set will be carried in the request and later be returned to the sending node hop by hop in the response. If iterative mode is used, candidate set will be returned to the sending node in response immediately. 3. Finally, NATed nodes get the results in the response and use them in the future communications. 3.3.3. Success ratio of discovery operations NATed nodes could use the above procedure to discover server candidates. In rare case, one piggyback operation may fail because there is no STUN/TURN server candidate on the intermediate peers. The candidate set returned from the overlay to NATed nodes is NULL in this case. Using another message which traverse different path may identify a non-NULL candidate set with higher capability. Reasoning is presented here to prove that the method makes sense for discovering server candidates. First, Let us assume that the ratio of the number of the peers which are willing to be STUN/TURN server to all peers is about f = 10% . Then we could deduce that there is about 10 percent of peers which could be STUN/TURN server candidates in the routing state of every peer. For example, in [Pastry], a Jiang Expires December 22, 2007 [Page 9] Internet-Draft P2PSIP STUN TURN June 2007 simulation result shows that with the b = 4, and 10 ** 6 nodes in the overlay, a routing table contains on average 75 entries and the expected number of routing hops is 5. So the number of entry in candidate table would be about 7.5( 75 * 10%) in each peer, and ultimately choice could be made based on these 38(7.5 * 5) server candidates. Even if f equals 2%, there are still about 7 server candidates. 4. NATed peer joins the overlay 4.1. Joining peer's behavior Before a joining peer joins the overlay, it MUST learn whether it is a NATed peer. Other than performing standard P2PSIP peer protocol procedure, NATed peer MUST perform the below procedure to discover server candidates. Certainly, non-NATed peers also could perform this procedure. 1. Joining peer MUST express its demand on STUN/TURN server candidates in the JOIN message for intermediate peers of the JOIN request to invoke discovery operation. How the joining peer express his demand is not determined at present because P2PSIP peer protocol has not been standardized. But it will be easy to achieve this goal as soon as P2PSIP peer protocol is fixed. The joining peer MAY specify the number of server candidates it wants in the requests. 2. When the joining peer receives the response from the peers in the overlay, if it has expressed the demand on server candidate, it MUST check the candidate set in the response and save the candidate set locally for later use. 4.2. Intermediate peers' behavior Intermediate peers of the JOIN message MUST do their routine processing based on standardized P2PSIP peer protcol. If they find that the sending peer has expressed his demand on server candidates, they MUST follow below procedure additionally. 1. If the message is a response, intermediate peers don't do additional processing beyond forwarding; 2. If the message is a request, peers receives a STUN/TURN candidate set in the request. If the sending peer has set the number of candidate it wants in the message, set the N to this number. If it has not been set in the message, we MAY choose a default value for N, for example, 10; Jiang Expires December 22, 2007 [Page 10] Internet-Draft P2PSIP STUN TURN June 2007 3. If the number K in STUN/TURN candidate set equals or exceeds N, peers don't do anything; 4. Peers fetch candidates from its candidate table according to a specific criteria, for example, priority, or performance parameters; 5. Peers perform comparison operation before adding a new STUN/TURN candidate into the candidate set. The comparison criteria MAY be based on IP address and keeps the candidate in the candidate set unique; 6. Each time peer places a server candidate into the candidate set, set K to K + 1; 7. The lookup operation in the candidate table will stop because either the K equals N or all server candidates in the candidate table has been examined. 5. NATed peer routine maintenance Peers often do routine maintenance work to keep the routing table consistent with the ovelay topology as much as possible. For example, the Chord algorithm checks whether peers in the finger table has changed due to topology change of the overlay by sending periodical message. So if NATed peers like, they could use this type of message to discover server candidates. 5.1. NATed peer's behavior The processing of this type of message MUST follow procedure in the P2PSIP peer protocol. If NATed peers would like to collect STUN/TURN server candidate, they MUST also follow the procedure below. Of course, Non-NATed peers could also perform the below procedure. 1. When NATed peers want to collect STUN/TURN server candidate, they MUST express their interest in the corresponding message. They MAY specify the number of the server candidate they want in the message. 2. When the NATed peer receives the response from the peers in the overlay, if it has expressed the demand, it MUST check the candidate set in the response and save the candidate set locally for later use. 5.2. Intermediate peers' behavior The procedure is the same as the procedure defined in section 4.2. Jiang Expires December 22, 2007 [Page 11] Internet-Draft P2PSIP STUN TURN June 2007 6. NATed nodes get/put resource When NATed clients of the overlay wants to get some candidates for their future communication, they MAY make use of the GET/PUT messages to achieve this goal. Certainly, GET/PUT messages are also to be used by NATed Peers to discover server candidate. 6.1. NATed node's behavior The processing of GET/PUT messages MUST follow procedures in the P2PSIP peer and client protocol. If they would like to discover STUN/TURN server candidate, they MUST follow the additional procedure below. 1. When NATed nodes want to discover server candidate, they MUST express their desire in the GET or PUT messages. They MAY specify the number of the server candidates they want in the message. 2. When the NATed node receives the response from the peers in the overlay, if it has expressed the desire for STUN/TURN server candidate, it check the candidate set in the response and save the candidate set locally for later use. 6.2. Behavior of peers processing the request The procedure is the same as the procedure defined in section 4.2. 7. Security considerations Security considerations will be discussed in a future version of this document. 8. IANA considerations IANA considerations will be discussed in a future version of this document. 9. Ackknowlegement The authors are especially grateful for the comments and constructive advice from Spencer Dawkins and Philip Matthews. Jiang Expires December 22, 2007 [Page 12] Internet-Draft P2PSIP STUN TURN June 2007 10. Reference 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/ Answer Protocols", Internet Draft draft-ietf-mmusic-ice (Work in Progress). [Concept] Bryan, D., Matthews, P., Shim, E., Willis, D., " Concepts and Terminology for Peer to Peer SIP " Internet Draft draft-willis-p2psip-concepts-04 (Work in progress) [TURN] Rosenberg, J., Mahy, R., Huitema, C., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)" Internet Draft draft-ietf-behave-turn-03 (Work in Progress) [STUN] Rosenberg, J., Huitema, C., Mahy, R., Willis, D., "Session Traversal Utilities for (NAT) (STUN)" Internet Draft draft-ietf-behave-rfc3489bis-06 (Work in Progress) 10.2. Informational References [dSIP] Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P Approach to SIP Registration and Resource Location", Internet Draft draft-bryan-p2psip-dsip-00 (Work in Progress), February 2007. [Illuminati] Cadaco, M. and M. Freedman, "Illuminati - Opportunistic Network and Web Measurement",http://illuminati.coralcdn.org/stats/, February 2007. [dSIP-NAT] Cooper, E., Matthews, P., Bryan, D., and B. Lowekamp, "NAT Traversal for dSIP", Internet Draft draft-matthews-p2psip-dsip-nat-traversal-00 (Work in Progress), February 2007. [Bootstrap] Cooper, E., Johnston, A., and P. Matthews, "Bootstrap Mechanisms for P2PSIP", Internet Draft draft-matthews-p2psip-bootstrap-mechanisms (Work in Progress). [P2PP] Baset, S., Schulzrinne, H., "Peer-to-Peer Protocol (P2PP)" Jiang Expires December 22, 2007 [Page 13] Internet-Draft P2PSIP STUN TURN June 2007 Internet Draft draft-baset-p2psip-p2pcommon-01 (Work in Progress ) [PASTRY] Rowstron, A., Druschel, R., "Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems" Proc. of the 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001). Heidelberg, Germany, November 2001. [Use case] 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. Author's Address XingFeng Jiang Huawei Tech. Phone: +86(25)84565468 Email: jiang.x.f@huawei.com Jiang Expires December 22, 2007 [Page 14] Internet-Draft P2PSIP STUN TURN 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). Jiang Expires December 22, 2007 [Page 15]