2.12.1 S6a/S6d Topology Hiding
In S6a/S6d transactions, a host name sent by the MME/SGSN in the Origin-Host AVP in a ULR message is saved by the HSS and used in the Destination-Host AVP for requests, such as the CLR, sent by the HSS. The figure below shows this linking of host names across Diameter transactions. As a result of this, it is necessary to ensure that a DSR receiving a CLR request from an untrusted peer network HSS can determine which MME/SGSN host is the target of the request.
With this approach, there is a configured mapping of real MME/SGSN host names to MME/SGSN pseudo-host names. When a request or answer associated with a protected network is forwarded towards an untrusted peer network, the MME/SGSN host name in the message is replaced by a MME/SGSN pseudo-host name. When are quest or answer is received by a DSR with TH enabled on the ingress Peer Node and it contains a MME/SGSN pseudo-host name, the MME/SGSN pseudo-host name is replaced by the real MME/SGSN host name.
Figure 2-45 MME/SGSN Topology Hiding
The MME/SGSN topology hiding feature also hides the number of MME/SGSNs in the protected network. To achieve this requirement the MME/SGSN Topology Hiding feature allows for the mapping of a variable number of MME/SGSN pseudo-host names per real MME/SGSN host name. For details on the configuration of the host names, see S6a/S6d Configuration.
The algorithm for selection of the MME/SGSN pseudo-host name ensures that the same MME/SGSN pseudo-host name is always selected for the same IMSI from the same MME/SGSN. This is to ensure that the HSS receiving a ULR doesn’t mistakenly think that the request is from a new MME/SGSN, triggering a CLR transaction. The MME/SGSN topology hiding feature also hides the host names included as part of the Session-Id AVP.
S6a/S6d HSS Topology Hiding
The S6a/S6d HSS topology hiding feature applies to all Diameter S6a/S6d messages between a protected network HSS and an untrusted peer network MME/SGSN. The HSS topology hiding feature also hides the number of HSSs in the protected network. To achieve this requirement the HSS Topology Hiding feature allows for the mapping of a variable number of HSS pseudo-host names per real HSS host name. For details on the configuration of the host names, see S6a/S6d Configuration.
For Diameter transactions originated by an MME/SGSN in an untrusted peer network, the following actions are taken for S6a/S6d HSS Topology Hiding:
- Request Messages – If the request message contains the Destination-Host address of S6a/S6d HSS and if HSS pseudo-name was selected from a list of HSS pseudo-names in previous S6a/S6d HSS Answer, then S6a/S6dHSS Topology Hiding restores the original S6a/S6d HSS addresses in the Destination-Host AVP. Restoral of Protected S6a/S6d HSS original host name is not done if single pseudo-name is used in S6a/S6d HSST opology Hiding. Instead this replacement is done by HSS Address resolution application such as DSR’s FABR or RBAR application.
- Answer Messages – The answer message contains the HSS real host name
in the Origin-Host AVP. This real host name is replaced based on one of the
following 2 methods for HSS pseudo host name selection.
- A single HSS pseudo-host name which has been defined for all the network HSS real host names in the protected Network.
- A HSS pseudo-host name selected from a list of HSS
pseudo-host names that have been defined for each real HSS host name in
the Protected Network (this approach is similar to the one described for
MME/SGSNT opology Hiding).
For Diameter transactions originated by the protected network HSS and targeted for an untrusted peer network MME/SGSN the following actions must be taken for S6a/S6d HSS Topology Hiding.
- Request Messages –
- The request message contains the HSS real host name in the Origin-Host AVP. Based on which HSS pseudo-host name selection method has been selected (as described above), this host name is replaced with either the single HSS pseudo-host name defined for all HSS real host names in the protected network,or by a HSS pseudo-host name from the list of HSS pseudo host names defined for each of the Protected Network real HSS host names.
- The request message also contains a Session-Id AVP that contains the HSS’s Diameter-ID. Based onwhich HSS pseudo-host name selection method has been selected (as described above), this HSS realhost name is also replaced with either the single HSS pseudo-host name defined for all HSS real hostnames in the protected network, or by a HSS pseudo-host name from the list of HSS pseudo host namesdefined for each of the Protected Network real HSS host names.
- Answer Messages –
- The answer message also contains a Session-Id AVP that contains a HSS pseudo host name in the Diameter-ID portion. This is replaced with the HSS real host name stored in the transaction state.
The figures below show message flows illustrating S6a/S6d HSS TH for requests originating at an untrusted peer network MME/SGSN as well as the protected network HSS.
Figure 2-46 S6a/S6d HSS Topology Hiding - ULR Message Flow
Figure 2-47 S6a-S6d HSS Topology Hiding CLR Message Flow
S6a/S6d Configuration
When configuring the Topology Hiding features a GUI is used to input the necessary data. The real host names of the network elements (MME/SGSN/HSSs) are entered. A pattern is entered that is used to generate the pseudo-host names. The DSR then generates from one to three pseudo-host names per entered MME/SGSN/HSS.
- mme1.westregion.example.com
- mme2.westregion.example.com
- mme1.eastregion.example.com
- mme2.eastregion.example.com
- mme1.texasregion.example.com
When configuring the topology hiding, the carrier enters these five real MME/SGSN host names. The carrier also enters the pattern to be used in generating the MME/SGSN pseudo-host names. The pattern is in the form:
prefix|digits|suffix
where the variable portion of the name is the digits field. For example, assume the carrier enters the following pattern:
prefix = “mme”
digits = “nnn”
suffix = “.example.com”
The resulting generated names look as follows:
mme|nnn|.example.co
In this case, the nnn portion of the MME/SGSN pseudo-host name contains three digits used to differentiate the MME/SGSN pseudo-host names.
Table 2-11 MME/SGSN PSEUDO-HOST NAME MAPPING EXAMPLE
| MME/SGSN Real HostName | MME/SGSN Pseudo-Host Name(s) | - | - |
|---|---|---|---|
| mme1.westregion.example.com | mme042.example.com | mme123.example.com | - |
| mme2.westregion.example.com | mme533.example.com | - | - |
| mme1.eastregion.example.com | mme922.example.com | - | - |
| mme2.eastregion.example.com | mme411.example.com | mme218.example.com | mme331.example.com |
| mme1.texasregion.example.com | mme776.example.com | mme295.example.com | mme333.example.com |
This mapping is then used for replacing MME/SGSN real host names with MME/SGSN pseudo-host names for messages directed toward the untrusted peer network HSS and for replacing MME/SGSN pseudo-host names with real host names for messages from the untrusted peer network HSS targeted for a protected network MME/SGSN. These same steps are used to create the pseudo-host names for HSSs to support S6a/S6d HSS topology hiding.