Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
updated by
- rfc-5626 — Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
Extracted elements (25)
Path accumulates hop-by-hop during REGISTER request processing but is returned end-to-end in the response without modification by intermediate proxies. This asymmetry motivates two different security approaches: hop-by-hop integrity (TLS/IPsec) for the request path and end-to-end protection (S/MIME) for the response.
Path differs from Record-Route in that Path applies to REGISTER requests and 200-class responses to REGISTER, whereas Record-Route cannot be defined for REGISTER due to backward compatibility constraints. Additionally, a Record-Route vector applies only to requests within the dialog that established it, while a Path vector applies to all future dialogs routed through the home proxy.
The Path mechanism was designed in response to 3GPP requirements where network topology places intermediate proxies between a UA and its registrar that are not discoverable via SIP routing tables, DNS, or similar mechanisms. The path must be explicitly recorded during REGISTER so the home proxy can reconstruct the reverse route for inbound requests.
The registrar reflects the accumulated Path back into the REGISTER response so that the originating UA is informed of which intermediate proxies have been inserted into its registered path. This transparency allows the UA to detect proxies that have inappropriately added themselves to the routing chain.
A UA MAY include a Path header field in a REGISTER request, but caution is required: intermediate proxies will treat the UA-inserted value as if it were inserted by a previously traversed proxy, which could result in unexpected routing behavior where the UA is asked to act as a proxy.
Loose routes may interact with routing policy in non-obvious ways at the home proxy. The stored path vector is generally appended to any locally configured route needed to egress the service cluster; the combination must provide valid routing in the local environment. The service proxy MAY transform the stored path vector as needed.
Support for the Path header field MAY be indicated by a UA by including the option-tag "path" in a Supported header field. The Path header field is allowed only in REGISTER requests (column 'R') and 200-class responses to REGISTER; it is not applicable to ACK, BYE, CANCEL, INVITE, or OPTIONS methods.
A UA SHOULD include the option tag "path" as a header field value in all Supported header fields, and SHOULD include a Supported header field in all requests.
If a Path header field exists in a successful REGISTER request, the registrar constructs an ordered path vector from the Path header field values (preserving order), stores it with the contact and address-of-record binding, and copies the Path header field values into the successful 200-class REGISTER response.
If the UA has indicated Path support and the proxy requires the registrar to support the Path extension, the proxy SHOULD insert a Requires header field value for this extension. If the UA has not indicated support but proxy requires it, the proxy SHOULD reject with a 421 response.
Intermediate proxies SHOULD NOT add a Path header field to a REGISTER request unless the UA has indicated support for this extension via a Supported header field value.
Path header field values MUST include the loose-routing indicator parameter ";lr" for full compliance with RFC 3261.
Proxies processing a REGISTER response SHOULD NOT alter any Path header field values present in the response. Proxies SHOULD only consider altering the Path value if they have credentials to correctly alter the S/MIME body to account for the change.
Registrars returning a Path header field SHOULD attach a signed S/MIME of the response, and UAs receiving a REGISTER response containing a Path header field SHOULD validate the message using S/MIME. UAs SHOULD render the Path header field to the user or check it programmatically.
Systems using the Path mechanism SHOULD use appropriate mechanisms (TLS, IPSEC, etc.) to provide message integrity and mutual authentication. UAs SHOULD use "sips:" URIs to request transitive protection.
The registering UA SHOULD use S/MIME mechanisms to provide a protected copy of the original request to the registrar, including a Supported header field indicating Path support in the protected copy. Registrars receiving such a request MUST honor the Path extension only if support is indicated in the protected header field.
When a registrar receives a REGISTER with a Path header field but no indication of UA support, the recommended policy is to reject with 420 'Bad Extension', allowing the UA to detect that an intermediate proxy has inappropriately added Path. However, some registrars MAY choose to accept the extension anyway.
An intermediate proxy wishing to be on the path for future requests inserts a URI referencing itself as the topmost value in the Path header field before forwarding the REGISTER request. A proxy with specific topology knowledge MAY also insert a Path value referencing another node, allowing construction of a path discongruent with the REGISTER route.
The home proxy, upon receiving a request targeted to a registered AOR, copies the stored path vector from the registrar database into the Route header field of the outgoing request as a preloaded route, inserting the stored path vector ahead of any existing Route header field values.
The Path header field is a SIP extension header with syntax similar to Record-Route. It is used in REGISTER requests and 200-class REGISTER responses to accumulate the list of intermediate proxies between a UA and its registrar, enabling future requests to traverse the same proxies.
IANA has added the SIP extension header field "Path" to the registry of SIP header fields defined in RFC 3261. RFC Number: RFC3327; Header Field Name: Path; Compact Form: none.
IANA has added the SIP option tag "path" to the registry of SIP option tags defined in RFC 3261. RFC Number: RFC3327; Option Tag: path.
An attacker that can insert itself into the Path chain during REGISTER processing can intercept all future calls intended for the UA. Node insertion attacks may be accomplished by altering data on the wire or through proxy impersonation; TLS or IPsec mitigates wire-level attacks while mutual authentication at the proxy layer addresses proxy insertion.
The Path header field returned in the REGISTER response provides transparency to the UA about which proxies will be included in future requests. S/MIME end-to-end protection of the REGISTER response prevents intermediate proxies from tampering with the returned Path and enables the UA to detect node insertion attacks.
Path header field syntax: 'Path = "Path" HCOLON path-value *( COMMA path-value )' where 'path-value = name-addr *( SEMI rr-param )'. Values conform to the Route element syntax defined in RFC 3261.