A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages
Extracted elements (25)
Content indirection is motivated by bandwidth-limited environments (e.g., cellular wireless), where moving large content out of the SIP signaling path to a separate data channel reduces latency and proxy overload. The mechanism is intended as a transport alternative only, not a semantic change.
The text/uri-list MIME type was considered but rejected because it lacked the ability to specify per-URI attributes such as version information or MIME type of referenced content. RFC 2017's extension to message/external-body was chosen as a more capable replacement.
A failure to complete HTTPS or starttls after having accepted the indirect content in a SIP request is not equivalent to rejecting the SIP request; it may require additional user-to-user communication for correction.
The UAS MAY advertise alternate URI access schemes in the schemes parameter of the Contact header in response to session establishment requests (INVITE, SUBSCRIBE), as described in RFC 3840.
A Content-Disposition entity header MUST be present for all indirect content.
A Content-Type entity header SHOULD be present in the entity payload to support SIP content-type negotiation. The sender MUST be prepared for the receiver to reject content indirection if it cannot negotiate an appropriate MIME type.
A UAC/UAS indicates support for content indirection by including the message/external-body MIME type in the Accept header. User-Agents supporting content indirection MUST support content indirection of the application/sdp MIME type.
Applications that use this content indirection mechanism MUST support the HTTP URI scheme. A UAC/UAS MUST support receiving an HTTP URI for indirect content if it advertises support for content indirection.
Changes in the underlying content referred to by a URI MUST result in a change in the Content-ID associated with that URI. Multiple SIP messages carrying URIs referring to the same content SHOULD reuse the same Content-ID to enable caching.
Content-Description MAY be used to supply optional freeform text about indirect content, but MUST NOT be used by elements to determine the disposition of the body.
If a hash parameter is included, the recipient MUST check the indirect content against that hash and indicate any mismatch to the user. If the hash parameter is NOT included, the sender SHOULD use only URI schemes that offer message integrity such as https.
If a UAS receives a SIP request with a content indirection payload it cannot support, it MUST reject the request with a 415 Unsupported Media Type response.
If HTTP is used for indirect content transfer, applications SHOULD support the HTTPS URI scheme and MUST support upgrading connections to TLS using starttls.
If multiple URIs are needed for content indirection, a multipart MIME type must be used. Each URI MUST be contained in a single entity. Indirect content may be mixed with directly-supplied content.
If the hash parameter is included and the target URI involves certificate-based security, the UAS MUST ignore certificate validation results and instead verify that the hash of the received content matches the hash in the content-indirection parameter.
If the UAS is unable to fetch or render an optional body part (marked via the Critical-Content mechanism), the server MUST NOT return an error to the UAC.
SIP headers Call-Info, Error-Info, and Alert-Info MUST be used in preference to the content indirection mechanism where applicable, because of their well-defined semantics.
When known in advance, the size of the indirect content in bytes SHOULD be supplied via a size parameter on the Content-Type header, allowing the receiver to decide whether to retrieve the content.
When the hash parameter is not included and certificate-based security is used, the UAS MUST verify server certificates using the UAS's list of trusted top-level certificate authorities.
An optional SHA-1 hash of the indirect content may be included as a hexadecimal-encoded 'hash' parameter on the message/external-body Content-Type header, allowing the recipient to validate content integrity.
The supplier of a URI MUST specify the time period for which the URI is valid via an 'EXPIRATION' parameter on the Content-Type header, formatted as an RFC 1123 GMT date-time value. This is a mandatory parameter.
The URI for indirect content is specified in a 'URI' parameter of the message/external-body MIME type, with an access-type parameter set to 'URL'. HTTP URI specifications MUST conform to RFC 2396.
Content indirection can be abused for protocol downgrade attacks (e.g., forcing HTTP Basic Auth), denial-of-service via excessive resource consumption, port-scanning of internal resources, and disclosure of sensitive information such as internal usernames or geolocation. These threats can be mitigated by careful screening of URIs and use of integrity/confidentiality protection.
For confidentiality, integrity, and authentication of the indirect content URI and its parameters, this mechanism relies on S/MIME as defined in Section 23 of RFC 3261.
The UAS SHOULD NOT implicitly trust the object referred to by a URI simply because it trusts the UAC that sent it; the UAS must establish its own trust relationship with the URI provider. This document does not advocate transitive trust.