The IMS makes it mandatory for the establishment of IP Sec Security associations (SA) between the IMS UE and the Proxy CSCF. These security associations are set up during the two way handshake:

REGISTER , 401, REGISTER and 200 OK, which takes place during IMS registration and authentication procedures.

On the SIP level, there are three headers that are of importance for the setup of these security associations. These are the Security-client, Security-server and Security-verify headers.

As part of the SA establishment at the client side, there are two ports that are negotiated with the P-CSCF. These are the protected client port and the protected server port. When the UE sends the initial ‘unprotected’ REGISTER request to the P-CSCF, it is sent over the default port for SIP (5060). This initial REGISTER request contains the Security-client header which specifies the encryption algorithms that the UE supports, the security schema that the client supports and the parameters needed for SA setup.

This REGISTER request reaches the registrar (S-CSCF). The S-CSCF formulates an authentication challenge in the form of a 401 Unauthorized response back to the UE. This message contains the challenge parameters under the www-authenticate header. Additionally it also contains the Security-server header. The parameters received in this header are used by the UE to setup a temporary set of SAs. The lifetime of these SAs is set to the reg-await-auth timer.

Subsequently, the UE answers the challenge with another REGISTER request. This request contains the Security-verify header that mirrors the Security-server header of the 401 response received earlier. If the authentication answer is successful at the S-CSCF, a 200 ok is received. If the 200 ok is received, then the newly set of SAs are established between the UE and P-CSCF in place of the temporary SAs.

Thus, two protected ports each are negotiated between the UE and the P-CSCF for all subsequent signaling traffic.

Upon re-authentication by the UE, be sending another REGISTER refresh message, another set of SAs are established. The P-CSCF may or may not decide to keep the old set of SAs in lieu of the SAs established due to re-authentication.

To summarize, there are three types of Security Associations:

1) Newly established set of security associations: Two pairs of IPsec security associations that have been created at the UE and/or the P-CSCF after the 200 (OK) response to a REGISTER request was received.

2) Old set of security associations: Two pairs of IPsec security associations still in existence after another set of security associations has been established due to a successful authentication procedure (re-authentication).

3) Temporary set of security associations: Two pairs of IPsec security associations that have been created at the UE and/or the P-CSCF, after an authentication challenge within a 401 (Unauthorized) response to a REGISTER request was received. The SIP level lifetime of such created security associations will be equal to the value of reg-await-auth timer.

In these procedures, the UE first establishes the IP connectivity access network (IP-CAN) bearer. Then, the UE sends a query to the DHCP server for retreiving the IP addresses and FQDN (Fully Qualified Domain Name) of the P-CSCF. After the DHCP query, the UE performs a DNS query on the FQDN received from the DHCP server. In response to the DNS query, the IP address of the P-CSCF is returned. This is known as the DHCP-DNS procedure for P-CSCF discovery. However, in some cases, it may be possible that the FQDN of the P-CSCF is pre-configured in the UE. In these scenarios, the UE can directly query the DNS server and get the IP address of the P-CSCF.

Subsequent to P-CSCF discovery, the UE can send a SIP REGISTER request to register itself in the IMS core network. The P-CSCF sets up IPSec security associations with the UE, which are facilitated with the two-way registration handshake (i.e. REGISTER-401-REGISTER-200 OK). The IPSec security assocaiations (SAs) setup four protected ports between the UE and the P-CSCF and ensure that all subsequent signaling traffic passes through the protected ports. The four protected ports negotiated during IMS registration are: The protected server port at the P-CSCF, the protected server port at the UE, the protected client port at the P-CSCF and the protected client port at the UE. The Protected client ports are used by the UE and P-CSCF to send requests while the server ports are used to receive incoming requests. IMS registration will be discussed seperately in another post.

The P-CSCF also translates the SDP body contained in the SIP INVITE message from the UE into DIAMETER over the Rx interface and sends it to the PCRF. The PCRF is responsible for policy control in the IMS core network. If the SDP offer contains a codec or any other media characteristics that are not allowed as per the policies of the IMS operator, the operator can choose to disallow that session setup.

Subsequent posts will dicuss the P-CSCF and PCRF interaction in more detail.

The IMS architectural view is given in the figure as under:

The Call Session Control Function is divided into three logical verticals:

a) Proxy CSCF (P-CSCF)

b) Interrogating CSCF (I-CSCF), and..

c) Serving CSCF (S-CSCF).

The P-CSCF acts as the entry point in the IMS core network. All UE’s (User Equipment) in the IMS are attached to the Proxy CSCF. The P-CSCF may be in the home domain or in the visited domain. The P-CSCF is responsible for routing incoming SIP messages to the IMS registrar server and for facilitating policy control over the Rx interface towards the PCRF (Policy and Charging Rules Function). The P-CSCF is also responsible for setting up IPSec Security associations with the UEs, thus ensuring secure access to the IMS core.

The I-CSCF acts as an inbound SIP proxy server in the IMS. During IMS registrations, the I-CSCF queries the HSS to select the appropriate S-CSCF which can serve the UE. During IMS sessions, the I-CSCF acts as the entry point to terminating session requests. The I-CSCF routes the incoming session requests to the S-CSCF of the called party. The role of the I-CSCF in the IMS core network is minimal. However, its property of S-CSCF selection can be utilized for load sharing amongst multiple S-CSCF nodes in the IMS core.

The S-CSCF is the heart of the IMS core network. The S-CSCF acts as a registrar server, and in some cases as a redirect server. It is the central point for IMS service control over the ISC reference point. Moreover, the S-CSCF facilitates the routing path for mobile originated or mobile terminated session requests. The S-CSCF is the most processing intensive node of the IMS core network due to its initial filter criteria processing logic which enables IMS service control. It also interacts with the Media Resource Function over the Mr interface for playing tones and announcements.

With the advent of IMS, comes the concept of access independence. Various 3G/3.5G access technologies can be directly plugged into a common IMS core network. A simplified view of the IMS architecture is shown in the figure below.

May it be WiMax or WiFi access, or fixed broadband access, the IMS core network serves as a common ‘glue’ layer for access aggregation. This is a significant value proposition for network operators, as they need to invest in the core network infrastructure only once. This is unlike the current scenario of legacy networks, where a GSM operator has to invest seperately if he wishes to roll out a CDMA2000 network for example.

As shown in the figure, the IMS core network has an application layer which consists of various application server hosting IMS services. The IMS application layer consists of SIP-Application servers  and other service delivery platforms.

The IMS-era promises to revolutionize the telco industry. For network operators, it generates new revenue generation streams by enabling them to provide newer, richer and personalized services to the end user. From the perspective of the customer, IMS offers an unparalleled customer experience and a greater choice of services. IMS thus offers a win-win situation for all.

This blog is dedicated to the IP Multimedia Subsystem and its related technologies. In the coming days, I will be coming up with some introductory posts explaining what IMS is and what makes it special. Subsequently, I will move into the specifics of IMS, starting from the basics and then moving to the core concepts. These technical posts will be punctuated with some market news-bits and the latest buzz of the telco domain.

I hope the readers will like what they see at the IMS Jungle ! For a more detailed explanation about this blog and it’s scope..i suggest that you read this page:

ABOUT THE IMS JUNGLE..

I hope you will keep visiting !

The IMS Jungle guy !