draft-ietf-p2psip-sip-19.txt   draft-ietf-p2psip-sip-20.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: October 19, 2016 Skype Expires: October 21, 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
April 17, 2016 April 19, 2016
A SIP Usage for RELOAD A SIP Usage for RELOAD
draft-ietf-p2psip-sip-19 draft-ietf-p2psip-sip-20
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 RELOAD AppAttach overlay. After such initial contact of a peer, the RELOAD AppAttach
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 October 19, 2016. This Internet-Draft will expire on October 21, 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 3, line 4 skipping to change at page 3, line 4
4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 11 4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 11
5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11
5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 11 5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 11
5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 12 5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 12
6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 13 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14 8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14
8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14
8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 14 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 14
8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 14 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15
8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15 8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15
8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 15 8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 15
9.2. XML Name Space Registration . . . . . . . . . . . . . . . 16 9.2. XML Name Space Registration . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Third Party Registration . . . . . . . . . . . . . . 18 Appendix A. Third Party Registration . . . . . . . . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 18 B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 19
B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 19 B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 19
B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 19 B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 19
B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 19 B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer- REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer-
to-peer (P2P) signaling protocol for the general use on the Internet. to-peer (P2P) signaling protocol for the general use on the Internet.
This document defines a SIP Usage of RELOAD that allows SIP [RFC3261] This document defines a SIP Usage of RELOAD that allows SIP [RFC3261]
user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions
without the requirement for permanent proxy or registration servers, without the requirement for permanent proxy or registration servers,
e.g., a fully distributed telephony service. In such a network, the e.g., a fully distributed telephony service. In such a network, the
RELOAD overlay itself performs the registration and rendezvous RELOAD overlay itself performs the registration and rendezvous
skipping to change at page 11, line 12 skipping to change at page 11, line 12
AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can
be contacted directly as described in Section 6. be contacted directly as described in Section 6.
AOR domain is hosted in overlay? If the domain part of the AOR AOR domain is hosted in overlay? If the domain part of the AOR
matches a domain pattern configured in the overlay, the user can matches a domain pattern configured in the overlay, the user can
continue to resolve the AOR in this overlay. The user MAY choose continue to resolve the AOR in this overlay. The user MAY choose
to query the DNS service records to search for additional support to query the DNS service records to search for additional support
of this domain name. of this domain name.
AOR domain not supported by overlay? If the domain part of the AOR AOR domain not supported by overlay? If the domain part of the AOR
is not supported in the current overlay, the user SHOULD query the is not supported in the current overlay, the user might query the
DNS (or other discovery services at hand) to search for an DNS (or other discovery services at hand) to search for an
alternative overlay that services the AOR under request. alternative overlay that services the AOR under request.
Alternatively, standard SIP procedures for contacting the callee Alternatively, standard SIP procedures for contacting the callee
SHOULD be used. might be used.
AOR inaccessible? If all of the above contact attempts fail, the AOR inaccessible? If all of the above contact attempts fail, the
call fails. call fails.
The procedures described above likewise apply when nodes are The procedures described above likewise apply when nodes are
simultaneously connected to several overlays. simultaneously connected to several overlays.
4.2. Resolving an AOR 4.2. Resolving an AOR
A RELOAD user that has discovered a route to an AOR in the current A RELOAD user that has discovered a route to an AOR in the current
skipping to change at page 12, line 15 skipping to change at page 12, line 15
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 schemes, or SIP and SIPS ports and accept calls from either SIP scheme, or select
select a single one. However, a callee that decides to accept SIPS a single one. However, a callee that decides to accept SIPS calls,
calls, only, SHOULD indicate its choice by setting the corresponding 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 protection of all links that may include client links
endpoint certificates. (if present) and 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
header field like in ordinary SIP. header field like in ordinary SIP.
5.2. Keeping a Connection Alive 5.2. Keeping a Connection Alive
In many cases, RELOAD connections will traverse NATs and Firewalls In many cases, RELOAD connections will traverse NATs and Firewalls
skipping to change at page 13, line 41 skipping to change at page 13, line 41
Data Model The data model for the SIP-REGISTRATION Kind-ID is Data Model The data model for the SIP-REGISTRATION Kind-ID is
dictionary. The dictionary key is the Node-ID of the storing dictionary. The dictionary key is the Node-ID of the storing
peer. This allows each peer (presumably corresponding to a single peer. This allows each peer (presumably corresponding to a single
device) to store a single route mapping. device) to store a single route mapping.
Access Control USER-NODE-MATCH. Note that this matches the SIP AOR Access Control USER-NODE-MATCH. Note that this matches the SIP AOR
against the rfc822Name in the X509v3 certificate. The rfc822Name against the rfc822Name in the X509v3 certificate. The rfc822Name
does not include the scheme so that the "sip:" prefix needs to be does not include the scheme so that the "sip:" prefix needs to be
removed from the SIP AOR before matching. Escaped characters ('%' removed from the SIP AOR before matching. Escaped characters ('%'
encoding) in the SIP AOR also need to be decoded prior to encoding) in the SIP AOR also need to be decoded prior to matching
matching. (see [RFC3986]).
Data stored under the SIP-REGISTRATION Kind is of type Data stored under the SIP-REGISTRATION Kind is of type
SipRegistration. This comes in two varieties: SipRegistration. This comes in two varieties:
sip_registration_uri sip_registration_uri
a URI which the user can be reached at. a URI which the user can be reached at.
sip_registration_route sip_registration_route
skipping to change at page 14, line 37 skipping to change at page 14, line 37
However, domain name control relies on a lightweight pattern matching However, domain name control relies on a lightweight pattern matching
and can be processed prior to validating certificates. Hence no and can be processed prior to validating certificates. Hence no
extra burden is introduced for RELOAD peers beyond loads already extra burden is introduced for RELOAD peers beyond loads already
present in the base protocol. present in the base protocol.
8.2. SIP-Specific Issues 8.2. SIP-Specific Issues
8.2.1. Fork Explosion 8.2.1. Fork Explosion
Because SIP includes a forking capability (the ability to retarget to Because SIP includes a forking capability (the ability to retarget to
multiple recipients), fork bombs are a potential DoS concern. multiple recipients), fork bombs (i.e., attacks using SIP forking to
However, in the SIP usage of RELOAD, fork bombs are a much lower amplify the effect on the intended victims) are a potential DoS
concern than in a conventional SIP Proxy infrastructure, because the concern. However, in the SIP usage of RELOAD, fork bombs are a much
calling party is involved in each retargeting event. It can lower concern than in a conventional SIP Proxy infrastructure,
therefore directly measure the number of forks and throttle at some because the calling party is involved in each retargeting event. It
reasonable number. can therefore directly measure the number of forks and throttle at
some reasonable number.
8.2.2. Malicious Retargeting 8.2.2. Malicious Retargeting
Another potential DoS attack is for the owner of an attractive AOR to Another potential DoS attack is for the owner of an attractive AOR to
retarget all calls to some victim. This attack is common to SIP and retarget all calls to some victim. This attack is common to SIP and
difficult to ameliorate without requiring the target of a SIP difficult to ameliorate without requiring the target of a SIP
registration to authorize all stores. The overhead of that registration to authorize all stores. The overhead of that
requirement would be excessive and in addition there are good use requirement would be excessive and in addition there are good use
cases for retargeting to a peer without its explicit cooperation. cases for retargeting to a peer without its explicit cooperation.
skipping to change at page 17, line 19 skipping to change at page 17, line 19
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>. <http://www.rfc-editor.org/info/rfc3840>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <http://www.rfc-editor.org/info/rfc5245>.
 End of changes. 14 change blocks. 
22 lines changed or deleted 28 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/