One document matched: draft-yang-sipping-voipli-00.txt
SIPPING Working Group Menghui. Yang
Internet-Draft Xiaodong. Li
Intended status: Experimental Wei. Mao
Expires: April 28, 2009 CNNIC
Oct 25, 2008
Architecture and Practice for VoIP Lawful Interception Using Session
Border Controller(SBC)
draft-yang-sipping-voipli-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2009.
Abstract
Recently broadband Voice over IP (VoIP) has a clear trend to
substitute for traditional telephone services such as wire telephone,
wireless telephone and mobile telephone service, it has become
increasingly clear that VoIP services will be expected to provide
Lawful Intercept to the same level experienced in the Public Switched
Telephone Network(PSTN)[7]. In an effort to provide lawful
interception for broadband VoIP, an architecture using session border
controller was proposed, and a prototype implementation of the
broadband VoIP lawful interception was created and basic performance
evaluation was conducted on this prototype system. This document
Yang, et al. Expires April 28, 2009 [Page 1]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
reports on the prototype implementation and the test results.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. A Prototype of Broadband VoIP LI Implementation . . . . . . . 6
3.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Internal network interface INI-1 . . . . . . . . . . . 8
3.1.2. Internal network interface INI-2 . . . . . . . . . . . 9
3.1.3. Internal network interface INI-3 . . . . . . . . . . . 9
3.1.4. Internal network interface HI-2 . . . . . . . . . . . 9
3.1.5. Internal network interface HI-3 . . . . . . . . . . . 9
3.1.6. Internal network interface HI-1 . . . . . . . . . . . 10
3.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Session border controller . . . . . . . . . . . . . . 10
3.2.2. Delivery Functions . . . . . . . . . . . . . . . . . . 11
3.2.3. Collection functions in LEMF . . . . . . . . . . . . . 12
3.2.4. Administration Function . . . . . . . . . . . . . . . 12
4. Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Test environment . . . . . . . . . . . . . . . . . . . . . 13
4.2. Test Scenarios and Results . . . . . . . . . . . . . . . . 14
4.2.1. SBC Intercepted Maximum Concurrent Session Number
without media . . . . . . . . . . . . . . . . . . . . 14
4.2.2. SBC Intercepted Maximum Concurrent Session Number
with media . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Delivery Function 2 CII Maximum Transactions
Throughput . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4. Delivery Function 2 CII Minimum, Average and
Maximum Transactions Response Time . . . . . . . . . . 19
4.2.5. Delivery Function 3 CC Maximum Transactions
Throughput . . . . . . . . . . . . . . . . . . . . . . 20
4.2.6. Delivery Function 3 Minimum, Average and Maximum
Transactions Response Time . . . . . . . . . . . . . . 21
4.2.7. Collection Function CII Maximum Transactions
Throughput . . . . . . . . . . . . . . . . . . . . . . 22
4.2.8. Collection Function CII Minimum, Average and
Maximum Transactions Response Time . . . . . . . . . . 23
4.2.9. Collection Function CC Maximum Transactions
Throughput . . . . . . . . . . . . . . . . . . . . . . 24
4.2.10. Collection Function CC Minimum, Average and
Maximum Transactions Response Time . . . . . . . . . . 25
5. Limitations and Issues . . . . . . . . . . . . . . . . . . . . 26
5.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 27
5.3. Protocol Details . . . . . . . . . . . . . . . . . . . . . 28
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Yang, et al. Expires April 28, 2009 [Page 2]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
7. Security considerations . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Yang, et al. Expires April 28, 2009 [Page 3]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
1. Introduction
Lawful Interception (LI) is a requirement placed upon service
providers to provide legally sanctioned official access to private
communications. With the existing PSTN, lawful intercept is
performed by applying a physical 'tap' on the telephone line of the
target in response to a warrant from a Law Enforcement Agency
(LEA)[6]. However, VoIP technology has enabled the mobility of the
end-user, so it is no longer possible to guarantee the interception
of calls based on tapping a physical line. So, interception of VoIP
based on traditional lawful interception regulatory framework, which
focused on PTSN-based telephone service, is not reasonable. LI of
PSTN-based telephone service can be done by wiretapping of the
switch, with assistance of telecommunications service providers with
LEA. But, for LI of VoIP, interception capability should be
developed and installed or separate interception equipment should be
deployed.
Current broadband VoIP services show that there are two types of
providers: Access providers and Service providers. Access providers
are those that actually provide broadband connectivity to the
premises (cable, DSL, etc.). Service providers are those providing
the VoIP services. In some cases, the Access provider can also be a
Service provider (e.g., a cable operator that provides VoIP telephony
services). The latest large-scale additions to the VoIP offering are
peer-to-peer connections. These services bypass the traditional
centralized call-control mechanisms and work directly with proxies
and end points.
In a Broadband access environment, the access provider doesn!_t know
what services the subscriber is utilizing because access providers
only supply a pipe from the subscribers premises to the Internet. In
this case, the service provider doesn!_t provide any switching
equipment and the subscriber can work with any Service provider they
choose via the pipe to the Internet. The subscriber can also decide
to utilize peer-to-peer services over this same broadband pipe. In
this environment, the access provider is unable to identify or
determine certain events or information due to the service provider
not owning or controlling the switching and routing equipment.
One of the primary problems that service providers face when managing
VoIP and multimedia calls is the separation of the signaling and
media streams. In other words it is quite possible that the two
streams may take completely different paths through the network. In
addition, even when they do pass through the same device, it may not
be aware of the relationship between the streams. Some devices
within the network are however specifically designed to understand
and manage the separate signaling and media streams - session border
Yang, et al. Expires April 28, 2009 [Page 4]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
controllers (SBC)[8].
SBC is a session-aware device that manages VoIP calls at the borders
of an IP network. Unlike most network devices, SBC are aware of the
relationship between the two parts of a VoIP call: signaling and
media. Session Border Controllers handle both media and signaling,
intercept can be performed in a completely undetectable manner.
SBCs usually sit between two service provider networks in a peering
environment, or between an access network and a backbone network to
provide service to residential and/or enterprise customers. They
typically are deployed at the border between two VoIP networks, and
they offer an ideal location to implement a Lawful Intercept
solution.
Whilst the detailed requirements for VoIP Lawful Interception may
differ from one jurisdiction to another, the general requirements are
the same. The LI system must provide transparent interception of
specified traffic only and the subject must not be aware of the
intercept. The service provided to other users must not be affected
during interception.
As part of the effort in developing a broadband VoIP lawful
interception architecture, we implemented a prototype and conducted
evaluation experiments on the prototype system. In this document, we
first describe the prototype solutions and then report experimental
results. We hope that this document can provide useful information
to those interested in the subject.
The prototype implementation and experimental results presented in
this report serve only as an input, and by no means preempt any
solution development that may be carried out by future IETF effort.
Indeed, the presented solutions are experimental approaches and have
a number of limitations as discussed in Section 5 and 6.
2. Terminology
Lawful Intercept (LI) "C The targeted intercept of VoIP services, by
a service provider on the behalf of Law Enforcement, when authorized
by a court.
Session Border Controller (SBC) - provides a variety of functions to
enable or enhance session-based multi-media services (e.g., Voice
over IP), provides access to an interception subject!_s.
Call-Identifying Information (CII) - refers to information that
identifies the origin, direction, destination, or termination of each
Yang, et al. Expires April 28, 2009 [Page 5]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
call generated or received by a subject.
Call Content (CC) - audio and video media flow.
Collection Function (CF) "C A law enforcement facility designated as
the transmission destination for CC and CII.
Delivery Function (DF) "C The mechanism responsible for delivering
intercepted communications form a VoIP network operator/service
provider to a CF via HI.
Administration Function - provides provisioning interface for the
intercept as a result of a court order or warrant delivered by the
Law Enforcement Agency (LEA)
Internal Network Interface (INI) "C The VoIP network!_s internal
interface between SBC and DF. Consists of INI1,INI2, and INI3
matching HI1,HI2, and HI3 interfaces.
Handover Interface (HI) "C Interface for delivering CC and CII from
DF to CF.
3. A Prototype of Broadband VoIP LI Implementation
A new VoIP Lawful intercept architecture based on SBC is proposed, as
shown in Figure 1.
Yang, et al. Expires April 28, 2009 [Page 6]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
+--------------------+ HI-1 +------------+
INI-1(1) | | | |
______________| Adminstration |------------| |
| | Function | | |
| | | | |
| +--------------------+ | |
V | INI-1(3) | INI-1 (2) | |
+------------+ | V | |
| | | +------------+ | Law |
| Session | INI-2 | | | HI-2 | Enforcement|
| Border |---------+----------| Delivery |-------| Monitoring |
| Controller | | | Function 2 | | Facility |
| | | | | | |
| | | +------------+ | |
+------------+ | | |
| V | |
| +--------------------+ | |
| | | HI-3 | |
| INI-3 | |------------| |
+--------------| Delivery Function 3| | |
| | | |
+--------------------+ +------------+
Figure 1 VoIP Lawful Intercept Architecture based on SBC
This methodology utilizes a TCP/IP interface to the SBC to both
provision it and receive call data events (originate, ring back, hook
lash, etc.) from it. Those interfaces are described as INI-1 for
provisioning and INI-2 for call data. A third interface INI-3
receives a copy of the media stream. All of this information is sent
to the Delivery functions from SBC. The Delivery functions then
sorts, filters, and formats the information for delivering to Law
Enforcement. The interfaces used to deliver the call data events and
media content to Law Enforcement are TCP/IP interfaces called HI-2
and HI-3, respectively. Lawful Interception deals with two products,
these are: contents of call (CC) and call-identifying information
(CII). CC is exactly what it sounds like: the voice, video or
message contents. CII refers to information that identifies the
origin, direction, destination, or termination of each call generated
or received by a subject. In the following sections, we describe the
specific mechanism implemented in detail.
3.1. Interfaces
This section provides a brief description of the interfaces in the
architecture (Figure 1). One of the objectives in defining these
interfaces is to keep both the internal interfaces (INI-1, INI-2, and
INI-3) and the handover interfaces (HI-1,HI-2, and HI-3) the same
Yang, et al. Expires April 28, 2009 [Page 7]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
regardless of country-specific requirements.
3.1.1. Internal network interface INI-1
This is an intercept request provisioning interface, through which
the Administration function provisions warrants on SBC, and activate,
deactivate or interrogate the Delivery functions.
Administration function uses this interface to provide the provision
for the intercept as a result of a court order or warrant delivered
by the LEMF. It involves separate provisioning interfaces for SBC
and Delivery functions. Administration function takes care of
provisioning of SBC and Delivery functions with some policy.
In order to provide a generic interface for intercepting,
replicating, encapsulating and transporting call information packets
to Delivery function, the intercept request interface should specify:
1 the identification of the subject to be intercepted, such as a SIP
URI;
2 the destination address and port of the Delivery function or
Collection function (where to send the intercepted packets);
3 encapsulation and transport parameters;
4 start time, end time, and duration.
INI-1 involves separate provisioning interfaces,INI-1(1),INI-1(2),and
INI-1(3). INI-1(1) is an interface between the SBC and
Administration function for delivering provisioning information to
point out the intercepted subject identify, when to start and end,
which delivery function the intercepted information should be sent
to, etc. INI-1(2) and INI-1(3) interfaces between the Delivery
functions and Administration function are used to config the Delivery
function which SBC will send intercepted information to it, and which
Collection function the intercepted information should be sent to,
etc. Because of the requirement in some laws to limit accessibility
to authorized personnel, the provisioning interface has to be
strictly controlled. In many cases, the identity of the subject
received from the LEMF has to be translated into an identity that can
be used by the network to enable the intercept.
In this prototype implementation, INI-1 is implemented with Abstract
Syntax Notation One(ASN.1)[1] and Basic Encoding Rule(BER)[2] encoded
to be binary compatible.
Yang, et al. Expires April 28, 2009 [Page 8]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
3.1.2. Internal network interface INI-2
This is the VoIP call data (e.g., SIP signaling) intercepting
interface, over which SBC sends call-identifying information (e.g.,
SIP signaling) to the DF server. The intercepted call data is
encapsulated using DIAMETER protocol [3]. This encapsulation method
retains all of the information in the original packets(source and
destination addresses as well as payload) and provides an identifier
for correlating the CC with the CII.
Note, however, this interface implemented in prototype is based on
UDP which is an unreliable and unordered transport protocol (i.e.,
provides neither retransmission on detection of errors nor ordering
of data). The underlying networks should be engineered to meet the
overall reliability requirements for delivery of content.
3.1.3. Internal network interface INI-3
This is the call content (e.g., RTP media stream) intercepting
interface, over which SBC sends the RTP media stream to the DF
server. The transferred information in this interface is
encapsulated into Diameter event messages[3].
Since the media path is independent of the signaling path, the media
may not traverse through the operator!_s network unless the SBC
modifies the session description exchanged between the user-agents.
By modifying the session description the SBC can force the media to
be sent through SBC. The SBC behaves as a Back-to-Back User
Agent(B2BUA) and inserts itself in the media path, and modifies the
session descriptions carried in the SIP messages. As a result, the
SBC receives media from one user-agent and relays it to other user-
agent and performs the identical operation with media traveling in
the reverse direction.
3.1.4. Internal network interface HI-2
The Handover Interface, HI-2, is the interface between DF 2 and LEMF
for delivering CII. This interface transmits the result of
intercepted SIP signaling to the LEMF, and is implemented with
Abstract Syntax Notation One(ASN.1) and Basic Encoding Rule(BER)
encoded to be binary compatible.
3.1.5. Internal network interface HI-3
The Handover Interface, HI-3, is the interface between DF 3 and LEMF
for delivering CC. This interface transmits the result of
intercepted RTP media stream to the LEMF, and is implemented with
Abstract Syntax Notation One(ASN.1) and Basic Encoding Rule(BER)
Yang, et al. Expires April 28, 2009 [Page 9]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
encoded to be binary compatible.
3.1.6. Internal network interface HI-1
This is an interception administration interface, through which the
LEMF provides intercept administration information to the service
provider administration function.
In this prototype, this interface is under consideration, and is not
available now.
3.2. Components
This section provides a brief description of the key components in
the architecture (Figure 1).
3.2.1. Session border controller
Session border controller handles all SIP messages which are needed
for interworking between different operators who exchange traffic
with each other. It takes care of replicating signaling and delivers
it to specific delivery function using appropriate format. SBC
inserts itself in the media path, and modifies the session
descriptions carried in the SIP messages to deliver it to specific
delivery function using appropriate format.
Example: Consider the following example scenario: the SBC receives an
INVITE request from the outer network, which in this case is an
access network. The received SIP message containing the SDP session
descriptor is shown as following.
v=0 o=- 5 2 IN IP4 218.241.111.22 s=CounterPath X-Lite 3.0 c=IN IP4
218.241.111.22 t=0 0 m=audio 12706 RTP/AVP 107 119 100 106 0 105 98 8
3 101 a=alt:1 1 : IF5eH1Wn YCfz8oLV 218.241.111.22 12706 a=fmtp:101
0-15 a=rtpmap:107 BV32/16000 a=rtpmap:119 BV32-FEC/16000 a=rtpmap:100
SPEEX/16000 a=rtpmap:106 SPEEX-FEC/16000 a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv
In this example, the SBC performs the media intercept function by
rewriting the !(R)c!_ and !(R)m!_ lines in above SDP. The following
shows the session description after the intercept function.
v=0 o=- 5 2 IN IP4 218.241.111.22 s=CounterPath X-Lite 3.0 c=IN IP4
218.241.108.108 t=0 0 m=audio 30006 RTP/AVP 107 119 100 106 0 105 98
8 3 101 a=alt:1 1 : IF5eH1Wn YCfz8oLV 218.241.111.22 12706 a=fmtp:101
0-15 a=rtpmap:107 BV32/16000 a=rtpmap:119 BV32-FEC/16000 a=rtpmap:100
SPEEX/16000 a=rtpmap:106 SPEEX-FEC/16000 a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv
Yang, et al. Expires April 28, 2009 [Page 10]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
SBCs can terminate media streams and SIP dialogs by generating BYE
requests in a situation where the LI needs.
Note, if an SBC directs many media streams through SBC itself, it is
likely to cause a significant amount of additional traffic to a path
to that SBC. This might create possible bottleneck in the path.
In this prototype, we used an Open Source software, OpenSBC, written
by Joegen Baclor, Solegy LCC. To enhance the OpenSBC to replicate
RTP packet, we added media intercept function by using PCAPLIB. We
also added some code in OpenSBC to encapsulate SIP and RTP using
Diameter AVP.
3.2.2. Delivery Functions
Delivery function implemented the INI-2, INI-3, HI-2 and HI-3
interfaces specification.
Delivery function performs the delivery functions. It converts the
information from the INI-2 and INI-3 interfaces to the corresponding
information format on the HI-2 and HI-3 interfaces respectively.
It receives the data from the SBC, packets them into the correct
format and delivers them to the correct LEMF. In the case where
multiple law enforcement agencies are intercepting the same subject,
the delivery function may replicate the information many times, and
forward them to multiple LEMF interfaces simultaneously.
Signaling messages and RTP media streams are using different delivery
functions. Delivery function 2 is used for signaling messages
processing and delivering, and Delivery function 3 is used for RTP
media streams processing and delivering.
Any information stored within the SBC and Delivery functions are
stored in volatile memory, so that these information are erased if a
component of the network node is removed or powered down. Only the
encrypted database of the ADMF should be maintained during power-down
situations. In the event of a link failure between the DF and the
LEMF the intercept products may be buffered for a short time in
memory only. Any long term failure of the interface will result in
intercept products being lost - this information must not be spooled
to permanent storage.
In this prototype, we implemented Delivery functions using C++.
Yang, et al. Expires April 28, 2009 [Page 11]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
3.2.3. Collection functions in LEMF
Collection function in LEMF implemented the HI-2 and HI-3 interfaces
specification, and can receive intercepted VoIP call signaling and
RTP media stream on these two interfaces.
It records and stores the intercepted traffic, and provides analysis
tools to track, correlate and interpret intercepted traffic.
Also, collection function can recover the original VoIP call based on
the received SIP signaling and RTP media.
In this prototype, we implemented collection function using C++.
3.2.4. Administration Function
Administration function provides the provisioning interface for the
intercept as a result of a court order or warrant delivered by the
LEMF. This function implemented INI-1 and HI interfaces
specification. It is used for receiving warrants from HI-1
interface, and delivering provisioning information to SBC and
Delivery functions to point out the intercepted subject identify,
when to start and end, which delivery function the intercepted
information should be sent to, etc.
It supports user interface, maintains all warrant information from
LEMF using encrypted database, creates shared memory image of
intercept information.
In this prototype, this component is under consideration, and is not
available now.
4. Test
The objective of test is to evaluate SBC behaviors while it performs
LI, and the intercepting capability of developed LI interfaces and
functions.
The test cases covered in this document provide performance
evaluation metrics for this prototype, including:
1.concurrent number of users that completed their run successfully;
2.number of transactions that passed, failed, stopped, or ended with
errors; 3.average response time taken to perform transactions during
each second; 4.total of number of completed transactions(both
successful and unsuccessful) performed during each second; 5.minimum,
average, and maximum response time for all the transactions in the
Yang, et al. Expires April 28, 2009 [Page 12]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
load test.
4.1. Test environment
Test environment is shown in Figure 2. SBC is using the OpenSBC
which is enhanced with RTP media intercept and supports INI
interfaces; The calling and called parties are using SIPP to simulate
concurrent calls.
+-------+ INI-2 +-------+ HI-2 +-------+
| SBC |-------| DF |-------| CF |
| |.......| |.......| |
.'+-------+`.INI-3+-------+ HI-3 +-------+
.' /\ `.
.' / \ `.
RTP SIP \SIP RTP
.' / \ `.
.' / \ `.
.' +-------+ +-------+ `.
+------+ | SIP | | SIP | +------+
| |----| Proxy | | Proxy |----| |
+------+ +-------+ +-------+ +------+
Target Subscriber Target Subscriber
Figure 2 Test Topology for VoIP Lawful Interception Using SBC
VoIP call flows is shown in Figure 3.
Yang, et al. Expires April 28, 2009 [Page 13]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
A B SBC DF CF
| | | | |
| | | | |
| Request:Invite| | | |
|---------------+-------------->|INI-2 CII:Invite| |
| Status:100|Trying |--------------->|HI-2 CII:Invite |
|---------------+---------------| |--------------->|
| | Request:Invite| | |
| |---------------| | |
| Status:180Ringing | |
| |-------------->| INI-2 CII:200OK| |
|Status:180Ringing |----------------| HI-2 CII:200 OK|
|---------------+---------------| |--------------->|
| |Status:200 OK | | |
| |-------------->| | |
|Status:200 OK | | | |
|---------------+---------------| INI-2 CII:ACK | |
| | Request:ACK |--------------->+ HI-3 CII:ACK |
|---------------+-------------->| |--------------->|
| | | | |
| | Request:ACK | | |
| |---------------| | |
| RTP | | | |
################################# INI-3 CC:RTP | |
| | RTP |--------------->| HI-3 CC:RTP |
| |################ |--------------->+
| Request:BYE | | | |
|---------------+-------------->| INI-2 CII:BYE | |
| | Request:BYE |--------------->| HI-2 CII:BYE |
| |---------------| |--------------->+
| |Status:200 OK | | |
| |-------------->| | |
| Status:200 OK | | | |
|---------------+---------------| | |
| | | | |
Figure 3 Call flow of VoIP in testing
4.2. Test Scenarios and Results
4.2.1. SBC Intercepted Maximum Concurrent Session Number without media
VoIP call flows is shown in Figure 3, but there are no RTP meida
stream sent.
Procedure:
Yang, et al. Expires April 28, 2009 [Page 14]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
1. Configure SIP UDP with an attempted session rate =10 sessions per
second, session duration=20ms, and media streams per session =0.
2. Start to initiate SIP Session establishment with the SBC.
3. Measure failed session attempts and total session established at
the SBC.
4. If no failed session attempt is recorded then increase the
attempted session rate configured on the Tester by 50%.
5. If a failed session attempt is recorded then reduce the attempted
session rate configured on the Tester by 50%.
6. Repeat steps 2 through 5 until the maximum concurrent session
establishment rate is obtained.
Test result is shown in Figure 4. From result in our test, the
maximum concurrent session number is about 80. The average response
time for SIP messages is within 30ms when LI was not carried out in
SBC. The average response time for SIP messages is within 80ms when
LI was carried out in SBC.
Yang, et al. Expires April 28, 2009 [Page 15]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Maximum Concurrent SIP Sessions
________________________________________________________
| |
160| |
| |
| |
140| /| |
| ,'` |
| ,' \ |
Average 120| ,-' | |
Respinse | / \. | |
Time for | / \ |` |
SIP 100| | L.-| J |
Messages | ,.__/ \ / +
| _/ _/ b' |
80| _..______,,... .--' +-' | |
|`-----' '`' | | |
| | | |
60| / `b ,.|
| / | _/ `|
| / `o' |
40| /i |
| |-_ _. _...-' |
| ,' '`'' `' |
20|..______/\ _/-' |
|_________iiiiiiiiii_____________________________________|
10 20 30 40 50 60 70 80 90 100 110
Number of Concurrent SIP Sessions
Figure 4 Maximum Concurrent Session Number
4.2.2. SBC Intercepted Maximum Concurrent Session Number with media
VoIP call flows is shown in Figure 3.
Procedure:
1. Configure SIP UDP with an attempted session rate =10 sessions per
second, session duration=20 sec.
2. Start to initiate SIP Session establishment with the SBC and
transmit media through the SBC by modifying the SDP.
3. Measure failed session attempts and total session established,
and Packet Loss of the media.
4. If no failed session attempt or packet loss is recorded then
Yang, et al. Expires April 28, 2009 [Page 16]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
increase the attempted session rate configured on the Tester by 50%.
5. If a failed session attempt or packet loss is recorded then
reduce the attempted session rate configured on the Tester by 50%.
6. Repeat steps 2 through 5 until the maximum concurrent session
number is obtained.
Test result is shown in Figure 5 and Figure 6. From Figure, we can
see the maximum concurrent session number is 80.
The average response time for SIP messages is within 30ms when LI was
not carried out in SBC. The average response time for SIP messages
is within 90ms when LI was carried out in SBC.
200 _______________________________________________________
| |
| |
180| |
| |
| |. |
160| |\ |
| ,' \ |
| / \ ,\|
Average 140| / - ||
Response | ,' \|
Time for | ' |
SIP 120| / |
Messages | |' |
| / |
100| ,Y'''`.| o |
| ,/ ' || |
|_/`.b ...._,,'''`-.......,' || |
80|/ `-----' / \ |
| / . |
| / \. |
60| ,' | |
| / `.+ ,|
| .-` `o ,'|
40| ,+.. __,.-' `/ |
| .._ / `...' ' |
| / -. / |
20+---L,' \ ,' |
|_____________\..===i___________________________________|
10 20 30 40 50 60 70 80 90 100 110
Number of Concurrent SIP Sessions
Yang, et al. Expires April 28, 2009 [Page 17]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Figure 5 Maximum Concurrent Session Number
In our SBC implementation, SIP signaling and RTP media are processed
in different modules. In our tester, SIP signaling flows are same in
above two test cases. From Figure, we can see the RTP media
processing reached the peak value at the 80 Concurrent SIP sessions.
The throughput of RTP media streams reaches about 600 kilo bytes per
seconds.
____________________________________________________
600| __............|
| ,' |
| ,'' |
| ,' |
500| / |
| ,' |
| / |
| | |
Throuthput 400| | |
of RTP | / |
media streams | ,' |
(kilo | / |
Byte 300| / |
per | ,' +
second) | _/ |
| ,' |
| _Y' |
200| _/' |
| ,' |
| ,' |
| ,' |
100| / |
| / |
| ,' |
+/ |
|i___________________________________________________|
0 20 30 40 50 60 70 80 90 100 110
Number of Concurrent SIP Sessions
Figure 6 Maximum Concurrent RTP Media Streams
4.2.3. Delivery Function 2 CII Maximum Transactions Throughput
We use the test tool Load Running to evaluate the Delivery function
performance. We create 200 concurrent transactions, and it is the
Yang, et al. Expires April 28, 2009 [Page 18]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
maximum that can be obtained in this tool.
We can obtain the result of maximum concurrent SIP signaling
transactions throughput of Delivery Function 2 is 110 transactions,
and average concurrent transactions per second is 32. Figure 7 shows
the total number of successful CII transactions performed during each
second of a load test.
Totol Transaction per Second
+-----------------------------------------------------+
120| |
| | |
| || |
100| |`. |
| ,' | |
Transactions | / | |
Number 80| | | |
| | | |
| | | |
60| | | |
| | | |
| | | |
40| _ | | |
| _ _/'". _.,`. | | |
| ,' \b_ ,/ " \. /''''o | `. |
20|- `'"./ `.__-' `| `ob___|
| |
| |
+-----------------------------------------------------+
00:00 00:05 00:10 00:15
Elapsed scenario time mm:ss
Figure 7 Total Passed CII Transactions per Second
This graph helps to determine the actual transaction load on VoIP
Lawful Intercept system at any given moment.
4.2.4. Delivery Function 2 CII Minimum, Average and Maximum
Transactions Response Time
Figure 8 shows the minimum, average and maximum CII transactions
response time for SIP signaling transactions. The minimum response
time is 0.002 seconds, the maximum response time is 0.269 second, and
the average response time is 0.018 second.
Yang, et al. Expires April 28, 2009 [Page 19]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Average Transaction Response Time
0.3+-------------------------------------------------------+
| |
| +| |
| || |
| |\ |
| | | |
| / | |
0.2| | | |
| | \ |
Average | | | |
Response | | | |
Time | | \ |
(seconds) | / | |
| | | |
| | | |
| | \ |
0.1| | | |
| / | |
| | \ |
| | | |
0.05| | | |
| | | |
| ......................................../ \....|
|_______________________________________________________|
00:00 00:05 00:10 00:15
Elapsed scenario time mm:ss
Figure 8 CII Transaction Response Time
4.2.5. Delivery Function 3 CC Maximum Transactions Throughput
Figure 9 shows the total number of successful CC transactions
performed during each second. We can obtain the result of maximum
concurrent RTP transactions throughput of Delivery Function 3 is 25
transactions, and average concurrent RTP transactions per second is
7.
Yang, et al. Expires April 28, 2009 [Page 20]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Totol Transaction per Second
24`+----------------------------------------------------+
| \ |
| `. |
21| \* |
| | |
| | |
18| \ |
| | |
| | |
Transaction 15| | |
Number | \ |
| | |
12| | |
| \ |
| | |
9+| | /| |
| \ / \ |
| | / \ |
6+| | | | |
| | / \ |
| \ / | |
3+| | ,'*/ \ /\ |
| | / \ ,' \ |
| \ ,' | / \ |
0|___________*/_________________\____,i_______\*______+
00:00 00:02 00:05 00:08
Elapsed scenario time mm:ss
Figure 9 Total Passed CC Transactions per Second
4.2.6. Delivery Function 3 Minimum, Average and Maximum Transactions
Response Time
Figure 10 show the minimum, average and maximum CC response time for
RTP transactions. The minimum response time is 0.02 seconds, the
maximum response time is 9.05 second, and the average response time
is 3.46 second.
Yang, et al. Expires April 28, 2009 [Page 21]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Average Transaction Response Time
9+---------------------------------------------------------'
| |
8| |
| |
7| .-'|
| .-' |
Average 6| .-:-' |
Response | .-' |
Time 5| .-' |
(seconds) | .' |
4| .-' |
| .-' |
3| .'+------+.-' |
| .-' |
2| .' |
| .-' |
1| .' |
+------.- |
+------+-------+------+------+------+------+------+------+
00.00 00.01 00.02 00.03 00.04 00.05 00.06 00.07 00.08
Elapsed scenario time mm:ss
Figure 10 CC Transaction Response Time
4.2.7. Collection Function CII Maximum Transactions Throughput
From Figure 11, we can obtain the result of maximum concurrent SIP
signaling transactions throughput of collection function in LEMF is
105 transactions, and average concurrent transactions per second is
38.
Yang, et al. Expires April 28, 2009 [Page 22]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Totol Transaction Response Time
____________________________________________________
| |
| \ |
100| |\ |
| | `. |
90| / \ .| |
| /| | \.' | |
80| / \ | \ |
| | | / | |
70| / | | | |
Transactions | / \ | \ |
Numberf 60| / | | ||
| + \ / ||
50| / | | ||
| / \ | \|
40| | | / |
| / | / |
30| / \ | |
| | | / |
20| /`. / \ / |
| / `-...../ +---+/ |
10| / |
| / |
|/___________________________________________________|
00:01 00:05 00:10
Elapsed scenario time mm:ss
Figure 11 Total Passed CII Transactions per Second
4.2.8. Collection Function CII Minimum, Average and Maximum
Transactions Response Time
Figure 12 shows the CF minimum, average and maximum CII transaction
response time for SIP signaling transactions. The minimum response
time is 0.003 seconds, the maximum response time is 3.029 second, and
the average response time is 0.669 second.
Yang, et al. Expires April 28, 2009 [Page 23]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Average Transaction Response Time
3 +----------------------------------------------------------
| .|
| / |
| / |
| | |
2 | / |
| / |
Average | / |
Response | / |
Time | X | |
(seconds) | / \ / |
1 + .' \ / |
+ / | / |
| / \ | |
| .' \ / |
| / \_ ./ |
0 |,,,,,,,,,,,,,,,,,,,,,,,,; ,++-,,,;+ |
+---+---+---+---+---+---+---+----+----+---+----+---+----+-+
00:00 00:05 00:10 00:14
Elapsed scenario time mm:ss
Figure 12 CII Transaction Response Time
4.2.9. Collection Function CC Maximum Transactions Throughput
Figure 13 shows the total number of successful CC transactions in CF
performed during each second of a load test. We can obtain the
result of maximum concurrent RTP transactions throughput of CF is 63
transactions, and average concurrent RTP transactions per second is
13.
Yang, et al. Expires April 28, 2009 [Page 24]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Totol Transaction per Second
____________________________________________________
| + |
60| + |
| |\ |
| / | |
50| | | |
| / \ |
| | | |
Transactions 40+ / | |
Number \ | \ |
|| / | |
30|\ | | |
| \ / | |
| \ | \ |
20+ | / | |
| \ | | |
| \ / \ |
10+ | | | .'. |
| \ / | .' `-. |
| \`-. .-' \ / `.._|
|__________i=..=i_______________+......i_____________|
00:00 00:01 00:02 00:03 00:04 00:05 00:06 00:07 00:08
Elapsed scenario time mm:ss
Figure 13 Total Passed CC Transactions per Second
4.2.10. Collection Function CC Minimum, Average and Maximum
Transactions Response Time
Figure 14 shows the minimum, average and maximum CC response time for
RTP transactions in CF. The minimum response time is 0.013 seconds,
the maximum response time is 7.083 second, and the average response
time is 3.285 second.
Yang, et al. Expires April 28, 2009 [Page 25]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Average Transaction Response Time
_________________________________________________________
7| |
| ,"|
| ," |
6| ," |
| ," |
| ," |
5| ,-" |
| ," |
Average | ," |
Response 4| ," |
Time | ," |
(seconds) | ," |
3| /.........," |
| ," |
| / |
2| ," |
| / |
| / |
1| ," |
| / |
|__________, |
|_________________________________________________________|
00:00 00:01 00:02 00:03 00:04 00:05 00:06 00:07
Elapsed scenario time mm:ss
Figure 14 CC Transaction Response Time
5. Limitations and Issues
There are several issues both within this overall VoIP LI problem
area and with the particular approach taken in the prototype.
5.1. General Issues
It seems not to be difficult to decide whether technically mature and
widely provided services such as PSTN-based voice services, cellular
services and 3G services are to be intercepted or not. However, the
situation for recently developed services such as internet telephony
service, internet access services and messenger is difficult. The
necessary of lawful interception for these services is increasing
because of the increase of the users, but LI of the services can be
controversial because the boundary of services is not clear,
government!_s policy for IP services is not fully established, and so
on[4].
Yang, et al. Expires April 28, 2009 [Page 26]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
For the internet telephone service, the followings can be considered
to decide whether to intercept the service or not:
1. Whether it substitutes for traditional telephone services
considering the number of the service users or communication time or
sales;
2. Telecommunication service management regulations, and so on.
Because VoIP has a clear trend to substitute for traditional
telephone services such as wire telephone, wireless telephone and
mobile telephone service, it has become increasingly clear that VoIP
services will be expected to provide Lawful Intercept to the same
level experienced in the PSTN. The FCC [9] in North America for
example has mandated that both emergency calls and Lawful Intercept
must be available for VoIP. Whilst not all countries mandate this
capability, any network operator building a publicly available voice
or multimedia over IP service today will need to plan a network which
is flexible enough to implement these regulatory services in the
future.
5.2. Security Issues
The lawful intercept solution should have the ability to provide
stringent security measures to combat threats such as impersonation
of delivery function!_s, privacy and confidentiality breaches, as
well as message forgery and replay attacks.
Illegal interception may be done using facilities, equipment,
functions, human resources and procedures prepared for lawful
interception. Therefore, it is very important to prepare technical
and managerial countermeasures to prevent illegal interception,
unauthorized access to call identifying information, call content, or
to interception log data.
In general, all interfaces could have the capability of providing
strong cryptographic authentication to establish the identity of the
principals, and be able to correlate the identity of the principle
with the action they are attempting to perform. All interfaces could
be capable of performing some sort of cryptographic message integrity
checking such as, for example, HMAC-MD5, if needed[5].
While this document doesn!_t discuss issues of physical security,
operating system, or application hardening within the principals of
the lawful intercept solution, they are clearly important.
Yang, et al. Expires April 28, 2009 [Page 27]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
5.3. Protocol Details
In the current VoIP lawful interception prototype, we defined the
HI-2 and HI-3 interface specification with Abstract Syntax Notation
One(ASN.1) and Basic Encoding Rule(BER). And also provide methods to
encapsulate SIP and RTP using Diameter AVP in INI-2 and INI-3
interfaces specification.
The broadband VoIP lawful intercept solution in this document is
merely one option among many. Solutions appear to depend highly on
SBC. In any case, the prototyped solution has a number of
limitations.
6. Conclusion
Several conclusions can be drawn from the practice.
First, the practice is a proof that a prototype can be built that is
deployable on border between two VoIP networks to carry out both
interworking and intercepting for VoIP services. The practice also
proved a proof of concept for the SBC-based lawful intercept for VoIP
service.
SBC is deployed at the border between two VoIP networks to execute a
number of access, router, switch, security and quality management
roles, and they offer an ideal location to implement a Lawful
Intercept solution. Carriers don!_t need to learn the LI functions
of multiple devices, reduces costs for training, maintenance, etc.
Nevertheless, as discussed in the previous section, there are a
number of limitations, issues, and questions in the prototype
designs.
Future work in this area should attempt to answer some of the issues
raised in section 5. Some of the key issues going forward include:
1. Scalability for SBC and Delivery functions.
2. Interfaces specification design issues, such as INI-1 and HI
interfaces, etc.
3. Security considerations, all interfaces could be capable of
performing some sort of cryptographic message integrity checking such
as, for example, HMAC-MD5, if needed.
Yang, et al. Expires April 28, 2009 [Page 28]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
7. Security considerations
The purpose of the document is to report broadband VoIP LI
architecture prototype implementation and experimental results. Some
security considerations of the solution mechanisms of the prototype
are mentioned in section 5, but are not the main problem to be
described in this document.
8. Acknowledgements
The authors thank Yuanmin Chen, Bin Guo, Wei Zhang, and Hui Chen for
their assistance in developing this prototype system. The authors
thank their contribution to this document.
9. References
9.1. Normative References
[1] CCITT, "Specification of Abstract Syntax Notation One (ASN.1)",
Recommendation x. 208, November 1988.
[2] CCITT, "Specification of Basic Encoding Rules for Abstract
Syntax Notation One (ASN.1)", Recommendation x. 209, November
1988.
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, Setpember 2003.
[4] Bradner, S., "IETF Policy on Wiretapping", RFC 2804, May 2000.
[5] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture for
Lawful Intercept in IP Networks", RFC 3924, October 2004.
[6] ANS, ., "Lawfully Authorized Electronic Surveillance(LAES) for
Voice over Packet Technologies in Wireline Telecommunications
Networks", T1 678, 2004.
[7] ETSI, "Telecommunications security: Lawful Interception (LI):
Requirements for network functions", ETSI 201 158, April 2004.
9.2. Informative References
[8] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A.,
and M. Bhatia, "Requirements form SIP (Session Initiation
Protocol) Session Border Control Deployments", June 2008.
Yang, et al. Expires April 28, 2009 [Page 29]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
[9] Federal Communication Commission, "Second Report and Order and
Memorandum Option and order, Washinton,D.C", May 2006.
Authors' Addresses
Menghui Yang
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3204
Email: yangmenghui@cnnic.cn
Xiaodong Li
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3020
Email: lee@cnnic.cn
Wei Mao
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 2230
Email: mao@cnnic.cn
Yang, et al. Expires April 28, 2009 [Page 30]
Internet-Draft Architecture and Practice for VoIP LI Oct 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Yang, et al. Expires April 28, 2009 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-24 01:33:20 |