A SIP Usage for REsource LOcation And Discovery (RELOAD)
Extracted elements (27)
AOR forwarding (alice -> sam) is permitted without the target's permission because requiring authorization from the target of every SIP registration store would impose excessive overhead and remove legitimate use cases for retargeting.
Domain names play no role in routing to a proxy in P2PSIP; once overlay connectivity is given, the technology allows any name registration, possibly constrained by overlay domain restrictions. This contrasts with regular SIP where domain names determine proxy routing.
Media never traverses the overlay. RELOAD's only role is setting up the direct SIP connection; after ICE checks complete, ordinary SIP/SIPS is used for signaling and media connectivity checks are handled by normal SIP ICE procedures.
RELOAD supports multiple registrations per AOR using a dictionary keyed by Node-ID. This allows a user with multiple devices (e.g., desk phone and cell phone) to each store a separate route mapping, and explicitly permits one Node-ID to forward to another.
Keepalives for NAT/firewall traversal are a mandatory component of ICE (RFC 5245 Section 10), so no additional operations are required. Applications needing session-level keepalives should use SIP keep-alive techniques per RFC 5626 Section 3.5.
SIP and SIPS are distinguished in P2PSIP by the Application-ID. An AOR is considered not to include the scheme (e.g., 'sip:') because it needs to match the rfc822Name in X.509 v3 certificates; the 'sip:' prefix must be removed before matching, and '%' encoding decoded.
SIP messages carry SIP URIs of overlay endpoints in Via and Contact headers while communication continues via the RELOAD connection. A UA can redirect by setting an alternate Contact header field as in ordinary SIP.
Third-party registration (RFC 3261 Section 10.2) cannot be directly translated to P2PSIP because only the certificate owner can store a SIP-REGISTRATION. It can be implemented using the USER-CHAIN-ACL mechanism from the ShaRe draft with a new 'SIP-3P-REGISTRATION' Kind.
A caller MAY contact the callee using SIP or SIPS but SHOULD follow the preference indicated in the callee's contact_prefs attribute. A callee that accepts SIPS calls only SHOULD indicate this in its contact_prefs.
A user wishing to call another user with a given AOR SHALL proceed by checking if it is a GRUU, if the AOR domain is hosted in the overlay, and if not, querying DNS or using standard SIP procedures. If all contact attempts fail, the call fails.
An existing RELOAD connection between peers MUST NOT be used for SIP messages unless it is a SIP connection. A previously established SIP connection MAY be reused for a new call.
Before a Store is permitted, the Storing Peer MUST check that the AOR is a valid Resource Name for configured namespaces, that the certificate contains a SIP AOR username that hashes to the Resource-ID, and that the certificate Node-ID matches the dictionary key. Failed checks MUST result in an Error_Forbidden error.
Before issuing a Store request, any Peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name and the overlay-configured namespaces.
If the <domain-restrictions> element is included in the overlay configuration and 'enable' is not set or false, the overlay MUST only accept AORs matching the overlay's own domain name. If 'enable' is true, it MUST only accept AORs matching the specified patterns.
To resolve an AOR, a RELOAD user SHALL fetch Kind SIP-REGISTRATION at the Resource-ID for the AOR (without specifying dictionary keys to retrieve all values), recursively resolving any non-GRUU AORs until only GRUUs and destination lists remain.
When routing AppAttach for SIP connection setup, the 'application' field MUST be either 5060 (SIP) or 5061 (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; otherwise the connection MUST NOT be used and MUST be closed.
All RELOAD SIP registration data is visible to all nodes in the overlay. Location privacy can be achieved using anonymous GRUUs; other anonymity and pseudonym methods exist but are beyond the scope of this document.
Anonymous GRUUs are constructed analogously to regular GRUUs but require either a different Node-ID per anonymous GRUU from the enrollment server, or a destination list including a peer that compresses the list to prevent Node-ID disclosure.
GRUUs in RELOAD are constructed by embedding a base64-encoded destination list in the 'gr' URI parameter, using the RFC 4648 Table 1 alphabet with '~' replacing '='. GRUUs do not require storing data in the overlay; the embedded destination list is used directly for routing.
The callee's capabilities are expressed in contact_prefs using the RFC 3840 media feature set syntax as a contact predicate string. SIP or SIPS preference can be indicated via attributes such as (sip.schemes=SIP) or (sip.schemes=SIPS).
The SIP-REGISTRATION Kind uses a dictionary data model keyed by Node-ID, allowing each peer (device) to store a single route mapping per AOR. The Resource Name is the user's AOR as defined in Section 2.
The SipRegistration Resource Record stores either a URI (sip_registration_uri) or a destination list (sip_registration_route) mapping an AOR to a Node-ID or another AOR. It has a type field, a uint16 length, and a SipRegistrationData union selected by type.
IANA registered Kind-ID 0x1 for SIP-REGISTRATION in the 'RELOAD Data Kind-ID' Registry (RFC 6940). The Kind uses a dictionary data model with USER-NODE-MATCH access control.
IANA registered the XML namespace URI 'urn:ietf:params:xml:ns:p2p:config-base:sip' in the IETF XML registry (RFC 3688) for the overlay configuration document extension defining AOR domain restrictions.
AOR hijacking is possible if the overlay liberally accepts registrations for unrelated domain names. Mitigation includes restricting admissible namespaces in the overlay, additional enrollment service verification, and callers querying DNS or alternate overlays to detect bogus registrations.
Fork bombs (DoS via SIP forking amplification) are a lower concern in RELOAD SIP than in conventional SIP proxy infrastructure because the calling party is involved in each retargeting event and can directly measure and throttle the number of forks.
SipRegistration encodes as: SipRegistrationType (1 byte enum, values 1=uri, 2=route), uint16 length, then SipRegistrationData. For sip_registration_uri, data is an opaque string up to 2^16-1 bytes. For sip_registration_route, data is an opaque contact_prefs string (up to 2^16-1 bytes) followed by a Destination list (3..2^16-1 bytes).