5.2 Session Border Controller Functions and Implementation
5.2.1 Access Control
5.2.1.1 Access Control Approaches
Access control by filtering IP traffic can be applied only to the signalling, or to both the signalling and the media. If it is applied only to the signalling, then the SBC can be thought to operate as a proxy server. On the other hand, if access control is applied to both the signalling and media, then the SBC can be thought to operate as B2BUA and media proxy. A key part of media-layer access control is that only media for authorized sessions is allowed to pass through the SBC.
If the access control is applied to both signalling and media, then firewall pinholes are dynamically opened and closed for media and authorized signalling after authenticating with an external signalling node. This helps to limit the traffic entering the service platform to flows generated by authenticated endpoints, thus limiting the impact of denials of service (DoS) and other network based attacks
In both of the cases, proxy and B2BUA, the SBC needs to handle every single signalling message. This function has scalability implications. In addition, the SBC is a single point of failure from the architectural point of view. Many current SBCs, however, have redundant configuration, which prevents the loss of calls/sessions in the event of a failure.
The nodes used as the sources of access control information can be SIP proxies, registrars or H.323 gatekeepers in the service platform. They have to be trusted by the service provider to contain correct information and configuration [Jun05].
The signalling based access control function can be achieved by co-operation of the firewall packet filter module, the signalling processing module and the core SBC application.
The following Figure 14 shows a successful registration example with SIP [Joh04], [Cam05].
SBC
Access Network Service Provider Network
R SIP User Agent
REGIS TE R
Registrar
REGIS TE R
200 OK 200 OK
Figure 14 User Agent registration
1. SIP User Agent sends REGISTER request to the SBC
2. The SBC modifies the REGISTER request by inserting itself to the path header field, or modifying the original UA Contact header field to point at the SBC instead of the original. Then the SBC sends the modified REGISTER to the SIP registration server, also known as a registrar.
3. The registrar responds to the SBC with SIP 200 OK response to indicate successful authentication
4. The SBC responds to the User Agent with 200 OK response
Before a valid authentication, the UA located in the access network has very limited access to the service provider service platform network. It can only access the access network side of the SBC. Access to the rest of the platform is blocked without valid authentication. Figure 15 below illustrates, how the UA, SBC and registrar and other SIP nodes in this example are located.
SBC
Access Network Service Provider Network
SIP User Agent
Proxy/Registrar
Media GW App Server, etc.
Figure 15 Network topology
The following call flow in Figure 16 illustrates the creation and teardown of a SIP session with SBC in the path. A user agent A initiates the session creation and teardown.
SBC
Figure 16 SIP session with SBC in the path
The following list explains what happens in Figure 16.
1. The User Agent A sends an INVITE to the SBC without Proxy-Authorization header field
2. The SBC forwards the INVITE to the proxy server.
3. The proxy requires authentication, and responds with 407 Proxy Authentication Required response containing challenge information
4. The SBC receives the response and sends ACK to the proxy
5. The SBC forwards the with 407 Proxy Authentication Required response to the User Agent A
6. The User Agent A send ACK to the SBC
7. The User Agent sends an new INVITE carrying the credentials to the SBC
8. The SBC forwards the INVITE to the proxy server.
9. The proxy receives the INVITE with appropriate credentials
10. The proxy processes the entry matching its own realm, leaving the remaining entries intact and forwards the INVITE to the User Agent B
11. The User Agent B responds with a 180 Ringing response to the proxy 12. The proxy forwards the 180 Ringing response to the SBC
13. The SBC forwards the 180 Ringing response to the User Agent A
14. When the User Agent B answers the incoming call a 200 OK response is sent to the proxy
15. The proxy forwards the 200 OK response to the SBC
16. The SBC forwards the 200 OK response to the User Agent A 17. The User Agent A responds with ACK to the SBC
18. The SBC forwards the ACK to the User Agent B
At this time both way media path is established. The call flow in Figure 16 shows two media path cases. The first case illustrates operating in B2BUA with media proxy mode and the second proxy mode.
In B2BUA mode, the media path setup is not end-to-end – the SBC terminates both media streams and bridges them. In order to terminate the media streams, SBC modifies the SDP carried in the SIP messages to point to itself instead of the original user agent.
The SDP is modified before forwarding it to the direction of the destination user agent.
The modification points are illustrated in the Figure 16.
In the SBC reference model the SDP information is passed from the Signalling Processing to the SBC Core Application which implements the B2BUA. The B2BUA makes the SDP modifications and passes the information back to the Signalling Processing to establish the other SIP session. In addition to the SDP modification, the Media Proxy function is configured for bridging of the two individual media streams according to the SDP information.
In proxy mode the media path setup is end-to-end between user agents and no SDP rewriting is done. The SBC can either be in the media path, or not. In a case where the
SBC is in the path, access control of the media can be done. In this case the SBC merely forwards the authorized RTP packets carrying the media stream as a traditional firewall would and drops the packets that have not been authorized.
In the SBC reference model SDP information is passed to the SBC core application, which in this case implements proxy functionality. In this case however, no signalling modification is performed. The SDP information is used to open firewall pinholes on the Firewall module in order to allow the RTP packet to be forwarded.
The User Agent A initiates the teardown of the session.
19. User Agent A sends BYE to the SBC
20. The SBC forward the BYE message to the User Agent B 21. The User Agent B responds to the SBC with 200 OK 22. The SBC forwards the 200 OK response to User Agent A
When the session ends, the SBC removes the media-bridging configuration of B2BUA mode or the firewall pinholes created in proxy mode. From an access control point of view, the access of User Agent A through the SBC is blocked until a new authorized session is granted.