RFC 5502

The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem 🎀

Okay bestie, this is RFC 5502 💖, and the title is The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem. It comes from the Network Working Group and was written by J. van Elburg of Ericsson Telecommunicatie B.V. 🧚 It's categorized as Informational, dated April 2009 📅, and its header doesn't list anything it obsoletes or updates. Fresh start, no drama 💅

Status of This Memo ✨

This memo provides information for the Internet community 🌸 It does not specify an Internet standard of any kind, and distribution of it is unlimited 🦋

Copyright Notice 💜

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as in effect on the date this document was published. Please read those carefully, because they describe your rights and restrictions for this document: http://trustee.ietf.org/license-info 📜

This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from them, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be made outside that process either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈

Abstract 📝

This document specifies the SIP P-Served-User P-header. It addresses an issue found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. The header conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. It's a whole main character moment 👑

Table of Contents 🗂️

1. Introduction ....................................................3
2. Conventions .....................................................3
3. Definitions .....................................................3
   3.1. Identity, Network Asserted Identity, Trust Domain,
        and Spec(T) ................................................3
   3.2. Served User ................................................3
4. Scenarios .......................................................4
   4.1. General ....................................................4
   4.2. Diversion: Continue on Terminating Leg, but Finish
        Subsequent Terminating iFC First ...........................5
   4.3. Diversion: Create New Originating Leg and Provide
        Originating iFC Processing .................................6
   4.4. Call Out of the Blue: on Behalf of User B, but
        Service Profile of Service Identity C.......................8
5. Requirements ....................................................8
6. P-Served-User Header Field Definition ...........................9
7. Proxy Behavior ..................................................9
   7.1. Generating the P-Served-User Header ........................9
   7.2. Consuming the P-Served-User Header ........................10
8. Applicability ..................................................10
9. IANA Considerations ............................................11
10. Security Considerations .......................................11
11. Acknowledgments ...............................................11
12. References ....................................................12
   12.1. Normative References .....................................12
   12.2. Informative References ...................................12
Appendix A.  Why the History-Info Header Is Not Suitable to
             Convey the Served User Information on the ISC
             Interface ............................................13
  A.1.  Semantics  ................................................13
  A.2.  Additional Observations  ..................................13
  A.3.  Conclusion ................................................14

1. Introduction 🚀

The 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses SIP (RFC 3261 [2]) as its main signaling protocol. 📞 (If you want the full IMS details, check out 3GPP TS 23.228 [9] and 3GPP TS 24.229 [11].) 3GPP noticed that linking in a SIP application server causes problems, and the best fix is defining a new SIP P-header, following the procedures in RFC 3427 [5] 🔧

Here's the roadmap ✨ Section 4 shows the problem through particular service scenarios, and Section 5 covers the requirements that come out of those scenarios. Section 6 defines the P-Served-User header field that meets those requirements, and Section 7 specifies the proxy behavior for it. Section 8 talks about its applicability and scope, Section 9 registers the P-Served-User header field with IANA, and Section 10 discusses the security properties of the environment where it's meant to be used 🛡️

2. Conventions 📏

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 [1]. These are the official rules-words, so pay attention 🧐

3. Definitions 📚

3.1. Identity, Network Asserted Identity, Trust Domain, and Spec(T)

The terms Identity, Network Asserted Identity, Trust Domain, and Spec(T) are specified in RFC 3324 [3]. 🪪

3.2. Served User

The served user to a proxy or AS (Application Server) is the user whose service profile gets accessed by that proxy or AS when an initial request arrives that is originated by, originated on behalf of, or terminated to that user. 🫶 That profile then provides useful information (preferences or permissions) for processing at a proxy and, potentially, at an AS 💜

4. Scenarios 🎬

4.1. General

In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) is a SIP proxy that acts as a registrar and handles originating and terminating session states for the users allocated to it. So any call originated by a specific user, or terminated to that user, goes through the S-CSCF allocated to them 🌟

When an S-CSCF is allocated for a specific user, a user profile is downloaded to the S-CSCF from the HSS (Home Subscriber Server) over the Cx interface, see 3GPP TS 29.228 [12]. This profile tells the S-CSCF whether the user is allowed to originate or terminate calls, or whether an AS needs to be linked in over the ISC interface. The user profile info that decides whether a particular initial request needs to go to a particular AS is called the initial Filter Criteria (iFC), see for example 3GPP TS 23.218 [8] 🗂️

For an S-CSCF to meet its responsibilities, it needs to figure out on whose behalf it's performing its tasks and which session case applies to the particular request. (For a definition of session case, see 3GPP TS 29.228 [12].) The session case tells apart the originating and terminating call cases, and it determines whether or not the particular user is registered 🧩

When the S-CSCF determines that the originating call case applies to an incoming initial request, it determines the served user by looking at the P-Asserted-Identity header field (RFC 3325 [4]), which carries the network asserted identity of the originating user 📤 After processing the iFC for this initial request, if the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of working out the session case and the served user. Since it's expected to reach the same conclusion that this is an originating session case, it also has to look at the P-Asserted-Identity header field to determine the served user 🔁

When the S-CSCF determines that the terminating call case applies to an incoming initial request, it determines the served user by looking at the Request-URI (RFC 3261 [2]), which carries the identity of the intended terminating user 📥 After processing the iFC for this initial request, if the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of determining the session case and the served user. Since it's expected to reach the same conclusion that this is a terminating session case, it also has to look at the Request-URI to determine the served user 🔁

Here's where it gets messy 👀 In the originating case, the P-Asserted-Identity header field just represents the originating user when it enters the S-CSCF. But when it's sent to an AS over the ISC interface, it gets overloaded with another meaning: it now serves as a representation of the served user. 🤯

In the terminating case, a similar overloading happens to the Request-URI. It first only represented the identity of the intended terminating user, but when it's sent to an AS over the ISC interface, it's overloaded with another meaning: it serves as a representation of the served user 💀

In basic call scenarios, this doesn't show up as a problem. But once more complicated service scenarios (notably forwarding services) need to be realized, it poses severe limitations 😭 Those scenarios are brought forward in the following subsections. 🦋

4.2. Diversion: Continue on Terminating Leg, but Finish Subsequent Terminating iFC First ✨

okay so picture this 💖 user B has a terminating service that diverts the call somewhere else, but she still needs the rest of her terminating services to run on the same call. so this user has multiple iFCs that match the same incoming initial request. 🎀 when the S-CSCF gets an initial INVITE, it figures out the session case is terminating for a registered user, and it picks user B as the served user by looking at the Request-URI.

now the S-CSCF starts the iFC processing. the first iFC that matches the INVITE gets the INVITE forwarded over the ISC interface to an AS that hosts user B's diversion service. to make that happen, the S-CSCF adds the AS's and its own hostnames to the Route header. it also adds an Original Dialog Identifier (ODI) to its own hostname on the Route header 🦋 that's how the S-CSCF can match an INVITE coming back from an AS over the ISC interface to the existing session that sent it to the AS in the first place. iconic, honestly.

when the AS gets the initial INVITE, it also works out that the session case is terminating for a registered user, and it picks user B as the served user by looking at the Request-URI. then the diversion logic decides the call should go to another user or application C, so it changes the Request-URI to C. 🌸 it can optionally record the Request-URI history using the History-Info header field (RFC 4244 [7]). then the AS removes itself from the Route header and sends the INVITE back to the S-CSCF using the topmost Route header field.

when the S-CSCF gets the INVITE back over the ISC interface, it sees that the Route header has its own hostname and an ODI that matches an existing terminating session for user B. 👑 the S-CSCF can use that to check whether there are still iFCs that haven't run yet. (ngl this is the part where it gets messy: the current behavior of the S-CSCF when it receives an INVITE with a changed Request-URI is to end the iFC processing and route the request based on the new Request-URI value.)

and then it repeats itself 😭 the INVITE goes to the AS tied to this next iFC. when that AS gets the initial INVITE, it decides the session case is terminating for a registered user and says the served user is user C by looking at the Request-URI. this is clearly wrong, because the user being served is still user B 💀

this whole scenario shows the exact problem you get when the Request-URI is overloaded with two jobs, "intended target identity" and "served user", using the operation described in Section 4.1. 🙈 it also shows this use case can't work unless there's a mechanism that tells the AS which user is being served, going from the S-CSCF to the AS. the History-Info element doesn't fix this, because it doesn't tell the AS who is being served. it just shows a history of diversions that might not even have been caused by the systems serving this user. Appendix A has a more detailed breakdown of why History-Info can't be used here.

4.3. Diversion: Create New Originating Leg and Provide Originating iFC Processing ✨

so this one is a different vibe 🧚 user B has a terminating service that diverts the call to another destination. the forwarded call leg is required to be handled as an originating call leg, and user B's originating services have to run too. that means this user has one or more iFCs that match an outgoing initial request.

when the S-CSCF gets an initial INVITE, it works out that the session case is terminating for a registered user, and it picks user B as the served user by looking at the Request-URI.

now the S-CSCF starts the iFC processing. the first iFC that matches the INVITE gets the INVITE forwarded over the ISC interface to an AS that hosts user B's diversion service. it does this by adding the AS's and its own hostnames to the Route header. the S-CSCF also adds an Original Dialog Identifier (ODI) to its own hostname on the Route header 💜 that's how it can match an INVITE coming back from an AS over the ISC interface to the existing session that sent it to the AS.

when the AS gets the initial INVITE, it decides the session case is terminating for a registered user, and it picks user B as the served user by looking at the Request-URI. then the diversion logic says the request should go to another user or application C, so it changes the Request-URI to C. 🎀 it can optionally record the Request-URI history using the History-Info header field (RFC 4244 [7]). then the AS removes itself from the Route header. to make sure the request is handled as a new originating call on behalf of user B, the AS adds the "orig" parameter to the topmost Route header. then it sends the INVITE back to the S-CSCF using that topmost Route header field.

when the S-CSCF gets the INVITE over the ISC interface, it sees that the topmost Route header has its own hostname and an "orig" parameter. because of that "orig" parameter, the S-CSCF decides the INVITE should be handled as if the served user originated the call. and here's where it goes sideways 😭 the served user gets determined from the P-Asserted-Identity header, which means user A. this is clearly wrong, because the user being served is and should be user B.

okay, but for the sake of discussion, let's pretend the S-CSCF somehow figures out the served user is user B. then the procedure would go like this 🌈 the S-CSCF starts the originating iFC processing. the first iFC that matches the INVITE gets the INVITE forwarded over the ISC interface to an AS that hosts an originating service of user B, by adding the AS's and its own hostnames to the Route header. the S-CSCF adds an Original Dialog Identifier (ODI) to its own hostname on the Route header.

the INVITE goes to the AS tied to this iFC. when that AS gets the initial INVITE, it decides the session case is originating for a registered user, and it picks user A as the served user by looking at the P-Asserted-Identity. this is clearly wrong, because the user being served is and should be user B 🙈

this scenario shows the problem you get when the P-Asserted-Identity is overloaded with two meanings, "call originator" and "served user", using the operation described in Section 4.1. it also shows this use case can't work without a mechanism that tells the S-CSCF and the AS which user is being served, in both directions. the History-Info element doesn't solve this either, because it doesn't tell the AS which user is being served. it just shows a history of diversions that might not have been caused by the systems serving this user. Appendix A has a more detailed explanation of why the History-Info header field can't be used.

4.4. Call Out of the Blue: on Behalf of User B, but Service Profile of Service Identity C ✨

there are services that need to start a call that looks like it's coming from user B, but the service profile for service identity C has to run in the S-CSCF 💅

when a call needs to look like it's coming from user B, the P-Asserted-Identity has to contain B's identity. that's because the Originating Identity Presentation (OIP) service, defined in 3GPP TS 24.173 [10], uses the P-Asserted-Identity to show who the call came from. honestly that makes total sense, since that's the main thing the P-Asserted-Identity header field is for 🍓

and here's the tea ☕ no INVITE request can currently be built that meets both requirements from the first paragraph. the reason is that the P-Asserted-Identity is overloaded with two meanings on the ISC interface. when the S-CSCF gets this request, it decides the served user is user B, and that's not what we want 🙃

5. Requirements ✨

this section lists the requirements that come out of the scenarios above 💖

1. to be able to offer real-world application services, it is required that the identity of the served user can be conveyed on the ISC interface (see 3GPP TS 23.218 [8]).
2. to be able to offer appropriate services to the served user, it is required that, in addition to the served user identity, the session case is conveyed.

6. P-Served-User Header Field Definition ✨

this section defines the SIP P-Served-User P-header 🦋 the header can be added to initial requests for a dialog, or to standalone requests, that get routed between nodes in a Trust Domain for P-Served-User. the P-Served-User P-header carries the identity of the user that represents the served user. the "sescase" parameter may be used to say whether the initial request is originated by or destined for the served user. the "regstate" parameter may be used to say whether the initial request is for a registered or unregistered user.

the augmented Backus-Naur Form (BNF) (RFC 5234 [6]) syntax of the P-Served-User header field goes like this 🧾

P-Served-User            = "P-Served-User" HCOLON PServedUser-value
                           *(SEMI served-user-param)
served-user-param        = sessioncase-param
                           / registration-state-param
                           / generic-param
PServedUser-value        = name-addr / addr-spec
sessioncase-param        = "sescase" EQUAL "orig" / "term"
registration-state-param = "regstate" EQUAL "unreg" / "reg"

EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are defined in RFC 3261 [2].

here's an example of a P-Served-User header field 🌸

P-Served-User: <sip:user@example.com>; sescase=orig; regstate=reg

7. Proxy Behavior ✨

7.1. Generating the P-Served-User Header

proxies that support the header MUST only insert it in initial requests for a dialog, or in standalone requests, when the following conditions hold 🫶

• the proxy has the capability to determine the served user for the current request.
• the next hop is part of the same Trust Domain for P-Served-User.

when the conditions above don't hold, the proxy MUST NOT insert the header. that's the rule, bestie 💅

7.2. Consuming the P-Served-User Header ✨

Okay bestie, now for the receiving side 💅 A proxy that supports the header MUST, upon receiving from a trusted node the P-Served-User header in initial requests for a dialog or in standalone requests, take the value of that header as the served user for any operation that needs that info 🫶

A proxy that supports the header MUST remove the header from requests or responses when it was received from a node outside the Trust Domain for P-Served-User, before forwarding the message any further 🚫

A proxy that supports the header MUST remove the header from requests or responses when the next hop is a node outside the Trust Domain for P-Served-User, before forwarding the message any further 🔒

---

8. Applicability 🎀

According to RFC 3427 [5], P-headers have a limited applicability 🙈 Specs for P-headers, like this one, need to clearly document the useful scope of the proposal, explain its limitations, and say why it's not suitable for general use of SIP on the Internet.

Using the P-Served-User header field extensions is only applicable inside a Trust Domain for the served user. Nodes in that Trust Domain explicitly trust each other to convey the served user, and to be responsible for keeping that information from leaking outside the Trust Domain. How the network determines the served user, and which policies get executed for a specific served user, is outside the scope of this document 🦋

The served user info doesn't say who or what specifically determined the served user, so you have to assume the Trust Domain determined it. That means the info is only meaningful when it's securely received from a node known to be a member of the Trust Domain 👑

Since the served user typically only has validity in one administrative domain, it's generally not suitable for inter-domain use or for use on the Internet at large 🌍

BUT, despite all these limitations, there are deployments that are useful enough, meet the assumptions above, and can live with the resulting limitations, so this mechanism is worth publishing as Informational 🧚 An example deployment would be a closed network like 3GPP IMS 💖

---

9. IANA Considerations 📋

This document defines a new SIP header field: P-Served-User. IANA has registered this header field in the SIP Parameters registry under the Header Fields subregistry ✨

---

10. Security Considerations 🔐

Okay, this section is serious, so no cap, read it all 😭 The P-Served-User header field defined in this document is meant to be used in an environment where the elements are trusted, and where attackers aren't supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes done with IPsec, and sometimes by physically protecting the network. Either way, the environment where the P-Served-User header field gets used makes sure the integrity and confidentiality of its contents are protected 🛡️

The Spec(T) that defines the Trust Domain for P-Served-User MUST require that member nodes understand the P-Served-User header extension 📜

There's a real security risk if a P-Served-User header field gets to propagate out of the Trust Domain where it was generated 💀 If that happens, user-sensitive information would be revealed, and that's a whole breach 🙅‍♀️ To stop this, proxies MUST NOT insert the header when forwarding requests to a hop that is located outside the Trust Domain. When forwarding a request to a node in the Trust Domain, proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another proxy in the Trust Domain that understands the header, such as the home proxy. There's no automatic mechanism to learn support for this specification, so you can't just guess 🙈 Proxies MUST remove the header when forwarding requests to nodes that are not in the Trust Domain, or when the proxy doesn't have knowledge of any other proxy in the route set that will remove it before it's routed to any node outside the Trust Domain 🚨

---

11. Acknowledgments 🫶

Huge thanks to Alf Heidermark, Hubert Przybysz, and Erik Rolin for the discussion that led to the solution written down in this document 🌸 Spencer Dawkins for performing the expert review 💜 Jon Peterson for performing the AD review ✨ Gonzalo Camarillo, Paul Kyzivat, Nils Haenstroem, Arunachalam Venkatraman, Mikael Forsberg, Miguel Garcia, Jozsef Varga, Keith Drage, Tim Polk, and Cullen Jennings for providing improvements 🍓 Francis Dupont for performing the general area review 🦋 And Sandy Murphy for performing the security area review 🔐

---

12. References 📚

12.1. Normative References

• [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [2] 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.
• [3] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
• [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
• [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
• [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

12.2. Informative References

• [7] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
• [8] 3GPP, "IP Multimedia (IM) session handling; IM call model; Stage 2", 3GPP TS 23.218 V7.
• [9] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 V7.
• [10] 3GPP, "IMS multimedia telephony communication service and supplementary services; Stage 3", 3GPP TS 24.173 V7.
• [11] 3GPP, "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 V7.
• [12] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 V7.

---

Appendix A. Why the History-Info Header Is Not Suitable to Convey the Served User Information on the ISC Interface 🧐

A.1. Semantics 💭

The History-Info header (as specified in RFC 4244 [7]) holds a record of subsequent Request-URI values that get put on an initial request while it's being processed in the network 📝

If it were possible at all to use the History-Info header to communicate the served user, you'd get the same overloading we're trying to get rid of (Section 4.2) 😩 In this case, you'd be overloading the History-Info header field's hi-entry with the meaning "historic target identity" and "served user" 🙃

Another reason the History-Info header can't solve the requirements in this document is that, in originating session case scenarios, the served user is currently determined from the P-Asserted-Identity, because that header field contains the asserted originating user's identity. The History-Info header, being a record of Request-URIs, can never be a solution for this case 🙅‍♀️

Looking at the call-out-of-the-blue scenario (Section 4.4), it's impossible to construct a History-Info header for an INVITE request on behalf of user C that appears to come from user B and targets user D, and that would express served user C, without violating the original semantics of the History-Info header according to (RFC 4244 [7]) 🌀

A.2. Additional Observations 🔍

The purpose of the History-Info header is to be a header with an end-to-end application. For informing an AS on the ISC interface, that's total overkill 🧁

When the AS receives an initial INVITE over the ISC interface, that INVITE may have passed a vast number of proxies, which may or may not have added history information. On top of that, the request may have traversed several AS instances for the same served user. If several subsequent iFCs are active, all of those AS instances may perform a forwarding. So it's not possible to define an algorithm that points out which hi-entry of a History-Info header should represent the served user. In other words, a History-Info header field with n entries expresses a branch of depth n, and any or none of those elements could be the served user identity 🌳

The History-Info header doesn't comply with the second requirement as expressed in Section 5, because it has no means to express the session case in a natural way 🫠

A.3. Conclusion 🎀

Each observation in the previous subsections, on its own, is enough to disregard the History-Info header as an information element suitable for transporting served user information over the ISC interface 💅

Note that this does not prohibit using the P-Served-User header and the History-Info header in the same request. In fact, that's going to be a pretty likely scenario for network-based diversion services like, for example, the Communication Diversion service as specified in (3GPP TS 24.173 [10]) 🌸✨

---

Author's Address 💌

Hans Erik van Elburg
Ericsson Telecommunicatie B.V.
Ericssonstraat 2
Rijen  5121 ML
Netherlands

EMail: HansErik.van.Elburg@ericsson.com