draft-ietf-p2psip-sip-17.txt   draft-ietf-p2psip-sip-18.txt 
P2PSIP C. Jennings P2PSIP C. Jennings
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track B. Lowekamp Intended status: Standards Track B. Lowekamp
Expires: September 10, 2016 Skype Expires: October 9, 2016 Skype
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
T. Schmidt, Ed. T. Schmidt, Ed.
HAW Hamburg HAW Hamburg
March 9, 2016 April 7, 2016
A SIP Usage for RELOAD A SIP Usage for RELOAD
draft-ietf-p2psip-sip-17 draft-ietf-p2psip-sip-18
Abstract Abstract
This document defines a SIP Usage for REsource LOcation And Discovery This document defines a SIP Usage for REsource LOcation And Discovery
(RELOAD). The SIP Usage provides the functionality of a SIP proxy or (RELOAD). The SIP Usage provides the functionality of a SIP proxy or
registrar in a fully-distributed system and includes a lookup service registrar in a fully-distributed system and includes a lookup service
for Address of Records (AORs) stored in the overlay. It also defines for Address of Records (AORs) stored in the overlay. It also defines
Globally Routable User Agent Uris (GRUUs) that allow the Globally Routable User Agent URIs (GRUUs) that allow the
registrations to map an AOR to a specific node reachable through the registrations to map an AOR to a specific node reachable through the
overlay. After such initial contact of a peer, the AppAttach method overlay. After such initial contact of a peer, the RELOAD AppAttach
is used to establish a direct connection between nodes through which method is used to establish a direct connection between nodes through
SIP messages are exchanged. which SIP messages are exchanged.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2016. This Internet-Draft will expire on October 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 18 skipping to change at page 4, line 18
his Node-ID in the overlay by applying a Store request for his Node-ID in the overlay by applying a Store request for
"bob@dht.example.com -> 1234". "bob@dht.example.com -> 1234".
2. Alice, operating Node-ID "5678", decides to call Bob. She 2. Alice, operating Node-ID "5678", decides to call Bob. She
retrieves Node-ID "1234" by performing a Fetch request on retrieves Node-ID "1234" by performing a Fetch request on
"bob@dht.example.com". "bob@dht.example.com".
3. Alice uses the overlay to route an AppAttach message to Bob's 3. Alice uses the overlay to route an AppAttach message to Bob's
peer (ID "1234"). Bob responds with his own AppAttach and they peer (ID "1234"). Bob responds with his own AppAttach and they
set up a direct connection, as shown in Figure 1. Note that set up a direct connection, as shown in Figure 1. Note that
mutual ICE checks are invoked automatically from AppAttach mutual Interactive Connectivity Establishment (ICE) checks are
message exchange. invoked automatically from AppAttach message exchange.
Overlay Overlay
Alice Peer1 ... PeerN Bob Alice Peer1 ... PeerN Bob
(5678) (1234) (5678) (1234)
------------------------------------------------- -------------------------------------------------
AppAttach -> AppAttach ->
AppAttach -> AppAttach ->
AppAttach -> AppAttach ->
AppAttach -> AppAttach ->
<- AppAttach <- AppAttach
skipping to change at page 12, line 26 skipping to change at page 12, line 26
possible that the peers already have a RELOAD connection mutually possible that the peers already have a RELOAD connection mutually
established. This MUST NOT be used for SIP messages unless it is a established. This MUST NOT be used for SIP messages unless it is a
SIP connection. A previously established SIP connection MAY be used SIP connection. A previously established SIP connection MAY be used
for a new call. for a new call.
Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted
SIP messages over the connection as in normal SIP. A caller MAY SIP messages over the connection as in normal SIP. A caller MAY
choose to contact the callee using SIP or secure SIPS, but SHOULD choose to contact the callee using SIP or secure SIPS, but SHOULD
follow a preference indicated by the callee in its contact_prefs follow a preference indicated by the callee in its contact_prefs
attribute (see Section 3.2). A callee MAY choose to listen on both 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 SIP and SIPS ports and accept calls from either SIP schemes, or
a single one. However, a callee that decides to accept SIPS calls, select a single one. However, a callee that decides to accept SIPS
only, SHOULD indicate its choice by setting the corresponding calls, only, SHOULD indicate its choice by setting the corresponding
attribute in its contact_prefs. It is noteworthy that according to attribute in its contact_prefs. It is noteworthy that according to
[RFC6940] all overlay links are built on (D)TLS secured transport. [RFC6940] all overlay links are built on (D)TLS secured transport.
While hop-wise encrypted paths do not prevent the use of plain SIP, While hop-wise encrypted paths do not prevent the use of plain SIP,
SIPS requires end-to-end protection that may include client links and SIPS requires end-to-end protection that may include client links and
endpoint certificates. endpoint certificates.
SIP messages carry the SIP URIs of actual overlay endpoints (e.g., SIP messages carry the SIP URIs of actual overlay endpoints (e.g.,
"sip:alice@dht.example.com") in the Via and Contact headers, while "sip:alice@dht.example.com") in the Via and Contact headers, while
the communication continues via the RELOAD connection. However, a UA the communication continues via the RELOAD connection. However, a UA
can redirect its communication path by setting an alternate Contact can redirect its communication path by setting an alternate Contact
skipping to change at page 13, line 7 skipping to change at page 13, line 7
traffic to keep NAT and Firewall states present and the connection traffic to keep NAT and Firewall states present and the connection
alive. Keepalives are a mandatory component of ICE (see Section 10 alive. Keepalives are a mandatory component of ICE (see Section 10
of [RFC5245]) and no further operations are required. Applications of [RFC5245]) and no further operations are required. Applications
that want to assure maintenance of sessions individually need to that want to assure maintenance of sessions individually need to
follow regular SIP means. Accordingly, a SIP Peer MAY apply keep- follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-
alive techniques in agreement with its transport binding as defined alive techniques in agreement with its transport binding as defined
in Section 3.5 of [RFC5626]. in Section 3.5 of [RFC5626].
6. Using GRUUs 6. Using GRUUs
Globally Routable User Agent Uris (GRUUs) [RFC5627] have been Globally Routable User Agent URIs (GRUUs) [RFC5627] have been
designed to allow direct routing without the indirection of a SIP designed to allow direct routing without the indirection of a SIP
proxy function. The concept is transferred to RELOAD overlays as proxy function. The concept is transferred to RELOAD overlays as
follows. GRUUs in RELOAD are constructed by embedding a follows. GRUUs in RELOAD are constructed by embedding a
base64-encoded destination list in the gr URI parameter of the GRUU. base64-encoded destination list in the "gr" URI parameter of the
The base64 encoding is done with the alphabet specified in table 1 of GRUU. The base64 encoding is done with the alphabet specified in
[RFC4648] with the exception that ~ is used in place of =. table 1 of [RFC4648] with the exception that ~ is used in place of =.
Example of a RELOAD GRUU: Example of a RELOAD GRUU:
alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~ alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~
GRUUs do not require to store data in the Overlay Instance. Rather GRUUs do not require to store data in the Overlay Instance. Rather
when a peer needs to route a message to a GRUU in the same P2P when a peer needs to route a message to a GRUU in the same P2P
overlay, it simply uses the destination list and connects to that overlay, it simply uses the destination list and connects to that
peer. Because a GRUU contains a destination list, it can have the peer. Because a GRUU contains a destination list, it can have the
same contents as a destination list stored elsewhere in the resource same contents as a destination list stored elsewhere in the resource
dictionary. dictionary.
skipping to change at page 16, line 26 skipping to change at page 16, line 26
10. Acknowledgments 10. Acknowledgments
This document was generated in parts from initial drafts and This document was generated in parts from initial drafts and
discussions in the early specification phase of the P2PSIP base discussions in the early specification phase of the P2PSIP base
protocol. Significant contributions (in alphabetical order) were protocol. Significant contributions (in alphabetical order) were
from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan
Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged. Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged.
Additional thanks go to all those who helped with ideas, discussions, Additional thanks go to all those who helped with ideas, discussions,
and reviews, in particular (in alphabetical order) Roland Bless, and reviews, in particular (in alphabetical order) Roland Bless,
Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, and Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral
Matthias Waehlisch. Shirazipour, and Matthias Waehlisch.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 18, line 13 skipping to change at page 18, line 13
2016. 2016.
[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-
Driven Privacy Mechanism for SIP", RFC 5767, Driven Privacy Mechanism for SIP", RFC 5767,
DOI 10.17487/RFC5767, April 2010, DOI 10.17487/RFC5767, April 2010,
<http://www.rfc-editor.org/info/rfc5767>. <http://www.rfc-editor.org/info/rfc5767>.
[I-D.ietf-p2psip-share] [I-D.ietf-p2psip-share]
Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A
Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf- Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf-
p2psip-share-07 (work in progress), November 2015. p2psip-share-08 (work in progress), March 2016.
Appendix A. Third Party Registration Appendix A. Third Party Registration
In traditional SIP, the mechanism of a third party registration In traditional SIP, the mechanism of a third party registration
(i.e., an assistant acting for a boss, changing users register a (i.e., an assistant acting for a boss, changing users register a
role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This
is a REGISTER which uses the URI of the third-party in its From is a REGISTER which uses the URI of the third-party in its From
header and cannot be translated directly into a P2PSIP registration, header and cannot be translated directly into a P2PSIP registration,
because only the owner of the certificate can store a SIP- because only the owner of the certificate can store a SIP-
REGISTRATION in a RELOAD overlay. REGISTRATION in a RELOAD overlay.
 End of changes. 12 change blocks. 
20 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/