RFC 4083
Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)
part 1 of 7 💖 more parts coming, so don't go anywhere!
RFC 4083: Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) 🎀
okay so the title block is giving everything 📋 This one comes from the Network Working Group and was written by M. Garcia-Martin at Nokia. It's filed as Informational and dated May 2005 🦋 It doesn't list any RFCs that it obsoletes or updates, so it isn't replacing or patching anything 🫶
Status of This Memo ✨
This memo is here to give info to the Internet community 📚 It does NOT specify an Internet standard of any kind 🙅 Distribution is unlimited, so share it with everyone 💅
Copyright Notice 🌸
The notice reads Copyright (C) The Internet Society (2005).
Abstract 🌈
Okay, the 3rd-Generation Partnership Project (3GPP) picked Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS) 🧚 IMS is part of Release 5 of the 3GPP specs. SIP mostly fulfills what's needed to set up a session on an IP network, but it has never been checked against the specific 3GPP requirements for working in a cellular network 👀 So this document lays out the requirements that 3GPP identified for supporting SIP in Release 5 of the 3GPP IMS in cellular networks 💜
Table of Contents 📖
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Overview of the 3GPP IMS ........................................5
4. 3GPP Requirements on SIP ........................................7
4.1. General Requirements .......................................7
4.1.1. Efficient Use of the Radio Interface ................7
4.1.2. Minimum Session Setup Time ..........................7
4.1.3. Minimum Support Required in the Terminal ............8
4.1.4. Roaming and Non-roaming .............................8
4.1.5. Terminal Mobility Management ........................8
4.1.6. IP Version 6 ........................................8
4.2. SIP Outbound Proxy .........................................8
4.2.1. SIP Outbound Proxy ..................................8
4.2.2. Discovery of the SIP Outbound Proxy .................8
4.3. Registration ...............................................9
4.3.1. Registration Required ...............................9
4.3.2. Efficient Registration .............................10
4.3.3. Registration for Roaming and Non-roaming Cases .....10
4.3.4. Visited Domain Name ................................10
4.3.5. De-registration ....................................10
4.4. SIP Compression ...........................................11
4.4.1. Compression Algorithm Independence .................12
4.4.2. Extensibility of the SIP Compression ...............12
4.4.3. Minimal Impact of SIP Compression on the Network ...12
4.4.4. Optionality of SIP Compression .....................12
4.5. QoS Requirements Related to SIP ...........................13
4.5.1. Independence between QoS Signaling and SIP .........13
4.5.2. Coordination between SIP and QoS/Resource
Allocation .........................................13
4.6. Prevention of Theft of Service ............................14
4.7. Radio Resource Authorization ..............................14
4.8. Prevention of Malicious Usage .............................14
4.9. Prevention of Denial of Service ...........................14
4.10. Identification of Users ..................................15
4.10.1. Private User Identity ............................15
4.10.2. Public User Identities ...........................15
4.10.3. Delivery of the Dialed Public User ID ............17
4.11. Identifiers Used for Routing .............................17
4.12. Hiding Requirements ......................................17
4.12.1. Hiding of the Network Structure ..................17
4.12.2. Hiding of IP Addresses ...........................17
4.12.3. SIP Hiding Proxy .................................18
4.13. Cell-ID ..................................................18
4.13.1. Cell-ID in Signaling from the UA to the
Visited and Home .................................18
4.13.2. Format of the Cell-ID ............................18
4.14. Release of Sessions ......................................18
4.14.1. Ungraceful Session Release .......................19
4.14.2. Graceful Session Release .........................19
4.15. Routing of SIP Messages ..................................20
4.15.1. SIP Outbound Proxy ...............................20
4.15.2. SIP Serving Proxy in the Home Network ............20
4.15.3. INVITE Might Follow a Different Path than
REGISTER .........................................20
4.15.4. SIP Inbound Proxy ................................20
4.15.5. Distribution of the Source Routing Set of
Proxies ..........................................21
4.16. Emergency Sessions .......................................21
4.17. Identities Used for Session Establishment ................21
4.17.1. Remote Party Identification Presentatio ..........21
4.17.2. Remote Party Identification Privacy ..............21
4.17.3. Remote Party Identification Blocking .............21
4.17.4. Anonymity ........................................22
4.17.5. Anonymous Session Establishment ..................22
4.18. Charging .................................................22
4.18.1. Support of Both Prepaid and Postpaid Models ......22
4.18.2. Charging Correlation Levels ......................23
4.18.3. Charging Correlation Principles ..................23
4.18.4. Collection of Session Detailed Information .......24
4.19. General Support of Additional Capabilities ...............24
4.19.1. Additional Capabilities ..........................24
4.19.2. DTMF Signaling ...................................24
4.19.3. Early Media ......................................25
4.20. Exchange of Session Description ..........................25
4.21. Prohibition of Certain SDP Parameters ....................26
4.21.1. Prohibition of Codecs ............................26
4.21.2. Prohibition of Media Types .......................26
4.22. Network-initiated Re-authentication ......................26
4.23. Security Model ...........................................27
4.24. Access Domain Security ...................................28
4.24.1. General Requirements .............................28
4.24.2. Authentication ...................................29
4.24.3. Message Protection ...............................29
4.24.4. Negotiation of Mechanisms ........................31
4.24.5. Verification of Messages .........................31
4.25. Network Domain Security ..................................32
5. Security Considerations ........................................32
6. Contributors ...................................................32
7. References .....................................................32
7.1. Normative References ......................................32
7.2. Informative References ....................................331. Introduction 🦋
Okay so 3GPP picked SIP [2] as the protocol for setting up and tearing down multimedia sessions in the IP Multimedia Subsystem (IMS) 💖 The 3GPP Technical Specification 23.228 [28] describes the IMS. The 3GPP Technical Specification 24.228 [29] has a full set of session flows, and the 3GPP Technical Specification 24.229 [30] describes how the various IMS nodes use SIP 📋
This document is an effort to define the requirements for using the SIP protocol suite in cellular networks, especially in the 3GPP IMS for Release 5 of the 3GPP specs ✨ Later releases of the 3GPP specs might add more SIP requirements, but this one only focuses on what was identified for Release 5 IMS 🎀
Here's how the rest of the doc is set up 🧚
- Section 3 gives an overview of the 3GPP IMS. If you're new to it, read this part carefully 🫶
- Section 4 has the 3GPP requirements for SIP, grouped by category. Some requirements include statements about possible solutions that could meet them. Since one requirement might be met by different solutions, not all of those solutions will necessarily affect SIP 🌸
This document is advisory, which means its main job is to help the IETF understand the IMS environment 📚 With that better understanding, the IETF can hopefully evolve SIP more effectively 🌈 The IETF won't respond to these requirements point-for-point 🙈 Some requirements have been or will be met by extensions to SIP. Others might be handled by using existing SIP or other protocol features well, and individual members of the SIP community are expected to work with 3GPP to really understand those mechanisms 💅 Some of these requirements might never be addressed by the IETF at all, but writing them down and talking about them still helps everyone get a better big-picture understanding of the task 💜
2. Conventions 🌷
This document does not specify any protocol of any kind 🙅 So the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, as described in RFC 2119 [1], do not apply 💀
3. Overview of the 3GPP IMS ✨
okay so this section is basically a quick tour of the 3GPP IM CN Subsystem (IMS) 🎀. it's not the full deep dive, but it gives you enough to get why everything else makes sense. if you want the whole story, go read the 3GPP Technical Specifications 23.060 [27], 23.228 [28], and 24.228 [29] 📚
for a particular cellular device, the 3GPP IMS network gets split into a home network and a visited network 🌸
an IMS subscriber belongs to their home network. services get triggered and can be executed there 💖 the home network runs one or more SIP servers to support the IP Multimedia Subsystem, and one of them is a SIP serving proxy that also acts as a SIP registrar 👑 authentication/authorization servers may live in the home network too. users get authenticated right there at home 🫶
then there's the SIP outbound proxy, which exists to support the User Agent (UA) 🦋 it's typically in the visited network, though it can also be in the home network. it keeps security associations between itself and the terminals, and it interworks with the resource management in the packet network 🔥
the SIP outbound proxy gets assigned after the mobile device connects to the access network. once it's assigned, it doesn't change while the mobile stays connected to the access network. so the mobile can roam freely within the access network without any SIP outbound proxy reassignment 🧚
the home network may also support one or more SIP edge proxies 💅 these are the first entry points for SIP signaling into the home network, and they may figure out (with help from location servers) which SIP registrar server to assign to a particular user. typically the home network SIP edge proxy's address is configured in DNS as a DNS Naming Authority Pointer (NAPTR) and Service (SRV) records for SIP 🌈
also, the home and visited networks may deploy a SIP-hiding proxy if they need one. the main job of the SIP-hiding proxy is to hide the network configuration 🙈
the 3GPP IM CN Subsystem is designed to be access independent ✨ access is granted from 3GPP cellular terminals or from other terminals using other accesses that are outside the scope of 3GPP 🌸
3GPP cellular IP Multimedia terminals use the existing General Packet Radio Service (GPRS) [27] as the transport network for IP datagrams 💜 the terminals first connect to the GPRS network to get an IPv6 prefix. to do that, the terminals must perform a GPRS Attach procedure followed by a GPRS PDP Context Activation procedure. these GPRS procedures are required to be completed before any IP Multimedia session can be established 😭
so once those GPRS procedures are done, the terminal has built an IPv6 address 🎀 that address belongs to the same network address space as the SIP outbound proxy. and it doesn't change while the mobile terminal moves around and stays attached to that same network address space 🦋
but if the terminal moves from one GPRS access to another GPRS access, the GPRS procedures have to start from the beginning so it can get an IPv6 address allocated 💀
here's Figure 1, the overview of the 3GPP architecture for the IM CN Subsystem 🍓
+-------------+ +----------------+ +----------------+
| | | | | +------+ |
| | | | | | SIP | |
| | | | | |server| |
| | | | | | +------+ |
+-|+ | | | | | / |
| | | | | +------+ | | +------+ |
| | | | | | SIP | | | | SIP | |
| | ---|-------------|--|----|server|----|---|-|server| |
+--+ | | | +------+ | | +------+ |
| | | | | |
SIP | GPRS access | | Visited Network| | Home Network |
dev. +-------------+ +----------------+ +----------------+
Figure 1: Overview of the 3GPP IMS architectureanother possible future setup is in Figure 2 🧚 here, a general-purpose computer (like a laptop) is connected to a GPRS terminal. the computer hosts the Multimedia application (SIP, SDP, RTP, etc.), and the GPRS terminal handles the radio access and the GPRS connectivity. the home network isn't drawn in this one, just so the example stays clear 💅
+-------------+ +----------------+
+-------+ | | | | |
| | +-|+ | | | |
| | | | | | | +------+ |
+-------+ | | | | | | SIP | |
/ / --------| | ---|-------------|-------|server|------
/-------/ +--+ | | | +------+ |
| | | |
SIP GPRS | GPRS access | | Visited Network|
client terminal +-------------+ +----------------+
Figure 2: A computer connected to a GPRS terminalservices are typically executed in an application server 🍓 the interface between the SIP server and the application server is based on SIP. still, some operators may want to reuse their existing technology, so they may need to get SIP working with protocols like CAMEL/Intelligent-Network or Open Services Architecture (OSA) 🫶
4. 3GPP Requirements on SIP 💖
4.1. General Requirements 🌸
this section doesn't specify any particular requirement for SIP 🙈 what it does have is a list of general requirements that must be considered when you're developing solutions for particular requirements 💅
4.1.1. Efficient Use of the Radio Interface 📡
the radio interface is a scarce resource 😭 so the exchange of signaling messages between the mobile terminal and the network should be minimized. every mechanism developed should make efficient use of the radio interface ✨
see also the related requirements in Section 4.4.
4.1.2. Minimum Session Setup Time ⏱️
all the procedures and mechanisms should have a minimum impact on the session setup time as the user perceives it 🦋 when there's a choice between doing tasks at session establishment or before session establishment, the tasks should be done before session establishment 🔥
see also the related requirements in Section 4.4.
4.1.3. Minimum Support Required in the Terminal 🔋
terminals could be pretty small devices, so memory requirements, power consumption, processing power, etc., should be kept to a minimum 🧸 mandating support for additional protocols in the terminal must meet this requirement 🎀
4.1.4. Roaming and Non-roaming 🌍
all the requirements must be met for both roaming and non-roaming scenarios 💜 there should not be a significant change in the signaling procedures between roaming and non-roaming scenarios 👑
4.1.5. Terminal Mobility Management 🚶♀️
terminal mobility is managed by the access network, so there's no need to support terminal mobility management in SIP 🧚
4.1.6. IP Version 6 🌐
3GPP IMS is solely designed to use IP version 6 💅 as a consequence, all protocols must support IPv6 addresses 🫶
4.2. SIP Outbound Proxy 🦋
4.2.1. SIP Outbound Proxy ✨
a SIP outbound proxy is provided to support both roaming and non-roaming scenarios 💖 the SIP outbound proxy may be located either in the home network or in the visited network 🌸
4.2.2. Discovery of the SIP Outbound Proxy 🔍
there must be a general mechanism whereby the mobile device (UA) learns the SIP outbound proxy address 🎀
the DHCPv6 option for SIP servers in RFC 3319 [19] seems to fulfill the requirement 🌈
on top of the above requirement, the 3GPP access network may provide the SIP outbound proxy address during access network bearer establishment 🙈 this is considered a less general mechanism, though 💀
4.3. Registration 📝
the home network must maintain one or more SIP registrars 👑 the SIP registrar authenticates the user and registers the IP address where the user can be located 💜
once the terminal is switched on, the mobile device UA reads its configuration data 📱 this data may be stored in a SIM card or in any other memory device. the configuration data contains an identification of the home network. the device finds the SIP registrar address from the home network domain name 🧚 the terminal sends the registration through the SIP outbound proxy 🦋
to help search for the registrar, the home network contains one or more SIP servers that may be configured in DNS with the NAPTR/SRV record of SIP 🍓 these are the home network edge proxies. their mission is to serve as the first points of contact in the home network, and to decide (with help from location servers) which SIP registrar server to assign to a particular user 💅
the procedures specified in RFC 3263 [10] applied to a REGISTER message seem to be sufficient to meet this requirement 🫶
4.3.1. Registration Required 🔐
a user must register to the IMS before they can receive any invitation to any sessions 😭 it's also desirable for the user to register before starting any sessions 💖 the following factors are the rationale behind this:
- The SIP serving proxy in the home network needs to know when and from which terminal the user is available, so it can route received SIP requests for sessions and services 👑
- The user can be pre-authenticated early so that authentication does not contribute to post-dial delay. The procedure should not have a penalty on the session setup time (see also the requirement stated in Section 4.1.2) 🌸
- The user is assigned a particular serving proxy. The serving proxy downloads the service profile for that user to trigger services 🎀
so, 3GPP has mandated the mobile device UA to register before the mobile device UA initiates any session 🙈
4.3.2. Efficient Registration 🌙
because the radio interface is a scarce resource, a single registration must be sufficient to ensure that the mobile UA is reachable from both the home and the visited networks 🦋
a single REGISTER message, addressed to the registrar, may traverse the SIP outbound proxy 🧚 this can install, if needed, soft registration states in the SIP outbound proxy ✨
4.3.3. Registration for Roaming and Non-roaming Cases 🌍
whether or not the UA is roaming, it's desirable for the registration procedure to be the same 💜
4.3.4. Visited Domain Name 🏠
the home network must be able to validate the existence of a roaming agreement between the home and the visited network 🫶 the home network needs to validate that the user is allowed to roam to that visited network. so there must be a mechanism whereby the visited network identity is known at registration time at the home network 💅
it's acceptable to represent the visited network identity either as a visited network domain name or as a string 🌈
4.3.5. De-registration 🌸
4.3.5.1. De-registration of Users ✨
okay so there must be a procedure that lets a user de-register from the network 🫶 this could come in handy when someone switches off their terminal 📴
we think a REGISTER with an expiration timer of 0 gets the job done 💖
4.3.5.2. Network-initiated De-registration or Re-registration 🦋
sometimes a network needs to de-register a UA that's already registered, or ask it to re-register 😭 sections 4.3.6.3, 4.3.6.4, and 4.3.6.5 show examples of when this happens 👀
that means the UA needs a way to be told about the de-registration or the re-registration request 🔔
we think the SIP-specific event notification [12] plus a registration event package [14] handles this 🫶
4.3.5.3. Network-initiated De-registration, Network Maintenance 🛠️
there might be times when the SIP serving proxy has to shut down, like for maintenance 🔧 it's not super likely in everyday life 🙈 but it's still desirable to have a mechanism that tells the UA its current registration is being cancelled 📢 the UA may start another registration, which leads to picking a new SIP serving proxy 🧚
4.3.5.4. Network-initiated De-registration, Network/Traffic Determined 🌐
the system must support a mechanism that avoids inconsistent information storage and clears out any redundant registration info 🧹 this happens when a subscriber roams to a different network without de-registering first 🌍 it also shows up in normal mobility, when a user moves from one access network to another, or when new service conditions get imposed on roamers ✈️
4.3.5.5. Network-initiated De-registration, Administrative 🗝️
for different reasons (like subscription termination, a stolen terminal, etc.), a home network administrative function might decide it needs to clear a user's SIP registration 🚫 it's desirable to have a mechanism where the SIP serving proxy can tell the UA that its registration is being cancelled 📢
there must be a procedure for the SIP serving proxy to de-register users 💅 the de-registration information must be available at all the proxies that keep registration state, and at the UA 🫶
we think a procedure based on SIP-specific event notification [12] and a registration event package [14] will meet this requirement ✨
4.4. SIP Compression 📡
the radio interface is a scarce resource, and the bandwidth over it is usually limited 📉 those two things together make it hard to send possibly large SIP messages over the air interface 😩 session setup time can stretch out because it takes so long to push SIP messages through a skinny channel 🐢
on the flip side, the number and size of certain SIP header values, like Via or Record-Route, don't seem to be limited 📈 and a mobile device UA might not have much memory to store that kind of info 📱
so there must be a mechanism to move SIP signaling packets over the radio interface efficiently 🚀 by compressing the SIP messages between the mobile device UA and the SIP outbound proxy, and between the SIP outbound proxy and the mobile device UA 🗜️ compressing the IP and transport layer protocol headers that carry these SIP messages is also a requirement, although we believe that doesn't really affect SIP 🤷
4.4.1. Compression Algorithm Independence 🧩
the chosen solution(s) must be able to work under several different compression algorithms 🎨
4.4.2. Extensibility of the SIP Compression 🧱
the chosen solution(s) must be extensible, so new and improved compression algorithms can be added in a backward-compatible way as they become available 🆕
4.4.3. Minimal Impact of SIP Compression on the Network 🌱
application-specific compression must minimize impacts on existing 3GPP access networks (such as base station transceivers 📶) on the other hand, the compression mechanism should be independent of the access, e.g., the compression must be defined between the mobile device UA and the outbound SIP proxy 🤝
4.4.4. Optionality of SIP Compression 🎛️
it must be possible to leave the usage of compression for SIP signaling optional 🙌 to help a mobile terminal roam between networks that use compression, the mobile terminal should always support SIP signaling compression 📶 if compression isn't supported, communication may continue without it, depending on the local policy of the visited network 🗺️
4.4.4.1. Compression Reliability 🛡️
the compression mechanism should be reliable and able to recover automatically from errors generated during decompression 🔁
4.5. QoS Requirements Related to SIP 🎯
4.5.1. Independence between QoS Signaling and SIP 🧠
the selection of QoS signaling and resource allocation schemes must be independent of the selected session control protocols 🙅 this lets QoS control and SIP evolve independently 🦋
4.5.2. Coordination between SIP and QoS/Resource Allocation 🤝
4.5.2.1. Allocation before Alerting ⏰
in establishing a SIP session, it must be possible for an application to request that the resources needed for bearer establishment are successfully allocated before the destination user is alerted 🔔 but it must also be possible for an SIP application in a terminal to alert the user before the radio resources are established (for example, if the user wants to join the media negotiation) 🎙️
we think Integration of Resource Management and SIP [15] meets this requirement ✨
4.5.2.2. Destination User Participates in the Bearer Negotiation 🗳️
in establishing a SIP session, it must be possible for a terminating application to let the destination user take part in deciding which bearers get established 💜 but it must be possible to establish the SIP session without user intervention 🙏
we think the standard SDP negotiation described in SIP [2], the SDP offer/answer model [11], and the extensions described in Integration of Resource Management and SIP covers this 💅
4.5.2.3. Successful Bearer Establishment 🏁
successful bearer establishment must include the completion of any required end-to-end QoS signaling, negotiation, and resource allocation 💯
we think the procedures described in Integration of Resource Management and SIP [15] meet this requirement 🫶
4.6. Prevention of Theft of Service 🕵️
typically, users are allocated QoS resources 🎟️ there's an admission control mechanism that stops users from going past the limits negotiated with the network 🚧 the network must stop unauthorized users from using non-authorized resources 🙅♀️ for instance, the network must provide a mechanism that stops a user from using the resources allocated to a second user, the one who might be paying for them 💸
we think this requirement may be met by the procedures described in the Private SIP extensions for Media Authorization [16] 🫶
4.7. Radio Resource Authorization 📻
radio resources are super valuable, so the network must be able to manage them in a controlled way 👑 the network must be able to identify who is using these resources and authorize their usage 🪪 for example, a mobile device terminal could run an unlimited and uncontrolled resource reservation procedure if the network doesn't supervise how radio resources are used 😬
we think this requirement is met by the procedures described in the Private SIP extensions for Media Authorization [16] ✨
4.8. Prevention of Malicious Usage 😈
the 3GPP IMS must stop mobile devices from making malicious use of the network 🚫 for instance, a malicious UA could ignore the procedures related to the Record-Route header field 🙈 when sending subsequent requests, the UA could skip proxies that inserted a Record-Route header during the initial transaction 🏃♀️
4.9. Prevention of Denial of Service 🛑
the risk that a proxy receives a denial of service attack should be minimized 🛡️ for instance, a malicious mobile device could learn a SIP proxy IP address and port number (for example, from a Record-Route header value) and launch an attack on that proxy 💀
4.10. Identification of Users 🪪
4.10.1. Private User Identity 🔐
in order to use the 3GPP IMS, a user is assigned a private user identity 🎀 the home network operator assigns it, and it's used to identify the user uniquely from a network perspective 🌐 the private user identity is used for things like authentication, authorization, administration, and possibly accounting 📚 note that the private user identity is not used for routing of SIP messages 🚫
the private user identity is a unique global identity defined by the Home Network Operator 🌍 it takes the form of a Network Access Identifier (NAI) as defined in RFC 2486 [6] 🧾
the end user doesn't have access to the private user identity 🙈 it's typically stored on a Subscriber Identity Module card 💳
the private user identity is permanently allocated to a user (it isn't a dynamic identity) and it's valid for the duration of the user's business subscription with the home network 📅
4.10.1.1. Private User ID in Registrations 📝
the mobile UA must deliver the private user identity to the SIP outbound proxy and the registrar at registration time 📤
the private user identity is used as the basis for authentication during registration of the mobile user 🔑 in this document, the term authentication has the same meaning it has in RFC 2828 [7] 📖
we think this requirement is met by populating the username field of the Authorization: header value of the REGISTER request with the private user identity ✨
4.10.2. Public User Identities 🌟
in order to use the 3GPP IMS, a user is assigned one or more public user identities 🎟️ the user makes use of these when requesting communication with other users 📞 for example, a public user identity might be printed on a business card 💼
different public user identities can be grouped into a user profile 🗂️ a user may have different profiles, each one containing different public user identities 🧩 a public user identity can be part of a single user profile 🫶
the user may need to register one or more public user identities before receiving communications addressed to that public user identity 📬
we think this requirement is met by populating the From: and To: header values of a REGISTER message with the public user identity 💖
4.10.2.1. Format of the Public User Identities 💌
the public user identity must take the form of a SIP URI (as defined in RFC 3261 [2] and RFC 2396 [4]) or of a E.164 [34] number 🔢
we think this requirement is met by using SIP URLs and telephone numbers represented in SIP URLs, as described in SIP [3] 🌸 in addition, tel: URLs as specified in RFC 3966 [35] can be used to fulfill the requirement 🦋
4.10.2.2. Registration of Public User IDs ✨
okay so this one is about a user who has more than one public identity that belongs to the same user profile 🦋 It must be possible to register globally (i.e., through one single UA request) that user, via a mechanism within the IMS. In this case, the user will be registered with all the public identities associated to a user profile 💅
We believe this requirement may be accomplished by external procedures. For example, the user's profile may contain a list of alias identities that the registrar considers active if the primary identity is registered. The user may get informed of the automatically registered public user IDs by subscribing to its own registration state 🌸
4.10.2.3. Authentication of the public user ID 🔐
Public user identities are not authenticated by the 3GPP IMS. However, the network authorizes that the public user identity is associated with the registered private user identity. It's giving "trust but verify," but make it network-level 🙈
There is a list of public user identities associated with each private user ID within the IMS. IMS will reject attempts to use other public identities with this private user ID. So no sneaking in a different identity on the same private ID, periodt 💀
4.10.3. Delivery of the Dialed Public User ID 📞
Typically a UA will be registered under a set of different public user IDs. As such, sessions destined to the user can be placed with any of the registered public user IDs. The serving proxy and application server(s) in the termination network may apply certain filtering rules or services based on the public user ID contained in the Request-URI. The UA may also apply certain filtering rules or services based on the called public user ID 🧚
Therefore, it must be possible for all sessions to deliver the dialed public user ID to the terminating entities, such as the serving proxy, application servers, and terminating UA. The dialed ID needs to make it all the way to the end, no drops 🎀
4.11. Identifiers Used for Routing 🛣️
Routing of SIP signaling within IMS must use SIP URLs as defined in SIP [2]. E.164 [34] format public user identities must not be used for routing within IMS, and session requests based on E.164 format public user identities will require conversion into SIP URI format for internal IMS usage. Plain E.164 numbers are a no-go for routing, lowkey 🙅♀️
We believe that this requirement is achieved by translating E.164 numbers into SIP URIs. A database, such as ENUM [9], might do the job ✨
4.12. Hiding Requirements 🫥
Although the requirements included in this section are not optional, the hiding feature is optional to use through configuration. This means that a network operator can, at his desire, switch the hiding functionality on or off. The requirements are non-negotiable but the hiding itself is a toggle, so it's giving flexible but still firm 💜
4.12.1. Hiding of the Network Structure 🪞
A network operator need not be required to reveal the internal network structure to another network (in Via, Route, or other headers) that may contain indication of the number of SIP proxies, domain name of the SIP proxies, capabilities of the SIP proxies, or capacity of the network. Operators don't have to spill their internal tea 🍵
4.12.2. Hiding of IP Addresses 🙊
A network need not be required to expose the explicit IP addresses of the nodes within the network (excluding firewalls and border gateways). Internal IPs can stay private, bestie 🤫
4.12.3. SIP Hiding Proxy 🛡️
In order to support the hiding requirements, a SIP hiding proxy may be included in the SIP signaling path. This additional proxy may be used to shield the internal structure of a network from other networks. Basically a bouncer for your network's secrets 💅
4.13. Cell-ID 📍
The identity of the cell through which the 3GPP UA is accessing the IMS (Cell-ID) may be used by the home network to provide localized services or information on the location of the terminal during an emergency call (when emergency calls are handled in IMS; see also the requirement stated in Section 4.16). So the Cell-ID can help with localized stuff and emergency location, but only if emergency calls are handled in IMS 🚨
4.13.1. Cell-ID in Signaling from the UA to the Visited and Home Networks 📡
Assuming that the Cell-ID is obtained by the UA by other mechanisms outside the scope of SIP, the Cell-ID must be transported at least in the following procedures:
- Registration
- Session Establishment (Mobile Originated)
- Session Establishment (Mobile Terminated)
- Session Release
The Cell-ID is private information and only of interest in the UA home network. Therefore, the Cell-ID should be removed prior to sending the SIP signaling beyond the originating home network. Keep it in the house, it's private info 🔒
4.13.2. Format of the Cell-ID 🔢
The cell-ID must be sent in any of the formats described in the 3GPP Technical Specification 23.003 [26]. Format check, all good 💖
4.14. Release of Sessions 📴
In addition to the normal mechanisms for releasing a SIP session (e.g., BYE), two cases are considered in this section: the ungraceful session release (e.g., the terminal moves to an out-of-coverage zone) and the graceful session release ordered by the network (e.g., prepaid caller runs out of credit). Two different kinds of goodbye, both need handling 👋
We believe that this requirement is met by a SIP entity acting as a so-called transparent back-to-back UA. ✨
4.14.1. Ungraceful Session Release 💥
If an ungraceful session termination occurs (e.g., a flat battery or a mobile leaves coverage), when a call stateful SIP proxy server (such as the SIP serving proxy at home) is involved in a session, memory leaks and, eventually, server failure can occur due to hanging state machines. To ensure stable server operation and carrier grade service, a mechanism to handle the ungraceful session termination issue must be provided. We assume that there is a mechanism by which the SIP outbound proxy is notified, by a mechanism external to SIP, of the ungraceful session termination. This allows transforming the ungraceful session release into a graceful session release ordered by the network (see the next section). For example, upon reception of the notification of loss of mobile radio coverage, the SIP outbound proxy could send a BYE request on behalf of the terminal, although this BYE cannot be authenticated. Hanging state machines are the worst, so the network cleans up after the dropped call 🧹
4.14.2. Graceful Session Release 🎟️
There must be a mechanism whereby an entity in the network may order the release of resources to other entities. This may be used, for example, in prepaid calls when the user runs out of credit.
This release must not involve any request to the UA to send out a release request (BYE), as the UA might not follow this request. The receiving entity needs the guarantee that resources are released when requested by the ordering entity. The network doesn't ask the UA nicely, it just makes it happen 💅
The following objectives must be met:
- Accurately report the termination to the charging subsystem.
- Release the associated network resources: bearer resources and signaling resources.
- Notify other parties to the session, if any, of the session termination.
When feasible, this mechanism should be at the SIP protocol level in order to guarantee access independence for the system. 🌈
4.15. Routing of SIP Messages 🗺️
4.15.1. SIP Outbound Proxy 📤
The 3GPP architecture includes a SIP outbound proxy that is typically located in the visited network (although it may be located in the home network). This outbound proxy provides local services such as compression of SIP messages or security functions. In addition, the outbound proxy may interact with the media reservation mechanism to provide authentication and authorization support for media reservation.
All mobile terminal originated session setup attempts must transit the outbound proxy so that the services provided by the outbound proxy can be delivered to the mobile terminal. Every outgoing call goes through the outbound proxy, no skipping the line 🙋♀️
4.15.2. SIP Serving Proxy in the Home Network 🏠
The serving proxy in the home network allows triggering of user-customized services that are typically executed in an application server.
All mobile terminal originated session setup attempts must transit the serving proxy in the home network so that the proxy can properly trigger the SIP services allocated to the user (e.g., speed dial substitution). This implies a requirement for some sort of source-routing mechanism to ensure these proxies are transited correctly. Source routing is doing the heavy lifting here 🧭
4.15.3. INVITE Might Follow a Different Path than REGISTER 🛤️
The path taken by an INVITE request need not be restricted to the specific path taken by a mobile terminal originated REGISTER request; e.g., the INVITE may traverse just the SIP outbound proxy and the SIP serving proxy, without passing through any other proxies. However, the path taken by the INVITE may follow the same path taken by the REGISTER. Different path for INVITE, same path if you want, your call 💁♀️
4.15.4. SIP Inbound Proxy 📥
The visited network may apply certain services and policies to incoming sessions (such as establishment of security services or interaction with the media reservation mechanism). Therefore, the visited network may contain a SIP inbound proxy for terminating sessions. In general, the SIP inbound proxy and the SIP outbound proxy are the same SIP proxy. Usually one proxy does both jobs, iykyk 🫶
4.15.5. Distribution of the Source Routing Set of Proxies 🗂️
Sections 4.15.2 and 4.15.4 assume that a source-routing mechanism is used to effect traversal of the required SIP proxies during session setup.
There must be some means of dynamically informing the node that adds the source-routing set of proxies that the INVITE has to traverse (e.g., the outbound proxy or serving proxy) of what that set of proxies should be.
The hiding requirements expressed in Section 4.12 also apply to the said set of proxies. The hiding rules follow the proxy list too 🙈
4.16. Emergency Sessions 🚑
3GPP networks already contain alternative procedures for delivering emergency sessions. Release 5 of the 3GPP specifications does not add any requirement for SIP emergency sessions. Emergency calls already have their own lane, so no extra SIP rules here 💀
4.17. Identities Used for Session Establishment 🪪
4.17.1. Remote Party Identification Presentation 📇
It must be possible to present to the caller the identity of the party to which he/she may dial back to return a call.
We believe that this requirement is met by the procedures described in RFC 3325 [17]. 💖
4.17.2. Remote Party Identification Privacy 🕶️
In addition to the previous requirement, the called party must be able to request that his/her identity not be revealed to the caller.
We believe that this requirement is met by the procedures described in RFC 3323 [18]. The callee can keep it on the down-low 🤫
4.17.3. Remote Party Identification Blocking 🚫
Regulatory agencies, as well as subscribers, may require the ability of callers to block the display of their caller identification. The destination subscriber's SIP serving proxy may be perform this function. In this way, the destination subscriber is still able to do a session-return, session-trace, transfer, or any other supplementary service.
Therefore, it must be possible that the caller request to block the display of his/her identity on the callee's display.
We believe that this requirement is met by the procedures described in RFC 3323 [18]. Caller ID blocking, but the callee still gets all the features 📵
4.17.4. Anonymity 🎭
Procedures are required for anonymous session establishment. However, sessions are not intended to be anonymous to the originating or terminating network operators.
We believe that this requirement is met by the procedures described in RFC 3323 [18] and RFC 3325 [17]. Anonymous to people, not to the network operators 👀
4.17.5. Anonymous Session Establishment 🥸
If the caller requests that the session be anonymous, the User Agent Client (UAC) must not reveal any identity information to the User Agent Server (UAS).
If the caller requests that the session be anonymous, the terminating network must not reveal any identity or signaling routing information to the destination endpoint. The terminating network should distinguish at least two cases: first, whether the caller intended the session to be anonymous, and second, whether the caller's identity was deleted by a transit network.
We believe that this requirement is met by the procedures described in RFC 3323 [18] and RFC 3325 [17]. Anonymous means anonymous, and the network has to know the difference between "the caller wanted this" and "a transit network stripped it" 🦋
4.18. Charging 💸
The 3GPP charging details live in the 3GPP Technical Specification 32.225 [31], so that's where to look if you want the full tea ☕.
4.18.1. Support of Both Prepaid and Postpaid Models
Operators get to pick prepaid, postpaid, or both 💅. Prepaid runs on online charging, and postpaid runs on offline charging.
Online charging is when the charging info can change the service the user gets in real time, like asking for a graceful release of a session that's already going. It's literally tangled up with the SIP signaling 🧵.
Offline charging is when the charging info does NOT touch the service in real time. Chill vibes 🌸.
4.18.2. Charging Correlation Levels
These are the levels of correlation for IMS charging that we're looking at:
- Correlation within a session 🎀: A session can have a bunch of media components inside it. You have to be able to correlate the charging data from all of those different media components that belong to the same session.
- Correlation at media-component level 🦋: If a session has several media types, like audio and video, charging data gets made for each media type and has to be correlated between network elements. The media identifier is unique and clearly tells you which media type of the session a given piece of charging info belongs to. This component identifier doesn't get swapped between network elements. It's based on the order of the media flows in the SDP, and that's the same order used in the binding info that gets passed to the GPRS network.
4.18.3. Charging Correlation Principles
To keep charging info correlated, these principles apply to both offline and online charging 🧠:
- Correlation for an IMS session is based on IMS Charging Identifiers (ICID) 🪪.
- The first IMS network entity in the SIP signaling path is the one that assigns an ICID 👑. That ICID then travels the whole session path end to end. This doesn't stop other elements along the path (other SIP proxies) from making extra identifiers and passing those along too 🌈.
- The ICID gets passed to every IMS network entity in the session signaling path, and it happens over SIP signaling 📡.
- The serving SIP proxy passes the addresses of the charging functions to every IMS network entity in the session signaling path. That gives all the charging records with the same ICID one common destination 🎯.
- For charging correlation between the GPRS network and the IMS, one or more GPRS Charging IDs get passed from the GPRS network to the IMS. These identify the PDP contexts of the session 🧚.
- The outbound SIP proxy passes the GPRS Charging IDs to the serving SIP proxy and the Application Servers, using SIP signaling. They are NOT transferred from one home IMS (like the caller's home) to another (like the callee's home) 🙅♀️.
- Inter Operator Identifiers (IOI) are shared between the caller's home IMS and the callee's home IMS. They give identifiers for the home originating and home terminating networks 🫶.
4.18.4. Collection of Session Detailed Information
The SIP serving proxy, or another SIP server in the home network, has to be able to log the details of all sessions, like duration, source, and destination, so they can be handed over to the charging subsystem 📒.
4.19. General Support of Additional Capabilities ✨
4.19.1. Additional Capabilities
3GPP is into applying and using extra services, like the ones in SIP Call Control - Transfer [20], SIP Basic Call Flow Examples [21], SIP Public Switched Telephone Network (PSTN) Call Flows [22], and SIP service examples [23]. 3GPP isn't going to standardize those extra services, though. What it can do is make sure the capabilities that enable those services are granted in the network 🔓.
So we think the SIP REFER method [24] and the Replaces header [25] make a great pair to act as the enabler for the requirement above 🤝.
4.19.2. DTMF Signaling
Voice calls need to give a level of service that's similar to the existing circuit-based voice service 📞. That includes being able to use DTMF signaling, for example to drive interactive voice response systems like ticket sales lines and timetable info 🎫.
DTMF tones need to be transportable from the mobile terminal to target systems that might be in the PSTN, or to SIP-based solutions with no PSTN connection involved 🌍.
The DTMF signals might be needed for the whole call, just the first part, or from some later point on. Because of that, when the signaling starts and how long it lasts is totally unpredictable 🎲.
We think the mechanisms specified in RFC 2833 [8] meet the requirement without messing with SIP 💖.
4.19.3. Early Media
Mobile terminals are going to interoperate with the PSTN a lot, so support for early media is required 📣.
4.20. Exchange of Session Description 📝
Usually SIP uses a session description protocol like SDP to describe the media streams and codecs needed to set up a session 🎶. SIP uses an offer/answer model for session descriptions, as described in RFC 3264 [11]. One party offers its session description, and the other one answers that offer 🤙.
In the 3GPP IMS, mobile terminals can have limits on memory, DSP capacity, and so on 🔋. Because of that, there needs to be a mechanism where the session description negotiation can end with one codec out of many for each media stream. Both the UAC and the UAS need to know which codec is being used for each media stream before any media gets sent or received 🎧.
Efficient use of network and radio resources is a big deal in the 3GPP IMS 📶. So the network should know in advance which codec is going to be used for a particular media stream. Network access control can use that info to grant access to the network and to control resource usage 🚦.
The party who pays for the resource usage also needs the chance to decide which codecs get used. That only works once both ends know the capabilities supported at the remote UA 💸.
So there needs to be a mechanism where both the UAC and the UAS can negotiate and trim down the number of codecs used per media stream. By the end of the negotiation, each media stream has a reduced set of agreed codecs ✂️.
We think the mechanism specified in RFC 3264 [11] meets the requirement 💜.
4.21. Prohibition of Certain SDP Parameters 🚫
4.21.1. Prohibition of Codecs
The SIP outbound proxy can have local policy rules about which codecs are allowed in the network 📋. For instance, some networks might not allow high-bandwidth-consuming audio codecs 🙅.
There has to be a mechanism that lets the SIP outbound proxy reject a session establishment attempt when a codec is prohibited in the network because of local policy 🛑.
4.21.2. Prohibition of Media Types
Some users' subscriptions can include restrictions on certain media types 🎥. For example, a user might not be allowed to set up a video session 🙈.
The SIP serving proxy in the home network downloads the user profile, which holds the rules for these kinds of restrictions 🗂️.
As session establishment goes through the SIP serving proxy in the home network, the proxy can block an attempt to set up a session that includes a media type that isn't allowed for that user. So there has to be a mechanism that lets the SIP serving proxy reject a session establishment attempt when the session includes a forbidden media type 🚷.
4.22. Network-initiated Re-authentication 🔁
Network operators need to authenticate users so they get charged correctly for the services they use 🧾. The re-authentication that happens when the user initiates a message won't be enough for this, as explained below 🙃.
If the authentication period is set to a fairly low value so the user can't rack up huge charges between authentications, it can cause tons of unnecessary authentications for users who've mostly been inactive 😩. That also burns air interface resources that didn't need to be burned 🔥.
If the authentication period is set to a fairly high value to avoid all those unnecessary authentications, then some users can end up running up high charges between authentications 💀.
A user's authentication gets automatically invalidated once a certain threshold is hit (for charges, number of events, or duration of sessions) and the user never got a chance to re-authenticate, even if a valid registration exists. That's not an adequate level of service 🙅♀️.
So it has to be possible for the network to start a re-authentication process at any time 🌟. The triggers get set within the network and can include charging thresholds, number of events, session duration, and so on ⏱️.
4.23. Security Model 🔐
Sections 4.23, 4.24, and 4.25 are based on the 3GPP Technical Specifications 33.203 [32], 23.228 [28], and 33.210 [33] 📚.
The scope of security for the 3GPP IMS is the SIP signaling between the various SIP entities 🗝️. Protecting the end-to-end media streams might be a future extension, but it isn't considered in the Release 5 version of the IMS specifications 🔮.
Each operator providing IMS services acts as its own domain of trust. It also shares a long-term security association with its subscribers, like pre-shared keys 🤍. Operators can sign roaming agreements with other operators, and then there's a certain level of trust between their domains 🤝.
SIP UAs have to authenticate to their home network before they're allowed to use IMS resources 🪪. In Release 5 of the 3GPP IMS specifications, authentication happens during registration and re-registrations 📝.
Portions of the SIP signaling have to be protected hop by hop 🛡️. If you look at Figure 1 in Section 3, you can spot two distinct zones where the required security is unique 👀:
- Access Domain: Between the SIP user device and the visited network 📱.
- Network Domain: Between the visited and home networks, or inside the home network 🏠.
The Access Domain and the Network Domain need really different things because of the terminal's needs for mobility, computation limits, battery life, bandwidth conservation, and the radio interface 🔋. SIP entities in the access domain should be able to keep security contexts with a big group of users in parallel 👯. The Access Domain gives user-specific security associations, while the Network Domain gives security associations between network nodes 🧩.
Heads up, bestie: because of all that, the weight of protocols and algorithms, and how well they work with compression mechanisms, matter a LOT for Access Domain Security 🚨. That's why the security solutions are required to allow different mechanisms in these two domains 🫶.
4.24. Access Domain Security 📶
4.24.1. General Requirements 🎀
4.24.1.1. Scalability and Efficiency 🌍
okay bestie, 3GPP IMS is giving massive energy 😭 it can have up to a billion users, and every single one of them must be treated in a secure way 🔐 no cap.
the security solutions must also allow global roaming across a huge number of administrative domains ✈️🧳 literally everywhere, periodt 💅
4.24.1.2. Bandwidth and Round-trips 📶
the wireless interface in 3GPP terminals is an expensive resource 💸 it eats power and uses up scarce spectrum, so it's not something to waste 🔋 on top of that, cellular networks usually have long round-trip time delays ⏳ and those have to be taken into account when designing the security solutions 🧠
any security mechanism that involves 3GPP terminals should not unnecessarily increase the bandwidth needs 📉
all security mechanisms that involve 3GPP terminals should minimize the number of necessary extra round-trips 🔁 especially during normal call signaling, there should not be any additional security-related messages 🤐 main character call setup only ✨
4.24.1.3. Computation 🧮
it must be possible for mobile device terminals to provide security without requiring public key cryptography and/or certificates 🙅♀️ 3GPP IMS may, however, include optional security schemes that use these techniques 🎀
current HTTP authentication methods only use symmetric cryptography, which is exactly what's required here 💜 lower-layer mechanisms (IKE, TLS) need public-key cryptography, e.g., Diffie-Hellman 🥲 if those lower-layer mechanisms were used, the mobile terminal would authenticate and negotiate session keys with the visited network using only symmetric methods 🦋 so it can still work without the heavy stuff ✨
4.24.1.4. Independence of the Transport Protocol 🚚
the selected security mechanism should work with any transport protocol allowed by SIP (e.g., TCP, UDP) 🫶 it shouldn't be picky about which road the packets take 🛣️
4.24.2. Authentication 🔐
okay so in this context, authentication means entity authentication 🪪 basically, two entities verify the identity of each other 👯♀️ iconic behavior
4.24.2.1. Authentication Method 🗝️
a strong, mutual authentication must be provided 💪 both sides have to prove who they are, no cap
the authentication method must be able to work when there are zero or more SIP proxies in the SIP path between the authenticator and the authenticated user 🧚 whether it's a direct line or a whole chain of proxies, it has to keep up 💅
it must be possible to support extensible authentication methods 🌈 so authentication using an extensible authentication framework is strongly recommended 🫧 future-proofing is so important bestie
authentication methods based on the secure storage of long-term keys used for authentication and the secure execution of authentication algorithms must be supported 🔑 those keys need to live somewhere safe and the algorithms need to run safely too 🛡️
the SIP client's credentials must not be transferred as plain text 🙈 absolutely not in plain text, that's a hard no 🚫
3GPP intends to reuse UMTS AKA [13] ✨ UMTS AKA applies a symmetric cryptographic scheme, provides mutual authentication, and is typically implemented on a so-called SIM card 📱 that gives secure storage on the user's side 🔒
additional requirements related to message protection that apply to the authentication method are stated in Section 4.24.3 📖 go check that one next
4.24.3. Message Protection 🛡️
4.24.3.1. Message Protection Mechanisms 🧱
SIP entities (typically a SIP client and a SIP proxy) must be able to communicate using integrity 🫡 by integrity, we mean the ability for the receiver of a message to verify that the message has not been modified in transit 👀 nobody messing with the message on the way
SIP entities should be able to communicate confidentially 🤫 in 3GPP IMS, these protection modes must be based on initial authentication 🔐 integrity protection and confidentiality must be possible using symmetric cryptographic keys 🗝️
it must also be possible to handle error conditions in a satisfactory manner so that recovery is allowed (see also sections 4.3.6.3 and 4.14) 🩹 things will go wrong, and we need a plan for it 🫠
it must be possible to provide this protection between two adjacent SIP entities 👭 in future network scenarios, it may also be necessary to provide this protection through proxies, though the 3GPP Release 5 IMS does not require this 🔮
the security mechanism must be able to protect a complete SIP message 📦 the whole thing, not just pieces 💖
if header compression/removal or SIP compression is applied to SIP messages, it must be compatible with message protection 🤝 compression and protection have to get along ✨
4.24.3.2. Delegation 🎁
3GPP IMS implements distributed security functions responsible for authentication and message protection 🧩 different parts handle different jobs 💅
it must be possible to perform an initial authentication based on long-term authentication credentials, followed by subsequent protected signaling that uses short-term authentication credentials 🔁 such as session keys created during that initial authentication 🗝️ the authentication mechanism used is able to provide such session keys 🌸 it must be possible to apply subsequent message protection as soon as possible, even during the initial authentication period ⏩ no waiting around 🙌
initial authentication is performed between the SIP UA and the authenticating SIP serving proxy in the home network 🏠 however, the authentication mechanism must not require access to the long-term authentication credentials in these nodes 🙅♀️ in the home network, the authenticating SIP serving proxy must support interaction with a dedicated authentication server to accomplish the authentication task 🤝 at the client side, a secured (tamper-resistant) device storing the long-term credentials of the user must perform the authentication 📱🔐
the long-term credentials stay on the tamper-resistant device, and the nodes in the network never need to touch them 🫢 that's the whole point 💜
additionally, the SIP serving proxy that performed the initial authentication must be able to delegate subsequent SIP signaling protection (e.g., session keys for integrity or encryption) securely to an authorized SIP proxy further downstream 🧚♀️ the tamper-resistant device at the client side must be able to delegate the session keys securely to the SIP UA 🎀 passing the baton safely 🏃♀️💨
4.24.4. Negotiation of Mechanisms 🤝
a method must be provided to negotiate the security mechanisms to be used in the access domain securely 🗣️ safe and sound 🔒
this method must at least support the negotiation of different security mechanisms providing integrity protection and encryption 🧁 along with the algorithms used within these mechanisms, and any additional parameters that they require in order to be exchanged 📬
the negotiation mechanism must protect against attackers who do not have access to authentication credentials 🕵️♀️ in particular, it must be able to detect a possible man-in-the-middle attacker who could influence the negotiation result so that services with weaker security, or with none at all, are negotiated 🚨 that's a huge red flag and we are not here for it 😤
a negotiation mechanism is generally required in all secure protocols to decide which security services to use and when they should be started 🗓️ this security mechanism serves algorithm and protocol development as well as interoperability 🧑🤝🧑 often, the negotiation is handled within a security service 🫧 for example, the HTTP authentication scheme includes a selection mechanism for choosing among appropriate algorithms 🍰 note that when we talk about negotiation, we mean just the negotiation, not all functions in protocols such as IKE 🙃 for instance, we expect that session key generation is to be a part of the initial authentication 🔑
SIP entities must be able to use the same security mode parameters to protect several SIP sessions without re-negotiation ♻️ for example, security mode parameters may be assumed to be valid within the lifetime of a registration 📝 note that it is necessary to amortize the cost of security association setup and parameter negotiation over several INVITEs 💸➡️📞 bestie, we don't want to redo the whole setup every single call 🙄
4.24.5. Verification of Messages ✅
4.24.5.1. Verification at the SIP Outbound Proxy 🚪
the SIP outbound proxy must be able to guarantee the message origin and to verify that the message has not been changed (e.g., it is integrity protected) 🕵️♀️ it's the bouncer at the door checking IDs 🪪
4.24.5.2. Verification at the SIP Serving Proxy 📡
the serving SIP proxy needs to receive an indication if the outbound proxy was able to verify the message origin 🔎 and, in the case of a REGISTER request, whether or not it was integrity protected 📮 it needs the receipts, bestie 🧾
4.25. Network Domain Security 🏰
message authentication, key agreement, integrity and replay protection, and confidentiality must be provided for communications between SIP network entities such as proxy servers 🫂 the whole squad needs protection 🛡️
network domain security mechanisms must be scalable up to a large number of network elements 📈 it has to grow without falling apart 🌱
3GPP intends to make having the protection discussed above mandatory at least between two operators 🤝 and optional within an operator's own network 🏡 security gateways exist between operators' networks 🚪🌉
we believe that the above requirements are fulfilled by applying security mechanisms as specified in the current IP Security standards in RFC 2401 [5] 🥰 that's the plan, and it's giving confidence 💖
5. Security Considerations 🚨
this document does not define a protocol, but it still presents some security requirements to protocols 📜 the main security requirements are stated in sections 4.23, 4.24, and 4.25 🔐 additional security-related issues are discussed under sections 4.6, 4.7, 4.8, 4.9, 4.10, and 4.12 👀 these are serious, so read them carefully and don't skip ahead 😭⚠️
6. Contributors 🫶
The following people contributed to this document:
Duncan Mills (Vodafone), Gabor Bajko (Nokia), Georg Mayer (Siemens), Francois-Xerome Derome (Alcatel), Hugh Shieh (AWS), Andrew Allen (dynamicsoft), Sunil Chotai (mmO2), Keith Drage (Lucent), Jayshree Bharatia (Nortel), Kevan Hobbis (Huthison 3G UK), Dean Willis (dynamicsoft), Krisztian Kiss (Nokia), Vesa Torvinen (Ericsson), Jari Arkko (Ericsson), and Sonia Garapaty (Nortel) 🎉👑
7. References 📚
7.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.
7.2. Informative References 📚✨
okay so this is the reading list bestie, and every single entry is staying exactly as written 🫶 These are the background docs the spec points at. Some are RFCs, some are 3GPP and ITU-T specs, and a couple are still drafts marked "Work in Progress" 🌸
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[7] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[8] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[13] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
[14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[15] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.
[16] Marshall, W., "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization", RFC 3313, January 2003.
[17] 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.
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[19] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", RFC 3319, July 2003.
[20] Sparks, R., "Session Initiation Protocol Call Control -
Transfer", Work in Progress, February 2005.
[21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[22] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Public Switched
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666,
December 2003.
[23] Johnston, A. and R. Sparks, "Session Initiation Protocol
Service Examples", Work in Progress, February 2005.
[24] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[25] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) 'Replaces' Header", RFC 3891, September 2004.
[26] 3GPP, "TS 23.003 Numbering, addressing and identification
(Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[27] 3GPP, "TS 23.060:General Packet Radio Service (GRPS); Service
Description; Stage 2", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.060/>.
[28] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) -
Release 5", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.228/>.
[29] 3GPP, "TS 24.228: Signaling flows for the IP Multimedia call
control based on SIP and SDP", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/24_series/24.228/>.
[30] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) -
Release 5", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[31] 3GPP, "TS 32.225: Telecommunication Management; Charging
Management; Charging Data Description for IP Multimedia
Subsystem; (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/32_series/32.225/>.
[32] 3GPP, "TS 32.203: 3G Security; Access security for IP based
services; (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/33_series/33.203/>.
[33] 3GPP, "TS 32.210: 3G Security; Network Domain Security; IP
network layer security (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/33_series/33.210/>.
[34] ITU-T, "Recommendation E.164 (05/97): The international public
telecommunication numbering plan", May 1997,
<http://www.itu.int/rec/recommendation.asp?
type=folders&lang=e&parent=T-REC-E.164>.
[35] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.Author's Address 🎀
the author is Miguel A. Garcia-Martin from Nokia, and here's how to reach them 💌
Miguel A. Garcia-Martin
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
EMail: miguel.an.garcia@nokia.comFull Copyright Statement 💜
the Internet Society owns the copyright for 2005 🌈 this document is covered by the rights, licenses and restrictions in BCP 78, and unless BCP 78 says otherwise, the authors keep all their rights.
the legal fine print, word for word 💅:
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.Intellectual Property 🦋
okay so the IETF is staying neutral here, bestie 🙈 it doesn't say whether any patents or other IP rights cover the tech in this doc, whether you'd be able to get a license for them, or whether it checked for any. You can find the rules for rights in RFC docs in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any license assurances, plus anything from attempts to get a general license for implementers or users. You can check the IETF online IPR repository at http://www.ietf.org/ipr ✨
And if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, please tell the IETF at ietf-ipr@ietf.org 🫶
Acknowledgement 🌸
the RFC Editor function is currently funded by the Internet Society. Thank you to them, periodt 👑
📦 where this page comes from
- ietf: rfc4083 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms