One document matched: draft-ietf-p2psip-sip-11.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-ietf-p2psip-sip.xml 4853 2012-01-18 02:48:41Z fluffy $ -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no"?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<!-- Don't change this. It breaks stuff -->
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-ietf-p2psip-sip-11"
ipr="pre5378Trust200902">
<front>
<title abbrev="RELOAD SIP Usage">A SIP Usage for RELOAD</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>MS: SJC-21/2</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Bruce B. Lowekamp" initials="B. B." surname="Lowekamp">
<organization>Skype</organization>
<address>
<postal>
<street></street>
<city>Palo Alto</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>bbl@lowekamp.net</email>
</address>
</author>
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
<organization>RTFM, Inc.</organization>
<address>
<postal>
<street>2064 Edgewood Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>
<phone>+1 650 678 2350</phone>
<email>ekr@rtfm.com</email>
</address>
</author>
<author fullname="Salman A. Baset" initials="S.A." surname="Baset">
<organization>Columbia University</organization>
<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<country>USA</country>
</postal>
<email>salman@cs.columbia.edu</email>
</address>
</author>
<author fullname="Henning Schulzrinne" initials="H.G."
surname="Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<country>USA</country>
</postal>
<email>hgs@cs.columbia.edu</email>
</address>
</author>
<author fullname="Thomas C. Schmidt" initials="T C." role="editor"
surname="Schmidt">
<organization>HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>20099</code>
<country>Germany</country>
</postal>
<email>schmidt@informatik.haw-hamburg.de</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>P2PSIP</workgroup>
<abstract>
<t>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 is used to
establish a direct connection between nodes through which SIP messages
are exchanged.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The REsource LOcation And Discovery (RELOAD) <xref
target="I-D.ietf-p2psip-base"></xref> 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 <xref
target="RFC3261"></xref> 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. In
such a network, the RELOAD overlay itself performs the registration and
rendezvous functions ordinarily associated with such servers.</t>
<t>The SIP Usage involves two basic functions.</t>
<t><list style="hanging">
<t hangText="Registration:">SIP UAs can use the RELOAD data storage
functionality to store a mapping from their address-of-record (AOR)
to their Node-ID in the overlay, and to retrieve the Node-ID of
other UAs.</t>
<t hangText="Rendezvous:">Once a SIP UA has identified the Node-ID
for an AOR it wishes to call, it can use the RELOAD message routing
system to set up a direct connection for exchanging SIP
messages.</t>
</list></t>
<t>Mappings are stored in the SipRegistration Resource Record defined in
this document. All operations required to perform a SIP registration or
rendezvous are standard RELOAD protocol methods.</t>
<t>For example, Bob registers his AOR, "bob@dht.example.com", for his
Node-ID "1234". When Alice wants to call Bob, she queries the overlay
for "bob@dht.example.com" and receives Node-ID 1234 in return. She then
uses the overlay routing to establish a direct connection with Bob and
can directly transmit a standard SIP INVITE. In detail, this works along
the following steps.</t>
<t><list style="numbers">
<t>Bob, operating Node-ID 1234, stores a mapping from his AOR to his
Node-ID in the overlay by applying a Store request for
"bob@dht.example.com -> 1234".</t>
<t>Alice, operating Node-ID 5678, decides to call Bob. She retrieves
Node-ID "1234" by performing a Fetch request on
"bob@dht.example.com".</t>
<t>Alice uses the overlay to route an AppAttach message to Bob's
peer (ID 1234). Bob responds with his own AppAttach and they set up
a direct connection, as shown in <xref
target="fig-connection"></xref>. Note that mutual ICE checks are
invoked automatically from AppAttach message exchange.</t>
</list></t>
<figure align="center" anchor="fig-connection"
title="Connection setup in P2P SIP using the RELOAD overlay">
<artwork><![CDATA[
Overlay
Alice Peer1 ... PeerN Bob
(5678) (1234)
-------------------------------------------------
AppAttach ->
AppAttach ->
AppAttach ->
AppAttach ->
<- AppAttach
<- AppAttach
<- AppAttach
<- AppAttach
<------------------ ICE Checks ----------------->
INVITE ----------------------------------------->
<--------------------------------------------- OK
ACK -------------------------------------------->
<------------ ICE Checks for media ------------->
<-------------------- RTP ---------------------->
]]></artwork>
</figure>
<t></t>
<t>It is important to note that here the only role of RELOAD is to set
up the direct SIP connection between Alice and Bob. As soon as the ICE
checks complete and the connection is established, ordinary SIP or SIPS
is used. In particular, the establishment of the media channel for a
phone call happens via the usual SIP mechanisms, and RELOAD is not
involved. Media never traverses the overlay. After the successful
exchange of SIP messages, call peers run ICE connectivity checks for
media.</t>
<t>In addition to mappings from AORs to Node-IDs, the SIP Usage also
allows mappings from AORs to other AORs. This enables an indirection
useful for call forwarding. For instance, if Bob wants his phone calls
temporarily forwarded to Charlie, he can store the mapping
"bob@dht.example.com -> charlie@dht.example.com". When Alice wants to
call Bob, she retrieves this mapping and can then fetch Charlie's AOR to
retrieve his Node-ID. These mechanisms are described in <xref
target="sec-registration"></xref>.</t>
<t>Alternatively, Globally Routable User Agent URIs (GRUUs) can be used
for directly accessing peers. They are handled via a separate mechanism,
as described in <xref target="sec-gruus"></xref>.</t>
<t>The SIP Usage for RELOAD addresses a fully distributed deployment of
session-based services among overlay peers. Two opposite scenarios of
deploying P2P SIP services are in the focus of this document: A highly
regulated environment of a "single provider" that admits parties using
AORs with domains from controlled namespace(s), only, and an open,
multi-party infrastructure that liberally allows a registration and
rendezvous for various or any domain namespace. It is noteworthy in this
context that - in contrast to regular SIP - domain names play no role in
routing to a proxy server. Once connectivity to an overlay is given, any
name registration can be technically processed.</t>
<t></t>
<!-- -->
<!-- -->
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>We use the terminology and definitions from <xref
target="I-D.ietf-p2psip-concepts">Concepts and Terminology for Peer to
Peer SIP</xref> and the <xref target="I-D.ietf-p2psip-base">RELOAD Base
Protocol</xref> extensively in this document.</t>
<t>In addition, term definitions from SIP <xref target="RFC3261"></xref>
apply to this memo. The term AOR is the SIP "Address of Record" used to
identify a user in SIP. For example, alice@example.com could be the AOR
for Alice. For the purposes of this specification, an AOR is considered
not to include the scheme (e.g sip:) as the AOR needs to match the
rfc822Name in the X509v3 certificates. It is worth noting that SIP and
SIPS are distinguished in P2PSIP by the Application-ID.</t>
</section>
<!-- -->
<section anchor="sec-registration" title="Registering AORs in the Overlay">
<section title="Overview">
<t>In ordinary SIP, a UA registers its AOR and location with a
registrar. In RELOAD, this registrar function is provided by the
overlay as a whole. To register its location, a RELOAD peer stores a
SipRegistration Resource Record under its own AOR using the
SIP-REGISTRATION Kind, which is formally defined in <xref
target="sec.sip-reg-kind"></xref>. A RELOAD overlay MAY restrict the
storage of AORs. Namespaces (i.e., the right hand side of the AOR)
that are supported for registration and lookup can be configured for
each RELOAD deployment as described in <xref
target="sec-ocde"></xref>.</t>
<t>As a simple example, consider Alice with AOR
"alice@dht.example.org" at Node-ID "1234". She might store the mapping
"alice@dht.example.org -> 1234" telling anyone who wants to call
her to contact node "1234".</t>
<t>RELOAD peers MAY store two kinds of SIP mappings,</t>
<t><list style="symbols">
<t>from an AOR to a destination list (a single Node-ID is just a
trivial destination list), or</t>
<t>from an AOR to another AOR.</t>
</list></t>
<t>The meaning of the first kind of mapping is "in order to contact
me, form a connection with this peer." The meaning of the second kind
of mapping is "in order to contact me, dereference this AOR". The
latter allows for forwarding. For instance, if Alice wants her calls
to be forwarded to her secretary, Sam, she might insert the following
mapping "alice@dht.example.org -> sam@dht.example.org".</t>
<t></t>
</section>
<section anchor="sec-datastructure" title="Data Structure">
<t>This section defines the SipRegistration Resource Record as
follows:</t>
<figure>
<!--begin-pdu-->
<artwork><![CDATA[
enum { sip_registration_uri(1), sip_registration_route(2),
(255) } SipRegistrationType;
select (SipRegistration.type) {
case sip_registration_uri:
opaque uri<0..2^16-1>;
case sip_registration_route:
opaque contact_prefs<0..2^16-1>;
Destination destination_list<0..2^16-1>;
/* This type can be extended */
} SipRegistrationData;
struct {
SipRegistrationType type;
uint16 length;
SipRegistrationData data;
} SipRegistration;
]]></artwork>
</figure>
<t>The contents of the SipRegistration Resource Record are:</t>
<t><list style="hanging">
<t></t>
<t hangText="type "></t>
<t>the type of the registration</t>
<t></t>
<t hangText="length "></t>
<t>the length of the rest of the PDU</t>
<t></t>
<t hangText="data "></t>
<t>the registration data</t>
</list></t>
<t><list style="symbols">
<t>If the registration is of type "sip_registration_uri", then the
contents are an opaque string containing the URI.</t>
<t>If the registration is of type "sip_registration_route", then
the contents are an opaque string containing the callee's contact
preferences and a destination list for the peer.</t>
</list></t>
<t>The encoding of contact_prefs - the callee's contact preferences -
follows the media feature set syntax of <xref target="RFC2533"></xref>
(see also <xref target="RFC2738"></xref>). As an example, a voicemail
server that is a UA that supports audio and video media types and is
not mobile would carry the following feature set description in its
contact_prefs attribute:</t>
<t></t>
<figure>
<artwork><![CDATA[(& (sip.audio=TRUE)
(sip.video=TRUE)
(sip.actor=msg-taker)
(sip.automata=TRUE)
(sip.mobility=fixed)
(| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
(sip.methods=ACK) (sip.methods=CANCEL)))]]></artwork>
</figure>
<t></t>
<t>A callee MAY indicate that it prefers contact via a particular SIP
scheme - SIP or SIPS - by using one of the following contact_prefs
attribute:</t>
<t></t>
<figure>
<artwork><![CDATA[ (sip.schemes=SIP)
(sip.schemes=SIPS)]]></artwork>
</figure>
<t></t>
<t>RELOAD explicitly supports multiple registrations for a single AOR.
The registrations are stored in a Dictionary with Node-IDs as the
dictionary keys. Consider, for instance, the case where Alice has two
peers:</t>
<t><list style="symbols">
<t>her desk phone (1234)</t>
<t>her cell phone (5678)</t>
</list></t>
<t>Alice might store the following in the overlay at resource
"alice@dht.example.com".</t>
<t><list style="symbols">
<t>A SipRegistration of type "sip_registration_route" with
dictionary key "1234" and value "1234".</t>
<t>A SipRegistration of type "sip_registration_route" with
dictionary key "5678" and value "5678".</t>
</list></t>
<t>Note that this structure explicitly allows one Node-ID to forward
to another Node-ID. For instance, Alice could set calls to her desk
phone to ring at her cell phone by storing a SipRegistration of type
"sip_registration_route" with dictionary key "1234" and value
"5678".</t>
</section>
<section anchor="sec-accesscontrol" title="Access Control">
<t>In order to prevent hijacking or other misuse, registrations are
subject to access control rules. Two kinds of restrictions apply:</t>
<t><list style="symbols">
<t>A Store is permitted only for AORs with domain names that fall
into the namespaces supported by the RELOAD overlay instance.</t>
<t>Storing requests are performed according to the USER-NODE-MATCH
access control policy of RELOAD.</t>
</list></t>
<t>Before issuing a Store request to the overlay, any peer SHOULD
verify that the AOR of the request is a valid Resource Name with
respect to its domain name and the namespaces defined in the overlay
configuration document (see <xref target="sec-ocde"></xref>).</t>
<t>Before a Store is permitted, the storing peer MUST check that:</t>
<t><list style="symbols">
<t>The AOR of the request is a valid Resource Name with respect to
the namespaces defined in the overlay configuration document.</t>
<t>The certificate contains a username that is a SIP AOR which
hashes to the Resource-ID it is being stored at.</t>
<t>The certificate contains a Node-ID that is the same as the
dictionary key it is being stored at.</t>
</list></t>
<t>Note that these rules permit Alice to forward calls to Bob without
his permission. However, they do not permit Alice to forward Bob's
calls to her. See <xref
target="sec-security-malicious-retargeting"></xref> for additional
descriptions.</t>
</section>
<section anchor="sec-ocde"
title="Overlay Configuration Document Extension">
<t>The use of a SIP-enabled overlay MAY be restricted to users with
AORs from specific domains. When deploying an overlay service,
providers can decide about these use case scenarios by defining a set
of namespaces for admissible domain names. This section extends the
overlay configuration document by defining new elements for patterns
that describe a corresponding domain name syntax.</t>
<t>A RELOAD overlay can be configured to accept store requests for any
AOR, or to apply domain name restrictions. For the latter, an
enumeration of admissible domain names including wildcarded name
patterns of the following form MAY be configured.</t>
<figure align="center" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
Example of Domain Patterns:
dht\.example\.com
.*\.my\.name
]]></artwork>
</figure>
<t></t>
<t>In this example, any AOR will be accepted that is either of the
form <user>@dht.example.com, or ends with the domain "my.name".
When restrictions apply and in the absence of domain patterns, the
default behavior is to accept only AORs that exactly match the domain
name of the overlay. Otherwise, i.e., when restrictions are not
configured (attribute enable not set), the default behavior is to
accept any AOR. In the absence of a <domain-restrictions>
element, implementors SHOULD assume this default value. Encoding of
the domain name complies to the restricted ASCII character set without
character escaping as defined in Section 19.1 of <xref
target="RFC3261"></xref>.</t>
<t>The <domain-restrictions> element serves as a container for
zero to multiple <pattern> sub-elements. A <pattern>
element MAY be present if the "enable" attribute of its parent element
is set to true. Each <pattern> element defines a pattern for
constructing admissible resource names. It is of type xsd:string and
interpreted as a regular expression according to "POSIX Extended
Regular Expression" (see the specifications in <xref
target="IEEE-Posix"></xref>).</t>
<t>The Relax NG Grammar for the AOR Domain Restriction reads:</t>
<figure align="left" anchor="fig-le" suppress-title="true">
<artwork align="left" xml:space="preserve"><![CDATA[
<!-- AOR DOMAIN RESTRICTION URN SUB-NAMESPACE -->
namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip"
<!-- AOR DOMAIN RESTRICTION ELEMENT -->
Kind-parameter &= element sip:domain-restriction {
attribute enable { xsd:boolean }
<!-- PATTERN ELEMENT -->
element pattern { xsd:string }*
}?
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec-lookup" title="Looking up an AOR">
<section anchor="sec-routing" title="Finding a Route to an AOR">
<t>A RELOAD user, member of an overlay, who wishes to call another
user with given AOR SHALL proceed in the following way.</t>
<t><list style="hanging">
<t hangText="AOR is GRUU?">If the AOR is a GRUU for this overlay,
the callee can be contacted directly as described in <xref
target="sec-gruus"></xref>.</t>
<t hangText="AOR domain is hosted in overlay?">If the domain part
of the AOR matches a domain pattern configured in the overlay, the
user can continue to resolve the AOR in this overlay. The user MAY
choose to query the DNS service records to search for additional
support of this domain name.</t>
<t hangText="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 DNS (or other discovery services at hand) to
search for an alternative overlay that services the AOR under
request. Alternatively, standard SIP procedures for contacting the
callee SHOULD be used.</t>
<t hangText="AOR inaccessible?">If all of the above contact
attempts fail, the call fails.</t>
</list></t>
<t>The procedures described above likewise apply when nodes are
simultaneously connected to several overlays.</t>
</section>
<section anchor="sec-resolving" title="Resolving an AOR">
<t>A RELOAD user that has discovered a route to an AOR in the current
overlay SHALL execute the following steps.</t>
<t><list style="numbers">
<t>Perform a Fetch for Kind SIP-REGISTRATION at the Resource-ID
corresponding to the AOR. This Fetch SHOULD NOT indicate any
dictionary keys, so that it will fetch all the stored values.</t>
<t>If any of the results of the Fetch are non-GRUU AORs, then
repeat step 1 for that AOR.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section anchor="sec-connecting" title="Forming a Direct Connection">
<section anchor="sec-setup" title="Setting Up a Connection">
<t>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 for a
new call.</t>
<t>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 <xref target="sec-datastructure"></xref>). 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.</t>
</section>
<section anchor="sec-keepalive" title="Keeping a Connection Alive">
<t>In many cases, RELOAD connections will traverse NATs and Firewalls
that maintain states established from ICE <xref
target="RFC5245"></xref> negotiations. It is the responsiblity of the
Peers to provide sufficiently frequent traffic to keep NAT and
Firewall states present and the connection alive. Keepalives are a
mandatory component of ICE (see Section 10 of <xref
target="RFC5245"></xref>) and no further operations are required.
Applications that want to assure maintanance of sessions individually
need to follow regular SIP means. Accordingly, a SIP Peer MAY apply
keep-alive techniques in agreement with its transport binding as
defined in Section 3.5 of <xref target="RFC5626"></xref>.</t>
</section>
</section>
<section anchor="sec-gruus" title="Using GRUUs">
<t>Globally Routable User Agent Uris (GRUUs) <xref
target="RFC5627"></xref> 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 <xref target="RFC4648"></xref> with the
exception that ~ is used in place of =.</t>
<figure>
<artwork><![CDATA[Example of a RELOAD GRUU:
alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~
]]></artwork>
</figure>
<t></t>
<t>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 overlay,
it simply uses the destination list and connects to that peer. Because a
GRUU contains a destination list, it MAY have the same contents as a
destination list stored elsewhere in the resource dictionary.</t>
<t>Anonymous GRUUs <xref target="RFC5767"></xref> are constructed
analogously, but require either that the enrollment server issues a
different Node-ID for each anonymous GRUU required, or that a
destination list be used that includes a peer that compresses the
destination list to stop the Node-ID from being revealed.</t>
</section>
<section anchor="sec.sip-reg-kind"
title="SIP-REGISTRATION Kind Definition">
<t>This section defines the SIP-REGISTRATION Kind.</t>
<t><list style="hanging">
<t></t>
<t hangText="Name">SIP-REGISTRATION</t>
<t></t>
<t hangText="Kind IDs">The Resource Name for the SIP-REGISTRATION
Kind-ID is the AOR of the user. The data stored is a
SipRegistration, which can contain either another URI or a
destination list to the peer which is acting for the user.</t>
<t></t>
<t hangText="Data Model">The data model for the SIP-REGISTRATION
Kind-ID is dictionary. The dictionary key is the Node-ID of the
storing peer. This allows each peer (presumably corresponding to a
single device) to store a single route mapping.</t>
<t></t>
<t hangText="Access Control">USER-NODE-MATCH. Note that this matches
the SIP AOR against the rfc822Name in the X509v3 certificate. The
rfc822Name does not include the scheme so that the "sip:" prefix
needs to be removed from the SIP AOR before matching.</t>
</list></t>
<t>Data stored under the SIP-REGISTRATION Kind is of type
SipRegistration. This comes in two varieties: <list style="hanging">
<t></t>
<t hangText="sip_registration_uri "></t>
<t>a URI which the user can be reached at.</t>
<t></t>
<t hangText="sip_registration_route "></t>
<t>a destination list which can be used to reach the user's
peer.</t>
</list></t>
<!-- -->
</section>
<section title="Security Considerations">
<section title="RELOAD-Specific Issues">
<t>This Usage for RELOAD does not define new protocol elements or
operations. Hence no new threats arrive from message exchanges in
RELOAD.</t>
<t>This document introduces an AOR domain restriction function that
must be surveyed by the storing peer. A misconfigured or malicious
peer could cause frequent rejects of illegitimate storing requests.
However, domain name control relies on a lightweight pattern matching
and can be processed prior to validating certificates. Hence no extra
burden is introduced for RELOAD peers beyond loads already present in
the base protocol.</t>
</section>
<section anchor="section.sip-issues" title="SIP-Specific Issues">
<section title="Fork Explosion">
<t>Because SIP includes a forking capability (the ability to
retarget to multiple recipients), fork bombs are a potential DoS
concern. However, in the SIP usage of RELOAD, fork bombs are a much
lower concern than in a conventional SIP Proxy infrastructure,
because the calling party is involved in each retargeting event. It
can therefore directly measure the number of forks and throttle at
some reasonable number.</t>
</section>
<section anchor="sec-security-malicious-retargeting"
title="Malicious Retargeting">
<t>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 difficult to ameliorate without requiring the target of a
SIP registration to authorize all stores. The overhead of that
requirement would be excessive and in addition there are good use
cases for retargeting to a peer without its explicit
cooperation.</t>
</section>
<section title="Misuse of AORs">
<t>A RELOAD overlay and enrollment service that liberally accept
registrations for AORs of domain names unrelated to the overlay
instance and without further justification, eventually store
presence state for misused AORs. An attacker could hijack names,
register a bogus presence and attract calls dedicated to a victim
that resides within or outside the Overlay Instance.</t>
<t>A hijacking of AORs can be mitigated by restricting the name
spaces admissible in the Overlay Instance, or by additional
verification actions of the enrollment service. To prevent an
(exclusive) routing to a bogus registration, a caller can in
addition query the DNS (or other discovery services at hand) to
search for an alternative presence of the callee in another overlay
or a normal SIP infrastructure.</t>
</section>
<section title="Privacy Issues">
<t>All RELOAD SIP registration data is public. Methods of providing
location and identity privacy are still being studied. Location
privacy can be gained from using anonymous GRUUs.</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<section title="Data Kind-ID">
<t>IANA shall register the following code point in the "RELOAD Data
Kind-ID" Registry (cf., <xref target="I-D.ietf-p2psip-base"></xref>)
to represent the SIP-REGISTRATION Kind, as described in <xref
target="sec.sip-reg-kind"></xref>. [NOTE TO IANA/RFC-EDITOR: Please
replace RFC-AAAA with the RFC number for this specification in the
following list.]</t>
<figure>
<artwork align="center"><![CDATA[
+---------------------+------------+----------+
| Kind | Kind-ID | RFC |
+---------------------+------------+----------+
| SIP-REGISTRATION | 1 | RFC-AAAA |
+---------------------+------------+----------+
]]></artwork>
</figure>
</section>
<section title="XML Name Space Registration">
<t>This document registers the following URI for the config XML
namespace in the IETF XML registry defined in <xref
target="RFC3688"></xref></t>
<t><list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:p2p:config-base:sip</t>
<t hangText="Registrant Contact:">The IESG</t>
<t hangText="XML:">N/A, the requested URI is an XML namespace</t>
</list></t>
</section>
</section>
<section title="Acknowledgments">
<t>This document was generated in parts from initial drafts and
discussions in the early specification phase of the P2PSIP base
protocol. Significant contributions (in alphabetical order) were from
David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan Rosenberg,
and Marcia Zangrilli, which is gratefully acknowledged.</t>
<t>Additional thanks go to all those who helped with ideas, discussions,
and reviews, in particular (in alphabetical order) Michael Chen, Marc
Petit-Huguenin, Brian Rosen, and Matthias Waehlisch.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.ietf-p2psip-base"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.2533"?>
<?rfc include="reference.RFC.2738"?>
<?rfc include="reference.RFC.3688"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5626"?>
<?rfc include="reference.RFC.5627"?>
<?rfc include="reference.RFC.4648"?>
<reference anchor="IEEE-Posix">
<front>
<title>IEEE Standard for Information Technology - Portable Operating
System Interface (POSIX) - Part 2: Shell and Utilities (Vol.
1)</title>
<author fullname="The Institute of Electrical and Electronics Engineers"></author>
<date month="January" year="1993" />
</front>
<seriesInfo name="IEEE Std" value="1003.2-1992, ISBN 1-55937-255-9" />
</reference>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-p2psip-concepts"?>
<?rfc include="reference.RFC.5767"?>
<?rfc include="reference.I-D.ietf-p2psip-share"?>
</references>
<section title="Third Party Registration">
<t>In traditional SIP, the mechanism of a third party registration
(i.e., an assistant acting for a boss, changing users register a
role-based AOR, ...) is defined in Section 10.2 of <xref
target="RFC3261"></xref>. This is a REGISTER which uses the URI of the
third-party in its From header and cannot be translated directly into a
P2PSIP registration, because only the owner of the certificate can store
a SIP-REGISTRATION in a RELOAD overlay.</t>
<t>A way to implement third party registration is by using the extended
access control mechanism USER-CHAIN-ACL defined in <xref
target="I-D.ietf-p2psip-share"></xref>. 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.</t>
</section>
<section anchor="sec-changes" title="Change Log">
<section title="Changes since draft-ietf-p2psip-sip-09">
<t><list style="symbols">
<t>Added subsection on keepalive</t>
<t>Updated references</t>
</list></t>
</section>
<section title="Changes since draft-ietf-p2psip-sip-08">
<t><list style="symbols">
<t>Added the handling of SIPS</t>
<t>Specified use of Posix regular expressions in configuration
document</t>
<t>Added IANA registration for namespace</t>
<t>Editorial polishing</t>
<t>Updated and extended references</t>
</list></t>
</section>
<section title="Changes since draft-ietf-p2psip-sip-07">
<t><list style="symbols">
<t>Cleared open issues</t>
<t>Clarified use cases after WG discussion</t>
<t>Added configuration document extensions for configurable domain
names</t>
<t>Specified format of contact_prefs</t>
<t>Clarified routing to AORs</t>
<t>Extended security section</t>
<t>Added Appendix on Third Party Registration</t>
<t>Added IANA code points</t>
<t>Editorial polishing</t>
<t>Updated and extended references</t>
</list></t>
</section>
<section title="Changes since draft-ietf-p2psip-sip-06">
<t><list style="symbols">
<t>Added Open Issue</t>
</list></t>
</section>
</section>
<!-- -->
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:36 |