Table of Contents Table of contents: Radiator® AAA Server Testing Radiator SIM Module 3 - Testing Radiator SIM Module Abbreviations 5 - Abbreviations

4. Configuring Radiator SIM Module

This section describes the configurable parameters of Radiator SIM Module. If TMSI or Fast Re-Authentication information is stored in an SQL database, start with the sample tables created using goodies/eap-sim-mysql.sql. For MySQL or MariaDB, DBD::mysql is required. Other types of databases and alternative database schemas are also supported. See the goodies directory for schemas for other SQL databases.

4.1. <AuthBy AKA>

This section describes the configuring parameters of <AuthBy AKA>. Apart from the parameters listed here, <AuthBy AKA> inherits other parameters from AuthGeneric. These parameters are documented in Radiator reference manual Opens in new window under section <AuthBy xxxxxx>.

4.1.1. UseTMSI

This flag defines whether the server offers and accepts pseudonyms. This is not set by default.

4.1.2. UseReauthentication

This flag defines if the server offers and accepts the reauthentication IDs. This is not set by default.

4.1.3. MaxReauthentications

This integer defines the maximum number of permitted consecutive reauthentications. The default value is 100.

4.1.4. ReauthenticationRealm

This string defines if ReauthenticationRealm is appended to the reauthentication ID. It ensures that RADIUS routing gets the reauthentication request back to the server, which handles the request. This has no default value.
The following formatter is available in ReauthenticationRealm:
  • %0
    This is the realm part of identity.
For more information about formatters, see Radiator reference manual Opens in new window under section Special characters.

4.1.5. UseResultInd

This flag enables the AT_RESULT_IND usage. AT_RESULT_IND is a flag which, when set, requires result indications if they are also enabled in the peer. This is not set by default.

4.1.6. IMSICrypt

This string defines the identifier of IMSICrypt clause to use for IMSI decryption. For more about IMSI encryption, see Section 4.18. <IMSICrypt>.

4.1.7. TemporaryIdentity

This string defines the identifier of TemporaryIdentity clause to use for creating pseudonyms, also called Temporary Mobile Subscriber Identity (TMSI), and re-authentication identity values. For more about pseudonyms, see Section 4.19. <TemporaryIdentityAES>. When TemporaryIdentity parameter is configured, SQL database configuration is not needed for storing TMSIs.

4.1.8. UpdateLocation

This flag parameter enables location update that is done after successful authentication to authorise the user before EAP Success is returned. The actual location update method depends whether authentication uses SIGTRAN or Diameter. When location update completes, AuthorisedHook is called. UpdateLocation is not set by default and location update finishes immediately with success.
Location update for MAP is configured with parameter UpdateLocationOperation.
Note
Currently MAP UpdateGprsLocation and UpdateLocation operations for SIGTRAN are supported. Other methods and Diameter support will be added in future releases.

4.1.9. AuthorisedHook

This is a Perl hook, which is called when the client is authenticated and authorised with location update, before the EAP Success message is sent. AuthorisedHook is called with 5 arguments:
  • $_[0]
    This is a pointer to this AuthBy.
  • $_[1]
    This is a pointer to the current EAP context structure of the current user.
  • $_[2]
    This is a pointer to the last request from the client.
  • $_[3]
    This is a pointer to the authentication result. It is preset to main::ACCEPT but it can be changed if needed.
  • $_[4]
    This is a pointer to the authentication reason. It is preset to empty string but it can be changed if needed.
CAUTION
When UpdateLocation is enabled, the received profile is available in EAP context but it's exact contents and presentation may still change.
# Log IMSI and the profile that was fetch with authorisation
AuthorisedHook sub { \
    my $self = $_[0]; my $context = $_[1]; my $p = $_[2]; \

    use Data::Dumper; $Data::Dumper::Sortkeys = 1; $Data::Dumper::Useqq = 1; \
    $self->log($main::LOG_DEBUG, "Profile for IMSI $context->{imsi}: " . \
                                  Dumper($context->{sim_profile}), $p); \
}

4.1.10. AKAPrimeKDF

This string defines the KDF (Key Derivation Function) algorithm used for AKA' (Authentication and Key Agreement Prime). The default value is DEFAULT, which means the default AKA' KDF.

4.1.11. AKAPrimeNetworkName

This string defines the network name used for AKA' authentication. The default value is WLAN.

4.1.12. ResLengthInBytes

This flag allows interoperation with the old AKA clients, such as wpa_supplicant up to at least version 0.6.5, but not with version 0.6.9 or later, which use an obsolete format for AT_RES encoding. This is now obsolete and should not be used. This is not set by default.

4.2. <AuthBy AKAMAP>

This section describes the configuring parameters of <AuthBy AKAMAP>. Apart from the parameters listed here, <AuthBy AKAMAP> inherits other parameters from <AuthBy AKASQL>.

4.2.1. MAP

This object list lists the <MAP> clauses used by this <AuthBy SIMMAP>.

4.3. <AuthBy AKAREST>

This section describes the configuration parameters of <AuthBy AKAREST>. Apart from the parameters listed here, <AuthBy AKAMAP> inherits other parameters from <AuthBy AKASQL>.
REST interface is provided by Radiator's HTTP client module. HTTP client parameters are documented in Radiator reference manual Opens in new window under section HTTP client configuration.
<AuthBy AKAREST> fetches authentication vectors over a HTTP or HTTPS REST interface. See goodies/eap_aka_rest.cfg and goodies/eap_aka_prime_rest.cfg for a sample configurations. The REST API is documented in goodies/rest.txt.

4.3.1. NoReplyReject

When set, this optional flag parameter causes Radiator to REJECT the request instead of returning IGNORE if badly formatted REST reply or no RESTreply at all is received. This parameter is not set by default.

4.4. <AuthBy AKASQL>

This section describes the configuring parameters of <AuthBy AKASQL>. Apart from the parameters listed here, <AuthBy AKASQL> inherits other parameters from <AuthBy AKA> and Radiator SQL database module. The inherited SQL database parameters are:
These parameters are documented in Radiator reference manual Opens in new window under section <AuthBy SQL>.

4.4.1. GetTMSIQuery

This string contains the SQL query for mapping the IMSI from a TMSI.
The following bind variable is available in GetTMSIQuery:
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.4.2. GetTMSIQueryParam

This string array defines the bind variables to be used with GetTMSIQuery. See GetTMSIQuery for more information about the available bind variables.

4.4.3. SaveTMSIQuery

This string contains the SQL query for saving the IMSI-TMSI mapping.
The following bind variables are available in SaveTMSIQuery:
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.4.4. SaveTMSIQueryParam

This string array defines the bind variables to be used with SaveTMSIQuery. See SaveTMSIQuery for more information about the available bind variables.

4.4.5. DeleteReauthQuery

This string contains the SQL query for deleting the reauthentication data from the database.
The following bind variable is available in DeleteReauthQuery:
  • %0
    This is the reauthentication ID.
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.4.6. DeleteReauthQueryParam

This string array defines the bind variables to be used with DeleteReauthQuery. See DeleteReauthQuery for more information about the available bind variables.

4.4.7. GetReauthQuery

This string contains the SQL query for getting the reauthentication data from the database.
The following bind variable is available in GetReauthQuery:
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.4.8. GetReauthQueryParam

This string array defines the bind variables to be used with GetReauthQuery. See GetReauthQuery for more information about the available bind variables.

4.4.9. SaveReauthQuery

This string contains the SQL query for saving the reauthentication data to the database.
The following bind variables are available in SaveReauthQuery:
  • %0
    This is the reauthentication ID.
  • %1
    This is the IMSI.
  • %2
    This is the counter.
  • %3
    This is the master key.
  • %4
    This is the authentication key.
  • %5
    This is the encryption key.
  • %6
    This is the reauthentication key.
  • %7
    This is the version of SIM.
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.4.10. SaveReauthQueryParam

This string array defines the bind variables to be used with SaveReauthQuery. See SaveReauthQuery for more information about the available bind variables.

4.5. <AuthBy AKATEST>

This section describes the configuring parameters of <AuthBy AKATEST>. Apart from the parameters listed here, <AuthBy AKATEST> inherits other parameters from <AuthBy AKA>.

4.5.1. 3GPPCardDatabaseFilename

This string defines the file path and name where 3G USIM card details are stored. Radiator requires read and write access to this file and its directory. When defined, this parameter is used to find the Milenage algorithm parameters for SIM and USIM cards. See goodies/simcards.dat for a sample file.
The file contains the following information coded to hexadecimal:

4.5.2. IndLength

This integer defines the length of the IND part in bits in the AKA authentication vector SQN. The default value is 5.

4.6. <AuthBy AKAWX>

<AuthBy AKAWX> does not have configurable parameters at the moment. It inherits parameters from <AuthBy AKASQL> and <WxClient>.

4.7. <AuthBy SIM>

This section describes the configuring parameters of <AuthBy SIM>. Apart from the parameters listed here, <AuthBy SIM> inherits other parameters from AuthGeneric. These parameters are documented in Radiator reference manual Opens in new window under section <AuthBy xxxxxx>.

4.7.1. UseTMSI

This flag defines whether the server offers and accepts pseudonyms. This is not set by default.

4.7.2. UseReauthentication

This flag defines if the server offers and accepts the reauthentication IDs. This is not set by default.

4.7.3. MaxReauthentications

This integer defines the maximum number of permitted consecutive reauthentications. The default value is 100.

4.7.4. ReauthenticationRealm

This string defines if ReauthenticationRealm is appended to the reauthentication ID. It ensures that RADIUS routing gets the reauthentication request back to the server, which handles the request. This has no default value.
The following formatter is available in ReauthenticationRealm:
  • %0
    This is the realm part of identity.
For more information about formatters, see Radiator reference manual Opens in new window under section Special characters.

4.7.5. UseResultInd

This flag enables the AT_RESULT_IND usage. AT_RESULT_IND is a flag which, when set, requires result indications if they are also enabled in the peer. This is not set by default.

4.7.6. IMSICrypt

This string defines the identifier of IMSICrypt clause to use for IMSI decryption. For more about IMSI encryption, see Section 4.18. <IMSICrypt>.

4.7.7. TemporaryIdentity

This string defines the identifier of TemporaryIdentity clause to use for creating pseudonyms, also called Temporary Mobile Subscriber Identity (TMSI), and re-authentication identity values. For more about pseudonyms, see Section 4.19. <TemporaryIdentityAES>. When TemporaryIdentity parameter is configured, SQL database configuration is not needed for storing TMSIs.

4.7.8. UpdateLocation

This flag parameter enables location update that is done after successful authentication to authorise the user before EAP Success is returned. The actual location update method depends whether authentication uses SIGTRAN or Diameter. When location update completes, AuthorisedHook is called. UpdateLocation is not set by default and location update finishes immediately with success.
Location update for MAP is configured with parameter UpdateLocationOperation.
Note
Currently MAP UpdateGprsLocation and UpdateLocation operations for SIGTRAN are supported. Other methods and Diameter support will be added in future releases.

4.7.9. AuthorisedHook

This is a Perl hook, which is called when the client is authenticated and authorised with location update, before the EAP Success message is sent. AuthorisedHook is called with 5 arguments:
  • $_[0]
    This is a pointer to this AuthBy.
  • $_[1]
    This is a pointer to the current EAP context structure of the current user.
  • $_[2]
    This is a pointer to the last request from the client.
  • $_[3]
    This is a pointer to the authentication result. It is preset to main::ACCEPT but it can be changed if needed.
  • $_[4]
    This is a pointer to the authentication reason. It is preset to empty string but it can be changed if needed.
CAUTION
When UpdateLocation is enabled, the received profile is available in EAP context but it's exact contents and presentation may still change.
# Log IMSI and the profile that was fetch with authorisation
AuthorisedHook sub { \
    my $self = $_[0]; my $context = $_[1]; my $p = $_[2]; \

    use Data::Dumper; $Data::Dumper::Sortkeys = 1; $Data::Dumper::Useqq = 1; \
    $self->log($main::LOG_DEBUG, "Profile for IMSI $context->{imsi}: " . \
                                  Dumper($context->{sim_profile}), $p); \
}

4.7.10. NumTriplets

This integer defines the number of triplets requested for SIM authentication. The number must match to what the client is expecting, otherwise the authentication fails. The value is either 2 or 3, the default value is 3.

4.7.11. NoSilentDeny

This flag controls the behaviour of EAP-SIM notifications in EAP-SIM version 0. If NoSilentDeny is set and the EAP-SIM version number is 0, Radiator sends a notification to the user client if the connection is rejected. If NoSilentDeny is not set, no rejection notification is sent. NoSilentDeny is not set by default.

4.7.12. RequireVersion

This flag defines if the SIM client version is required or not. The recent versions of the EAP-SIM standard require the SIM client to send a protocol version information with each authentication. Some clients (for example, Cisco V5) do not send the protocol version. The default value is 1. Set this parameter to 0 only when you must support clients that do not send the version number.

4.7.13. SupportVersions

This string controls which versions of EAP-SIM standard are supported. The parameter is a list of comma-separated version numbers, listed in order of preference, the most preferred first. The default value is 0,1 which means that all versions are supported.

4.8. <AuthBy SIMMAP>

This section describes the configuring parameters of <AuthBy SIMMAP>. Apart from the parameters listed here, <AuthBy SIMMAP> inherits other parameters from <AuthBy SIMSQL> and <AuthBy SQL>. The <AuthBy SQL> parameters are documented in Radiator reference manual Opens in new window under section <AuthBy SQL>.

4.8.1. MAP

This object list lists the <MAP> clauses used by this <AuthBy SIMMAP>.

4.9. <AuthBy SIMREST>

This section describes the configuration parameters of <AuthBy SIMREST>. Apart from the parameters listed here, <AuthBy SIMREST> inherits other parameters from <AuthBy SIMSQL>.
REST interface is provided by Radiator's HTTP client module. HTTP client parameters are documented in Radiator reference manual Opens in new window under section HTTP client configuration.
<AuthBy SIMREST> fetches authentication vectors over a HTTP or HTTPS REST interface. See goodies/eap_sim_rest.cfg for a sample configuration. The REST API is documented in goodies/rest.txt.

4.9.1. NoReplyReject

When set, this optional flag parameter causes Radiator to REJECT the request instead of returning IGNORE if badly formatted REST reply or no RESTreply at all is received. This parameter is not set by default.

4.10. <AuthBy SIMSQL>

This section describes the configuring parameters of <AuthBy SIMSQL>. Apart from the parameters listed here, <AuthBy SIMSQL> inherits other parameters from <AuthBy SIM> and Radiator SQL database module. The inherited SQL database parameters are:
These parameters are documented in Radiator reference manual Opens in new window under section <AuthBy SQL>.

4.10.1. GetTMSIQuery

This string contains the SQL query for mapping the IMSI from a TMSI.
The following bind variable is available in GetTMSIQuery:
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.10.2. GetTMSIQueryParam

This string array defines the bind variables to be used with GetTMSIQuery. See GetTMSIQuery for more information about the available bind variables.

4.10.3. SaveTMSIQuery

This string contains the SQL query for saving the IMSI-TMSI mapping.
The following bind variables are available in SaveTMSIQuery:
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.10.4. SaveTMSIQueryParam

This string array defines the bind variables to be used with SaveTMSIQuery. See SaveTMSIQuery for more information about the available bind variables.

4.10.5. DeleteReauthQuery

This string contains the SQL query for deleting the reauthentication data from the database.
The following bind variable is available in DeleteReauthQuery:
  • %0
    This is the reauthentication ID.
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.10.6. DeleteReauthQueryParam

This string array defines the bind variables to be used with DeleteReauthQuery. See DeleteReauthQuery for more information about the available bind variables.

4.10.7. GetReauthQuery

This string contains the SQL query for getting the reauthentication data from the database.
The following bind variable is available in GetReauthQuery:
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.10.8. GetReauthQueryParam

This string array defines the bind variables to be used with GetReauthQuery. See GetReauthQuery for more information about the available bind variables.

4.10.9. SaveReauthQuery

This string contains the SQL query for saving the reauthentication data to the database.
The following bind variables are available in SaveReauthQuery:
  • %0
    This is the reauthentication ID.
  • %1
    This is the IMSI.
  • %2
    This is the counter.
  • %3
    This is the master key.
  • %4
    This is the authentication key.
  • %5
    This is the encryption key.
  • %6
    This is the version of SIM.
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.10.10. SaveReauthQueryParam

This string array defines the bind variables to be used with SaveReauthQuery. See SaveReauthQuery for more information about the available bind variables.

4.10.11. UpdateReauthQuery

This string contains the SQL query for updating the reauthentication data to the database.
The following bind variables are available in UpdateReauthQuery:
  • %0
    This is the reauthentication ID.
  • %1
    This is the IMSI.
  • %2
    This is the counter.
  • %3
    This is NONCE_S, the nonce value from the AT_NONCE_S attribute.
  • %4
    This is the ID of the next reauthentication.
  • %5
    This is the EAP user name.
For more information about SQL bind variables, see Radiator reference manual Opens in new window under section SQL Bind Variables.

4.10.12. UpdateReauthQueryParam

This string which defines the bind variables to be used with UpdateReauthQuery. See UpdateReauthQuery for more information about the available bind variables.

4.11. <AuthBy SIMWX>

This section describes the configuring parameters of <AuthBy SIMWX>. Apart from the parameters listed here, <AuthBy SIMWX> inherits other parameters from <AuthBy SIMSQL> and <WxClient>.

4.11.1. ConvertAKAVectors

This flag defines whether the AKA vectors received via Diameter SWx, Cx or SWx are converted to SIM triplets. Enable this option if the HSS cannot return 2G triplets over Wx interface. This is not set by default but if Interface is set to SWx or Cx, this is enabled automatically.

4.12. <MAP>

This section describes the configuration parameters of <MAP>. Apart from the parameters listed here, all parameters from <PeerSP> are available for setting the default values for <PeerSP> clauses within a <MAP>.

4.12.1. NumVectors

This integer defines the number of authentication vectors requested via MAP, if the number of the vectors is not specified in the MAP request. This parameter is used with version 2 SendAuthenticationInfo requests which do not specify the number of requested vectors. The default value is 3.

4.12.2. UpdateLocationOperation

UpdateLocationOperation defines the MAP operation for location update. Supported values are UpdateGprsLocation and UpdateLocation. Defaults to UpdateGprsLocation.
# Old HLR/AuC requires UpdateLocation
UpdateLocationOperation UpdateLocation

4.13. <ServerSIGTRAN> within <MAP>

<ServerSIGTRAN> does not have configurable parameters at the moment. It inherits parameters from common StreamServer class. These parameters are documented in Radiator reference manual Opens in new window under section <ServerDiameter>.
A <ServerSIGTRAN> is required if connections need to be accepted from peer IPSPs or ASPs.

4.14. <PeerSP xxxxxx> within <MAP>

This section describes the configuration parameters of <PeerSP>. A <PeerSP> defines parameters and settings for a SIGTRAN IPSP or ASP a <MAP> uses.
To be able to use <PeerSP>, you must have Convert::ASN1 Perl module version 0.26 or later.

4.14.1. AckTimeout

This integer defines the timeout in seconds for how long to wait M3UA ASP (Application Server Process) Up and ASP Active responses. This is also used for scheduling peering restart with ASP Up when an error is received because peering is not up. The default value is 2.

4.14.2. ACVersionForSAI

This integer defines the application context version for sendAuthenticationInfo operation. The value can be 2 (3GPP TS 09.02) or 3 (3GPP TS 29.002). The default value is 3. When AKA quintuplets are set, this parameter must be 3.

4.14.3. ASPIdentifier

This integer defines the optional value for ASP Identifier parameter in M3UA messages.

4.14.4. DebugASN

This flag enables ASN.1 library debug dumps to be printed to STDERR.

4.14.5. DestPointCode

This integer defines the destination point code in M3UA payload data messages. This is a mandatory parameter and must be defined as it has no default value. The value must be decimal, for example 4827 instead of 2-091-3.
# 4827 in ITU 14 bit 3-8-3 format is 2-091-3
DestPointCode 4827

4.14.6. GprsLocationSgsnAddress

GprsLocationSgsnAddress defines the value of sgsn-Address parameter in MAP UpdateGprsLocationArg when UpdateLocation is set and UpdateGprsLocation operation is used for authorisation. The value is an IPv4 or IPv6 address.
# IP Address of SGSN Radiator acts as
GprsLocationSgsnAddress 10.20.30.40

4.14.7. GprsLocationSgsnNumber

GprsLocationSgsnNumber defines the value of sgsn-Number parameter in MAP UpdateGprsLocationArg when UpdateLocation is set and UpdateGprsLocation operation is used for authorisation. The value is an ISDN-AddressString and configured as a phone number. All non-digits are removed before the value is used. Defaults to OurGlobalTitle.
# ISDN-AddressString of SGSN Radiator acts as
GprsLocationSgsnNumber +353 020 912 1234

4.14.8. LocationMscNumber

LocationMscNumber defines the value of msc-Number parameter in MAP UpdateLocationArg when UpdateLocation is set and UpdateLocation operation is used for authorisation. The value is an ISDN-AddressString and configured as a phone number. All non-digits are removed before the value is used. Defaults to OurGlobalTitle.
# ISDN-AddressString of MSC Radiator acts as
LocationMscNumber +353 020 912 1234

4.14.9. LocationVlrNumber

LocationVlrNumber defines the value of vlr-Number parameter in MAP UpdateLocationArg when UpdateLocation is set and UpdateLocation operation is used for authorisation. The value is an ISDN-AddressString and configured as a phone number. All non-digits are removed before the value is used. Defaults to OurGlobalTitle.
# ISDN-AddressString of VLR Radiator acts as
LocationVlrNumber +353 020 912 1234

4.14.10. HeartbeatTimeout

This optional parameter defines the timeout in seconds that is used when waiting for M3UA Heartbeat responses. Setting this to a non-zero value enables peer availability checks with M3UA Heartbeat messages. This is not set by default.
If there are no M3UA messages received after 2 consecutive Heartbeat messages, the peer is automatically disconnected.
# Monitor connectivity to the peer with M3UA heartbeat messages
HeartbeatTimeout 3
Note
Heartbeat messages are always responded to. You do not have to set HeartbeatTimeout for responses.

4.14.11. HeartbeatData

This parameter defines an optional value that is sent with M3UA Heartbeat messages. Special formatting characters are allowed. This is not set by default.
Here is an example of using HeartbeatData:
HeartbeatData Radiator SIGTRAN stack heartbeat %t

4.14.12. ImmediateResponsePreferredInSAI

This flag defines whether immediateResponsePreferred is sent with sendAuthenticationInfoArg. This is set by default.

4.14.13. InfoString

This string defines the value for INFO String parameter in M3UA messages. This is an optional parameter, it has no default value and thus no INFO String TLV is added by default.

4.14.14. Initiator

This flag opens the connection to the peer, when set.

4.14.15. LocalAddress and LocalPort

These parameters control the address and optionally the port number used for the client source port, although this is usually not necessary. LocalPort is a string, it can be a port number or name. It binds the local port if LocalAddress is defined. If LocalPort is not specified or if it is set to 0, a port number is allocated in the usual way.
When SCTP multihoming is supported, multiple comma separated addresses can be configured. All addresses defined with LocalAddress must be either IPv4 or IPv6 addresses.
LocalAddress 203.63.154.29
LocalPort 12345

4.14.16. NetworkAppearance

This integer defines the network appearance in M3UA payload data messages. This has no default value and thus no Network Appearance TLV is added.

4.14.17. NetworkIndicator

This string defines the network indicator name or number in M3UA payload data messages. The default value is National. You can define the value with either as a numerical value or as text. The allowed values are shown in the table below.

Table 1. Available values of NetworkIndicator

Numerical value Text
0 International
1 Spare international
2 National
3 Spare national

4.14.18. OrigPointCode

This integer defines the originating point code in M3UA payload data messages. This is a mandatory parameter and must be defined as it has no default value. The value must be decimal, for example 6134 instead of 2-254-6.
# 6134 in ITU 14 bit 3-8-3 format is 2-254-6
OrigPointCode 6134

4.14.19. OurGlobalTitle

This string defines the global title number in calling party address when it is sent to the peer. This has no default value.

4.14.20. OurGlobalTitleIndicator

This integer defines the value of global title indicator in calling party address when it is sent to the peer. The value is either 0 or 4, the default value is 4 (the global title includes translation type, numbering plan, encoding scheme and nature of address indicator).

4.14.21. OurNatureOfAddress

This string defines the nature of address name or number in calling party address when it is sent to the peer. The default value is international. This parameter has the same allowed values as PeerNatureOfAddress. For a complete list of available parameters, see Table 2. Available values of PeerNatureOfAddress.

4.14.22. OurNumberingPlan

This string defines the numbering plan name or number in calling party address when it is sent to the peer. The default value is ISDN/telephony. This parameter has the same allowed values as PeerNumberingPlan. For a complete list of available parameters, see Table 3. Available values of PeerNumberingPlan.

4.14.23. OurRoutingIndicator

This string defines the routing indicator name or number in calling party address when it is sent to peer. The default value is GT (Route on GT). This parameter has the same allowed values as PeerRoutingIndicator. For a complete list of available parameters, see Table 4. Available values of PeerRoutingIndicator.

4.14.24. OurSubSystemNumber

This string defines the subsystem number or name in calling party address when it is sent to the peer. The default value is 149 (SGSN (Serving GPRS Support Node)). This parameter has the same allowed values as PeerSubSystemNumber. For a complete list of available parameters, see Table 5. Available values of PeerSubSystemNumber.

4.14.25. OurTranslationType

This string defines the translation type number or name in calling party address when it is sent to the peer. The default value is 0.

4.14.26. PeerGlobalTitle

This string defines the global title number in called party address when it is sent to the peer. This has no default value.

4.14.27. PeerGlobalTitleHook

This is a Perl hook, which creates peer global title from the IMSI and returns the global title. If no value is returned, PeerGlobalTitle is used as the global title. This has no default value. PeerGlobalTitleHook is called with 2 arguments:
  • $_[0]
    This is the IMSI.
  • $_[1]
    This is the current peer global title
PLMN database lookup is done before this hook is called. The global title from the lookup, if any is found, is supplied as the second argument. See goodies/sigtran-peer-gt-hook.pl for a sample PeerGlobalTitleHook.
PeerGlobalTitleHook file:"%D/sigtran-peer-gt-hook.pl"

4.14.28. PeerGlobalTitleIndicator

This integer defines the value of global title indicator in called party address when it is sent to the peer. The value can be 0 or 4, the default value is 4 (the global title includes translation type, numbering plan, encoding scheme and nature of address indicator).

4.14.29. PeerNatureOfAddress

This string defines the nature of address name or number in called party address when it is sent to the peer. The default value is international. You can define the value with either as a numerical value or as text. The allowed values are shown in the table below.

Table 2. Available values of PeerNatureOfAddress

Numerical value Text
0 unknown
1 subscriber
2 reserved for national use
3 national significant
4 international

4.14.30. PeerNumberingPlan

This string defines the numbering plan name or number in called party address when it is sent to the peer. The default value is ISDN/mobile. You can define the value with either as a numerical value or as text. The allowed values are shown in the table below.

Table 3. Available values of PeerNumberingPlan

Numerical value Text
0 unknown
1 ISDN/telephony
2 generic
3 data
4 telex
5 maritime mobile
6 land mobile
7 ISDN/mobile
14 private network or network-specific
15 reserved

4.14.31. PeerRoutingIndicator

This string defines the routing indicator name or number in called party address when it is sent to peer. The default value is Route on GT. You can define the value with either as a numerical value or as text. The allowed values are shown in the table below.

Table 4. Available values of PeerRoutingIndicator

Numerical value Text
0 Route on GT
1 Route on SSN

4.14.32. PeerSubSystemNumber

This string defines the subsystem number or name in called party address when it is sent to the peer. The default value is 149 (SGSN). You can define the value with either as a numerical value or as text. The allowed values are shown in the table below.

Table 5. Available values of PeerSubSystemNumber

Numerical value Text
0 Not used/Unknown
1 SCCP management
3 ISDN user part
4 OMAP
5 MAP
6 HLR
7 VLR
8 MSC
9 EIC
10 AUC
11 ISDN supplementary services
142 RANAP
143 RNSAP
145 GMLC
146 CAP
147 gsmSCF or IM-SSF
148 SIWF
149 SGSN
150 GGSN
241 INAP
249 PCAP
250 BSC
251 MSC
252 SMLC
253 BSS O&M
254 A interface

4.14.33. PeerTranslationType

This string defines the translation type number or name in called party address when it is sent to the peer. The default value is 0.

4.14.34. PLMNDatabase

This string defines the identifier of PLMNDatabase clause to use for looking up PLMN information for an IMSI. PLMN information includes, for example, SCCP peer global title for SIGTRAN and Destination-Realm for Diameter. Currently SQL based database is supported, see Section 4.15. <PLMNDatabaseSQL>.

4.14.35. Port

This string defines the peer port the <PeerSP> connects to.

4.14.36. RequestingNodeTypeInSAI

This string defines the RequestingNodeType number in sendAuthenticationInfoArg. The value can be 0 (VLR (Visitor Location Register)) or 1 (SGSN). This has no default value and RequestingNodeType is not sent with sendAuthenticationInfoArg.

4.14.37. RoutingContext

This split string array defines a comma-separated list of routing context values we advertise to peer service provider. This has no default value.

4.14.38. SCTPPeer

This parameter specifies one host name or address of an SCTP peer to connect to. An address can be an IPv4 or IPv6 address. Multiple SCTPPeer parameters are supported. When SCTPPeer is defined, it is used instead of Host or Peer parameters. Special formatting characters are supported. If SCTP multihoming is not supported, connection is attempted to each peer at a time.
When SCTP multihoming is supported, connection is attempted to all peers at once. In this case, all addresses defined with SCTPPeer must be either IPv4 or IPv6 addresses
Here is an example of using SCTPPeer:
# Peer has multiple IPv6 addresses
SCTPPeer 2001:db8:1500:1::a100
SCTPPeer 2001:db8:1500:2::a100

4.14.39. SEModeSendASPUP

This flag defines if Radiator sends ASPUP when running in Single Exchange IPSP (IP Server Process) mode. This is not set by default.

4.14.40. SEModeWaitNotify

This flag defines if Radiator waits for NTFY(AS-INACTIVE) after ASP Up Ack and NTFY(AS-ACTIVE) before sending traffic to the peer. When set, notify messages are needed before traffic is sent to the peer which is typical for SGP-ASP communication where Radiator acts as an ASP. Otherwise ASP Active is sent immediately after ASP Up Ack which is typical for IPSP-IPSP communication. This is not set by default which means ASP Active is sent immediately after ASP UP Ack.

4.14.41. SPGroup

SPGroup is a string parameter for defining a group from which the reply for a MAP request is allowed from. SPGroup is not set by default and reply for a request must come from the SP that the request was originally sent to.
Here is a brief example of using SPGroup:
<MAP>
    # Set the default group for all SPs
    SPGroup group1

    <PeerSP 10.2.3.4>
        # This SP belongs to its own group
        SPGroup group2
    </PeerSP>
    <PeerSP 10.2.3.5>
        # SPGroup is not set, use value from the enclosing <MAP>
    </PeerSP>
    <PeerSP 10.2.3.6>
        # SPGroup is not set, use value from the enclosing <MAP>
    </PeerSP>
</MAP>

4.14.42. Timeout

This integer defines the used timeout when waiting for MAP responses.

4.14.43. TriggerFailure

When TriggerFailure is set, timed out requests, TCAP Abort primitive, MAP errors, and broken messages trigger a failure indication to upper layers, such as EAP-AKA, when the received message can be mapped to a sent message. Enabling TriggerFailure allows Radiator to reject authentication attempts instead of ignoring them. TriggerFailure is not set by default.
By default errors and time outs are logged and otherwise ignored. When the client has more than one RADIUS server configured, it can switch to a secondary server if the current server does not answer. This helps recovering from transient connectivity and other problems.
Here is an example of using TriggerFailure:
# We don't want cause time outs to RADIUS client
TriggerFailure

4.15. <PLMNDatabaseSQL>

This section describes the configuration parameters of a <PLMNDatabaseSQL> clause. This clause provides support for WLAN roaming for EAP-SIM, EAP-AKA and EAP-AKA' by looking up SCCP layer Peer Global Title and other PLMN information based on the currently authenticating end user's IMSI. PLMN information is needed to route the authentication and authorisation messages to the correct HLR/AuC, HSS or other target that holds the information for the IMSI.
To enable IMSI to PLMN information lookup, you need to modify Radiator configuration as follows:
  1. First define a <PLMNDatabaseSQL> clause with an Identifier parameter.
  2. Then add PLMNDatabase configuration parameter in MAP or PeerSP clauses using the value from step 1.
PLMNDatabase configuration parameter is supported for SIGTRAN and it's not yet available for Diameter or other authentication and authorisation methods. For required software versions and modules, see Section 2.1. Prerequisites. A configuration sample is in file goodies/plmndb.cfg
SQL query for looking up PLMN information is not yet configurable. The current default value works with the SQL schema the configuration sample uses.
PeerGlobalTitleHook runs after PLMN database lookup is done. This allows the hook to access and modify the looked up information, if needed.

4.15.2. RefreshPeriod

If this optional parameter is set to non-zero, it specifies the time period in seconds that PLMNDatabaseSQL uses to refresh the PLMN information by rereading the database. If set to 0, then PLMN information is only read from the database once at startup and on SIGHUP. Defaults to 0. The % formats are permitted.
When the RefreshPeriod expires and the information is read from the SQL database, all previously read information is replaced with the SQL information. When information from SQL can not be completely read, the old information is kept. Refresh from the SQL is attempted again when the refresh period elapses the next time.
# Reread the PLMN information every hour
RefreshPeriod 3600

4.16. <ServerWXMAP>

This section describes the configuring parameters of <ServerWXMAP>. Apart from the parameters listed here, <ServerWXMAP> inherits other parameters from AuthGeneric. These parameters are documented in Radiator reference manual Opens in new window under section <ServerDIAMETER>.

4.16.1. 3GPPCardDatabaseFilename

This string defines the file path and name where 3G USIM card details are stored. Radiator requires read and write access to this file and its directory. When defined, this parameter is used to find the Milenage algorithm parameters for SIM and USIM cards. See goodies/simcards.dat for a sample file.
The file contains the following information coded to hexadecimal:

4.16.2. IndLength

This integer defines the length of the IND part in bits in the AKA authentication vector SQN. The default value is 5.

4.16.3. TripletsFile

This string defines the path and name of the file containing the pre-generated triplets when vectors for EAP-SIM are requested. When defined, Radiator extracts the triplets from the specified file. If extracting fails or the file path and name are not defined, Radiator extracts the Milenage algorithms from a file specified in 3GPPCardDatabaseFilename and computes the triplets from the Milenage data.

4.17. <WxClient>

This section describes the configuring parameters of <WxClient>. Apart from the parameters listed here, <ServerWXMAP> inherits other parameters from DiaClient except PostDiaToRadiusConversionHook and PostRadiusToDiaConversionHook. These parameters are documented in Radiator reference manual Opens in new window under section <AuthBy DIAMETER>.

4.17.1. Interface

This string defines the interface supported by the <WxClient>. Possible values are Wx, SWx and Cx.

4.17.2. LocalAddress and LocalPort

These parameters control the address and optionally the port number used for the client source port, although this is usually not necessary. LocalPort is a string, it can be a port number or name. It binds the local port if LocalAddress is defined. If LocalPort is not specified or if it is set to 0, a port number is allocated in the usual way.
When SCTP multihoming is supported, multiple comma separated addresses can be configured. All addresses defined with LocalAddress must be either IPv4 or IPv6 addresses.
LocalAddress 203.63.154.29
LocalPort 12345

4.17.3. CxRealm and CxServerName

When the Interface parameter is set to Cx, Radiator uses the Diameter Cx interface, defined between IMS I-CSCF/S-CSCF and HSS, for fetching authentication vectors from the HSS. String parameters CxRealm and CxServerName are required for formatting Diameter attributes in Cx requests sent to the HSS. These parameters must be set accordingly to your naming conventions. They do not have a default value.
The configured value of CxRealm is used to set two attributes:
  • User-Name is set to IMSI@CxRealm
  • Public-Identity is set to sip:+IMSI@CxRealm
For example, when a client authenticates with IMSI 23201000000000 and CxRealm is set to ims.mnc001.mcc232.pub.3gppnetwork.org, Cx requests sent to the HSS contain User-Name with the value of 232010000000000@ims.mnc001.mcc232.pub.3gppnetwork.org and Public-Identity with the value of sip:+232010000000000@ims.mnc001.mcc232.pub.3gppnetwork.org
CxServerName sets the value of Server-Name attribute. The value of this attribute is in SIP-URL format and it identifies a SIP server (e.g. S-CSCF name) to the HSS. 
# The MNC and MCC values match a test SIM in goodies file aka-simulator.conf
CxRealm ims.mnc001.mcc232.pub.3gppnetwork.org
CxServerName scscf.ims.mnc001.mcc232.pub.3gppnetwork.org:6060

4.18. <IMSICrypt>

This section describes the configuration parameters of an <IMSICrypt> clause. This clause provides support for Permanent Identity encryption, sometimes also called IMSI encryption or IMSI privacy. IMSI encryption is specified in 3GPP document S3-170116 and Wireless Broadband Alliance technical specification IMSI Privacy Protection for Wi-Fi.
IMSI encryption is supported by all EAP-SIM, EAP-AKA, EAP-AKA' and 3GPP AAA Server configuration clauses. To enable IMSI encryption, you need to modify Radiator configuration as follows:
For required software versions and modules, see Section 2.1. Prerequisites. A full configuration example is in file goodies/imsicrypt.cfg

4.18.2. DefaultPrivateKeyFile

DefaultPrivateKeyFile defines a private key file name for a key that is used when an encrypted permanent identity does not have key identifier. You can configure multiple key files to support key roll over. Decryption is attempted with all key files until the first one succeeds. If no key is able to correctly decrypt an encrypted identity, an error is returned to the client and the authentication fails.
See the configuration example for more information.

4.18.3. DefaultPrivateKeyPassword

DefaultPrivateKeyPassword defines the password for decrypting a default private key defined with DefaultPrivateKey. Key encryption is optional. If a key is stored without encryption, this parameter is not needed. An encrypted key file and its respective password must be configured in pairs.
See the configuration example for more information.

4.18.4. PrivateKeyFile

PrivateKeyFile defines a private key file name in name=value,filename format. This key is used when an encrypted permanent identity sent by the client has a key identifier. Decryption is attempted only with the key that matches the key identifier the client sends. If the key is not able to correctly decrypt the encrypted identity, an error is returned to the client and the authentication fails. You should not configure more than one PrivateKeyFile parameter with the same name=value because only the latest parameter is used.
See the configuration example for more information.

4.18.5. PrivateKeyPassword

PrivateKeyPassword defines the password for decrypting a private key defined with PrivateKey. The format for this parameter is name=value,password where name and value must match the respective values of a PrivateKeyFile parameter. Key encryption is optional. If a key is stored without encryption, this parameter is not needed.
See the configuration example for more information.

4.19. <TemporaryIdentityAES>

This section describes the configuration parameters of an <TemporaryIdentityAES> clause. This clause provides support for creating pseudonym, also called Temporary Mobile Subscriber Identity (TMSI), and re-authentication identity values, by encrypting the IMSI together with a random string. See 3GPP TS 33.402 version 13.1.0, or later, Section 14 for the detailed algorithm. The algorithm was originally published in 3GPP TS 33.234 up to version 13.0.0 after which it was moved to TS 33.402. When IMSI based temporary identity generation is not enabled, random strings are used. This is the default behaviour.
Note
Currently only TMSI generation is supported. SQL database is not needed for storing TMSIs.
Both IMSI encryption, configured with <IMSICrypt>, and encrypted temporary identities can be enabled at the same time.
Temporary identities are supported by all EAP-SIM, EAP-AKA, EAP-AKA' and 3GPP AAA Server configuration clauses. To enable temporary identities, you need to modify Radiator configuration as follows:
For required software versions and modules, see Section 2.1. Prerequisites. A brief configuration sample is below and a full configuration example is in file goodies/temporary-identity.cfg
<TemporaryIdentityAES>
   # Identifier is used by AKA and SIM clauses to refer to this
   # clause for identity encryption and decryption.
   Identifier temporary-id-aes

   # Multiple keys can be configure at the same time.
   # CurrentKey defines the key that is actively used for encryption.
   CurrentKey 0

   # Keys are numbered from 0 to 15. CurrentKey sets the key that is used for
   # encryption. All configured keys are used decryption to allow key rollover.
   Key  0, 30303030303030303030303030303030
#  Key  1, %{GlobalVar:key1}
   Key 15, 00112233445566778899aabbccddeeff
</TemporaryIdentityAES>

<AuthBy AKAWX>
   # Other AKAWX configuration parameters
   TemporaryIdentity temporary-id-aes
</AuthBy>

4.19.1. CurrentKey

CurrentKey defines the value of KeyIndicator that is used to select the Key that is currently used for encryption. Values are from 0 to 15. When there is only one Key configured, defaults to it.
See the configuration example for more information.

4.19.2. Key

Key defines encryption key information in KeyIndicator, KeyValue format where KeyIndicator is a number from 0 to 15 and KeyValue is a string used to derive the encryption key, called Kpseu in 3GPP TS 33.402. When KeyValue is exactly 32 hexadecimal characters, it is used directly as the key. Otherwise it is made 16 octets long.
KeyValue supports special % formatting characters. This is typically used to include the key as a variable so that it's not directly visible in the configuration file. See the configuration example for more information.
Table of Contents Table of contents: Radiator® AAA Server Testing Radiator SIM Module 3 - Testing Radiator SIM Module Abbreviations 5 - Abbreviations