RFC 3327
Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts 🎀
Okay bestie, the title block is giving everything 💅 This is RFC 3327 from the Network Working Group, and it's on the Standards Track 🦋. D. Willis (dynamicsoft Inc.) and B. Hoeneisen (Switch) wrote it, and it's dated December 2002 🌸. The title block doesn't list any RFCs that it obsoletes or updates 🧚
Status of This Memo 📣
So this doc is an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions for improvements 🙏 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited 🌈
Copyright Notice 💜
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract ✨
So the REGISTER function is the thing a SIP system mainly uses to link a temporary contact address to an address-of-record 🧚 That contact is usually a URI, like Contact: <sip:alice@pc33.atlanta.com>, and it's pretty dynamic, tied to the IP address or hostname of the SIP User Agent (UA) 🎀 Here's the tea: network topology can put one or more SIP proxies between the UA and the registrar 😭 So any request going from the user's home network to the registered UA must traverse those proxies. REGISTER has no way to find and record that chain of proxies in the registrar for later use 💀 This document defines an extension header field called "Path" that fills that gap 👑
Table of Contents 🧚
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . 3
4. Path Header Field Definition and Syntax . . . . . . . . . . 3
5. Usage of Path Header Field . . . . . . . . . . . . . . . . . 5
5.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . 5
5.2 Procedures at Intermediate Proxies . . . . . . . . . . . . . 5
5.3 Procedures at the Registrar . . . . . . . . . . . . . . . . 6
5.4 Procedures at the Home Proxy . . . . . . . . . . . . . . . . 6
5.5 Examples of Usage . . . . . . . . . . . . . . . . . . . . . 7
5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . . 7
5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . 13
6.1 Considerations in REGISTER Request Processing . . . . . . . 13
6.2 Considerations in REGISTER Response Processing . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 16
Non-Normative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 171. Background 🌸
3GPP set up a requirement for discovering intermediate proxies during SIP registration, and published that requirement in [5].
Here's the scenario 👀
UA1----P1-----P2-----P3------REGISTRARUA1 wants to register with REGISTRAR. But because of network topology, UA1 has to use P1 as an "outbound proxy", and all requests between UA1 and REGISTRAR must also traverse P1, P2, and P3 before reaching REGISTRAR. Likewise, all requests between REGISTRAR and UA1 must also traverse P3, P2, and P1 before reaching UA1.
UA1 has a standing relationship with REGISTRAR. How UA1 sets that up is outside the scope of this document. UA1 finds out about P1 through configuration, DHCP assignment, or some other similar operation, which is also outside the scope of this document. REGISTRAR has a similar "default outbound proxy" relationship with P3.
Eventually, REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) closely related to it will get a request destined for UA1. It needs to know which proxies that request must go through to get back to UA1 🧭 Sometimes that info can be figured out from SIP routing configuration tables or DNS entries. Other times, like the case 3GPP raised, the info just isn't readily available outside of the SIP REGISTER transaction 😩
The Path extension header field lets us gather up and send along the list of proxies between UA1 and REGISTRAR 🎀 Intermediate nodes like P1 can statefully hang on to Path information if operational policy needs it. This is kind of like how Record-Route works in dialog-initiating requests 💅 The routing set up by the Path header field mechanism only applies to requests transiting or originating in the home domain.
2. Terminology 📖
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 BCP 14, RFC 2119 [3].
3. Applicability Statement 🦋
The Path mechanism is a good fit whenever there are intermediate proxies between a SIP UA and a SIP Registrar that the UA uses, and these conditions are true:
- One or more of the intermediate proxies are visited by registration requests from the UA to the Registrar.
- The same intermediate proxies, or a set of proxies known to the intermediate proxies, must be traversed, in reverse order, by requests sent through a home proxy to the UA. In the simplest form, the route between the home proxy and the UA is the exact inverse of the route between the UA and the route between the UA and the registrar.
- The network topology is such that the intermediate proxies which must be visited are NOT implied by SIP routing tables, DNS, or similar mechanisms.
4. Path Header Field Definition and Syntax 🧚
The Path header field is a SIP extension header field with syntax that's very similar to the Record-Route header field. It gets used with SIP REGISTER requests and with 200 class messages in response to REGISTER (REGISTER responses) ✨
A Path header field MAY be inserted into a REGISTER by any SIP node that the request goes through. Like the Route header field, sequential Path header fields get evaluated in the order they show up in the request, and Path header fields MAY be combined into a compound Path header in a single Path header field. The registrar reflects the accumulated Path back into the REGISTER response, and intermediate nodes pass it back toward the originating UA. So the originating UA finds out which nodes got added to its registered Path, and it MAY use that info in other capacities outside the scope of this document 👀
Now, the difference between Path and Record-Route is that Path applies to REGISTER and 200 class responses to REGISTER. Record-Route doesn't, and it can't be defined in REGISTER for reasons of backward compatibility 🙃 Also, the vector set up by Record-Route only applies to requests within the dialog that established that Record-Route, but the vector set up by Path applies to future dialogs 💖
The syntax for Path is defined as follows:
Path = "Path" HCOLON path-value *( COMMA path-value )
path-value = name-addr *( SEMI rr-param )Note that the Path header field values follow the syntax of a Route element as defined in [1]. As suggested there, such values MUST include the loose-routing indicator parameter ;lr for full compliance with [1] 🫶
The allowable usage of header fields is described in Tables 2 and 3 of SIP [1]. The following additions to that table are needed for Path 📋
Support for the Path header field MAY be indicated by a UA by including the option-tag "path" in a Supported header field 🌈
Addition of Path to SIP Table 3:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Path R ar - - - - - o
Path 2xx - - - - - - o5. Usage of Path Header Field 🌟
5.1 Procedures at the UA 💌
The UA runs its register operation as usual. The response MAY contain a Path header field. The general operation of the UA is to ignore the Path header field in the response 🙈 It MAY choose to display the contents of the Path header field to the user, or take other action outside the scope of this document. The Path info in the REGISTER response tells the UA which intermediate proxies got added during registration. Checking this info might matter from a security perspective, since that inspection could let the UA spot intermediate proxies that added themselves where they shouldn't have 😭
The 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 🎀
The UA MAY include a Path header field in a request. This is not broadly applicable, and caution must be taken to insure proper function, since the Path header field inserted by the UA may have additional Path header field values appended by intermediate proxies. Those proxies aren't aware that the Path header field value was inserted by a UA. They'll treat it as if a previously traversed proxy inserted it, which could lead to unexpected routing behavior where the UA is asked to act as a proxy 💀
5.2 Procedures at Intermediate Proxies 🦋
okay so bestie, when a proxy is handling a REGISTER request and wants to stay on the path for future requests heading toward the UA that sent that REGISTER, it slaps its own URI on as the topmost value in the Path header field (or adds a brand new topmost Path header) before passing the request along ✨ it's also possible for a proxy that really knows its network topology to add a Path value pointing at some other node, which means the Path can end up not matching the route the REGISTER actually took 👀 that construction is implementation specific and totally outside the scope of this doc 🫶
Intermediate proxies SHOULD NOT add a Path header field to a request unless the UA has said it supports this extension with a Supported header field value 💅 if the UA did say that and the proxy needs the registrar to support the Path extension, then the proxy SHOULD insert a Requires header field value for this extension. but if the UA hasn't indicated support and the proxy needs the registrar to support it, the proxy SHOULD reject the request with a 421 response indicating a requirement for the extension 😭
Proxies processing a REGISTER response SHOULD NOT alter any Path header field values that may be present in the response 🙈 the registrar MAY protect the Path header field in the response by putting it inside a protected S/MIME body, and then if an intermediate proxy changes the Path, the UA can catch it as a man-in-the-middle attack 🔥 so proxies SHOULD only consider altering the Path value in the REGISTER response if they have the credentials to correctly fix up the S/MIME body to match the change. no shortcuts, periodt 💜
5.3 Procedures at the Registrar 🎀
if a Path header field exists in a successful REGISTER request, the registrar builds an ordered list of route elements (a path vector) out of the nodes listed in the Path header field values, keeping the order exactly as the Path header field values show it 🧚 then it stores that path vector together with the contact and the address-of-record from the REGISTER request (the "binding" as defined in [1]). the registrar also copies the Path header field values into a Path header field in the successful (200 class) REGISTER response 💖 and if the home proxy and registrar aren't co-located, the registrar MAY apply a locally-determined transformation to the stored path vector.
now, if a registrar gets a REGISTER request with a Path header field but there's no sign of extension support from the UA (no Supported header field), the registrar must rely on local policy to decide what to do 🤷♀️ the recommended policy is for the registrar to reject the request with a 420 "Bad Extension" response that names the Path extension. this lets the UA catch the fact that an intermediate proxy inappropriately added a Path header field 🕵️♀️ the Path mechanism should technically still work without UA support (at some compromise to security), so some registrars MAY choose to support the extension even when there's no Supported header field value in the request 🌈
5.4 Procedures at the Home Proxy 🌸
in the common SIP model, there's a home proxy tied to the registrar for a user. every incoming request aimed at the user's public address-of-record gets routed to this proxy, which checks the registrar's database to figure out which contact the request should be retargeted to 💅 in its basic mode of operation, the home proxy rewrites the request-URI from the incoming request with the registered contact's value and retransmits the request.
with Path in the mix, the home proxy also copies the stored path vector for that specific contact (from the registrar database) into the Route header field of the outgoing request, as a preloaded route ✨ this is what makes the outgoing request transit the proxies that were listed in the Path header field of the REGISTER request 🦋
in normal processing, the home proxy is the "terminal point" for the user's address-of-record (AOR) 🎯 so the Route header field on the incoming request will have been used up by the time it reaches the home proxy. if it isn't used up, then things get interesting 👀 in the most common case, the home proxy builds the outgoing Route header field by sticking the stored path vector in front of the Route header field values that came in with the incoming request. this procedure may be altered by a local policy at the home proxy 💜
loose routes can interact with routing policy in some pretty wild ways 🙈 how the stored path vector plays with any locally required default route and local policy is implementation dependent. for example, some devices use locally-configured explicit loose routing to reach a next-hop proxy, and others use a default outbound-proxy routing rule. but for the result to actually work, the combination must provide valid routing in the local environment. generally, the stored path vector gets appended to whatever locally configured route is needed to egress the service cluster 🔥 the service proxy (or registrar, as noted earlier) MAY also transform the stored path vector as needed so everything functions correctly. and honestly? systems designers must match the Path recording policy of their nodes with the routing policy, or the whole system just won't be workable 😭
5.5 Examples of Usage ✨
quick heads up 💅 some header fields (e.g. Content-Length) and session descriptions are left out here so the examples are shorter and hopefully easier to read. the node marked REGISTRAR is a registrar and a proxy, and it serves as a home proxy. so in the DNS, the domain EXAMPLEHOME.COM points to the same host as REGISTRAR.EXAMPLEHOME.COM 🍓
5.5.1 Example of Mechanism in REGISTER Transaction 💖
let's use the scenario from the Background section 🧚
UA1----P1-----P2----P3-----REGISTRARso in this example, UA1 sends a REGISTER request to REGISTRAR 📨 the request goes through its default outbound proxy P1, an intermediate proxy P2, and the firewall proxy for the home domain, P3, before it reaches REGISTRAR. because of network topology and operational policy, P1 and P3 need to be transited by requests from REGISTRAR or other nodes in the home network that are targeted to UA1. P2 doesn't need that. P1 and P3 have been configured to include themselves in Path header fields on the REGISTER requests they process 🫶 UA1's current IP address is "192.0.2.4".
here's the message sequence for REGISTER with Path 🦋
F1 Register UA1 -> P1
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
. . .F2 Register P1 -> P2
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P1.EXAMPLEVISITED.COM;lr>
. . .Note: P1 has added itself to the Path. 🌟
F3 Register P2 -> P3
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P1.EXAMPLEVISITED.COM;lr>
. . .Note: P2 did NOT add itself to the Path. 🙅♀️
F4 Register P3 -> REGISTRAR
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .Note: P3 added itself to the Path. 💫
F5 REGISTRAR executes Register
REGISTRAR Stores:
For UA1@EXAMPLEHOME.COM
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>F6 Register Response REGISTRAR -> P3
SIP/2.0 200 OK
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .Note: The Path header field in the response is identical to the one received in the REGISTER request. ✅
F7 Register Response P3 -> P2
SIP/2.0 200 OK
Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .F8 Register Response P2 -> P1
SIP/2.0 200 OK
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .F9 Register Response P1 -> UA1
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .5.5.2 Example of Mechanism in INVITE Transaction ✨
Okay bestie, this one follows an INVITE from UA2 all the way to UA1 🦋 REGISTRAR slides a preloaded Route toward UA1 onto the request, swaps the request URI for the registered Contact, and sends the retargeted INVITE along the Path toward UA1. Heads up: this example brings in a foreign user agent, UA2 (address "71.91.180.10"), and a foreign domain, FOREIGN.ELSEWHERE.ORG 🌍 We took the diagram from the last example and added UA2. We also show P2 out-of-line, which means it did not add itself to the path during registration 🧚
Scenario
UA1----P1---------P3-----REGISTRAR
| |
P2 |
|
UA2--------------------------Message sequence for INVITE using Path:
F1 Invite UA2 -> REGISTRAR
INVITE UA1@EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .F2 REGISTRAR processing
REGISTRAR looks up the name "UA1@EXAMPLEHOME.COM" and comes back with:
Contact = <sip:UA1@192.0.2.4>Path vector = <sip:P3.EXAMPLEHOME.COM;lr>, <sip:P1.EXAMPLEVISITED.COM;lr>
Note: the Contact swaps in for the request-URI 🔄 The path vector gets pushed onto the Route stack (the preloaded Route) of the outgoing INVITE. The topmost Route is what drives the routing decision, together with local policy 💅
F3 Invite REGISTRAR -> P3
INVITE UA1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
Route: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
. . .Note: in this example REGISTRAR doesn't want to stick around on the Route, so it does not insert a Record-Route 🙅♀️
F4 Invite P3 -> P1
INVITE UA1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e
Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>
Route: <sip:P1.EXAMPLEVISITED.COM;lr>
. . .Note: P3 added a Record-Route entry, which says it wants to be walked through by future messages in this dialog 👑
F5 Invite P1 -> UA1
INVITE UA1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p
Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e
Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
Record-Route: <sip:P1.EXAMPLEVISITED.COM;lr>
Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>
. . .Note: P1 added a Record-Route entry too, saying it wants to be traversed by future messages in this dialog 🌸
6. Security Considerations 🔐
Okay, security is serious, so listen up 😭 There are few security considerations for this document beyond those in SIP [1]. Honestly, the Path extension and how it's used are identical to the Record-Route header field of basic SIP 💖 Also, the user's expectations stay transparent because the final Path gets returned to the originating UA. So the UA is told which additional proxies were inserted into the path for the registration tied to that response ✨
The Path header field collects information hop-by-hop during REGISTER processing. The information that comes back is basically end-to-end, meaning intermediate proxies don't change it 🧚 This gives us two slightly different security approaches.
6.1 Considerations in REGISTER Request Processing 🛡️
Here's the scary part: the information gathered during REGISTER processing decides which extra proxies get included in future requests between the registrar's location and the UA. If an attacker manages to let an intruding proxy add itself to that chain, they could intercept future calls meant for the UA 😱
An attacker could also try to change the Path, either by messing with data "on the wire" or through other tricks like impersonation that get it included in the SIP routing chain (a "node insertion" attack) 🙈 Messing with data "on the wire" can be dealt with pretty well by transport-layer integrity protection like TLS or IPSEC. Proxy insertion can be handled with mutual authentication at the proxy layer, which TLS or IPSEC can also provide. The "sips:" URI class defined in [1] gives a UA a way to ask intermediate proxies for integrity protection and mutual authentication 💜
Systems using the Path mechanism SHOULD use appropriate mechanisms (TLS, IPSEC, etc.) to provide message integrity and mutual authentication. UAs SHOULD use "sips:" to request transitive protection 🫶
The registering UA SHOULD use S/MIME mechanisms to send a protected copy of the original request to the registrar. In that case, the UA SHOULD include a Supported header field in the protected copy, with a value that shows support for the Path extension. Registrars receiving such a request MUST honor the Path extension only if support is indicated in the protected header field 🔒 Plus, they SHOULD compare the unprotected Supported header field with the protected one, and take appropriate action if an intermediate changed the message to claim support for Path when the requesting UA never indicated it 🚨
6.2 Considerations in REGISTER Response Processing 🎀
The data the Path header field sends back to the UA in the REGISTER response is there to give the UA openness. The registrar is basically saying, "These are the intermediate proxies that will be included on future requests to you processed through me" 💅 By looking at this header field, the UA may be able to spot node insertion attacks that stick a proxy into the SIP routing chain. S/MIME techniques can stop intermediate proxies from changing this header field during response processing 🔐
As specified, there's no requirement for arbitrary proxies between the UA and the registrar to modify the Path header field in the REGISTER response. So we can use an end-to-end protection technique 🦋 The S/MIME technique defined in [1] is an effective mechanism. With it, the registrar makes a copy of the complete response, signs it, and attaches it as a body to the response. The UA can then verify it, which makes sure the Path header field it got is unmodified ✅
On top of the hop-by-hop integrity protection and mutual authentication suggested for REGISTER request processing in the previous section, systems using Path header fields SHOULD implement end-to-end protection using S/MIME. To be specific, 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 the S/MIME technique. Furthermore, UAs receiving a Path header field in a REGISTER response SHOULD render it to the user or, where feasible, check it programmatically 🌈
7. IANA Considerations 📋
This document defines the SIP extension header field "Path", which IANA has added to the registry of SIP header fields defined in SIP [1] 🌷
This document also defines the SIP option tag "path", which IANA has added to the registry of SIP option tags defined in SIP [1] ⭐
The registration for the Path header field looks like this:
RFC Number: RFC3327
Header Field Name: Path
Compact Form: noneThe registration for the path option tag looks like this:
RFC Number: RFC3327
Option Tag: path8. Acknowledgements 🫶
Min Huang and Stinson Mathai put together the original proposal for this mechanism in 3GPP, and worked out most of the 3GPP procedures in 24.229 👑
Keith Drage, Bill Marshall, and Miguel Angel Garcia-Martin argued with everybody a lot about the idea, and also helped refine the requirements 🔥
Juha Heinanen argued steadfastly against standardizing the function of discovering the home proxy with this technique in this document 💀
Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
Non-Normative References
[5] Garcia-Martin, MA., "3GPP Requirements On SIP", Work in Progress.
[6] Mankin, A., "SIP Change Process", Work in Progress.
Authors' Addresses
Dean Willis
dynamicsoft Inc.
5100 Tennyson Parkway
Suite 1200
Plano, TX 75028
US
Phone: +1 972 473 5455
EMail: dean.willis@softarmor.com
URI: http://www.dynamicsoft.com/
Bernie Hoeneisen
Switch
Limmatquai 138
CH-8001 Zuerich
Switzerland
Phone: +41 1 268 1515
EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/Full Copyright Statement ✨
Okay bestie, the legal bit 💅 Copyright (C) The Internet Society (2002). All rights reserved 🦋
You can copy this document and hand it to other people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those, in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph stay on every copy and derivative work 🫶
What you can't do is change this document itself in any way. That means no removing the copyright notice and no removing the references to the Internet Society or other Internet organizations. There are two exceptions. The first is developing Internet standards, where you have to follow the copyright procedures in the Internet Standards process. The second is translating it into languages other than English 🌍
These permissions are perpetual, so the Internet Society and its successors or assigns won't revoke them 💜
This document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙈
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society 🫶 That's the whole ending, and it's giving tidy wrap-up energy ✨
📦 where this page comes from
- ietf: rfc3327 2002-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms