@miconda
Thank you for the feedback. I agree that my initial approach—only hiding up to the last Record-Route (RR) header—was incorrect, as it doesn’t account for scenarios where the Topoh proxy (e.g., P-CSCF) is not the last entity in the RR chain.
However, I believe there’s a misunderstanding about the specific issue in the IMS topology I’m working with. Let me clarify the problem more precisely.
Scenario
In an IMS setup, due to spiraling behavior (e.g., S-CSCF -> I-CSCF -> S-CSCF), the same proxy (like P-CSCF) may appear multiple times in the Record-Route list. For example, in the 180 Ringing or 200 OK responses sent from the core network back to the UE, the RR headers might look like:
Record-Route: PCSCF
Record-Route: SCSCF
Record-Route: SCSCF
Record-Route: PCSCF
Here, P-CSCF (which is running Topoh) appears twice—once at the beginning and once at the end. However, the current Topoh implementation works by scanning RRs top-down and stops at the first occurrence of its own IP. That means in this example, none of the RR headers are hidden, because the first occurrence of its IP is at the top of the list.
In this case, Topoh fails to hide any RR headers, which results in exposing internal IPs (like those of S-CSCF). This breaks the topology hiding requirement expected in IMS.
Suggested Behavior
Instead of stopping at the first match of its own IP in the RR headers, Topoh should:
- First, scan all Record-Route headers to find the last occurrence of its own IP.
- Then, hide all Record-Route headers up to that position.
This ensures that:
All internal hop headers before and including the last instance of the Topoh proxy are hidden.
Any legitimate Record-Route headers after the Topoh proxy (e.g., from a downstream proxy or UE) remain intact.
I'd appreciate your thoughts on whether this approach aligns with the original design goals of Topoh, especially with respect to spiraling.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4170/c2782942577@github.com>
@miconda
Thank you for the feedback. I agree that my initial approach—only hiding up to the last Record-Route (RR) header—was incorrect, as it doesn’t account for scenarios where the Topoh proxy (e.g., P-CSCF) is not the last entity in the RR chain.
However, I believe there’s a misunderstanding about the specific issue in the IMS topology I’m working with. Let me clarify the problem more precisely.
Scenario
In an IMS setup, due to spiraling behavior (e.g., S-CSCF -> I-CSCF -> S-CSCF), the same proxy (like P-CSCF) may appear multiple times in the Record-Route list. For example, in the 180 Ringing or 200 OK responses sent from the core network back to the UE, the RR headers might look like:
Record-Route: PCSCF
Record-Route: SCSCF
Record-Route: SCSCF
Record-Route: PCSCF
Here, P-CSCF (which is running Topoh) appears twice—once at the beginning and once at the end. However, the current Topoh implementation works by scanning RRs top-down and stops at the first occurrence of its own IP. That means in this example, none of the RR headers are hidden, because the first occurrence of its IP is at the top of the list.
In this case, Topoh fails to hide any RR headers, which results in exposing internal IPs (like those of S-CSCF). This breaks the topology hiding requirement expected in IMS.
Suggested Behavior
Instead of stopping at the first match of its own IP in the RR headers, Topoh should:
- First, scan all Record-Route headers to find the last occurrence of its own IP.
- Then, hide all Record-Route headers up to that position.
This ensures that:
All internal hop headers before and including the last instance of the Topoh proxy are hidden.
Any legitimate Record-Route headers after the Topoh proxy (e.g., from a downstream proxy or UE) remain intact.
I'd appreciate your thoughts on whether this approach aligns with the original design goals of Topoh, especially with respect to spiraling.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <kamailio/kamailio/pull/4170/c2782942577@github.com>
Fr-Soltanzadeh left a comment