Internet DRAFT - draft-sriram-sipping-poc-lip
draft-sriram-sipping-poc-lip
SIPPING Working Group
Document: draft-sriram-sipping-poc-lip-02.txt <S.Sriram>
Internet-Draft Motorola
Expires: February 17, 2006 August 17, 2005
Lawful Intercept procedure via the Session Initiation Protocol (SIP) for
the Open Mobile Alliance (OMA) Push to talk over Cellular (PoC)
draft-sriram-sipping-poc-lip-02.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 February 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the Lawful Intercept Procedure using Session
Initiation Protocol (SIP) used by the Open Mobile Alliance (OMA), for
S.Sriram Expires - February, 2006 [Page 1]
LIR: Lawful Intercept Request May 2005
Push to talk over Cellular (PoC) along with their applicability, which
is limited to the OMA PoC application.
Table of Contents
1 Overall Applicability ............................... 2
2 Conventions ......................................... 2
3 Overview ............................................ 3
4 Definitions ......................................... 4
5 Lawful Interception Operation in PoC ................ 4
5.1 Procedure at the PoC User to perform Legal
Interception ....................................... 4
5.2 Procedures at the PoC Server performing the Lawful
Intercept function ................................. 5
5.2.1 PoC Control Plane Procedure ......................... 5
5.2.2 PoC User Plane Procedure ............................ 6
5.3 Procedure at the PoC User to stop Legal
Interception ....................................... 7
5.4 Procedure at the PoC Server to stop Legal
Interception ....................................... 7
6 Lawful Intercept Request Protocol Syntax ............ 7
6.1 Header Fields ....................................... 8
6.1.1 Mode-of-Tapping ...................................... 8
6.1.2 Direction ........................................... 9
6.1.3 PoC-User-to-be-Tapped ............................... 9
7 Illustrative Examples ............................... 9
8 IANA considerations ................................. 10
8.1 The "application/lir" mime type ..................... 10
9 Formal Syntax ....................................... 10
10 Security Considerations ............................. 11
11 References .......................................... 12
12 Copyright Statement ................................. 13
13 Disclaimer of Validity .............................. 13
14 Acknowledgment ...................................... 13
15 Author's Address .................................... 13
1 Overall Applicability
The SIP extensions specified in this document make certain assumptions
regarding network topology, and the availability of transitive trust.
These assumptions are generally NOT APPLICABLE in the Internet as a
whole. The mechanisms specified here were designed to satisfy the
requirements specified by the Open Mobile Alliance for Push-to-talk
over cellular for which either no general-purpose solution was found,
where insufficient operational experience was available to understand
if a general solution is needed, or where a more general solution
is not yet mature. For more details about the assumptions made about
these extensions, consult the Applicability subsection for each
extension.
2 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
S.Sriram Expires - February, 2006 [Page 2]
LIR: Lawful Intercept Request May 2005
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [2].
3 Overview
The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is
specifying the Push-to-talk Over Cellular (PoC) service where SIP is
the protocol used to establish half duplex media sessions across
different participants. Push to talk over Cellular (PoC) is intended
to provide rapid communications for business and consumer customers of
mobile networks. PoC will allow user voice and data communications
shared with a single recipient, (1-to-1) or between groups of
recipients as in a group chat session, (1-to-many). This document
describes the procedure for Lawful Interception of the PoC via SIP
signaling.
The PoC Server implements the application level network functionality
for the PoC service and shall provide centralized PoC Session
handling, media distribution and Talk Burst Control functionality. The
PoC Service uses a half duplex type of communication and only one PoC
User in a PoC Session can send media at the time. The PoC User does
not send a continuous stream of RTP Media packets instead the media is
sent in bursts, in this document referred to as a Talk Burst. A PoC
Server located between the PoC Users communicating with each other
acts as an arbitrator and controls the sending of Talk Burst using a
Talk Burst Control Protocol (TBCP). PoC Users are located on mobile
devices hence the quality of the transmission may vary depending on
access network and distance to the base station.
All RTP Media packets, RTCP packets and TBCP messages (RTCP APP or
other negotiated TBCP) flow through the PoC Server performing the
Participating PoC function (if inserted in the transport path) and are
terminated in the PoC Server performing the Controlling PoC Function.
The transport path between the PoC User and the PoC Server performing
the Controlling PoC Function is established on a per PoC Session
basis.
When the PoC Session is established, the PoC Server performing the
Participating PoC Function normally includes itself into the transport
path to relay the RTP Media packets, RTCP packets and TBCP messages
between the PoC User and the PoC Server performing the Controlling PoC
Function and act as a translator according to [RFC3550].
Considering a case where a PoC Server performing the Participating PoC
Function has inserted itself in the transport path. When the transport
path includes the Participating PoC Function, the PoC Server
(performing the Participating PoC Function) forwards RTP Media
packets, RTCP packets and TBCP messages between the PoC User and the
PoC Server (performing the Controlling PoC Function). This is done
when the PoC server is used to support lawful intercept procedures.
S.Sriram Expires - February, 2006 [Page 3]
LIR: Lawful Intercept Request May 2005
This document proposes the approach to perform the the Lawful
Intercept procedure via SIP signaling for OMA PoC. The PoC server
processes the Lawful Intercept request information generated in the
SIP request received from the PoC user and performs the Lawful
Intercept procedure.
4 Definitions
The following OMA PoC related definitions are relevant to this
document
PoC Address: A PoC Address identifies a PoC User. The PoC Address can
be used by one PoC User to request communication with other PoC Users.
PoC User: A PoC User is a user of the PoC service.
PoC Client: A PoC Client is a PoC functional entity that resides on
the PoC User Equipment that supports the PoC service.
Talk Burst: A Talk Burst is the flow of media from a PoC User while
that has the permission to send media.
The following definitions are relevant to this document
FBI Agent: The FBI Agent is a PoC Client/User who has special access
to tap any other PoC user supported by the PoC server.
Mode-of-Tapping: The tapping shall be done in split or combined mode.
In Split mode, the FBI agent SHALL be able to listen to either SEND or
RECEIVE media stream of the PoC user who is tapped. The "Direction" in
this context specifies SEND stream or RECEIVE stream. In combined
mode, the FBI agent SHALL be able to listen to both the SEND and
RECEIVE media streams of the PoC user who is tapped.
5 Lawful Interception Operation in PoC
The Lawful Interception request information contains a series of
information lines. Each line contains some part of the operation
information and follows text based encoding rules and procedures that
could be carried in the SIP signaling message.
5.1 Procedure at the PoC User to perform Legal Interception:
The FBI Agent, who has the special privileges to listen to any PoC
User, is himself a PoC User. The FBI Agent (PoC User)
1. SHALL Set the Request-URI of the SIP INVITE request to the
Conference-factory-URI for the PoC service in the Home PoC Network.
S.Sriram Expires - February, 2006 [Page 4]
LIR: Lawful Intercept Request May 2005
2. SHALL add the Lawful Intercept Message body which carries the
information regarding
a. PoC User to be tapped.
b. The mode in which the tapping should be done.(Split or
Combined mode)
c. The direction in which the tapping should be done.(Only in
case of split mode.(send or receive))
i. If "direction=send", the FBI agent (PoC User) requests for
tapping only the media streams sent out by the PoC User who
is to be tapped.
ii.If "direction=receive", the FBI agent (PoC User) requests
for tapping only the media streams that is received the PoC
User who is to be tapped.
3. SHALL generate an initial SIP INVITE request according to the rules
and procedures of [RFC3261] and the general procedure as in section
6.1.3.1 with the media stream direction as "sendonly" in the
session description parameter
FBI Agent (PoC User) SHALLL be challenged and authenticated by the
PoC Server for authorization credentials and the same shall be
sent by the FBI Agent (PoC User) in the second INVITE request
towards the PoC Server.
If the authentication was successful and if the PoC server was able
to successfully extract the Lawful Intercept message and process it
successfully, then the FBI Agent (PoC User) SHALL receive a 200 OK
from the PoC Server with the media description parameters of the
PoC Server. The FBI Agent (PoC User) SHALL send an ACK for 200 OK and
listen on the RTP port for media streams sent by the PoC server.
5.2 Procedures at the PoC Server performing the Lawful Intercept
function:
5.2.1 PoC Control Plane Procedure
1. Upon receiving an initial SIP INVITE request the PoC Server SHALL
check
- if it is the Terminating PoC Service Point.
- if the SIP URI in the Request-URI of the SIP INVITE request
corresponds to the Conference-factory-URI of the PoC service in
the network served by the PoC Server.
If both the checks are valid, then the PoC Server SHALL check if
the SIP message contains the Lawful Intercept Message body.
If this message body is present,the PoC server SHALL challenge the
authenticity of the FBI agent by sending a 407 SIP response
message with the realm, nonce, qop, opaque and algorithm to the
FBI Agent (PoC User).
S.Sriram Expires - February, 2006 [Page 5]
LIR: Lawful Intercept Request May 2005
2. Upon receiving the second INVITE from the FBI Agent (PoC User), the
PoC server shall authenticate all the credentials to confirm that
the PoC user(FBI Agent) has all the privileges to use the Lawful
Intercept Message body.
3. If the credentials supplied by the FBI Agent (PoC User) are valid,
then the PoC server SHALL read the Lawful Intercept Message body
and get the details of
a. PoC User to be tapped.
b. The mode in which the tapping should be done.(Split or
Combined mode explained below)
c. The direction in which the tapping should be done.(Only in
case of split mode.(send or receive))
4. The PoC server shall check if it is the terminating PoC Service
Point for the PoC User URI mentioned in the Lawful Intercept
Message body. If so, then the PoC Server SHALL send a 200 OK for
the INVITE with the SDP answer according to the rules and
procedures of [RFC 3264] and [RFC 3267].
5. The PoC server SHALL interact with the PoC User Plane and
instruct the Controlling PoC Function to start the legal intercept
procedure by providing the following information:
a. FBI Agent's (PoC User's) SDP profile
b. The PoC User identification to be tapped.
c. The mode of tapping to be followed.
5.2.2 PoC User Plane Procedure
The Controlling PoC Function performing the Lawful Intercept function:
1. SHALL receive the identification of the PoC User to be tapped;(RTP
port and IP address).
2. SHALL receive the identification of the FBI agent(s)(PoC User(s));
(RTP port and IP address).
3. SHALL receive the mode in which the tapping is to be done on the
PoC User;(Combined or Split mode).
4. SHALL perform the tapping functionality via two modes of operation
as listed:
a. In Combined mode, The Controlling PoC Function takes on
additional responsibility:
- To transmit the RTCP SR and RTP packets sent by the PoC User
that is tapped to the FBI agent (PoC User).
S.Sriram Expires - February, 2006 [Page 6]
LIR: Lawful Intercept Request May 2005
- To transmit the RTP SR and RTP packets sent by all other PoC
Users in the same group call to the FBI agent (PoC User).
b. In Split mode, The Controlling PoC Function takes on additional
responsibility:
- To transmit the RTCP SR and RTP packets sent by the PoC User
that is tapped to the FBI agent (PoC User) if the direction
requested for the tap creation is onl for 'send' media
streams.
- To transmit the RTP SR and RTP packets sent by all other PoC
Users in the same group call to the FBI agent (PoC User) if
the direction requested for the tap creation is only for
'receive' media streams.
Note: As the FBI Agent(s) (PoC User(s)) are invisible to all other PoC
users in the active group call, the controlling PoC function should
not inform the RTCP SR compound packet sent by the FBI Agent(s) (PoC
User(s)) to any of the PoC Users in the PoC Session.
When the FBI agent (PoC User) wants to release the tap, the same SHALL
be informed via the Control Plane and the Controlling PoC Function
shall stop sending the multicast RTP packets to the FBI Agent(s) RTP
port and shall release the reserved resources.
5.3 Procedure at the PoC User to stop Legal Interception:
This procedure is same as the one mentioned in the section 6.1.6 in
the PoC Control Plane document [Reference 3].
5.4 Procedure at the PoC Server to stop Legal Interception:
This procedure is same as the one mentioned in the section 7.2.1.9.1
in the PoC Control Plane document [Reference 3].
6 Lawful Intercept Request Protocol Syntax
The media type follows the conventions of the SIP (RFC 3261 [1]) for
Lawful intercept request header information formatting. The Lawful
intercept request header information contains a series of information
headers with each of the information header lines terminated by a
CRLF.
Lawful-intercept request-info = *info-header
info-header = "header-name" HCOLON header-value *(COMMA header value)
CRLF
S.Sriram Expires - February, 2006 [Page 7]
LIR: Lawful Intercept Request May 2005
The basic set of information header fields are defined in this
document. However the information elements can be extended adhering to
the generic framework of header format defined above.
The header field formats strictly adhere to the conventions defined
for SIP in section 7.3.1 of RFC 3261. Each header field consists of a
field name followed by a colon (":") and the field value.
field-name: field-value
The header names and the header values are case sensitive.
6.1 Header Fields
This section lists the full set of header fields along with notes on
syntax, meaning, and usage. The ABNF [8] definitions for the headers
follow the notations on the basis of section 25 of SIP(RFC 3261[1]).
The conditions for the presence of the header fields in the lawful
intercept request information are summarized in Table 1.
The following codes are used in the table.
c: Conditional; requirements on the header field depend on other
fields in the information.
m: The header field is mandatory.
o: The header field is optional.
Header Field presence
____________________________________________________
Mode-of-Tapping m
Direction c
PoC-User-to-be-Tapped m
Table 1: Presence of headers
There is a specific requirement for the order in which the information
headers should be present in the charging information. It is required
that the Mode-of-Tapping header field be present as the first header
field. The other header fields following this first header field shall
be present in any order.
6.1.1 Mode-of-Tapping
The Mode-of-Tapping header field defines the mode in which the tapping
shall be done. There are two modes of tapping defined in this
document: split mode, combined mode.
S.Sriram Expires - February, 2006 [Page 8]
LIR: Lawful Intercept Request May 2005
This header field MUST be present one and only once per Lawful
intercept information.
Mode-of-Tapping = " Mode-of-Tapping" HCOLON Modes-of-Tapping
Modes-of-Tapping = "split" | "combined"
Example: Mode-of-Tapping: split
6.1.2 Direction
The Direction header field defines the direction in which the split
mode of tapping is done. This header field shall be present only if
the 'Mode-of-Tapping' is 'split' mode. This field can take two
values:
- 'send' indicating the SEND stream of the PoC user to be tapped,
- 'receive'indicating the RECEIVE stream of the PoC user to be
tapped.
This header field MUST be present one and only once per billing
information.
Direction = "Direction" HCOLON Directions
Directions = "send" | "receive"
Example: Direction: send
6.1.3 PoC-User-to-be-Tapped
The PoC-User-to-be-Tapped field defines the SIP/TEL URI of the PoC
user who is to be tapped.
This header field MUST be present one and only once per billing
information.
PoC-User-to-be-Tapped = "PoC-User-to-be-Tapped" HCOLON SIP-URI or TEL-
URI
SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ]
Example: PoC-User-to-be-Tapped: sip:sriram@motorola.com
7 Illustrative Examples
The Lawful Intercept request information is sent in the INVITE method
by the FBI Agent who wants to tap a PoC User listed in his request
information.
INVITE sip:FBI_Agent@conference-factoryURI.net SIP/2.0
P-Preferred-Identity: "FBI_Agent" <sip: FBI_Agent @networkA.net>
Accept-Contact:*;+g.poc.talkburst; require;explicit
S.Sriram Expires - February, 2006 [Page 9]
LIR: Lawful Intercept Request May 2005
User-Agent: PoC-User/OMA1.0 Acme-Talk5000/v1.01
Authorization: Digest username=" FBI_Agent-private@networkA.net",
realm="registrar.networkA.net", nonce="",
uri="sip:registrar.networkA.net", response=""
Privacy: Id
Contact: <sip: FBI_Agent @conference-factoryURInet >
Supported: Timer
Session-Expires: 1800;refresher=uac
Allow: INVITE,ACK,CANCEL,BYE,REFER,MESSAGE,SUBSCRIBE, NOTIFY,PUBLISH
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: 407
--unique-boundary-1
Content-Type: application/SDP
v=0
o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4
c=IN IP4 motds.mot.com
m=audio 3456 RTP/AVP 97
a=Rtpmap:97 AMR
a=rtcp:5560
m=application 2000 udp TBCP
a=recvonly
a=fmtp:TBCP queuing=1; tb_priority=2; timestamp=1
--unique-boundary-1
Content-Type: application/lir
Mode-of-Tapping: split
Direction: send
PoC-User-to-be-Tapped: sip:sriram@motorola.com
--unique-boundary-1--
8 IANA considerations
8.1 The "application/lir" mime type
This draft registers the "application/lir" MIME media type.
The Lawful intercept request (lir) information is text-based. It
follows the recommendations of RFC 2045[10] for the usage of text-
based data for MIME.
This media type is defined by the following information:
Media type name: application
Media subtype name: lir
Required Parameters: None
Encoding scheme: ASCII
Security considerations: See section 10
S.Sriram Expires - February, 2006 [Page 10]
LIR: Lawful Intercept Request May 2005
9 Formal Syntax
The following syntax specification uses the augmented Backus-Naur Form
(BNF) as described in RFC-2234 [3].
The grammar for this mime-type is mostly derived out of the SIP
specification (RFC 3261[1]). The following definitions are derived
from the SIP specification (RFC 3261[1]) token DIGIT HCOLON
quoted-string
Lawful-Intercept-Request-Info = *(Information-Header)
Information-Header = (Advice-State / Mode-of-Tapping /
Direction / PoC-User-to-be-Tapped)
Mode-of-Tapping = " Mode-of-Tapping" HCOLON Modes-of-Tapping Modes-
of- Tapping = "split" | "combined"
Direction = "Direction" HCOLON Directions Directions = "send" |
"receive"
PoC-User-to-be-Tapped = "PoC-User-to-be-Tapped" HCOLON SIP-URI or TEL-
URI SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
10 Security Considerations
The Lawful Intercept request message body contains sensitive
information that requires the use of encryption. Lawful Intercept
request information should not be trusted until it is ensured that it
is received through reliable sources.
As a reference, security mechanisms provided in SIP [1] (section
26.1.3) can be used as this is appropriate for both the SIP message
and the encapsulated Lawful intercept request information. Encryption
of the Lawful intercept request information is also considered a good
solution. Some form of cryptographic hashing on the Lawful intercept
request information may be used to ensure there is no tampering of the
message en-route. MD5 (RFC 1321[14]) is a good choice.
However, OMA PoC standards does not mandate any security mechanisms, a
cryptographic hash of the Lawful intercept request information along
S.Sriram Expires - February, 2006 [Page 11]
LIR: Lawful Intercept Request May 2005
with a shared key SHOULD be carried as a part of the Lawful intercept
request information. PoC Server SHALL authenticate the FBI Agent (PoC
User) credentials and SHALL process the Lawful Intercept Message body
only after confirming that the PoC User has the rights to intercept
the call of another PoC User.
11 References
1 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 OMA PoC Control Plane
Candidate Version 1.0 û 17 March 2005, Open Mobile Alliance
OMA-TS-POC-ControlPlane-V1_0-20050317-C
4 PoC User Plane Version
Candidate Version 1.0 û 17 March 2005, Open Mobile Alliance
OMA-TS_PoC-UserPlane-V1_0-20050317-C
5 Push to talk over Cellular (PoC) - Architecture
Candidate Version 1.0 û 17 March 2005, Open Mobile Alliance
OMA-AD_PoC-V1_0-20050317-C
6 J. Galvin, Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted, RFC:1847, October 1995
7 B. Ramsdell, Editor,
S/MIME Version 3 Message Specification, RFC:2633, June 1999
8 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
9 Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail
Extensions (MIME) Part Four: Registration Procedures", BCP 13,
RFC 2048, November 1996.
10 Freed, N. and N. Borenstein, "Multipart Internet Mail
Extensions(MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
11 Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, November 1996.
12 Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header
Field", RFC 2183, August 1997.
S.Sriram Expires - February, 2006 [Page 12]
LIR: Lawful Intercept Request May 2005
13 W. Marshall, Ed., F. Andreasen, Ed Private Session Initiation
Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the
PacketCable Distributed Call Signaling Architecture, RFC 3603,
October 2003
14 IAB, IETF Policy on Wiretapping, RFC 2804,May 2000
12 Copyright Statement
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.
13 Disclaimer of Validity
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 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.
14 Acknowledgment
I would like to thank my Manager Mr S Hariprasad for constant support
and encouragement for proposing a draft on Lawful intercept procedure
in OMA PoC via SIP signaling.
15 Author's Addresses
S.Sriram
4-D9-170, Motorola
No.66/1, Plot No. 5, Bagmane Techpark
CV Raman Nagar Post
Bangalore - 560 093
DID phone: 91-80-26014170
Mobile: 91-9886704956
Fax: 91-80-25343100
Email: sriram.s@motorola.com
S.Sriram Expires - February, 2006 [Page 13]
