Vulnerability in IMS-Internet interworking:
analysis and relevant solutions
M. Mogno, I. Petrilli, M. Listanti
INFOCOM Dept.
University of Roma “La Sapienza”
Roma (Italy)
Abstract — Security is a crucial aspect when designing
telecommunication networks. This is even more important in the
transition from the third generation mobile networks to Beyond
3G networks (B3G). In fact, the adoption of all-IP networks
network paradigm involves a wide set of possible threats and
security attacks that should be avoided and/or mitigated in a
quick and efficient way. This paper illustrates a possible
interworking scenario between IMS and Internet. In particular
possible attacks involving SIP protocols are examined and some
guidelines to solutions are proposed.
Keywords-component: Network security, IMS, SIP, protocols.
I.
INTRODUCTION
Beyond Third Generation (B3G) networks aim to merge
two of the most successful paradigms in communications:
cellular networks and the Internet. The IP Multimedia
Subsystem (IMS) is the key element in the B3G architecture
that makes it possible to provide ubiquitous cellular access to
all the services that the Internet provides. The goal of IMS is to
support all the services, current and future, that the Internet
provides. In addition, users have to be able to execute all their
services when roaming as well as from their home networks.
The IMS principles foresee a complete migration towards
an all-IP architecture, in which both the user and the control
plane are based on the IP protocol stack. In particular, the
control plane and the call control functions will be supported
by the Session Initiation Protocol (SIP) [1]. The IMS is defined
independently of the type of access and its services can be
accessed from any IP networks external to the IMS (e.g. GPRS,
UTRAN, WLAN, xDSL access, etc.) A full IP connectivity,
possibly based on IPv6 protocol, will be offered to each user.
components: i) the Network Domain Security (NDS) and ii) the
IMS Access Security.
The NDS provides IP security between different domains
and nodes within a domain. Integrity and possibly
confidentiality of information exchanged between entities
internal to a domain are protected by the IPSec protocol via the
creation of specific Security Associations (SAs). Traffic
entering and leaving a domain passes through a SEcurity
Gateway (SEG). A SEG is responsible of the application of the
security policies on the traffic incoming to and outgoing from
the SD; such policies may also include packet filtering and/or
firewall functionality. Each SEG maintains IPSec SAs with
other SEGs of other domains [2].
The IMS access security includes protection and security
functionality associated to the SIP protocol. The SIP is used for
the creation, management and tear down of the multimedia
sessions. The procedures defined to assure the access security
by a user to the IMS are described in [12].
As far as the specific area of SIP security is concerned,
many studies are available in literature, example (e.g [7], [8],
[9], [10], [11]). These papers, on the one hand, deal with
possible SIP vulnerabilities and attacks and, on the other one,
propose some countermeasures to increase the protocol
security. Moreover, IETF published a series of RFC regarding
SIP security [13], [14], [15], [16]. In these RFCs the use of
security protocols either at transport layer (TLS) [5] or at the
network layer (IPSec) [17] is suggested.
Security is now becoming a crucial aspect when designing
telecommunication networks; this is even more important in
IMS, in fact the adoption of all-IP networks involves the full
opening and access to the network and its protocols to a wide
set of possible threats and security attacks that should be
avoided and/or mitigated in a quick and efficient way.
Nevertheless, due to the new SIP application environments
and the wider and wider functions that it supports, the SIP
security is still open problem that has to be examined in depth
to find suitable solutions. Particular attention is required in SIP
implementation in order to obtain an adequate level of security.
The critical elements to be considered are: i) a diffused use of
mediation devices as Proxy servers, Registar servers and
Redirect servers; ii) possible interactions with network
elements no trusted relationship exists to; iii) the possible
exchange of user-to-user signalling traffic.
According to 3GPP standards, the central component of the
UMTS security architecture is the Authentication and Key
Agreement (AKA) procedure. The AKA serves to mutually
authenticate the MS (i.e., the USIM) and the network, and at
the same time exchange the session keys that will be used for
encryption and integrity check. Besides the AKA protocol, the
IMS security architecture is composed by other two
In this paper, a possible interworking scenario in which a
legitimate user in the Internet can access the IP Multimedia
Subsystem (IMS) to get its services is considered. In this
context, one of the vulnerability points of the IMS reference
architecture is located at the Mm Reference Point, i.e. the access
interface between the IMS domain and another external IP
domain. In this case, to avoid that security threats, generated by
external users belonging to IP domains in which the security
level is non adequately controlled, damage the IMS internal
resources it is needed to provide specific control functionality
at the boundary between two network domains.
The purposes of this paper are: i) to specify some possible
attacks to SIP procedure deriving from the interaction between
IMS and the external unprotected Internet world; ii) to propose
some possible guidelines to achieve SIP security even in the
considered scenario.
In particular, in Sec. II the considered interworking
scenario between IMS and Internet is presented, whereas in
Sec. III the main security threats and attacks concerning SIP
protocol are classified and discussed in detail. In Sec. IV some
possible security solutions are proposed and briefly compared.
Finally, Sec. V summarizes the main conclusions of this work.
II.
NETWORK SCENARIO AND ATTACK CLASSIFICATION
A. IMS/Internet interworking scenario.
Support for interworking of IMS with the Internet is an
obvious requirement, given that the Internet offers millions of
potential destinations for multimedia sessions initiated in the
IMS. By requiring interworking with the Internet, the number
of potential sources and destinations for multimedia sessions is
dramatically expanded.
S - CSCF
Service
Platform
Mm
Network
A
I -CSCF
Visited
Network
Za
Registrar
SIP
Proxy
SIP
SEG
SEG
A
V
P -CSCF
Access
Network
GGSN
User
Agent
Attacker
User
Equipment
Internet
Fig. 1 – IMS/Internet interworking scenario for security aspect analyisis.
Interworking between the IMS and non-IMS SIP-based
networks is not still mature. There is still a need to define the
behaviour of IMS entities when a SIP entity on the Internet
does not support some of the extensions used in the IMS (e.g.
preconditions).
The assumed IMS/Internet interworking scenario is shown
in Fig. 1. The IMS environment is supposed to be secure, as
well as the Mm interface, whereas the Internet domain is
unprotected or cannot guarantee an adequate level of
protection, so that a fraudulent user (attacker) can sniff the SIP
traffic crossing this domain and can have almost unlimited
access to the carried data.
B. SIP threats classification
According to the traditional definition, network security
comprises integrity, confidentiality and availability. Message
integrity ensures that if an unauthorized party modifies a
message between the sender and the receiver, the receiver is
able to detect this modification. In addition to message
integrity, integrity mechanisms always provide some type of
proof of data origin. Knowing that a message has not been
modified without knowing who initially created the message
would be useless.
Confidentiality mechanisms keep unauthorized parties from
getting access to the contents of a message. Confidentiality is
typically achieved through encryption.
DoS (Denial of Service) attacks compromise the system
availability by keeping authorized users from accessing a
particular service. The most common DoS attack consists of
keeping the servers busy performing an operation or sending
the servers more traffic than they can handle.
SIP provides several security mechanisms to address
integrity, confidentiality and availability. Some of the security
mechanisms come from the world of the web, some come from
the world of email and some of them are SIP-specific.
The purpose of this section is to list possible security
threats to the IMS system, detailing what the threats achieve,
how they are carried out and where in the system they could
occur. It is possible to classify security threats in many
different ways [3]; in this paper the following threats categories
have been considered.
 Violation of confidentiality.
o Eavesdropping: An intruder intercepts messages without
detection.
o Masquerading: An intruder hoaxes an authorised user into
believing that they are the legitimate system to obtain
confidential information from the user; or an intruder
hoaxes a legitimate system into believing that they are an
authorised user to obtain system service or confidential
information.
o Traffic analysis: An intruder observes the time, rate,
length, source, and destination of messages to determine a
user’s location or to learn whether an important business
transaction is taking place.
o Browsing: An intruder searches data storage for sensitive
information.
o Leakage: An intruder obtains sensitive information by
exploiting processes with legitimate access to the data.
o Inference: An intruder observes a reaction from a system
by sending a query or signal to the system. For example,
an intruder may actively initiate communications sessions
and then obtain access to information through observation
of the time, rate, length, sources or destinations of
associated messages on the radio interface.
 Violation of integrity.
o Manipulation of messages: Messages may be deliberately
modified, inserted, replayed, or deleted by an intruder.
 Denial of service.
o Intervention: An intruder may prevent an authorised user
from using a service by jamming the user’s traffic,
signalling, or control data.
o Resource exhaustion: An intruder may prevent an
authorised user from using a service by overloading the
service.
o Misuse of privileges: A user or a serving network may
exploit their privileges to obtain unauthorised services or
information.
o Abuse of services: An intruder may abuse some special
service or facility to gain an advantage or to cause
disruption to the network.
o Repudiation: A user or a network denies actions that have
taken place.
 Unauthorised access to services
o Intruders can access services by masquerading as users or
network entities.
o Users or network entities can get unauthorised access to
services by misusing their access rights.
A number of security threats belonging to these categories
are subsequently discussed in detail in the next section. A more
complete description of possible attacks to SIP are contained in
[4].
III.
ATTACKS
A. Violation of confidentiality.
1) Eavesdropping user traffic.
This attack belongs to “man in the middle” category and is
utilized by an intruder to intercept the information flows
emitted by the two legitimate users involved in a SIP session.
This effect is obtained by means of the generation of a reINVITE SIP message in which the IP addresses and possibly
the dialog parameters are modified with respect to those
exchanged in the original SIP setup phase.
The intruder needs to sniff the messages exchanged
between the two users during the set-up phase of the SIP
session in order to acquire the main dialog parameters. After
this preliminary phase, the intruder emits a re-INVITE message
towards both the victims (Fig. 2) indicating, in the parameter
“c” of the SDP message body, his own IP address as the
destination address of the multimedia flow. After the reception
of this message, both the victims will respond with a 200 OK
message. It is to be noted that, the 200 OK messages are
addressed towards the legitimate users (Alice and Bob in Fig.
2), in fact the SIP addresses contained in the re-INVITE have
not been changed by the intruder.
As soon as the intruder will sniff the 200 OK messages, he
will emit the OK messages to close the re-negotiation phase.
From now on, in order to remain invisible to the victims, the
intruder will forward the received information flows towards
the legitimate users by modifying the source address within the
forwarded IP packets.
This attack can be successfully operated since in the IMS
integrity and confidentiality checks are not performed in the
messages emitted by the users after the completion of their
registration phase. This is due to the fact that IMS supposes
that after the registration phase all the traffic is protected by the
IPSec protocol, whereas, in an open environment as Internet,
this condition can not supposed as always true.
Alice
sip:victimA@atlanta.com
192.0.1.101
SEG
Bob
sip:victimB@biloxi.com
5555::aaa:bbb:ccc:ddd
RTP flow between Victim A & Victim B
SIP Proxy
Attacker
sip:proxy@atlanta.com
sip:attacker@hacker.com
192.0.1.110
192.0.3.103
INVITE sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=5432532
To: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 2 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
INVITE sip:victimA@atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.102
Max-Forwards: 70
From: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
To: "Alice"
<sip:victimA@atlanta.com>;tag=5432532
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.biloxi.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.102
s=c=IN IP4 192.0.3.103
…
v=0
o=- 2987933615 2987933615 IN IP4 192.0.1.101
s=c=IN IP4 192.0.3.103
…
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.102
From: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
To: "Alice"
<sip:victimA@atlanta.com>;tag=5432532
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.1.101
From: "Alice"
<sip:victimA@atlanta.com>;tag=5432532
To: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 2 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.1.101
s=c=IN IP4 192.0.1.101
…
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.102
s=c=IN IP4 192.0.2.102
Bob’s IPv4
…
ACK sip:victimA@atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.102
Max-Forwards: 70
From: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
To: "Alice"
<sip:victimA@atlanta.com>;tag=5432532
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 ACK
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Length: 0
ACK sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=5432532
To: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 2 ACK
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Length: 0
RTP flow between Victim A & Victim B
RTP flow between Victim A & Victim B
Fig. 2 - Modifying IP address
2) Compromise of location information.
This attack, as the previous one, belongs to the “man in the
middle” class and is based on the vulnerability of the 3xx
response messages (Redirection).
By supposing the network scenario shown in Fig. 1, the
intruder emits a 302 Moved Temporarily message assuming the
identity of the destination contained in the INVITE previously
emitted by the victim (Alice in Fig. 3). By inserting his own IP
address in the field “Contact” of the SIP header of the 302
response, the attacker re-directs towards himself the successive
requests emitted by Alice.
It is crucial that the attacker sends the 302 response as soon
as he intercepted the INVITE message; in this way the response
of the legitimate destination user (Bob in Fig. 3) will be
ignored by the victim. Moreover, the parameters To, From,
Call-ID of the 302 response have to be identical to those
contained in the request, so that Alice recognizes that the
received response belongs to the current SIP dialog. At this
point in time, Alice will send a new INVITE message addressed
towards the intruder, that, in order to remain unknown to the
legitimate users, will forward the messages towards Bob by
inserting in the SIP header a field Record-Route containing his
IP address. From now on, every requests and responses
relevant to current SIP session will transit through the intruder
UA.
3) Eavesdropping signalling
In this attack belonging to the “Man in the middle” class,
the intruder aims at impersonating a SIP Proxy Server.
The reception of a 305 Use Proxy response indicates to an
UAC that a specified resource has to be reached by means a
Proxy specified in the field “Contact”. When this event occurs,
the UAC has to present a new request properly modified
according to the indications contained in the 305 Use Proxy
message.
IP address. From now on, every messages relevant to current
SIP session will transit through the intruder UA.
B. Denial of service (DoS).
1) Tearing down a session
Alice
sip:victimA@atlanta.com
192.0.1.101
SEG
INVITE sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
Bob
sip:victimB@biloxi.com
5555::aaa:bbb:ccc:ddd
SIP Proxy
sip:proxy@atlanta.com
192.0.1.110
Attacker
sip:attacker@hacker.com
192.0.3.103
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 192.0.1.101
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob"
<sip:victimB@biloxi.com>;tag=46453645
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:victimB@192.0.3.103>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
INVITE sip:victimB@192.0.3.103 SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
This kind of attack aims at tearing down a SIP session
previously established between two victims A and B (Fig. 5).
This attack needs a preliminary phase in which the intruder
sniffs the dialog parameters (From, To, Call-ID). Once the
values of these parameters are known, the intruder emits a BYE
message towards both the legitimate users. The BYE message
sent to Alice will contain the Bob identity and vice versa. The
emission of these two messages will cause an unexpected tear
down of the SIP session.
INTERNET
IMS Home Network
200 OK
200 OK
200 OK
200 OK
200 OK
200 OK
IMS Visited Network
200 OK
200 OK
200 OK
200 OK
Victim A
SIP Proxy
INVITE sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Record-Route: <sip:192.0.3.103;lr>
Content-Type: application/sdp
Content-Length: (…)
I-CSCF
SEG
SEG
Victim B
BYE from Victim A
BYE from Victim B
Attacker
Fig. 5 - Tearing down a session.
Fig. 3 - 302 Response code message: flow of attack messages.
Alice
sip:victimA@atlanta.com
192.0.1.101
SEG
INVITE sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
Bob
sip:victimB@biloxi.com
5555::aaa:bbb:ccc:ddd
SIP Proxy
sip:proxy@atlanta.com
192.0.1.110
Attacker
sip:attacker@hacker.com
192.0.3.103
SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP 192.0.1.101
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob"
<sip:victimB@biloxi.com>;tag=46453645
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:192.0.3.103>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
INVITE sip:victimB@192.0.3.103 SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
INVITE sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Record-Route: <sip:192.0.3.103;lr>
Content-Type: application/sdp
Content-Length: (…)
2) Modifying a session
This attack uses the re-INVITE message to modify the SIP
session parameters (e.g. the audio/video codecs) so as to inhibit
the session parties to correctly receive the multimedia flows.
Alice
sip:victimA@atlanta.com
192.0.1.101
Attacker
sip:attacker@hacker.com
192.0.3.103
INVITE sip:victimA@atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.102
Max-Forwards: 70
From: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
To: "Alice"
<sip:victimA@atlanta.com>;tag=5345324
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.biloxi.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
…
m=audio 3456 RTP/AVP 97
a=rtpmap:97 AMR
m=video 3400 RTP/AVP 99
a=rtpmap:99 MP4V-ES
...
192.0.2.102
SEG
IPv6-->IPv4
Bob
sip:victimB@biloxi.com
5555::aaa:bbb:ccc:ddd
SIP Proxy
sip:proxy@atlanta.com
192.0.1.110
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.102
Max-Forwards: 70
From: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
To: "Alice"
<sip:victimA@atlanta.com>;tag=5345324
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
…
m=audio 3488 RTP/AVP 97
a=rtpmap:97 AMR
m=video 3416 RTP/AVP 99
a=rtpmap:99 MP4V-ES
...
ACK sip:victimA@atlanta.com
Via: SIP/2.0/UDP 192.0.2.102
Max-Forwards: 70
From: "Bob"
<sip:victimB@biloxi.com>;tag=12314534
To: "Alice"
<sip:victimA@atlanta.com>;tag=5345324
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 ACK
Contact: <sip:client1.biloxi.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Length: 0
Fig. 4 - 305 Response code message: flow of attack messages.
This kind of attack proceeds as shown in Fig. 4. When the
victim (Alice) generates a request, the intruder readily responds
with a 305 Use Proxy message, masquerading as the called
user (Bob) and inserting, in the “Contact” field, his own IP
address. In this way the intruder assumes the role of a Proxy.
Alice will react by emitting a new request addressed towards
the intruder. In order to remain unknown to the legitimate
users, the intruder will forward the message towards Bob by
inserting in the SIP header a field Record-Route containing his
Fig. 6 - Modifying a session.
Normally, the session parameter negotiation is performed
by means of a three-way-handshake procedure taking place
during the session setup. The session parameters are contained
in the SDP body of the INVITE, 200 OK and ACK messages. In
particular, the UAC insert in the INVITE message the list of
supported media capabilities, whereas, the UAS responses with
a 200 OK message containing those capabilities that are
accepted for the session.
The session parameters can be re-negotiated during the
session by means of the emission of a re-INVITE message . If
this message contains parameters unsupported by the
counterpart, the new proposal is refused by means of a 488 Not
Acceptable Here message and the session continues with the
previously accepted parameters.
As shown in Fig. 6, the attacker can sniff the values of
dialog parameters negotiated during the initial setup phase;
successively, he can emit towards the UAC a re-INVITE
message assuming the identity of the UAS; in the body of this
message the attacker inserts a list of parameters (e.g. codec
types, port numbers, protocols) unsupported by the UAS. After
the emission of the 200 OK message by the UAC, the attacker
concludes the procedure with an ACK message. From now on,
the multimedia flow can not be correctly decoded by the UAs.
correspondent UA. Similarly to the previous case, this type of
attack can be successfully operated only if the victim is located
in a unprotected networks as Internet.
4) Response code messages
This attack employs three classes of SIP responses to create
a denial of service condition of a victim. The classes of
responses used are:

4xx Client Error: messages emitted when a request can
not be completed since it contains bad syntax or cannot
be fulfilled at a server;

5xx Server Failure: messages emitted when a server
failed to fulfill an apparently valid request;

6xx Global Failure: messages emitted if the request
cannot be fulfilled at any server.
3) Cancelling a session
Aim of this type of attack is to make unattainable a UA by
deleting the SIP request directed to it.
The attacker emits a CANCEL message just before that the
UAS emits the definitive response (200 OK message) to an
INVITE sent by a UAC. This a mandatory condition for the
success of the attack, otherwise the reception of the CANCEL
message will not have any effect on the UAS. The attacker
sniffs the communication channel and, whenever an INVITE
addressed towards a specified UAS is revealed, a CANCEL
message carrying the same session parameter is emitted so as
to make impossible the session setup.
Alice
sip:victimA@atlanta.com
192.0.1.101
192.0.2.102
INVITE sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Allow: INVITE, ACK, CANCEL, BYE, PRACK,
UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
SEG
IPv6-->IPv4
Bob
sip:victimB@biloxi.com
5555::aaa:bbb:ccc:ddd
SIP Proxy
sip:proxy@atlanta.com
192.0.1.110
The attacker, by sniffing the traffic emitted by the victim,
emits an error response (4xx, 5xx o 6xx) whenever the
emission of a request is detected. Such a response has to
contain the destination identity or the identity of the SIP proxy
associated to the victim. When the request will be received by
the destination UA, he will emit a response that in any case will
be ignored by the requesting UA since he will have already
received the error message.
This kind of attack can be carried out only outside the IMS
domain, since, as already specified, the traffic inside the IMS
domain is protected by IPSec. However, an attacker can make
unattainable an IMS user currently located in Internet by
reacting with 4xx, 5xx, 6xx error messages to the interception
of SIP requests directed to the victim (Fig. 8).
Alice
victimA @ atlanta . com
192 .0.1. 101
Attacker
sip : attacker @ hacker . com
192 .0 .3. 103
SIP Proxy
sip : proxy @ atlanta . com
192 .0.1. 110
192 .0.2. 102
Attacker
sip:attacker@hacker.com
192.0.3.103
CANCEL sip:victimB@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 2 CANCEL
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.1.101
Max-Forwards: 70
From: "Alice"
<sip:victimA@atlanta.com>;tag=12314534
To: "Bob" <sip:victimB@biloxi.com>;tag=5345324
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 2 CANCEL
Content-Length: 0
SEG
IPv 6 -- > IPv 4
Bob
sip : victimB @ biloxi . com
5555 :: aaa : bbb : ccc : ddd
INVITE sip : victim A @ atlanta . com SIP /2.0
Via : SIP /2.0/ UDP 192 .0.2.10 2
Max - Forwards : 70
From : " Bob " < sip : victim B @ biloxi . com > ; tag = 5345324
To : " Alice " < sip : victim A @ atlanta . com >
Call - ID : cb 03 a0 s 09 a2 sdfglkj 490333
Cseq : 1 INVITE
Contact : < sip : client 1. biloxi . com >
Allow : INVITE , ACK , CANCEL , BYE , PRACK , UPDATE ,
REFER , MESSAGE
Content - Type : application / sdp
Content - Length : ( … )
SIP /2.0 486 Busy Here
Via : SIP /2.0/ UDP 192 .0.2.10 2
From : " Bob " < sip : victim B @ biloxi . com >; tag = 5345324
To : " Alice " < sip : victim A @ atlanta . com >; tag = 12314534
Call - ID : cb 03 a0 s 09 a2 sdfglkj 490333
Cseq : 1 INVITE
Content - Length : 0
ACK sip : victim A @ atlanta . com SIP /2.0
Via : SIP /2.0/ UDP 192 .0.2.10 2
Max - Forwards : 70
From : " Bob " < sip : victim B @ biloxi . com >; tag = 5345324
To : " Alice " < sip : victim A @ atlanta . com > ; tag = 12314534
Call - ID : cb 03 a0 s 09 a2 sdfglkj 490333
Cseq : 1 ACK
Content - Length : 0
Fig. 8 - 4xx response code messages: 486 Busy Here.
Fig. 7 - Cancelling a session.
It is to be noted that, this kind of attack can be addressed
only towards UA located in open IP networks (e.g. Internet),
since traffic crossing the interface between a P-CSCF and an
IMS terminal is protected by IPSec, so the sniffing of the
session parameter at this interface is impossible.
A similar effect (Fig. 7) can be achieved by intercepting the
INVITE messages emitted by a UA and with the immediate
emission of CANCEL messages impersonating the
5) SIP DoS attack and amplification
This attack aims at directing a huge amount of SIP
signalling traffic towards a network element so as to make it
unusable. In particular, this effect can be obtained by issuing a
set of SIP requests, with a false source address, towards a set of
destinations. Each message contains the address of the victim
in the “Via” field. In this way, all the responses of the
destination parties will be addressed towards the victim so as to
cause the saturation of its processing capabilities (Fig. 9). The
attacker can also exploits the forking functions provided by the
S-CSCF to increase the amount of traffic directed to the victim.
attack is guaranteed by inserting the IP address of the attacker
within the Via field in the REGISTER message.
2) 3xx response code
By means of this attack an intruder aims at assuming the
identity of the called user. The 3xx responses provide
information of the current location of the victim, so an attacker
can send the victim a 3xx response by assuming the identity of
the original destination of the INVITE by indicating in the field
“Contact” his own IP address (Fig. 11).
INVITE sip : user @ domain . com SIP /2.0
Via : SIP /2.0/ UDP 192 .0.1. 10 1
Max - Forwards : 68
From : < sip : anonymous @ site . com >; tag = 5889671
To : " Alice " < sip : user @ domain . com >
Call - ID : cb 03 a 0 s 09 a2 sdfglkj 490333
Cseq : 1 INVITE
Contact : < sip : client . site . com >
Content - Type : application / sdp
Content - Length : (..)
1) INVITE VictimA
INTERNET
1) INVITE VictimA
2) 100 Trying
2) 100 Trying
4) INVITE VictimA
192 .0.1. 101
IPv 6 --> IPv 4
Bob
sip : victimB @ biloxi . com
5555 :: aaa : bbb : ccc : ddd
SIP Proxy
Victim A
4) INVITE VictimA
4) INVITE VictimA
I-CSCF
SEG
3) 301 Moved Permanently
SEG
IMS Visited
Network
Victim B
IMS Home
Network
Attacker
sip : attacker @ hacker . com
192 .0.3. 103
Attacker
Fig. 9 – SIP DoS Attack.
Fig. 11 - 3xx response code message: 301 Moved Permanently.
C. Unauthorized access to service
1) Registration hijacking
Registration hijacking means that the attacker may do
malicious registrations to the registrar. Attacker may for
example register his own device as the contact address of the
victim and deregister all old contacts. After that all requests to
victim direct to the device of the attacker. In this case the
victim is an IMS terminal currently located in Internet.
Attacker
sip : attacker @ hacker . com
192 .0.3. 103
SEG
S- CSCF
REGISTER sip : scscf . atlanta . com SIP /2.0
Via : SIP /2.0/ UDP 192 .0.1. 101
Max - Forwards : 70
From : " Alice " < sip : victim A @ atlanta . com >; tag = 12314534
To : " Alice " < sip : victim A @ atlanta . com >
Contact : < sip : attacker @ 192 .0.3. 103 >
Call -ID : apb 03 a 0 s 09 dkjdfglkj 49111
Authorization : Digest
username =" victimA _ private @ atlanta . com " ,
realm =" scscf . atlanta . com ", " nonce = base 64 ( RAND +
AUTN + server specific data ) , algorithm = AKAv 1MD 5 , uri =" sip : scscf . atlanta . com " ,
response =" 6629 fae 49393 a 05397450978507 c 4ef 1"
Require : sec - agree
Proxy - Require : sec - agree
CSeq : 2 REGISTER
Supported : path
Content - Length : 0
Bob
sip : victimB @ biloxi . com
5555 :: aaa : bbb : ccc : ddd
A key point for the success of this attack is the timeliness of
the 3xx response; in fact, it must reach the victim before the
definitive response emitted by the legitimate destination user.
Moreover, the attacker must copy the content of the fields
From, To and Call-ID sniffed from the INVITE message
within the 3xx response.
IV.
PROPOSED SOLUTION
This section deals with the description of a possible
guideline for implementing efficient countermeasures to faced
with the security attacks discussed in the previous section.
IPv 6-- > IPv 4
192 .0.2. 102
IMS Network
atlanta . com
S- CSCF
Service Platform
IMS
Network A
I- CSCF
SIP /2. 0 200 OK
Via : SIP /2.0/ UDP 192 .0.1. 101
From : " Alice " < sip : victim A @ atlanta . com >; tag = 12314534
To : " Alice " < sip : victim A @ atlanta . com >: tag = 45243254
Call -ID : apb 03 a 0 s 09 dkjdfglkj 49111
Contact : < sip : attacker @ 192 .0.3. 103 >
CSeq : 2 REGISTER
Content - Length : 0
Mm
Attacker
Za
Internet
Proxy SIP
INVITE sip : victim A @ atlanta . com SIP /2.0
Via : SIP /2.0/ UDP 192 .0.2. 10 2
Max - Forwards : 68
From : " Bob " < sip : victim B @ biloxi . com >; tag = 5889671
To : " Alice " < sip : victim A @ atlanta . com >
Call -ID : cb 03 a0 s 09 a 2 sdfglkj 490333
Cseq : 1 INVITE
Contact : < sip : victimB @ 192 .0.2. 102 >
Content - Type : application / sdp
Content - Length : 0
IMS Visited
Network
SEG
SEG A
SEG V
Za
P- CSCF
Access
Network
GGSN
Registrar SIP
User 1' s UE
User 2' s UE
SEG B
IMS
Network B
Fig. 10 - Registration hijacking.
In IMS the registration procedure requires the mutual
authentication between user and network; such an
authentication is based on the use of a couple of keys (IK and
CK) exchanged between the user and the HSS. Normally, this
couple of keys are not transmitted by the P-CSCF in the 401
Unauthorized response emitted after the first REGISTER
message. On the contrary, if the terminal is not currently
located in an IMS domain, the keys IK and CK will be
transmitted unencrypted through Internet, so an attacker can
sniff them and use them to make a registration assuming the
identity of the legitimate user (Fig. 10). The success of this
Fig. 12 - SEG on the Mm reference point
The proposed solution is based on the definition of a
Security Gateway for the interworking between IMS and the
Internet. In the following the main functions to be performed
by the SEG are firstly discussed, then the security procedures
are briefly presented.
A. Security Gateway (SEG)
As we saw previously, the lack of any adequate system of
security enforcement on the Mm reference point and on the
signalling traffic passing through the Internet can be exploited
by an attacker on the Internet to carry out attacks over the SIP
signalling.
A possible filter against this kind of attacks could be
deployed by inserting a properly designed Security Gateway
(SEG) on the Mm interface, between the I-CSCF and the SIP
Proxy on the Internet (Error! Reference source not found.).
Since the Mm reference point has not still been completely
defined by the 3GPP, the SEG will also be required to offer
interworking functions. The following services should be at
least offered by the SEG:
1) IPv4/IPv6 interworking
Since IMS requires the use of IPv6 protocol, while IPv4 is
still widely used in the Internet, IP level and application level
interworking is an aspect that has to be solved at Mm interface.
The IP level interworking could be solved by a Network
Address (and Port) Translation (NA(P)T). As for application
level address translation, an Application Level Gateway (ALG)
should be used. An ALG is a functional entity allowing
application level processing of messages. In our case it must
allow an IPv4 node to transparently contact an IPv6 node (and
viceversa) by properly modifying the IP addresses and
transport level ports contained in the application level header
fields and payloads (SIP and SDP).
Any ALG is application-specific, so it allows a transparent
communication between a host implementing a certain
application and another host implementing the same
application but with a different IP protocol version. We named
“IMS ALG” the SIP/SDP specialized Application Level
Gateway. It will require the usage of a NA(P)T-PT to create
bindings between the ports and the addresses used by the IPv4
side and the IPv6 side: such bindings will be released at the end
of the session.
2) NA(P)T-PT
The Network Address (and Port) Translator-Protocol
Translator (NA(P)T-PT) [18] uses a pool of IPv4 addresses to
be associated to IPv6 nodes when a session crossing the
IPv4/IPv6 boundaries is set up. The IPv4 to IPv6 (and
viceversa) binding allows a transparent routing between the
two IP domains without the need to modify any of the endpoints of the communication. The port translation allows to
make a multiplexing from manifold IPv6 addresses to a unique
IPv4 address having a different port for each originating IPv6
address. Differently by the ALG, the NA(P)T-PT is
application-independent.
3) Protection SEG.
It is the SEG component specialized in the resolution of the
previously listed attacks and security issues. It can be
integrated in the IMS ALG, since it works at application level.
This aspect will be examined more in detail in the next section.
4) Signalling adaptation between 3GPP profile of
SIP/SDP and non-3GPP SIP/SDP standard.
The 3GPP introduced a few header extensions into the SIP
protocol to allow its usage within the IMS procedures. To grant
a correct interworking with non-IMS SIP terminals, the
signalling extension headers should be properly treated, since a
standard SIP User Agent would not understand the 3GPP
extensions. This mechanism should allow a totally transparent
communication between an IMS User Equipment and a SIP
standard User Agent. Since it works at application level, this
function can be integrated in the IMS ALG.
5) TLS.
The TLS usage over the Mm reference point was suggested
by Nokia [6] and approved on February 2004. This proposal
requires the I-CSCF to implement TLS by simply modifying
the SIP URIs of all messages going towards the Internet by
replacing them with a sips URI.
This solution has the advantage that is fully compliant to
the basic SIP standard, moreover it grants that the messages
will be relayed securely via TLS hop-by-hop till the called
terminal. However this does not provide security in case the
Internet SIP UA is the caller and not the called terminal. In this
case the SEG should detect whether security was implemented
all over the hops from the calling UA to the IMS network.
The Fig. 13 represents an SDL description of the defined
SEG. More detail on this aspects are contained in [4].
Block: FW/ NAT
Firewall
Process
Ch 1
Ch 6
Ch 8
I- CSCF
SIP Proxy
L4- NAT
Process
Ch 3
Ch2
IMS
Internet
Block: IMS ALG
Application
level- NAT
Process
Ch 9
Ch 7
Ch 4
Ch 10
SIP Extensions
Process
Ch 5
Protection SEG
Process
Ch 11
Database
Process
Ch 12
Block: Database
SEG
Fig. 13 – SDL description of SEG.
B. SEG Interworking scenarios.
In this section the security aspects of IMS interworking
with the Internet are examined. We assume that all the
mechanisms for signalling and addressing adaptation are
deployed in the SEG to grant a correct interworking between
IMS and Internet. Moreover, we assume that the security
mechanisms used in the IMS core network assure a good level
of security, while no security procedure is deployed in the
Internet.
The following interworking cases have been considered:
 IMS UE located in the Internet.
 SIP non-IMS UA in the Internet initiating a call towards an
IMS UE over IMS network.
 IMS UE over IMS network initiating a call towards a SIP
non-IMS UA in the Internet.
3) IMS UE over IMS network initiating a call towards a SIP
UA in the Internet
The scenario shown in Fig. 16 is considered.
IPSec
1) IMS UE in the Internet
The scenario shown in Fig. 14 is considered.
IPSec?
IPSec
IPSec?
IPSec
IPSec?
IMS Home Network
2
IMS Home Network
1
IMS Visited Network
1
I- CSCF
P- CSCF
IPSec tunnel
SEG
SEG
S- CSCF
SEG
SEG
I- CSCF
S- CSCF
IMS UE
IPSec?
IPSec
IPSec?
S
TL
IMS Home Network
INTERNET
S
TL
IPSec
Mm
SEG
IMS Visited Network
Mm
SIP Proxy
SEG
I- CSCF
S- CSCF
SEG
P- CSCF
SEG
SIP Proxy
TLS
IMS UE
IMS UE
??
TLS
INTERNET
T LS
Fig. 14 – Scenario for IMS-UE in the Internet
To guarantee an adequate level of protection to the
signalling going across the Internet, the IMS UE in the Internet
should register to its home network via an IPSec tunnel
established with the SEG. The procedure to establish a IPSec
SA between the SEG and the IMS UE is briefly described in
the following section.
2) SIP UA in the Internet initiating a call towards an IMS
UE over IMS network
The scenario shown in Fig. 15 is considered.
IPSec?
TLS
TLS
TL
S
IPSec?
SEG
I- CSCF
S- CSCF
SEG
SEG
INTERNET
Fig. 16 – A call towards a SIP UA in the internet.
In this case the usage of TLS in the hops from the I-CSCF
to the non-IMS UA is requested by the 3GPP standards. If one
of the proxies in the Internet can not offer TLS, it must answer
with an error message. The SIP standard recommends the UAs
to support TLS, but this is not a mandatory requirement;
anyway, the last hop preceding the UA, receiving a sips URI in
the request URI, must relay the message in any secure
mechanism to the UA or answer with an error message. This
guarantees that a good level of protection can be ensured till
the SIP User Agent in the Internet.
IPSec
IMS Visited Network
Mm
TLS
SIP Proxy
Non- IMS UA
IPSec
IMS Home Network
2
TLS
Non- IMS UE
P- CSCF
IMS UE
Fig. 15 – Call initiated by a SIP UA in the internet
C. IMS UE security procedures.
Since the security aspects regarding SIP non-IMS terminals
in the Internet can be treated in a simple way as described in
the previous section, we will examine in more detail the case of
IMS terminal trying to access to its home network via Internet.
The non-IMS UA could try to setup a session without using
any security mechanism. This should be rejected by the SEG,
that should send an error message requiring security. Then the
UA should retry the session setup using TLS (which is the
default security mechanism supported by basic SIP entities).
The SEG must check whether TLS has been used over all the
hops between the terminal and the SEG itself. This check is
executed by assuring that all the sip URIs listed in the Via
header field are sips.
1) Solution 1.
If at least one of the Via references is sip, the SEG will
refuse the session by emitting an error message requesting
security. The TLS usage over the Mm interface – but not over
the previous hops – can be achieved by indicating the SEG
URI as a sips URI: this would then be stored in the DNS (to
declare its capability) and could be resolved by NAPTR/SRV
[20] records to indicate the SEG should be reached only
through TLS.
The same considerations apply if more than one SIP proxy
is traversed in the Internet. We are assuming the IMS UE is not
conscious to be connected over the Internet, so it sends a
standard IMS REGISTER message towards its home network.
The first SIP proxy in the Internet is fully SIP compliant, but
we are assuming it does not recognize the SIP extensions
contained in the received REGISTER message (Fig. 18).
If IMS network provider would allow communication even
with unsecure SIP UAs not implementing TLS or any other
security mechanism, an Intrusion Detection System (IDS)
functionality should be integrated in the SEG to analyze the
SIP signalling between the SIP terminal and the IMS core
network.
In particular the required sec-agree extension, not defined
in the basic SIP RFC 3261, is not recognized and the SIP proxy
answers with a 420 error message indicating in the
Unsupported header field the sec-agree. After receiving this
unexpected answer the IMS UE gets conscious to be connected
via Internet and retries with a second REGISTER which is
basic SIP compliant, without extensions.
The first proposed solution exploits the access granted by a
SIP network in the Internet to locate the correct SEG to reach
the IMS home network. Since any IMS UE is SIP compliant, it
can use the SIP proxies in the Internet to locate, hop by hop,
the SEG – which is itself a SIP proxy – via NAPTR/SRV DNS
procedures.
The message flow for registration is shown in Fig. 17.
The SEG does not relay this message in the IMS network,
but answers with a 401 message indicating its IPv4 address in
the Contact header field. Now the IMS UE can send IP packets
containing the new IMS standard REGISTER message directly
to the SEG address. The remaining flow is similar to the usual
IMS registration, and allows to set up a direct IPSec tunnel
from the UE to the SEG as shown in Fig. 19.
INTERNET
IMS UE
IMS Network
158.83.97.1
(1 ) IMS REGISTER
(2 ) 420 Bad Extension
(3 ) SIP REGISTER
2) Solution 2.
The second solution (Fig. 20) is based on the assumption
that the internet SIP provider has an agreement with the IMS
provider and implements an IMS server offering the SEG
location function for all the IMS core networks having
subscribed an agreement.
This solution allows the IMS UE to send standard IMS
registration messages since the IMS Server can transparently
redirect all messages towards the SEG. The IMS server can
implement load balancing and fault tolerance functions.
SEG
SIP Proxy
151. 100.37. 149
one, with the exception that the error message number (2) is
replaced by a 494 Security Agreement Required indicating the
security mechanisms supported by the SIP proxy.
(4 ) SIP REGISTER
(6 ) 401( Unauthorized)
(5 ) 401( Unauthorized)
IPSec tunnel
Contact: 158.83.97.1
Contact: 158.83.97.1
INTERNET
IMS core
(7 ) IMS REGISTER
IMS
Forward REGISTER
401( Unauthorized)
(8 ) 401( Unauthorized)
Mm
SIP
IMS Server
(9 ) IMS REGISTER
SIP Proxy
SIP
IMS UE
(10 ) 200(OK)
SEG
I- CSCF
SIP
Forward REGISTER
200 OK
Fig. 20 – IPSec tunnel between SEG and IMS UE in solution 2.
Fig. 17 –Information flow related to registration of an IMS UE currently
located in Internet
REGISTER sip:registrar.homeIMS.net SIP/2.0
Via: SIP/2.0/UDP [151.100.37.149];branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: ADSL; dsl-location=234151D0FCE11
From: <sip:user1_public1@homeIMS.net>;tag=4fa3
To: <sip:user1_public1@homeIMS.net>
Contact: <sip:[151.100.37.149];comp=sigcomp>;expires=600000
Call-ID: apb03a0s09dkjdfglkj49111
Authorization: Digest username="user1_private@homeIMS.net",
realm="registrar.homeIMS.net", nonce="",
uri="sip:registrar.homeIMS.net", response=""
Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678;
port-c=2468;
port-s=1357
Require: sec-agree
Proxy-Require: sec-agree
CSeq: 1 REGISTER
Supported: path
Content-Length: 0
Fig. 18 – SIP REGISTER Message.
3) Solution 3.
The third solution is similar to the solution 2, but this time
the IMS server in the Internet has a permanent static IPSec
tunnel towards each SEG it is connected to (Fig. 21).
INTERNET
IPSec
IPSec static tunnel
SIP
IMS UE
IMS
Mm
SIP
IMS Server
SIP Proxy
SEG
I- CSCF
SIP
Fig. 21 – IPSec tunnel between SEG and IMS UE in solution 3.
This scenario allows the IMS UE to REGISTER to its
home network in the same way as it would make via standard
access networks as a GPRS access. The IMS server would get
the integrity and encryption keys by the IMS home network via
the IPSec tunnel and should behave in the same way as a PCSCF.
IPSec tunnel
INTERNET
IMS
Mm
SIP
SIP Proxy
SEG
I- CSCF
IMS UE
SIP
Fig. 19 – IPSec tunnel between SEG and IMS UE in solution 1.
In the case the SIP proxy recognizes the sec-agree
extension, it would not be able to negotiate the security
mechanism since the ipsec-3gpp requested in the first
REGISTER message is a 3GPP algorithm not known to SIP
standard entities. The message flow is the same as the previous
V.
CONCLUSIONS
In this paper some security aspects arising from a scenario
in which IMS network interoperate with an open IP network
like Internet have been examined. In particular, possible
security threats related to SIP protocol have been classified and
described. Finally, some possible solutions to achieve a
satisfying level of security have been proposed.
Current activity concerns the detailed definition of SEG
functions and procedures and the creation of an experimental
test-bed.
REFERENCES
J. Roseberg, H. Schulzrine, G. Camarillo et al., “SIP: Session Initiation
Protocol”, IETF RFC 3261, June 2002
[2] G. Camarillo, M.A. Garcia-Martin – “The 3G IP Multimedia
Subsystem”, Wiley
[3] 3GPP, TS 21.133 V4.1.0, “3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; 3G
Security; Security Threats and Requirements (Release 4)”, December
2002
[4] Ivan Petrilli, INFOCOM dept., “TECHNICAL_REPORT v1.0-001.doc”,
July 2005
[5] Dierks, T. and C. Allen: “The TLS Protocol Version 1.0”. RFC 2246,
IETF Network Working Group, January 1999.
[6] 3GPP TSG SA WG3 Security; S3-030727, November 2003
[7] Salsano, S., Veltri, L. and D. Papalilo: “SIP security issues: the SIP
authentication procedure and its processing load” IEEE Network,
Volume:16, Issue:6 , Nov/Dec 2002, pp. 38-44.
[8] Tat Chan and S. Sengodan: “On applying SIP security to networked
appliances”. Proceedings. IEEE 4th International Workshop on
Networked Appliances, 2001, pp. 31-40.
[9] S. Knuutinen: “Session Initiation Protocol security considerations”.
Seminar on Internetworking, Helsinky, Spring 2003. Available in
http://www.tml.hut.fi/Studies/T-110.551/2003/papers.
[10] O. Rantapuska: “SIP call security in an open IP network”. Seminar on
Internetworking,
Helsinky,
Spring
2003.
Available
in
http://www.tml.hut.fi/Studies/T-110.551/2003/papers.
[1]
[11] A. Steffen, D. Kauffman, A. Striker: “SIP security”. Lecture notes in
Informatics P-55, Bonner Kollen Verlag 2004, pp.397-410.
[12] 3GPP Technical Specification TS 33.203: “3G security. Access security
for
IP-based
services”.
Available
in:
http://www.3gpp.org/specs/specs.htm.
[13] Peterson, J.: “A Privacy Mechanism for the Session Initiation Protocol
(SIP”). RFC 3323, IETF NetworkWorking Group, November 2002.
[14] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and A. Haukka:
“Security Mechanism Agreement for the Session Initiation Protocol
(SIP)”. RFC 3329, IETF Network Working Group, January 2003.
[15] Franks, J., Hallam-Baker, P., Hostetler et alii: “Authentication:Basic and
Digest Access Authentication”. RFC 2617, IETF NetworkWorking
Group, June 1999.
[16] Jennings, C., Peterson, J. and M. Watson: “Private Extensions to the
Session Initiation Protocol (SIP) for Asserted Identity within Trusted
Networks”. RFC 3325, IETF Network Working Group, November 2002.
[17] Kent, S. and R. Atkinson. “Security Architecture for the Internet
Protocol”. RFC 2401, IETF NetworkWorking Group, November 1998.
[18] G. Tsirtsis, P. Srisuresh, “Network Address Translation - Protocol
Translation (NAT-PT)”, IETF RFC 2766, February 2000
[19] ITU-T Recommendation Z.100 – Formal description techniques (FDT) Specification and Descriprion Language (SDL), August 2002
[20] J. Rosenberg, H. Schulzrinne, “Session Initiation Protocol (SIP):
Locating SIP Servers”, IETF RFC 3263, June 2002