IMS AKA over TCP

IMS-AKA registration is conducted over UDP or TCP protocol only. The Oracle Communications Session Border Controller supports both transport protocols.

Within mobile IMS VoLTE/RCSe deployments, IP packets carrying SIP messages can be large due to IPv6 headers, IMS-AKA specific headers, extensive codec policies, and other 3GPP related headers. Because of this, IPv6 VoLTE signaling messages using IMS-AKA frequently exceed 1300 bytes and require TCP according to RFC3261 section 18.1.1.

IMS-AKA Secure Call Registration over TCP

To register and place a call into the network, a UE creates 3 TCP connections. The first insecure connection is established to the port (usually 5060) specified in the sip-port for the first registration request. You should create a sip-ports configuration element with port 5060 and an ims-aka-profile parameter that references an ims-aka-profile configuration element. The ims-aka-profile configuration element initiates the process that creates secure connections. For example:

sip-ports

		address                        sd-ip-address
		port                           5060
		transport-protocol             TCP
		tls-profile
		multi-home-addrs
		allow-anonymous                registered
		ims-aka-profile                profile

The ims-aka-profile configuration element defines the protected-server-port (PORT-SDS) and protected-client-port (PORT-SDC). The protected-server-port is opened for both inbound TCP and UDP traffic. For example:

ims-aka-profile

	name                           profile
	protected-client-port          PORT-SDC
	protected-server-port          PORT-SDS
	encr-alg-list                  aes-cbc des-ede3-cbc null
	auth-alg-list                  hmac-sha-1-96

When the UE receives the 401Unauthorized challenge from the Oracle Communications Session Border Controller acting as P-CSCF, both devices have the information to set up security association for two IPSec channels. The UE establishes the second TCP connection via IPSec channel from the UE's PORT-UEC to the P-CSCF's PORT-SDS, and the registration process continues.

Hereafter, the UE uses the IPSec channels from communication.

The UE and P-CSCF set up the TCP connection.
The UE sends an unauthenticated SIP Register message to the P-CSCF’s unprotected server port (usually 5060). The Register message is forwarded to the UE's Home S-CSCF. The S-CSCF then replies with a the SIP 401 Authentication Required response back to P-CSCF. This message contains encryption keys and authentication information.

The P-CSCF modifies the 401 message back to UE. At this point, both UE and P-CSCF should have all the information need to establish secure IPSec channels.
The UE and P-CSCF create a TCP connection over a secure channel from port-ue-c to port-sd-s.
The UE sends an authenticated REGISTER over the secure channel via the P-CSCF to the S-CSCF. If the authentication is valid, the P-CSCF will forward the 200 OK response from the S-CSCF to the UE. The 200 OK response will be sent in the same secure TCP connection.

IMS-AKA Call Establishment over TCP

For the UE to send a new request into the network and establish a call, a third TCP connection is created using the information configured/generated prior to creating the first secure connection.

If the TCP connection over a secure channel does not exist, the Caller will establish it.
The Caller initiates the call by sending SIP INVITE from its PORT-UEC to the P-CSCF's PORT-SDS.
The P-CSCF forwards the INVITE to the Caller. If not present, it will create a secure TCP connection from its PORT-SDC to the callee's PORT-UES.
The INVITE is then forwarded to the Callee securely.

SIP SUBSCRIBE and NOTIFY over TCP IMS-AKA

SUBSCRIBE and NOTIFY messages are exchanged between a UE and the P-CSCF in a manner similar to the previous INVITE example whereby the secure channel is first created and then the SIP messages are exchanged securely.