PPSP Working Group L. Li Internet-Draft J. Wang Intended status: Standards Track Y. Meng Expires: April 21, 2011 ZTE Corporation October 18, 2010 PPSP NAT traversal draft-li-ppsp-nat-traversal-00 Abstract This document proposes a NAT traversal solution using ICE for PPSP. To use ICE with PPSP, this document proposes some modifications to ICE and some requirements on PPSP. First, capable PPSP peers function as STUN/relay servers, and PPSP protocol is used to discover them. Second, PPSP protocol is used to convey candidate addresses. Third, in addition to STUN message, PPSP message is proposed as an option to test connectivity. Fourth, as an option, proxy peer is proposed to relay PPSP messages. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Li, et al. Expires April 21, 2011 [Page 1] Internet-Draft PPSP NAT traversal October 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5 4. NAT traversal solution . . . . . . . . . . . . . . . . . . . . 7 4.1. PPSP signal traversal . . . . . . . . . . . . . . . . . . 7 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . . 8 4.1.2. Conveying Candidates . . . . . . . . . . . . . . . . . 9 4.1.3. One-direction Connectivity Checks . . . . . . . . . . 9 4.1.4. Using ICE to optimize connection . . . . . . . . . . . 10 4.2. PPSP media traversal . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Li, et al. Expires April 21, 2011 [Page 2] Internet-Draft PPSP NAT traversal October 2010 1. Introduction NAT is widely deployed in the Internet. Three NAT traversal solutions have been proposed in [I-D.gu-ppsp-peer-protocol]. However, these solutions either require introducing RELOAD protocol or require server(e.g. tracker) to relay. This document proposes another NAT traversal solution using ICE [RFC5245] for PPSP. This solution doesn't require introducing RELOAD protocol, and doesn't increase much workload on tracker. This document discusses both signal and media traversal of NAT. To use ICE with PPSP, this document proposes some modifications to ICE and some requirements on PPSP. First, capable PPSP peers function as STUN [RFC5389] or relay servers, and PPSP protocol is used to discover them. Second, PPSP protocol is used to convey candidate addresses. Third, in addition to STUN message, PPSP message is proposed as an option to test connectivity. Fourth, as an option, proxy peer is proposed to relay PPSP messages. Li, et al. Expires April 21, 2011 [Page 3] Internet-Draft PPSP NAT traversal October 2010 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. We use the terminology and definitions from "Problem Statement of P2P Streaming Protocol" [I-D.zhang-ppsp-problem-statement] and ICE [RFC5245] and extensively in this document. Other terms used in this document are defined below. STUN peer. A STUN peer is a peer functioning as a STUN server and providing STUN services to other peers. Relay peer. A relay peer is a peer providing relay service to other peers. The relay service may be provided in PPSP layer or TURN layer or both. TURN peer. A TURN peer is a relay peer providing relay service in TURN [RFC5766] layer. In another word, a TURN peer is a peer functioning as a TURN server and providing TURN services to other peers. Proxy peer. A proxy peer is a relay peer providing relay service in PPSP layer. In another word, a proxy peer is a peer functioning as a proxy server and providing PPSP proxy services to other peers. Unlike TURN peer, proxy peer only relays PPSP messages. Proxy candidate. As the defined in ICE, a candidate is a transport address, which is potential for communication. A peer's proxy candidate is the address of a proxy peer serving for the peer. Through a peer's proxy candidate, the peer can be contacted. Li, et al. Expires April 21, 2011 [Page 4] Internet-Draft PPSP NAT traversal October 2010 3. Reference Model In the PPSP architecture, there are two kinds of nodes: tracker and peer. As shown in figure 1, this document introduces some special peers: STUN peer, relay peer, TURN peer and proxy peer. STUN peers act as STUN servers and provide STUN services to other peers, while relay peers act as relay servers and provide relay services to other peers. Relay service can be provided in two layers: TURN layer and PPSP layer. If relay service is provided in TURN layer, relayed messages are encapsulated in TURN packets. The relay peer providing relay service in TURN layer is called TURN peer. If relay service is provided in PPSP layer, only PPSP messages can be relayed. The relay peer providing PPSP relay service in PPSP layer is called proxy peer. +------------+ |relay peer E| report TURN ability |(TURN peer) |-------------------+ +------+ +------------+ \ |peer C| \ +------+ \ get | \ peer | +------+report candidates \ list | |peer A|---------------->+-----+--------+<-------+ +------+ | | report STUN ability+-----------+ | tracker |<--------------------|STUN peer D| | | ` +-----------+ +------+get STUN/relay peer list | | |peer B|------------------------>+-----+--------+ +---+--+ | \establish | \asocition | \ | +---+--------+ | |relay peer F| report proxy ability| |(proxy peer)|---------------------+ +------------+ Figure 1: PPSP reference model PPSP protocol is used to discover STUN/relay peer. Capable peer reports its STUN/relay ability to tracker when connecting to the P2P streaming system and tracker maintains the STUN/relay peer list. Then a peer can query STUN/relay peer list from tracker when needed. Additionally, peers MAY exchange STUN/relay server peer list. PPSP protocol is used to convey candidate addresses. Each peer Li, et al. Expires April 21, 2011 [Page 5] Internet-Draft PPSP NAT traversal October 2010 gathers its candidate addresses and reports them to tracker. Peer can discover other peers' candidate addresses from the peer list obtained from tracker or other peers. Two peers can exchange ICE parameters including candidate addresses in offer/answer model directly or via a third-party proxy peer. Li, et al. Expires April 21, 2011 [Page 6] Internet-Draft PPSP NAT traversal October 2010 4. NAT traversal solution 4.1. PPSP signal traversal The process of PPSP signal traversal is shown in Figure 2. As shown in Figure 2, the process of a peer (peer A) establishing PPSP connection to another peer (peer B) includes following seven steps (step 5 to step 7 is optional). 1, both peer A and B gather their candidates, and report their candidates to tracker when joining swarm. 2, peer A gets peer list from tracker or other peer(s) and learns peer A's candidates from peer list. 3, peer A does one- direction ICE or PPSP connectivity checks from peer A to peer B. 4, peer A chooses candidate pair based the result of one-direction ICE or PPSP connectivity checks. 5, peer B and peer A exchange ICE parameters with PPSP messages. 6, peer A and B performs two-direction ICE connectivity checks or one-direction ICE connectivity checks from peer B to peer A. 7, peer A or peer B chooses candidate pair. After step 4, peer A has established a communication path to peer B. But the communication path may not be the optimal one, because the path is discovered based on one-direction connectivity checks from peer A to peer B. So step 5 to step 7 is used to find a better communication path. Step 5 to step 7 a standard ICE process. This ICE process is optional because the best communication path may have been found or may not be necessary. Following sections will describe the key steps of PPSP signal traversal in details. Li, et al. Expires April 21, 2011 [Page 7] Internet-Draft PPSP NAT traversal October 2010 Peer A Peer B | | +-------+---------+ +-------+---------+ |gather candidates| |gather candidates| |and report to | |and report to | | tracker | | tracker | +-------+---------+ +-------+---------+ | | +-------+-----------------+ | |Get peer list from | | |tracker or other peers. | | |Extract peer B's | | |candidates from peer list| | +-------+-----------------+ | +----+--------------------------------------------+----+ |one-direction ICE/PPSP connectivity checks from A to B| +----+--------------------------------------------+----+ +-----------+---------+ | |select candidate pair| | +-----------+---------+ | | | | exchange ICE paras with PPSP AttachReq&Ans | |<------------------------------------------>| | | +--+--------------------------------------------+--+ | | ICE connectivity checks | | +--+--------------------------------------------+--+ | | +--+--------------------------------------------+--+ | | select candidate pair | | +--+--------------------------------------------+--+ | | Figure 2: PPSP signal traversal 4.1.1. Gathering Candidates Every peer MUST gather candidates for communication. As the defined in ICE, a candidate is a transport address, which is potential for communication. ICE defines host candidate, reflexive candidate and relayed candidate. This document defines one more candidate type called proxy candidate. Proxy candidate is obtained from proxy peer. A proxy peer is a PPSP peer with public accessibility, which can relay PPSP messages to peers associated with it. To be accessible, a peer behind NAT MAY establish association with at least one proxy peer. Establishing association can use PPSP Connect message or a new defined message. Li, et al. Expires April 21, 2011 [Page 8] Internet-Draft PPSP NAT traversal October 2010 Every peer MUST gather its candidates according to its accessibility and the type of connectivity check. Proxy candidate is used for the connectivity check in PPSP layer. Relayed candidate is used for the connectivity check in ICE layer. Host candidate and reflexive candidate can be used for the connectivity check in both ICE layer and PPSP layer. 4.1.2. Conveying Candidates Candidates are conveyed by PPSP messages. When joining a swarm, a peer puts its candidates and peer ID in the JOIN message sent to tracker. Peer list in the PPSP message contains each peer's candidates and peer ID in the list. 4.1.3. One-direction Connectivity Checks Because peer A doesn't know peer B's candidates, the connectivity checks are one-direction checks. The one-direction connectivity checks can be performed in ICE layer or PPSP layer. This document leaves the layer of connectivity checks as an open issue for the WG to discuss. If the connectivity checks are performed in ICE layer, ICE connectivity check is used with some modifications to STUN/TURN authentication. ICE uses STUN binding request and response to check connectivity. Standard ICE [RFC5245] uses offer/answer exchange to exchange STUN username fragment and password. In standard ICE [RFC5245], the username part of STUN credential is formed by concatenating a username fragment from each ICE agent, separated by a colon. However, there is no offer/answer exchange for the one-direction connectivity checks here. A possible solution is to put STUN username and password in peer list. Then in the example shown in Figure 2, peer A can extract peer B's STUN username and password from peer list. According to standard ICE [RFC5245], before certain connectivity checks, an ICE agent MUST create permissions in its TURN server for the IP addresses learned from its peer in the offer/answer exchange. However, in the example shown in figure 2, peer B can't create permissions because peer B doesn't know peer A's IP addresses due to the absence of offer/answer exchange. To address this issue, it needs a new TURN authentication method or another way to create permissions in peer B's TURN server. If the connectivity checks are performed in PPSP layer, PPSP message is used to test connectivity. This document proposes to define a Li, et al. Expires April 21, 2011 [Page 9] Internet-Draft PPSP NAT traversal October 2010 PPSP message called PING for connectivity check. Connectivity check in PPSP layer can use PPSP's own authentication method. 4.1.4. Using ICE to optimize connection After step 4, connection between peer A and peer B is established based on one-direction connectivity checks. Because the checks are one-direction, the established connection may not be optimal. A better connection may be established by performing a standard ICE with two-direction connectivity checks or one-direction connectivity checks of reverse direction. This document proposes to define new PPSP messages called Attach for candidates exchanging. 4.2. PPSP media traversal This document proposes to use ICE for media traversal. The way to use ICE here is almost the same as the way defined in [RFC5245]. In ICE as defined by [RFC5245], SDP is used to carry the ICE parameters. This document proposes to define a PPSP message called MediaAttach for exchanging the ICE parameters including candidates and authentication data. The use of MediaAttach with ICE for NAT traversal is shown in Figure 3 and Figure 4. As shown in these figures, a peer (say peer B) wants to establish media connection to another peer (say peer A). Peer A and peer B already have established PPSP signal connection directly or via a third-party peer (the method to establish signal connection please refers to the above section). So peer A can send a PPSP MediaAttach request to peer B directly or via a third peer. Then Peer B responses to peer A with MediaAttach response message. Through MediaAttach request and response, peer A and peer B exchange ICE parameters. After that, the following NAT traversal process complies with standard ICE [RFC5245]. Li, et al. Expires April 21, 2011 [Page 10] Internet-Draft PPSP NAT traversal October 2010 Peer A Peer B | | | PPSP MediaAttachReq | |------------------------------------------->| | | | PPSP MediaAttachAns | |<-------------------------------------------| | | | | +--+--------------------------------------------+--+ | | ICE connectivity checks | | +--+--------------------------------------------+--+ | | | | +--+--------------------------------------------+--+ | | select candidate pair | | +--+--------------------------------------------+--+ | | Figure 3: PPSP Media Traversal 1 Peer A Peer C(as relay) Peer B | | | | PPSP MediaAttachReq | | |----------------------->|PPSP MediaAttachReq| | |------------------>| | | | | |PPSP MediaAttachAns| | PPSP MediaAttachAns |<------------------| |<-----------------------| | +--+------------------------+-------------------+--+ | | ICE connectivity checks | | +--+------------------------+-------------------+--+ | | | | | | +--+------------------------+-------------------+--+ | | select candidate pair | | +--+------------------------+-------------------+--+ | | | Figure 4: PPSP Media Traversal 2 Li, et al. Expires April 21, 2011 [Page 11] Internet-Draft PPSP NAT traversal October 2010 5. Security Considerations Todo: The content of this section need further input. Li, et al. Expires April 21, 2011 [Page 12] Internet-Draft PPSP NAT traversal October 2010 6. IANA Considerations TBD Li, et al. Expires April 21, 2011 [Page 13] Internet-Draft PPSP NAT traversal October 2010 7. Acknowledgments Thanks Yunfei for commenting on this draft. Li, et al. Expires April 21, 2011 [Page 14] Internet-Draft PPSP NAT traversal October 2010 8. References 8.1. Normative References [I-D.zhang-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", draft-zhang-ppsp-problem-statement-06 (work in progress), July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. 8.2. Informative References [I-D.gu-ppsp-peer-protocol] Gu, Y. and David A. Bryan, "Peer Protocol", draft-gu-ppsp-peer-protocol-00 (work in progress), July 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5766] Matthews, P., Rosenberg, J., and R. Mahy, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC RFC5766, April 2010. Li, et al. Expires April 21, 2011 [Page 15] Internet-Draft PPSP NAT traversal October 2010 Authors' Addresses Lichun Li ZTE Corporation 4F,RD Building 2,Zijinghua Road No.68 Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-7612 Email: li.lichun1@zte.com.cn Jun Wang ZTE Corporation 4F,RD Building 2,Zijinghua Road No.68 Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-7648 Email: wang.jun17@zte.com.cn Yu Meng ZTE Corporation C1-04,RD Building 1,Zijinghua Road No.68 Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-2045 Email: meng.yu@zte.com.cn Li, et al. Expires April 21, 2011 [Page 16]