Much Ado about Registration

Registration is something what was missing in the times of wires. Ok, not completely but it was done more or less once when an MSISDN was assigned to some line.

IMS Registration

In contrast to the previous types of the networks the 4G network is ‘user-centric’. It means the user can use multiple devices and identities and we have to deal with it. The main purpose of the registration is to create a binding between user (her public identity) and IP address of the device, so we know where we can send the data to. That’s why there is a Contact header in the SIP REGISTER message. The Contact header contains an address which identifies the current location of the user (Point-of-Presence – e.g. IP/FQDN of a particular client). During the registration is the Contact Address is linked to a Public Identity (IMPU, AOR in SIP terminology). The IMPU is an equivalent to MSISDN in GSM and has to be present in the To header of the SIP REGISTER. One identity can by used by more terminals and as each terminal can have different capabilities this has to be also taken into account. This information is part of the Contact header.

Contact: <sip:119560022547@152.67.235.234:49635;transport=tcp>;
   expires=3200;
   +g.oma.sip-im;
   language="en,fr";
   +u.asmc.apn="6a6044869e2aba3d23d4cfc0ef1384d00da28854c2408ddbbf";
   +sip.instance="<urn:uuid:D4196919-ED8A-4E00-9436-B9CDD1E76813>"

 

The next reason why registration is important in mobile networks is that we have to authenticate users. In contrast to 2/3G networks the user can access the network also via IP-Network (VoWifi, Internet). And last but not least registration can also trigger some other actions.

IMS Registration – access networks

To get properly registered in IMS network is a bit like doing a treasure hunt. Firstly the client (UE) has to know the IP address of P-CSCF (SBC). This address can be either obtained from DNS or preconfigured, provided (DHCP+DNS) by the access network (see 3GPP 24.229). In case of VoLTE the IR.92 says that the P-CSCF address is provided by PDN in the response to Protocol Configuration Options (PCO) information element of the PDN CONNECTIVITY REQUEST message or BEARER RESOURCE ALLOCATION REQUEST message.  For now just suppose this address is already present.

The P-CSCF receives the SIP REGISTER request from the UE and inserts a Path header with a SIP URI identifying the P-CSCF for routing, a P-Charging-Vector header with the icid-value and P-Visited-Network-ID to identify the P-CSCF’s network domain.

Once the message is in the IMS network it is trying to register to Registrar. Registrar is the end point for SIP REGISTER and acts as a server from the SIP point of view. Unfortunately it can happen that we’re roaming and P-CSCF is not in our home network. For that there is a SIP URI in the REGISTER message, which will tell the P-CSCF  which network we want to register to.  The Request-URI contains the domain of the Registrar (S-CSCF) and there is no userinfo part ( e.g. “user@”) present.

REGISTER sip:registrar.home.net SIP/2.0

When forwarding the REGISTER request the P-CSCF needs to specify the protocol, port number and IP address of the I-CSCF server in the home network to which to send the REGISTER request. In order to find out these details the P-CSCF performs several DNS queries (NAPTR, SRV, A/AAAA). The DNS records are retrieved according to RFC 3263.

VoLTE Registration

When the REGISTER gets on the I-CSCF we need to discover which S-CSCF is the registrar for this particular user. The information is either stored in HSS or a default decision is taken. The HSS is queried via User-Authorization-Request (UAR) over Cx interface and the key is the registered identity (IMPU) which is stored in the To header.

To: <sip:+119560022547@home.net>

The HSS validates that the Public User Identity and Private User Identity are valid and not barred. We can also evaluate the roaming status of the user. The HSS returns in the User-Authorization-Answer (UAA) either the name of the handling S-CSCF or if there is not an S-CSCF associated with the user (IMPU), the HSS may return S-CSCF capabilities allowing the I-CSCF to select an appropriate S-CSCF. 

Finally the I-CSCF will forward the message to the right S-CSCF. Does it mean we’re finished? Nope. That is just the beginning. The S-CSCF has to authenticate the user and when successful than it has to update the routing information, capabilities and based on initial filter criteria (iFC) trigger application servers.

Various authentication methods could be described in its own post. For simplicity let’s assume that we use the VoLTE authentication with 3GPP AKA.

3GPP AKA

The S-CSCF identifies that the SIP REGISTER is part of an initial IMS registration with IMS-AKA related security. The S-CSCF initiates a Multimedia Authentication Request (MAR) to the HSS to retrieve the authentication vectors to perform IMS-AKA security. The HSS stores the related S-CSCF name for the IMPU being registered and returns the authentication vectors in Multimedia Authentication Answer (MAA).

Upon receipt of the IMS AKA authentication vectors, the S-CSCF stores the expected response (XRES) and challenges the user with a 401 Unauthorised response indicating that AKAv1-MD5 is the security mechanism to be used. The AKA values RAND, AUTN  (encoded by base64 in nonce field – nonce=base64(RAND,AUTN)), Integrity Key and Cipher Key are also included in the response message.

If it is too much for you, just remember that the S-CSCF will challenge the UE (401 Unauthorized) and will expect response in Authorization header in the consequent SIP REGISTER with the CSeq: 2 REGISTER.

The P-CSCF removes the Cipher Key and Integrity Key from the 401 Unauthorised response and binds these to the Private User Identity with a set of temporary security associations for the result of the challenge. The P-CSCF then forwards the response to the UE.

IMS AKA

The UE extracts the RAND and AUTN parameters, calculates the RES, and derives the Cipher Key and Integrity Key from the RAND. The UE creates a temporary set of security associations based on parameters received from the P-CSCF (IPSec), and sends a new REGISTER request to the P-CSCF with the Authorization header containing the response RES indicating that the message is integrity protected.

The S-CSCF checks whether the RES received in the SIP REGISTER and the XRES previously stored match. If the registration went successfully the S-CSCF informs (via Cx SAR) the HSS that user has been registered at this instance and stores the SCSCF Restoration Data. In the response (Cx SAA) will the S-CSCF receive a user profile along with the iFCs. It will send 200 OK back to UE and trigger the services.

On receipt of the 200 OK, the P-CSCF changes the temporary set of security associations to a newly established set of security associations. It protects the 200 OK with these associations and sends the 200 OK to the VoLTE UE. All future messages sent to the UE will be protected using the security associations.

Also the UE on receipt of the 200 OK changes the temporary security association to a newly established set of security associations that will be used for further messages to the P-CSCF.

IMS Registration

The UE is registered now in the IMS network. The S-CSCF based on the initial filter criteria (iFC) sends a Third Party SIP REGISTER to the Application Servers.

The UE, P-CSCF and TAS can also subscribe to the registration event package using the SIP SUBSCRIBE message, in order to be notified on any change of registration state for the public user identity. In turn, the S-CSCF shall send a SIP NOTIFY to the subscribing entities informing them of the active registration status.

More information related to the registration from the Application Server point of view can be found in the Third Party Registration post. A detail VoLTE registration flow is shown in the VoLTE flows – close encounters, How to read tcpdump – Registration and SIP Illustrated 3: Routing and IMS Registration post.

Advertisement