SBCs and Security – Part 2

SBCs and Security – Part 2

7 years ago 11 6334

Further to the last post on SBC security issues, I also found this section of the same IETF document that deals with architectural security issues related to the topology hiding functionality of an SBC, again ironic in that topology hiding is designed to provide security.

Here is the excerpt from section 3.1.2 of the IETF doc:

Performing topology hiding as described above by SBCs that do not have the users’ consent presents some issues. This functionality is based on a hop-by-hop trust model as opposed to an end-to-end trust model. The messages are modified without the subscriber’s consent and could potentially modify or remove information about the user’s privacy, security requirements, and higher-layer applications which are communicated end-to-end using SIP. Neither user agent in an end-to-end call has any way to distinguish the SBC actions from a Man-In-The-Middle (MitM) attack.

Topology hiding function does not work well with Authenticated Identity Management [4] in scenarios where the SBC does not have any kind of consent from the users. The Authenticated Identity Management mechanism is based on a hash value that is calculated from parts of From, To, Call-Id, CSeq, Date, and Contact header fields plus from the whole message body. If the authentication service is not provided by the SBC itself, the modification of the forementioned header fields and the message body is in violation of [4]. Some forms of topology hiding are in violation, because they are e.g., replacing the Contact header of a SIP message.

Again, anyone have any real-world experience to support this?