RFC 7904

A SIP Usage for REsource LOcation And Discovery (RELOAD)

📅 published October 2016, from ietf

Title Block 💖 Everything you need to know up front, bestie

This doc is RFC 7904 🎀, titled "A SIP Usage for REsource LOcation And Discovery (RELOAD)", and it's from the IETF 🌸. It's on the Standards Track 👑 and it's dated October 2016 🦋. Its ISSN is 2070-1721 ✨. Nothing in the header says it obsoletes or updates another RFC, so there's no "replaces" drama here 💅.

The authors are a whole squad 🫶: C. Jennings (Cisco), B. Lowekamp (Skype), E. Rescorla (RTFM, Inc.), S. Baset (IBM), H. Schulzrinne (Columbia University), and T. Schmidt, Ed. (HAW Hamburg) 🌈. "Ed." means T. Schmidt is the editor 💜.

Abstract ✨

okay so the whole point of this one is to bring SIP 📞 (the calling protocol) into a fully distributed overlay 🕸️ so there's no permanent proxy or registrar server. The SIP Usage gives you the job a SIP proxy or registrar would normally do, plus a lookup service for Address of Records (AORs) stored in the overlay 🔍. It also defines Globally Routable User Agent URIs (GRUUs) 🎯, which let a registration map an AOR to one specific node in the overlay. After the first contact with a Peer, the RELOAD AppAttach method 🦋 sets up a direct connection so SIP messages can flow between nodes. Honestly iconic 😭.

Status of This Memo 📜

This is an Internet Standards Track document 👑. It's a product of the IETF, it reflects the consensus of the IETF community 🫶, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥. For more on Internet Standards, check Section 2 of RFC 7841 💜.

Current status, errata, and feedback info live at http://www.rfc-editor.org/info/rfc7904 🌸.

Copyright (c) 2016 IETF Trust and 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) as they stand on the publication date 🦋. Read them carefully, because they spell out your rights and restrictions 📜. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in that license 🌈.

This document may include material from IETF Documents or IETF Contributions published before November 10, 2008 🙈. The people who control the copyright in some of that older material may not have let the IETF Trust allow modifications outside the IETF Standards Process 💀. Without a proper license from them, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🧚.

Table of Contents 🍓

Here's the map of the whole doc, so you can see what's coming 🗺️💖. Page numbers are from the original, which is pretty iconic of it 😭.

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
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  . . . . . . . .  10
4.  Looking Up an AOR . . . . . . . . . . . . . . . . . . . . . .  11
  4.1.  Finding a Route to an AOR . . . . . . . . . . . . . . . .  11
  4.2.  Resolving an AOR  . . . . . . . . . . . . . . . . . . . .  12
5.  Forming a Direct Connection . . . . . . . . . . . . . . . . .  12
  5.1.  Setting Up a Connection . . . . . . . . . . . . . . . . .  12
  5.2.  Keeping a Connection Alive  . . . . . . . . . . . . . . .  13
6.  Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . .  13
7.  SIP-REGISTRATION Kind Definition  . . . . . . . . . . . . . .  14
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
  8.1.  RELOAD-Specific Issues  . . . . . . . . . . . . . . . . .  14
  8.2.  SIP-Specific Issues . . . . . . . . . . . . . . . . . . .  15
    8.2.1.  Fork Explosion  . . . . . . . . . . . . . . . . . . .  15
    8.2.2.  Malicious Retargeting . . . . . . . . . . . . . . . .  15
    8.2.3.  Misuse of AORs  . . . . . . . . . . . . . . . . . . .  15
    8.2.4.  Privacy Issues  . . . . . . . . . . . . . . . . . . .  16
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
  9.1.  Data Kind-ID  . . . . . . . . . . . . . . . . . . . . . .  16
  9.2.  XML Namespace Registration  . . . . . . . . . . . . . . .  16
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
  10.2.  Informative References . . . . . . . . . . . . . . . . .  18
Appendix A.  Third-Party Registration . . . . . . . . . . . . . .  19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction 🎀

okay bestie, let's get into it 💖. REsource LOcation And Discovery (RELOAD) [RFC6940] is a peer-to-peer (P2P) signaling protocol 🕸️ meant for general use across the Internet 🌍. This document defines a SIP Usage of RELOAD ✨. It lets SIP [RFC3261] user agents (UAs) set up peer-to-peer SIP (or SIPS) sessions with no permanent proxy or registration servers 🙅‍♀️. Think a fully distributed telephony service 📞🦋. The service supports SIP addressing, telephone numbers included 💅. In this kind of network, the RELOAD overlay itself does the registration and rendezvous jobs that servers usually handle 🫶.

The SIP Usage has two basic functions 👑:

  • Registration: SIP UAs can use the RELOAD data storage feature to store a mapping from their Address of Record (AOR) to their Node-ID in the overlay, and to fetch the Node-ID of other UAs 📥.
  • Rendezvous: Once a SIP UA has found the Node-ID for an AOR it wants to call, it can use the RELOAD message routing system to set up a direct connection for swapping SIP messages 🤝.

Mappings get stored in the SipRegistration Resource Record defined in this document 🗂️. Every operation needed for a SIP registration or rendezvous is a standard RELOAD protocol method 💜.

Here's an 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 gets Node-ID "1234" back 💖. Then she uses the overlay routing to set up a direct connection with Bob, and she can send a standard SIP INVITE straight to him 🦋. Here are the steps 🌈:

  1. Bob, running 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" 📝.
  2. Alice, running Node-ID "5678", decides to call Bob 📞. She gets Node-ID "1234" by doing a Fetch request on "bob@dht.example.com" 🔍.
  3. Alice uses the overlay to route an AppAttach message to Bob's Peer (ID "1234") 🦋. Bob replies with his own AppAttach, and they set up a direct connection, as shown in Figure 1 ✨. Mutual Interactive Connectivity Establishment (ICE) checks get kicked off automatically by the AppAttach exchange 🔥.
                        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 ---------------------->

      Figure 1: Connection Setup in P2P SIP Using the RELOAD Overlay

Important tea ☕: RELOAD's only job in this example is to set up the direct SIP connection between Alice and Bob 🫶. As soon as the ICE checks finish and the connection is up, regular SIP or SIPS takes over ✨. The media channel for a phone call gets set up through the usual SIP mechanisms, and RELOAD isn't involved at all 🙈. Media never goes through the overlay 🚫. After the SIP messages are exchanged, the Peers run ICE connectivity checks for media 💜.

The SIP Usage also maps AORs to other AORs, not just to Node-IDs 🔁. That's an indirection that's handy for call forwarding 📲. Say Bob wants his calls forwarded to Charlie for a bit. He stores the mapping "bob@dht.example.com -> charlie@dht.example.com" 🎀. When Alice calls Bob, she fetches that mapping, then fetches Charlie's AOR to get his Node-ID 🧚. These mechanisms are covered in Section 3 🦋.

Alternatively, Globally Routable User Agent URIs (GRUUs) [RFC5627] can be used to reach Peers directly 🎯. They're handled by a separate mechanism, covered in Section 6 💅.

Concepts in this document can be extended to include tel URIs [RFC3966] 📞, but that will need more specs so implementations stay semantically interoperable 🤓.

The SIP Usage for RELOAD is built for a fully distributed deployment of session-based services among overlay Peers 🕸️💖. It could be useful in lots of environments 🌈. One is a tightly controlled setup from a single provider that only lets in parties using AORs from controlled namespaces 🔒. Another is an open, multi-party infrastructure that freely allows registration and rendezvous for any domain namespace 🌍. Here's the tea 🫖: unlike regular SIP, domain names play no role in routing to a proxy server 🙅‍♀️. Once you're connected to an overlay, the tech lets anyone register a name, though overlay domain restrictions may limit that 🦋.

Part 1 of 4. Next up: Section 2 (Terminology) and onward 💜✨

2. Terminology ✨

okay bestie, 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 "Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)" [RFC7890] and the RELOAD Base Protocol [RFC6940] extensively in this document 🧠💅

also, terms defined by SIP [RFC3261] 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 this spec, an AOR is considered NOT to include the scheme (e.g., sip:), because the AOR needs to match the rfc822Name in the X.509 v3 certificates [RFC5280]. it's worth noting that SIP and SIPS are distinguished in P2PSIP by the Application-ID 🔑

3. Registering AORs in the Overlay 🦋

3.1. Overview

okay so in ordinary SIP, a UA registers the user's AOR and its network 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 Section 7. ngl the registration lifetime you know from the regular SIP REGISTER method is inherited from the lifetime attribute of the basic RELOAD StoredData structure (see Section 7 in [RFC6940]) ⏳✨

a RELOAD overlay MAY restrict the storage of AORs. namespaces (aka the right-hand side of the AOR) that are supported for registration and lookup can be configured for each RELOAD deployment, as described in Section 3.4 🌈

as a simple example, consider Alice with an AOR alice@dht.example.org at Node-ID 1234. she might store the mapping alice@dht.example.org -> 1234, which basically tells anyone who wants to call her to contact node 1234 📞💖

RELOAD peers can store two kinds of SIP mappings:

  • from an AOR to a destination list (a single Node-ID is just a trivial destination list), or
  • from one AOR to another.

the meaning of the first kind is "in order to contact me, form a connection with this Peer." the meaning of the second kind is "in order to contact me, dereference this AOR". the latter allows for forwarding 💅 for instance, if Alice wants her calls forwarded to her secretary, Sam, she might insert the following mapping: alice@dht.example.org -> sam@dht.example.org 🧚

3.2. Data Structure

this section defines the SipRegistration Resource Record as follows 🎀

       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<3..2^16-1>;

         /* This type can be extended */

       } SipRegistrationData;
       struct {
          SipRegistrationType   type;
          uint16                length;
          SipRegistrationData   data;
      } SipRegistration;

the contents of the SipRegistration Resource Record are:

  • type: the type of the registration
  • length: the length of the rest of the PDU
  • data: the registration data
  • if the registration is of type "sip_registration_uri", then the contents are an opaque string containing the AOR.
  • if the registration is of type "sip_registration_route", then the contents are an opaque string containing the registrant's contact preferences and a destination list for the Peer.

the callee expresses its capabilities within the contact preferences as specified in [RFC3840] 🧁 it encodes a media feature set made up of its capabilities as a contact predicate, i.e., a string of feature parameters that show up as part of the Contact header field. feature parameters are derived from the media feature set syntax of [RFC2533] (see also [RFC2738]) as described in [RFC3840] 🤓

this encoding covers all SIP User Agent capabilities, as defined in [RFC3840] and registered in the SIP feature tag registration tree 💜 in particular, a callee can indicate that it prefers contact via a particular SIP scheme (SIP or SIPS) by using one of the following contact_prefs attributes:

      (sip.schemes=SIP)
      (sip.schemes=SIPS)

RELOAD explicitly supports multiple registrations for a single AOR 🙌 the registrations are stored in a dictionary with Node-IDs as the dictionary keys. like, consider Alice with two Peers:

  • her desk phone (1234)
  • her cell phone (5678)

Alice might store the following in the overlay at resource alice@dht.example.com:

  • a SipRegistration of type "sip_registration_route" with dictionary key "1234" and value "1234", both referring to Node-IDs
  • a SipRegistration of type "sip_registration_route" with dictionary key "5678" and value "5678"

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 a dictionary key "1234" and a value "5678" 📱✨

3.3. Access Control

okay so in order to prevent hijacking or other misuse, registrations are subject to access control rules 🚨 two kinds of restrictions apply:

  • A Store is permitted only for AORs with domain names that fall into the namespaces supported by the RELOAD Overlay Instance.
  • Storing requests are performed according to the USER-NODE-MATCH access control policy of RELOAD.

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 Section 3.4) 🔍

before a Store is permitted, the Storing Peer MUST check that:

  • The AOR of the request is a valid Resource Name with respect to the namespaces defined in the overlay configuration document.
  • The certificate contains a username that is a SIP AOR that hashes to the Resource-ID it is being stored at.
  • The certificate contains a Node-ID that is the same as the dictionary key it is being stored at.
if any of these checks fail, the request MUST be rejected with an Error_Forbidden error. 🚫

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 Section 8.2.2 for additional details 🫶

3.4. Overlay Configuration Document Extension

the use of a SIP-enabled overlay MAY be restricted to users with AORs from specific domains. when deploying an overlay service, providers can implement such restrictions 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 🗂️

a RELOAD overlay can be configured to accept store requests for any AOR, or to apply domain name restrictions. to apply restrictions, the overlay configuration document needs to contain a <domain-restrictions> element. 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 [IEEE-Posix]). encoding of the domain name adheres to the restricted ASCII character set without character escaping, as defined in Section 19.1 of [RFC3261] 🔤

inclusion of a <domain-restrictions> element in an overlay configuration document is OPTIONAL 💖 if the element is not included, the default behavior is to accept any AOR. if the element is included and the "enable" attribute is not set or is set to false, the overlay MUST only accept AORs that match the domain name of the overlay. if the element is included and the "enable" attribute is set to true, the overlay MUST only accept AORs that match patterns specified in the <domain-restrictions> element 🌷

example of domain patterns:

dht\.example\.com
.*\.my\.example

in this example, any AOR will be accepted that is either of the form <user>@dht.example.com, or ends with the domain "my.example" 🎀

the RELAX NG grammar for the AOR Domain Restriction reads:

# 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 sip:pattern { xsd:string }*
}?

4. Looking Up an AOR 🔎

4.1. Finding a Route to an AOR

a RELOAD user, member of an overlay, who wishes to call another user with a given AOR SHALL proceed in the following way 📲

  • AOR is a GRUU? If the AOR is a GRUU for this overlay, the callee can be contacted directly as described in Section 6. 🎯
  • 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. 🌐
  • AOR domain not supported by overlay? If the domain part of the AOR is not supported in the current overlay, the user might 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 might be used. 🔁
  • AOR inaccessible? If all of the above contact attempts fail, the call fails. 💀

the procedures described above likewise apply when nodes are simultaneously connected to several overlays 🫧

4.2. Resolving an AOR

a RELOAD user that has discovered a route to an AOR in the current overlay SHALL execute the following steps 🧩

  1. 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.
  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 🌈

Okay bestie, let's get into it! 🎀 Part 3 picks up right where the last one left off, so here we go ✨

5.1. Setting Up a Connection ✨

Okay so once the Peer has turned the AOR into a set of destination lists, it uses the overlay to send AppAttach messages to each of those Peers 🦋 The "application" field MUST be either 5060 (for SIP) or 5061 (for 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 destination list 🔥 If that doesn't happen, the connection MUST NOT be used and MUST be closed. Literally no exceptions 💀

Also, the Peers might already have a RELOAD connection set up between them 🌸 That connection 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, so it's giving reuse energy 🧚

Once AppAttach succeeds, the Peer sends plain or (D)TLS-encrypted SIP messages over the connection, just like normal SIP 💜 A caller MAY pick SIP or SIPS to contact the callee, but they SHOULD follow the preference the callee sets in its contact_prefs attribute (see Section 3.2) 🫶 A callee MAY listen on both SIP and SIPS ports and accept calls from either scheme, or pick just one. BUT if a callee only wants to accept SIPS calls, it SHOULD say so by setting the matching attribute in its contact_prefs ✨ And fun fact, according to [RFC6940], all overlay links are built on (D)TLS-secured transport 🔐 iykyk 😭

SIP messages carry the SIP URIs of the actual overlay endpoints (like "sip:alice@dht.example.com") in the Via and Contact headers, while the communication keeps going over the RELOAD connection 🌈 A UA can still redirect its path by setting an alternate Contact header field, just like ordinary SIP. Main character redirect energy 👑

5.2. Keeping a Connection Alive 🌷

Real talk, RELOAD connections set up from ICE [RFC5245] negotiations usually go through stateful NATs and firewalls 🧱 So it's the Peers' job to send messages often enough to keep the state in those NATs and firewalls alive, and keep the connection going 💖 Keepalives are a mandatory part of ICE (see Section 10 of [RFC5245]), so no extra operations are needed 🙌 Apps that want to keep their own sessions alive need to use regular SIP methods. And a SIP Peer MAY apply keep-alive techniques that match its transport binding, as defined in Section 3.5 of [RFC5626] 🦋

6. Using GRUUs 🎀

Globally Routable User Agent URIs (GRUUs) [RFC5627] were designed to let you route directly to one specific UA instance, without needing a domain-specific SIP proxy to look it up first 🧚‍♀️ The same idea gets carried over to RELOAD overlays like this: a GRUU is built by embedding a base64-encoded destination list in the gr URI parameter 💅 The base64 encoding uses the alphabet from Table 1 of [RFC4648], with one twist: ~ is used in place of = 🌸

Example of a RELOAD GRUU: alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~

GRUUs don't need any data stored in the Overlay Instance 🙅‍♀️ Instead, when a Peer needs to route a message to a GRUU in the same P2P overlay, it just uses the destination list and connects to that Peer 🦋 And since a GRUU contains a destination list, it can have the same contents as a destination list stored somewhere else in the resource dictionary ✨

Anonymous GRUUs [RFC5767] are built the same way, but they require either that the enrollment server issues a different Node-ID for each anonymous GRUU needed, or that a destination list is used that includes a Peer which compresses the destination list so the Node-ID doesn't get revealed 🫣 Sneaky, but make sure you're doing it right 🥷

7. SIP-REGISTRATION Kind Definition 💜

This section defines the SIP-REGISTRATION Kind 🎀

Name: SIP-REGISTRATION

Kind IDs: The Resource Name for the SIP-REGISTRATION Kind-ID is the AOR of the user as specified in Section 2. The data stored is a SipRegistration, which can contain either another URI or a destination list to the Peer that is acting for the user 📮

Data Model: The data model for the SIP-REGISTRATION Kind-ID is a dictionary. The dictionary key is the Node-ID of the Storing Peer. This lets each Peer (presumably corresponding to a single device) store a single route mapping 📱

Access Control: USER-NODE-MATCH. Note that this matches the SIP AOR against the rfc822Name in the X.509 v3 certificate. The rfc822Name doesn't include the scheme, so the "sip:" prefix needs to be removed from the SIP AOR before matching. Escaped characters ('%' encoding) in the SIP AOR also need to be decoded before matching (see [RFC3986]) 🔍

Data stored under the SIP-REGISTRATION Kind is of type SipRegistration, containing one of two data types:

sip_registration_uri A URI that the user can be reached at. 📞

sip_registration_route A destination list that can be used to reach the user's Peer. 🗺️

8. Security Considerations 🚨

8.1. RELOAD-Specific Issues

This Usage for RELOAD doesn't define any new protocol elements or operations. So no new threats come from message exchanges in RELOAD 🙌

This document adds an AOR domain restriction function that MUST be compared against the registration attempt by the Storing Peer. A misconfigured or malicious Peer could cause frequent rejects of illegitimate storing requests. However, domain name control relies on lightweight pattern matching and can be processed before validating certificates. So no extra burden is added for RELOAD peers beyond the loads already in the base protocol 💪

8.2. SIP-Specific Issues

8.2.1. Fork Explosion 💥

Because SIP has a forking capability (the ability to retarget to multiple recipients), fork bombs (attacks that use SIP forking to amplify the effect on the intended victims) 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. So they can directly measure the number of forks and throttle at some reasonable number 🛑

8.2.2. Malicious Retargeting 😤

To launch a DoS attack, the owner of a popular AOR could retarget all calls to the victim. This attack is common to SIP and is difficult to reduce without requiring the target of a SIP registration to authorize all stores. That overhead would be excessive, and there are also good use cases for retargeting to a Peer without its explicit cooperation 🙄

8.2.3. Misuse of AORs 🚩

A RELOAD overlay and enrollment service that liberally accepts registrations for AORs of domain names unrelated to the overlay instance, and without further authorization, could store presence state for AORs without the consent of the AOR's owner. An attacker could hijack names, register a bogus presence, and attract calls meant for a victim who lives inside or outside the Overlay Instance 😱

Hijacking AORs can be mitigated by restricting the name spaces allowed in the Overlay Instance, or by additional verification actions from the enrollment service. To prevent (exclusive) routing to a bogus registration, a caller can also query DNS (or other discovery services at hand), or look for an alternative presence of the callee in another overlay or a SIP infrastructure, using [RFC3263] for name resolution 🕵️‍♀️

8.2.4. Privacy Issues 🙈

All RELOAD SIP registration data is visible to all nodes in the overlay. Location privacy can be gained by using anonymous GRUUs. Methods of providing anonymity or deploying pseudonyms exist, but they're beyond the scope of this document 🥹

9. IANA Considerations 📋

9.1. Data Kind-ID

IANA has registered the following code point in the "RELOAD Data Kind-ID" Registry (cf., [RFC6940]) to represent the SIP-REGISTRATION Kind, as described in Section 7.

          +---------------------+------------+-----------+
          | Kind                |    Kind-ID | Reference |
          +---------------------+------------+-----------+
          | SIP-REGISTRATION    |        0x1 | RFC 7904  |
          +---------------------+------------+-----------+

9.2. XML Namespace Registration

This document registers the following URI for the config XML namespace in the IETF XML registry defined in [RFC3688]:

URI: urn:ietf:params:xml:ns:p2p:config-base:sip

Registrant Contact: The IESG

XML: N/A; the requested URI is an XML namespace

10. References 📚

Still more to come in the next part, bestie 🦋💖

10.1. Normative References 📚

These are the big-deal docs this spec leans on, so the bestie has to read them too 💅

10.2. Informative References 🌸

These ones are extra reading, nice to know but not required to build the thing ✨

Appendix A. Third-Party Registration 🎀

Okay so, non-peer-to-peer SIP has this thing called third-party registration, where an assistant registers on behalf of a manager, or a changing group of people registers under a role-based AOR. It's all described in Section 10.2 of [RFC3261] 💁‍♀️. It works by sending a REGISTER that carries the third party's URI in its From header. The catch is that this can't be translated straight into a P2PSIP registration, because only the owner of the certificate is allowed to store a SIP-REGISTRATION in a RELOAD overlay 🔒.

Good news though, it's fixable ✨ Third-party registration can be done using the extended access control mechanism USER-CHAIN-ACL, which is defined in [SHARE] 🦋. If you create a new Kind called SIP-3P-REGISTRATION and make it governed by USER-CHAIN-ACL, the certificate owner can delegate registration rights to individual third parties 👑. That means SIP third-party registration can come back to life without weakening the security controls of RELOAD 🫶.

Acknowledgments 🫶

This document was generated in parts from initial drafts and discussions in the early specification phase of the P2PSIP base protocol. Huge thanks to (in alphabetical order) David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan Rosenberg, and Marcia Zangrilli for their significant contributions 💜.

Extra thanks to everyone who helped with ideas, discussions, and reviews, especially (in alphabetical order) Roland Bless, Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral Shirazipour, and Matthias Waehlisch 🌈.

Authors' Addresses 💌

The people who wrote this, with their contact details exactly as published:

Cullen Jennings
Cisco
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA  95134
United States of America
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Bruce B. Lowekamp
Skype
Palo Alto, CA
United States of America
Email: bbl@lowekamp.net
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA  94303
United States of America
Phone: +1 650 678 2350
Email: ekr@rtfm.com
Salman A. Baset
IBM T. J. Watson Research Center
1101 Kitchawan Road
Yorktown Heights, NY  10598
United States of America
Email: sabaset@us.ibm.com
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue
New York, NY  10027
United States of America
Email: hgs@cs.columbia.edu
Thomas C. Schmidt (editor)
HAW Hamburg
Berliner Tor 7
Hamburg  20099
Germany
Email: t.schmidt@haw-hamburg.de
📦 where this page comes from