2.12.2 Path Topology Hiding
Path Topology Hiding is the most generic form of topology hiding. It is required for Topology Hiding on any Diameter interface type. Path Topology Hiding involves removing Diameter host names from the Route-RecordAVPs included in request messages. This feature does more than just Path Topology Hiding. It might be better called Diameter Topology Hiding, as there are host names that are hidden that are beyond just the path recorded in Route-Record AVPs. This feature hides all of the host names included by the base Diameter protocol, with the exception of the Session-Id header, which is left to the TH feature for the specific interface to handle.
Path Topology Hiding also hides addresses in other AVPs that are part of the base Diameter specification. This includes the following:
- The Error-Reporting-Host AVP contains the name of the host that generated an error response. When present,this host name needs to be obscured in answer messages.
- The Proxy-Host which is an embedded AVP within the grouped Proxy-Info
AVP contains the name of a proxy that handled a request. This is used as a way for
the proxy to insert state into a request message and receive the state back in the
answer message. As such, the method for hiding the name of the Proxy-Host name must
allow for reconstruction of the name when the answer message is received.
Route-Record Hiding
The Route-Record AVP has two uses in Diameter signaling:- The primary purpose is to detect loops in the routing of
Diameter Request. In this case, a Diameter Relay or Proxy looks at
Route-Record AVPs to determine if a message loop has or will occur. This is
detected either by the relay or proxy (the DSR in our case) finding its own
host-id in the Route-Record message or by the DSR determining that the host
to which the request is to be routed in the Route-Record AVP(referred to as
forward loop detection). Note that not all Diameter Relays/Proxies do
forward loop detection. The DSR, however, does.
Note:
For the purposes of this feature, the definition of a loop is modified slightly to include any time that a Request leaves the home or interworking network and then returns to the home or interworking network. This is independent of the DEA or DIA at which request returns to the home or interworking network. This means that a Request leaving the network on one DEA/DIA and returning to the network on a different DEA/DIA is considered a loop. - The other defined purpose of the Route-Record AVP is for authorization of the request. A Diameter service might not want to accept a request if it has traveled through a suspect realm. While the DSR does not support such an authorization feature, the Path TH feature does not remove the ability for other Diameter agents or servers to use the Route-Record AVPs to authorize the request.
- The primary purpose is to detect loops in the routing of
Diameter Request. In this case, a Diameter Relay or Proxy looks at
Route-Record AVPs to determine if a message loop has or will occur. This is
detected either by the relay or proxy (the DSR in our case) finding its own
host-id in the Route-Record message or by the DSR determining that the host
to which the request is to be routed in the Route-Record AVP(referred to as
forward loop detection). Note that not all Diameter Relays/Proxies do
forward loop detection. The DSR, however, does.
Each Route-Record AVP contains a Host-Id of a Diameter node that has handled the request. A Relay/ProxyAgent inserts a Route-Record AVP into the message containing the Host-Id of the Diameter node from which itreceived the request.
It is the Protected Network’s Host-Ids included in the Route-Record AVPs that need to be hidden.
For Request messages leaving a protected network, the Path TH feature handles Route-Record AVPs by stripping the protected network’s Route-Record AVPs and replacing them with a single Route-Record AVP containing a Route-Record pseudo-host name.
For example, the following request:
xxR
...
Route-Record: host1.protectednetwork1.net
Route-Record: host2.protectednetwork1.net
...
Would be modified to the following:
xxR
...
Route-Record: pseudohost.protectednetwork1.net
...
Route-Record AVPs for network other than the Protected Network are preserved. As such, the following request:
xxR
...
Route-Record: host.foreign1.net
Route-Record: host.foreign2.net
Route-Record: host.protectednetwork1.net
...
Would be modified to the following:
xxR
...
Route-Record: host.foreign1.net
Route-Record: host.foreign2.net
Route-Record: pseudohost.protectednetwork1.net
...
For requests ingressing into a protected network, the Path TH feature examines the Route-Record headers in the request. If any of the Route-Record AVPs contains a host name matching a protected network’s Route Record pseudo-host name then the DSR considers it a loop and returns an answer message with Result-Code AVP value3005 (DIAMETER_LOOP_DETECTED).
- Proxy-Host AVP (embedded in the grouped Proxy-Info AVP).
- Error-Reporting-Host AVP.
Proxy-Host Hiding
The handling of the Proxy-Host AVP can be achieved using a pseudo-host name. In this case, the real name is stored in the pending transaction record. The pseudo-host name found in the answer message is replaced by the real host name stored in the pending transaction record. The figure below shows a simple message flow illustrating this functionality.
Figure 2-48 Proxy-Host Topology Hiding Message Flow
Error-Reporting-Host Hiding
When obscuring the Error-Reporting-Host AVP the real host name is recovered in case it is needed for troubleshooting activities. Encryption is used for obscuring the Error-Reporting-Host AVP. This allows for troubleshooters in the protected network to decrypt the AVP to determine the original value. The encryption algorithm used only requires the operator to know the key for decrypting this value in a common troubleshooting tool such as Wireshark.