. 120
( 132 .)


Figure 9.20 SIP QoS negotiation with SDP parameters

Figure 9.21(a) shows the call ¬‚ow. When the called party™s QoS fails, they respond
to the INVITE with 580-precondition-failure ¬nal response rejecting the call. The calling
UA releases the QoS requested locally and signals back the user that the call failed.
Figure 9.21(b) shows the call ¬‚ow when the caller™s QoS request fails. In this case the
CANCEL message is used to drop the call; the other party responds with 487 request
terminated. Note that in both cases the called party™s phone does not ring.

9.5.17 SIP security
Without some degree of security, attacking the services of a SIP network would not be
dif¬cult. Possible attack methods might be to:


request QoS request QoS

183 Session Progress (SDP2) 183 Session Progress (SDP2)

request QoS
request QoS

200 OK (for PRACK) 200 OK (for PRACK)

reject QoS confirm QoS
reject QoS
580 precondition failure CANCEL

release QoS release QoS
ACK 200 OK (for CANCEL)

487 request terminated
(for INVITE)

(a) (b)

Figure 9.21 Call ¬‚ow with failure to establish QoS

1. add a false registry binding, forwarding all sessions to the hacker™s SIP phone or
2. introduce a spoof proxy server that would forward sessions to the hacker™s SIP phone
or email;
3. make calls on somebody else™s account and at their cost, spoo¬ng their SIP address;
4. perform a denial of service attack against the SIP network.

Each of these attacks is made possible by the fact that SIP messages are being carried
on an IP network which may not be physically secure. An attacker could snoop the
network using a network analyser, looking for SIP messages. This type of attack not only
allows the user to invade the privacy of other users of the network, it also can be used
as a platform to perform more complex hacking activities such as setting up false calls
or interfering with SIP registrations. A denial of service attack could be carried out by
possibly bombarding a SIP server with more call requests than it can cope with. To help
protect against these attacks a number of security services are required: authentication
and integrity protection, privacy and denial of service attack protection.
Three main approaches to providing security with SIP are commonly used: SIP-based,
TLS or IPSec. SIP-based security allows for user authentication only. TLS security secures
TCP connections for each SIP message transfer hop by hop. TLS is not used for secure IP
communication in UMTS since it precludes the use of UDP. IPSec provides network level
security for SIP communications regardless of the transport protocol, and for this reason,
as well as the fact that IPSec is a mandatory requirement of IPv6, 3GPP recommends the
use of IPSec ESP to protect all IP communications carrying core network signalling.
590 RELEASE 5 AND BEYOND (ALL-IP) Authentication and integrity

Authentication services establish the identity of the origin of the message, while integrity
checking ensures that the message has not been modi¬ed in transit. Messages sent between
SIP UAs and SIP servers should be correctly authenticated and integrity protected. This
is to guard against attacks based on user or server spoo¬ng (attack scenarios 1, 2 and 3).
Using SIP messaging, authentication is the only service provided (no integrity pro-
tection). SIP authentication is de¬ned as a mandatory requirement in RFC 3261 for all
registration requests but can be used with any SIP message. This will protect against
a hacker providing new false registrations but does not stop active attacks such as the
contact ¬eld in the registration request being modi¬ed en route. For networks where
active attacks are possible, TLS or IPSec should be used. SIP authentication is based on
a challenge/response model. The initial message from the sender is challenged with a
401 unauthorized or 407 proxy authentication required (for proxy services) response. The
challenge information is contained within WWW-Authentication and Proxy-Authenticate
headers for 401 and 407 responses, respectively. The request must then be sent again,
this time containing the appropriate authorization header or proxy authorization header
containing the correct credentials for the user.
An authenticated registration request is shown in Figure 9.22. First, the registration is
rejected by the proxy with a 407 response containing the challenge. The UA resubmits
the request with a proxy authorization ¬eld containing the authentication response. The
request is then forwarded to the registrar, which also requires authentication. It responds
with a 401 containing its challenge, which is then forwarded by the proxy to the UA.
The UA now resubmits the request a third time. This time it contains authentication
credentials for both the registrar and the proxy. The request is forwarded to the registrar,
which checks the credentials and the registration succeeds.

UA Proxy Registrar


407 Proxy Unauthorised


401 Unauthorised
401 Unauthorised


Figure 9.22 Authenticated registration

The exact method to produce the response can vary from application to application;
3GPP de¬nes its own technique in 3GPP 33.203 for the authentication of registra-
tion requests.
3GPP 33.203 mandates the use of IPSec in ESP mode for the authentication and integrity
protection of all other SIP requests/responses (i.e. not REGISTER) between the UA and
P-CSCF. These techniques are described in Section 9.7.3.
Between all other core network elements using IP to communicate (e.g. SIP proxy or
registrars) 3GPP 33.210 speci¬es the use of IPSec ESP headers to provide authentica-
tion/integrity protection. Privacy
This is to guard against the snooping of SIP messages on the network. Without protection,
a subscriber™s con¬dential call data can be accessed. 3GPP 33.210 states that IPSec ESP
con¬dentiality shall be used for all IP communications crossing the interface between
different operators or security domains, but using the authentication/integrity only option
is allowed. For all IP communication within an operator™s network the use of IPSec ESP
con¬dentiality is optional. Denial of service attack
This is probably one of the most dif¬cult attacks to protect the SIP network against.
Techniques that may be deployed include:

• Hot standby backups for SIP servers: these can be con¬gured as clusters and use the
virtual router redundancy protocol (VRRP; see Chapter 5) or M3UA to communicate
service state.
• Stateless SIP proxy servers: these are useful since they do not keep call state. A hacker
attacking a stateful proxy could overwhelm the server by initiating many different
INVITE requests. For each request the proxy needs to allocate memory; eventually the
proxy may run out of memory and fail. All servers that provide authentication on a
SIP network should perform the authentication in a stateless manner. This will protect
against hackers who are currently not authenticated attacking the network. Attacks
from nodes which are already authenticated can then be logged and the authenticated
hacker identi¬ed.

9.5.18 SIP“PSTN interworking
Not all calls will use IP end-to-end. For example, many VoIP sessions from the IMS will
need to be terminated within legacy PSTNs. At the interface between the two domains
there will be a requirement for interworking. The SIP-T (SIP for Telephones, RFC 3372)
de¬nes an architectural framework in which legacy telephony signalling can be incorpo-
rated into SIP messages. Two types of service are de¬ned:

• mapping between SIP and PSTN messages (e.g. ISUP)
• tunnelling of PSTN parameters not supported in SIP.

The second service is required since there may be no equivalent mapping for some
PSTN signalling parameters within SIP.
In the examples given, the PSTN protocol shown is the ISDN User Part (ISUP), because
of its wide-scale deployment in modern telecommunications networks. The mapping of
ISUP to SIP is covered by RFC 3398. Some of the more important ISUP messages are
shown in Table 9.6. Their operation in the context of GSM is outlined in Chapter 3.
Figure 9.23 shows how a call originating in the SIP network is terminated in the PSTN.
To initiate the call, the SIP phone sends an INVITE to the gateway. This INVITE message
is translated by the gateway into the IAM message and forwarded to the PABX for call
routing to the ¬nal destination. If the address is valid and routable, the PABX will respond
with an ACM. At this point the call is in progress and as soon as the remote phone starts
to ring, an ALERTING signal will be sent back to the gateway from the PABX. This will
be translated by the gateway to the 180 RINGING provisional response. In practice, calls
over the PSTN cannot be guaranteed to be handled purely with ISDN end-to-end; for this
reason call progression indicators (busy, ringing, number unobtainable, etc.) are therefore
carried in-band as audio. This audio is generated at the terminating PSTN switch. This
in-band technique also allows the PSTN operator to provide instructions to the caller, such
as asking them to redial using a different pre¬x. To handle this situation, the SIP gateway
uses the session progression indication (SIP provisional response 183), which indicates
to the SIP phone that it should replay the audio stream or early media (containing the
ringing or busy tone or other message) received from the remote PSTN switch.
When the call is answered, the ANM message is sent back, which is translated by the
SIP gateway into the 200 OK response. The SIP phone sends an ACK to acknowledge
and the two parties can now talk over the speech channel. When the SIP caller hangs
up, the call is terminated by the SIP phone using the BYE message. This message is
translated to the ISUP REL message. Finally, the PSTN con¬rms the call release using
RLC and the gateway con¬rms the BYE message with a 200 OK.

Table 9.6 ISUP messages
ISUP message Description

IAM Initial Address Message Sent from call originator to the remote node and
is used to initiate call setup
ACM Address complete message Sent from remote node back to origin; con¬rms
that call setup is in progress.
ANM Answer message Sent from remote node back to origin to indicate
called party has answered the phone
CPG Call progress Sent from remote node back to origin to indicate
how call is progressing
REL Release Sent from either end to request release of
RLC Release complete Sent from either end to con¬rm release of

SIP Gateway PABX
SIP User Agent
Audio (Call Progress)

183 Session Progress

RTP media (call progress)

200 OK


RTP audio session Duplex speech

200 OK

Figure 9.23 SIP-PSTN call (outgoing to PSTN)

Figure 9.24 shows the call sequence for an incoming call from the PSTN network
into the SIP network. In this situation, the message translation is similar to the previous
example except the direction is reversed. Note that in this case, the SIP gateway itself
has to generate the in-band ring tone back to the calling PSTN phone.
For both call scenarios the gateway acts as a SIP UA, terminating and originating the
SIP signalling.

9.5.19 SIP bridging
Interworking from PSTN to SIP and SIP to PSTN works well for the most part but will
lead to loss of some of the signalling information. This is because a SIP message may
not contain all the corresponding header ¬elds in the ISUP message or vice versa. In fact,
there are a lot more ¬elds in ISUP than in SIP, leading to possibly considerable loss of
service. This is not a problem in the interworking examples shown above since the ISUP


. 120
( 132 .)