IMS-AKA
The Oracle Communications Session Border Controller supports IP Media Subsystem-Authentication and Key Agreement (IMS-AKA).
Defined in 3GPPr7 (specifications in TS 33.203 and call flows in TS 24.228), IMS-AKA can be used as a framework for authentication and for securing the signaling path between a UE and the Oracle Communications Session Border Controller (when the Oracle Communications Session Border Controller is acting as a P-CSCF or as a B2BUA) across the Gm interface.
In addition, the Oracle Communications Session Border Controller’s serving as an IMS-AKA termination point is valuable because it allows IMS-AKA use behind by multiple endpoints sitting behind a NAT device. IMS-AKA support also works when there are no NAT devices between endpoints and the Oracle Communications Session Border Controller acting as a P-CSCF, and when the Oracle Communications Session Border Controller sits behind a third-party P-CSCF. In addition, you can use IMS-AKA when the endpoint uses SIP UDP.
Requirements
IMS-AKA use assumes that you have installed the appropriate IPSec module on your SBC, or that it has come from Oracle with those modules pre-installed. IMS-AKA will not work without this hardware.
IMS-AKA deployments require an activated network-parameters element configured with the options shown below.
options atcp-rxmt-count=2
atcp-rxmt-interval=2
atcp-syn-rxmt-interval=2
atcp-syn-rxmt-maxtime=6
atcp-idle-timer=3700In addition, your configuration must have SIP registration caching enabled.
IMS-AKA Socket Cleanup
To ensure that the SBC properly removes idle IMS-AKA sockets, you can set the cleanup-inactive-imsaka-tcp-socket option. This option generates the cleanup logic when you also set the inactivity-conn-timer on the access side sip-interface. When you configure this option, the SBC:
- Increments idle connection timer of the core side registration expiry value for
sip service sockets that are TCP, are created with an IMS-AKA profile, and are
not expecting more data.
Sets the idle connection timer for the 5060 unsecured TCP socket, the secure inbound TCP socket, and the secure outbound TCP socket for IMS-AKA to the core side reg-expiry value plus the value you configured in the inactivity-conn-timer parameter.
- Resets this inactivity time every time it has a Send or Recv event on the SipService socket.
- Disconnects the service socket when it detects no activity for that amount of time.
The refreshRegForward Option
The Oracle Communications Session Border Controller provides a the user with a means of ignoring its registration refresh half-life timer, and send all applicable registration refreshes received via IMS-AKA to the core for authentication.
By default, the Oracle Communications Session Border Controller uses its half-life function and attempts to manage registration refreshes prior to half-life expiry without forwarding the refresh to the core. The Oracle Communications Session Border Controller sends registration refreshes that arrive after the half-life expiry to the core.
The user changes this behavior by setting the refreshRegForward in the applicable IMS-AKA profile to as follows.
ORACLE(ims-aka-profile)# options +refreshRegForwardWhen this option is set, the system forwards every refresh registration to the IMS core regardless of the half-life timer's status.
Monitoring
The ACLI show sipd endpoint-ip command is updated to show the IMS-AKA parameters corresponding to each endpoint. The display shows the algorithms used, the ports used, and the security parameter indexes (SPIs) used.
In addition, the show sa stats command now shows the security associations information for IMS-AKA.
DDoS for IMS-AKA
The Oracle Communications Session Border Controller (SBC) supports DDoS protection for IMS-AKA. This can be enabled on the realm interface for the access network when the access-control-trust-level configuration element is set to low or medium.
- The SBC installs two dynamic trusted flows in its network processor (NP)
as soon as the user agent client (UAC) completes registration with a 200 OK.
Because both flows are trusted, this ensures that the signaling from authenticated IMS-AKA endpoints will not be dropped even during a DDoS attack.
- Rather than installing multiple flows
for different protocols, the SBC installs two protocol-aware flows.
One flow covers the TCP and UDP traffic from or to the endpoint client port; the
other flow covers the TCP traffic from or to the endpoint server port. This
allows the SBC to avoid size limitations in the NAT
endpoint tables.
- invalid-signal-threshold
- maximum-signal-threshold
- deny-period
- cac-failure-threshold
- untrust-cac-failure-threshold
- wait-time-for-invalid-threshold (if the IDS feature is enabled)
ACLI Instructions and Examples
You enable IMS-AKA by configuring the following:
- An IMS-AKA profile
- Certain parameters in the global IPSec configuration
- Certain parameters in the SIP interface, and in the SIP interface’s SIP port
Setting Up an IMS-AKA Profile
An IMS-AKA profile establishes the client and server ports to be protected, and it defines lists of encryption and authentication algorithms the profile supports. You can configure multiple IMS-AKA profiles, which are uniquely identified by their names.
You apply an IMS-AKA profile to a SIP port configuration using the name.
To configure an IMS-AKA profile:
Setting Up an IPSec Profile for IMS-AKA Use
Using the global IPSec configuration, you establish the parameters governing system-wide IPSec functions and behavior. This configuration also contains parameters required for IMS-AKA support. The IPSec global configuration is a single instance element, meaning there is one for the whole system.
To configure the global IPSec parameters that apply to IMS-AKA: