--- 1/draft-ietf-p2psip-sip-09.txt 2013-07-15 01:14:22.345115727 -0700 +++ 2/draft-ietf-p2psip-sip-10.txt 2013-07-15 01:14:22.385116720 -0700 @@ -1,26 +1,26 @@ P2PSIP C. Jennings Internet-Draft Cisco Intended status: Standards Track B. Lowekamp -Expires: August 29, 2013 Skype +Expires: January 16, 2014 Skype E. Rescorla RTFM, Inc. S. Baset H. Schulzrinne Columbia University T C. Schmidt, Ed. HAW Hamburg - February 25, 2013 + July 15, 2013 A SIP Usage for RELOAD - draft-ietf-p2psip-sip-09 + draft-ietf-p2psip-sip-10 Abstract This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method @@ -35,21 +35,21 @@ 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 August 29, 2013. + This Internet-Draft will expire on January 16, 2014. Copyright Notice Copyright (c) 2013 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 @@ -76,41 +76,44 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Access Control . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Overlay Configuration Document Extension . . . . . . . . . 9 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 11 4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . . 11 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11 + 5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 12 + 5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . . 12 6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . . 13 + 8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . . 14 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . . 14 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 14 8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . . 14 - 8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . 14 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . 15 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. XML Name Space Registration . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Third Party Registration . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 - B.1. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . . 17 - B.2. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . . 17 - B.3. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . . 17 + B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . . 17 + B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . . 17 + B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . . 18 + B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] specifies a peer-to-peer (P2P) signaling protocol for the general use on the Internet. This document defines a SIP Usage of RELOAD that allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions without the requirement for permanent proxy or registration servers, e.g., a fully distributed telephony service. @@ -459,20 +462,21 @@ 2. If any of the results of the Fetch are non-GRUU AORs, then repeat step 1 for that AOR. 3. Once only GRUUs and destination lists remain, the peer removes duplicate destination lists and GRUUs from the list and initiates SIP or SIPS connections to the appropriate peers as described in the following sections. If there are also external AORs, the peer follows the appropriate procedure for contacting them as well. 5. Forming a Direct Connection +5.1. Setting Up a Connection Once the peer has translated the AOR into a set of destination lists, it then uses the overlay to route AppAttach messages to each of those peers. The "application" field MUST be either 5060 to indicate SIP or 5061 for using SIPS. If certificate-based authentication is in use, the responding peer MUST present a certificate with a Node-ID matching the terminal entry in the route list. Note that it is possible that the peers already have a RELOAD connection mutually established. This MUST NOT be used for SIP messages unless it is a SIP connection. A previously established SIP connection MAY be used @@ -481,20 +485,31 @@ Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted SIP messages over the connection as in normal SIP. A caller MAY choose to contact the callee using SIP or secure SIPS, but SHOULD follow a preference indicated by the callee in its contact_prefs attribute (see Section 3.2). A callee MAY choose to listen on both SIP and SIPS ports and accept calls from either SIP scheme, or select a single one. However, a callee that decides to accept SIPS calls, only, SHOULD indicate its choice by setting the corresponding attribute in its contact_prefs. +5.2. Keeping a Connection Alive + + In many cases, RELOAD connections will traverse NATs and Firewalls + that maintain states established from ICE [RFC5245] negotiations. It + is the responsiblity of the application to provide sufficiently + frequent traffic to keep NAT and Firewall states present and the + connection alive. Thus an application SHOULD survey traffic pauses + on each of its SIP or SIPs connections and connection-wise issue a + RELOAD ping after each pause excceeding the STUN indication message + interval. + 6. Using GRUUs Globally Routable User Agent Uris (GRUUs) [RFC5627] have been designed to allow direct routing without the indirection of a SIP proxy function. The concept is transferred to RELOAD overlays as follows. GRUUs in RELOAD are constructed by embedding a base64- encoded destination list in the gr URI parameter of the GRUU. The base64 encoding is done with the alphabet specified in table 1 of [RFC4648] with the exception that ~ is used in place of =. Example of a RELOAD GRUU: @@ -659,40 +674,45 @@ [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999. [RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, December 1999. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + April 2010. + [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [IEEE-Posix] "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937- 255-9, January 1993. 11.2. Informative References [I-D.ietf-p2psip-concepts] - Bryan, D., Willis, D., Shim, E., Matthews, P., and S. + Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", - draft-ietf-p2psip-concepts-04 (work in progress), - October 2011. + draft-ietf-p2psip-concepts-05 (work in progress), + July 2013. [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- Driven Privacy Mechanism for SIP", RFC 5767, April 2010. [I-D.ietf-p2psip-share] Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf-p2psip-share-01 (work in progress), February 2013. @@ -709,44 +729,49 @@ A way to implement third party registration is by using the extended access control mechanism USER-CHAIN-ACL defined in [I-D.ietf-p2psip-share]. Creating a new Kind "SIP-3P-REGISTRATION" that is ruled by USER-CHAIN-ACL allows the owner of the certificate to delegate the right for registration to individual third parties. In this way, original SIP functionality can be regained without weakening the security control of RELOAD. Appendix B. Change Log -B.1. Changes since draft-ietf-p2psip-sip-08 +B.1. Changes since draft-ietf-p2psip-sip-09 + + o Added subsection on keepalive + o Updated references +B.2. Changes since draft-ietf-p2psip-sip-08 o Added the handling of SIPS o Specified use of Posix regular expressions in configuration document o Added IANA registration for namespace o Editorial polishing o Updated and extended references -B.2. Changes since draft-ietf-p2psip-sip-07 +B.3. Changes since draft-ietf-p2psip-sip-07 o Cleared open issues o Clarified use cases after WG discussion o Added configuration document extensions for configurable domain names o Specified format of contact_prefs o Clarified routing to AORs o Extended security section o Added Appendix on Third Party Registration o Added IANA code points o Editorial polishing o Updated and extended references -B.3. Changes since draft-ietf-p2psip-sip-06 +B.4. Changes since draft-ietf-p2psip-sip-06 + o Added Open Issue Authors' Addresses Cullen Jennings Cisco 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA