One document matched: draft-dcsgroup-mmusic-privacy-00.txt
B. Beser
M. Mannette
K. Steinbrenner
3Com
D. Oran
Cisco
J. Pickens
Com21
P. Lalwaney
J. Fellows
General Instrument
D. Evans
Lucent Cable
K. Kelly
NetSpeak
F. Andreasen
Telcordia
June, 1999
SIP Extensions for Caller Privacy
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the IETF
with any rights other than to publish as an Internet-Draft.
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."
DCS Group Internet Draft - Expiration 12/31/99 1
SIP Extensions for Caller Privacy June 1999
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.
The distribution of this memo is unlimited. It is filed as <draft-
dcsgroup-mmusic-privacy-00.txt>, and expires December 31, 1999.
Please send comments to the authors.
1. Abstract
The Session Initiation Protocol (SIP) is an application layer
control (signaling) protocol for creating, modifying and terminating
sessions with one or more participants. In the current PSTN, call
signaling messages travel through switches which act as trusted
intermediaries. The signaling messages typically include calling
party identification information which may be delivered to the
called party. The calling party is able to suppress the delivery of
such information to the called party in order to maintain privacy.
In a Voice over IP environment using SIP user agents as the
equivalent of telephones and SIP proxies as trusted intermediaries,
calling parties may also desire to maintain their privacy. In this
document, we describe a proposed SIP extension that may be used to
request calling party privacy in the above mentioned environment.
This includes a recognition that privacy in a VoIP environment
extends beyond simply hiding SIP level user information to
potentially hiding calling party IP address information as well.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
3. Introduction
In the telephone network, the Calling Number Delivery and Calling
Name Delivery services provide the called party with identity
information about the calling party prior to the called party
answering the call; the calling party is here identified as the
station originating the call. In order for this service to be
dependable, the called party must be able to trust that the calling
identity information being presented is valid. Consider for example
a tele-marketer presenting himself with the identity of one of your
co-workers, or, even worse, an automated credit-card activation
system using calling identity information as an authorization check.
DCS Group Internet Draft - Expiration 12/31/99 2
SIP Extensions for Caller Privacy June 1999
In order for the calling identity information to be trustworthy, the
information must come from a trusted source.
One scenario for establishing such trust is for a SIP user agent to
require that all incoming SIP invitations arrive through a set of
trusted SIP proxies; for simplicity we will assume that each SIP
user agent is associated with a single SIP proxy, which we will
refer to as a DCS-proxy in this document. DCS-proxies are
interconnected and maintain a transitive trust relationship. Thus if
a SIP user agent originates a call through a DCS-proxy, it trusts
that the DCS-proxy will carry out the service requested, even if
other DCS-proxies are involved. DCS-proxies however do not trust SIP
user agents, since these will typically reside at the customer
premise.
When a call is placed, the calling identity delivery services reveal
privacy information to the called party, and the calling party
therefore has the option to block the delivery of this information
to the called party. This is typically achieved by subscribing to a
Calling Identity Delivery Blocking service but can be done on an
individual call basis as well. When the Calling Identity Delivery
Blocking Service is invoked, information about the calling party is
still passed through the trusted intermediaries, however
presentation restriction indicators are set in the signaling
messages to signal the far-end side, that the calling identity
information is not to be provided to the called party.
More generally, we may say that the service provided is that of
preventing the called party from obtaining information about the
calling party that may either be used to identify the party or
reveal location information about the party. In an IP environment,
IP addressing information may provide the called party with
information to reach or identify the calling party. IP addressing
information may reveal some level of location information, for
instance if one has knowledge of which addresses are deployed where,
or by revealing that a given caller is using a different IP-address
or address block than usual.
When such a privacy service is to be provided in a SIP environment,
it leads to two requirements. First, calling identity information
present in SIP messages must not be delivered in an intelligible
form to the called party. Secondly, when using SIP in an IP
environment, IP addressing information must be hidden from the
called party.
We assume that a SIP user agent can recognize invitations arriving
through its trusted DCS-proxy. Furthermore, as in the current
telephone network, the trusted DCS-proxy is expected to either
receive or possess calling party information enabling it to identify
the calling party.
The calling party identification information can be provided to the
called party's DCS-proxy as the "display-name" in the "name-addr"
DCS Group Internet Draft - Expiration 12/31/99 3
SIP Extensions for Caller Privacy June 1999
part of a From header field [2]. In such a scenario, the calling
party may have excluded the "display-name" field from the invitation
it issued in order to not reveal its identity to the called party.
The absence of this field could by itself be an indication to the
DCS proxy, that privacy was requested. For DCS-proxy to DCS-proxy
communication, where the information would still be passed, a
presentation restriction indicator would then be needed.
In order to maintain complete privacy in an IP environment, calling
party IP-address information may have to be concealed from the
terminating party as well. The cost and complexity of providing IP
address level privacy rather than simply SIP level privacy is likely
to differ enough to warrant two separate services. The calling party
will thus need to signal the DCS-proxy which privacy service it is
requesting.
4. SIP Extension
In the following we first present a proposed SIP extension to
address the privacy issues identified. We then present an example of
how this may be used to provide the privacy service.
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [3].
4.1 PRIVACY
We propose to extend SIP with a new header field called DCS-Privacy
which allows the calling party to indicate the degree of privacy
that should be provided by the DCS-proxy.
The syntax of the proposed extension is as follows:
Privacy = "Privacy" ":" *privacy-tag
privacy-tag = "Full" | "Caller-Num" | "Caller-Name" | "IPAddr"
The value "Caller-Num" requests the originating phone number not be
displayed to the destination. The value "Caller-Name" requests the
calling name not be displayed. The value "IPAddr" requests IP
privacy such that the destination is not given the originator's IP
address. The value "Full" requests both Caller-Num and Caller-Name
blocking and IP address privacy. Any combination of these values
may appear in this header.
4.2 Example of Use
In this Section, we will illustrate how the request for privacy may
work in practice. It should be noted that the privacy service
described can be implemented in a number of ways; we merely describe
one possible solution in this section.
DCS Group Internet Draft - Expiration 12/31/99 4
SIP Extensions for Caller Privacy June 1999
The Figure below illustrates a basic privacy example scenario
+---------+ +--------+
1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE
+------->| proxy-o |------------>| proxy-t|---------+
| +---------+ +--------+ |
| |
| trust boundary |
. . |. . . . . . . . . . . . . . . . . . . . . . .. . . | . . .
| |
| \/
+------+ RTP/RTCP +------+
|MTA-o |<------------------------------------------->|MTA-t |
+------+ +------+
Figure 1 - Basic Privacy Example
The originating user agent (MTA-o) sends an INVITE (1) message
requesting caller-name privacy to DCS-proxy-o. DCS-proxy-o ensures
that authentic calling identity information is included in the
message before it sends INVITE (2) to DCS-proxy-t. DCS-proxy-t
examines the DCS-caller header field included in the INVITE and sees
that caller-name privacy is requested. Consequently, DCS-proxy-t
replaces the caller-name in "display-name" with the string
"anonymous".
While this illustrates the basic operation of the service, there are
additional issues that need to be considered. In SIP, there are
other fields than "display-name" that can reveal the identity of the
calling party, either in part or completely. In the cases of calling
name and calling number privacy, the "addr-spec", e.g. SIP-URL, part
of the From header field may contain calling party information. This
privacy problem can be overcome by having MTA-o encrypt the SIP-URL
and supplying a user parameter indicating that the SIP-URL is
encrypted. The key used is shared between MTA-o and DCS-proxy-o.
Also, when the session description protocol (SDP) is used to
describe the media in the session, the use of SDP fields revealing
calling identity information needs to be examined as well. Similar
concerns apply to the use of RTCP.
The second example we look at is one where full privacy is
requested, i.e. both calling name and number privacy, as well as IP
address privacy. The Figure below illustrates how IP address privacy
can be achieved by inserting a trusted intermediary, an anonymizer,
for the media streams between MTA-o and MTA-t.
DCS Group Internet Draft - Expiration 12/31/99 5
SIP Extensions for Caller Privacy June 1999
+---------+ +--------+
1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE
+------->| proxy-o |------------>| proxy-t|----------+
| +---------+ +--------+ |
| \ / |
| \ / |
| SIP +--------+ SIP |
| +----------------->| anony- |-------------------+ |
| | +------>| mizer |--------+ | |
| | | +--------+ | | |
| | | | | |
| | | | | |
| | | trust boundary | | |
. . |.|. . . . . | . . . . . . . . . . . . | . . .. . |..| . . .
| | | | | |
| | | | \/ \/
+------+ RTP/RTCP| |RTP/RTCP +------+
|MTA-o |<--------+ +-------->|MTA-t |
+------+ +------+
Figure 2 - Full Privacy Example
For all signaling and media exchange purposes, the anonymizer adds a
level of indirection thereby hiding the IP address(es) of MTA-o from
MTA-t. This indirection is used both for the media streams and SIP
signaling, beyond the initial INVITE, exchanged directly between
MTA-o and MTA-t.
Also, the following commonly used header fields may reveal privacy
information, which can be remedied as described:
@ The From header field must not reveal any calling identity
information in the SIP-URL, e.g. by encrypting it. The "display-
name" must be anonymous.
@ A Contact header field must be set to point to the anonymizer to
prevent any direct signaling between MTA-o and MTA-t
@ Via header fields identifying either MTA-o or DCS-proxy-o must be
hidden, e.g. by encryption or simple stateful removal and re-
insertion by DCS-proxy-t.
@ Call-ID should not be based on MTA-o's IP-address
Furthermore, when SDP is used to describe the media in the session,
the session descriptions exchanged by the user agents need to be
modified to direct the media streams to the anonymizer. Again, the
use of SDP fields revealing calling identity information needs to be
considered as well. Similar concerns apply to the use of RTCP.
5. Security Considerations
A user requesting complete privacy must still authenticate himself
to the DCS-Proxy, and therefore the SIP messages between MTA-o and
DCS Group Internet Draft - Expiration 12/31/99 6
SIP Extensions for Caller Privacy June 1999
DCS-proxy-o must be protected. Likewise, it is necessary that the
proxies take precautions to protect the user identification
information from eavesdropping and interception. Use of IPSec
between MTA and DCS-proxy and between proxies is recommended.
6. References
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol," RFC 2543, March 1999.
3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
7.
Acknowledgments
The Distributed Call Signaling work in the PacketCable project is
the work of a large number of people, representing many different
companies. The authors would like to recognize and thank the
following for their assistance: John Wheeler, Motorola; David
Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows,
Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug
Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay
Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckle, Cisco;
and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, and Partho
Mishra, AT&T.
8. Author's Addresses
Bill Marshall
AT&T
Florham Park, NJ 07932
Email: wtm@research.att.com
K. K. Ramakrishnan
AT&T
Florham Park, NJ 07932
Email: kkrama@research.att.com
Ed Miller
CableLabs
Louisville, CO 80027
Email: E.Miller@Cablelabs.com
Glenn Russell
DCS Group Internet Draft - Expiration 12/31/99 7
SIP Extensions for Caller Privacy June 1999
CableLabs
Louisville, CO 80027
Email: G.Russell@Cablelabs.com
Burcak Beser
3Com
Rolling Meadows, IL 60008
Email: Burcak_Beser@3com.com
Mike Mannette
3Com
Rolling Meadows, IL 60008
Email: Michael_Mannette@3com.com
Kurt Steinbrenner
3Com
Rolling Meadows, IL 60008
Email: Kurt_Steinbrenner@3com.com
Dave Oran
Cisco
Acton, MA 01720
Email: oran@cisco.com
John Pickens
Com21
San Jose, CA
Email: jpickens@com21.com
Poornima Lalwaney
General Instrument
San Diego, CA 92121
Email: plalwaney@gi.com
Jon Fellows
General Instrument
San Diego, CA 92121
Email: jfellows@gi.com
Doc Evans
Lucent Cable Communications
Westminster, CO 30120
Email: n7dr@lucent.com
Keith Kelly
NetSpeak
Boca Raton, FL 33587
Email: keith@netspeak.com
Flemming Andreasen
Telcordia
Piscataway, NJ
Email: fandreas@telcordia.com
DCS Group Internet Draft - Expiration 12/31/99 8
SIP Extensions for Caller Privacy June 1999
DCS Group Internet Draft - Expiration 12/31/99 9
SIP Extensions for Caller Privacy June 1999
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."
Expiration Date This memo is filed as <draft-dcsgroup-mmmusic-
privacy-00.txt>, and expires December 31, 1999.
DCS Group Internet Draft - Expiration 12/31/99 10
| PAFTECH AB 2003-2026 | 2026-04-24 02:47:56 |