idnits 2.17.1 draft-dcsgroup-sip-privacy-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 639 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 7) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 41 looks like a reference -- Missing reference section? '4' on line 195 looks like a reference -- Missing reference section? '2' on line 94 looks like a reference -- Missing reference section? '3' on line 180 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group W. Marshall 3 Internet Draft K. Ramakrishnan 4 Document: AT&T 5 Category: Informational 6 E. Miller 7 G. Russell 8 CableLabs 10 B. Beser 11 M. Mannette 12 K. Steinbrenner 13 3Com 15 D. Oran 16 F. Andreasen 17 Cisco 19 J. Pickens 20 Com21 22 P. Lalwaney 23 J. Fellows 24 Motorola 26 D. Evans 27 Secure Cable Solutions 29 K. Kelly 30 NetSpeak 32 March, 2000 34 SIP Extensions for Caller Identity, Privacy and Operator Services 36 Status of this Memo 38 This document is an Internet-Draft and is NOT offered in accordance 39 with Section 10 of RFC2026[1], and the author does not provide the 40 IETF with any rights other than to publish as an Internet-Draft. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. Internet-Drafts are draft documents valid for a maximum of 46 six months and may be updated, replaced, or obsoleted by other 47 documents at any time. It is inappropriate to use Internet- Drafts 48 as reference material or to cite them other than as "work in 49 progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 DCS Group Internet Draft - Expiration 9/30/00 1 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 The distribution of this memo is unlimited. It is filed as , and expires September 30, 2000. Please 60 send comments to the authors. 62 1. Abstract 64 The Session Initiation Protocol (SIP) [4] is an application layer 65 control (signaling) protocol for creating, modifying and terminating 66 sessions with one or more participants. In the current PSTN, call 67 signaling messages travel through switches which act as trusted 68 intermediaries. The signaling messages typically include calling 69 party identification information which may be delivered to the 70 called party. The calling party is able to suppress the delivery of 71 such information to the called party in order to maintain privacy. 73 In a Voice over IP environment using SIP user agents as the 74 equivalent of telephones and SIP proxies as trusted intermediaries, 75 there may still be requirements to provide calling party 76 identification information, yet communicating parties may also 77 desire to maintain their privacy. In this document, we describe 78 three proposed SIP extensions. The first one may be used to support 79 calling and called party, i.e. remote party, identification 80 including a remote party-type to identify special types of callers 81 such as operators. The second extension allows a party to request 82 privacy in the above mentioned environment and includes a 83 recognition that privacy in a VoIP environment extends beyond simply 84 hiding SIP level user information, to potentially hiding the parties 85 IP address information as well. The third extension allows a user 86 agent to be requested to extend special operation to some calls such 87 as operator services. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 93 this document are to be interpreted as described in RFC-2119 [2]. 95 3. Introduction 97 In the telephone network, calling identity information is needed to 98 support the Calling Number Delivery and Calling Name Delivery 99 services which provide the called party with identity information 100 about the calling party prior to the called party answering the 101 call; the calling party is here identified as the station 102 originating the call. In order for this service to be dependable, 103 the called party must be able to trust that the calling identity 105 DCS Group Internet Draft - Expiration 9/30/00 2 106 information being presented is valid. Consider for example a tele- 107 marketer presenting himself with the identity of one of your co- 108 workers, or, even worse, an automated credit-card activation system 109 using calling identity information as an authentication check. In 110 order for the calling identity information to be trustworthy, the 111 information must come from a trusted source. 113 Calling identity information may also be needed to support 114 regulatory requirements for a public telephony service. An example 115 of this is the Customer Originated Trace service, which enables a 116 called party to have the identity of a calling party recorded by the 117 telephony service provider. This enables, e.g., the receiver of 118 harassing phone calls to make the identity of the originator of such 119 calls available to the proper authority. Again, in order for this 120 service to be useful, the Calling Identity information recorded must 121 be trustworthy. 123 One scenario for establishing such trust is for a SIP user agent to 124 require that all incoming SIP invitations arrive through a trusted 125 SIP proxy. For simplicity we will assume that each SIP user agent is 126 associated with a single SIP proxy, which we will refer to as a DCS- 127 proxy in this document. DCS-proxies are interconnected with other 128 DCS-proxies which may or may not trust each other. When a SIP user 129 agent originates a call through its DCS-proxy, it trusts that the 130 DCS-proxy will carry out the service requested, even if other DCS- 131 proxies are involved. The DCS-proxy however does not trust the SIP 132 user agent since it will typically reside at the customer premise. 134 When a call is placed, the calling identity delivery services reveal 135 privacy information to the called party, and the calling party 136 therefore has the option to block the delivery of this information 137 to the called party. In the PSTN, this is typically achieved by 138 subscribing to a Calling Identity Delivery Blocking service but can 139 be done on an individual call basis as well. When the Calling 140 Identity Delivery Blocking Service is invoked, information about the 141 calling party is still passed through the trusted intermediaries, 142 however presentation restriction indicators are set in the signaling 143 messages to signal the far-end side, that the calling identity 144 information is not to be provided to the called party. 146 More generally, we may say that the service provided is that of 147 preventing the called party from obtaining information about the 148 calling party that may either be used to identify the party or 149 reveal location information about the party. In an IP environment, 150 IP addressing information may provide the other party with 151 information to reach or identify the calling party. IP addressing 152 information may reveal some level of location information, for 153 instance if one has knowledge of which addresses are deployed where, 154 or by revealing that a given caller is using a different IP-address 155 or address block than usual. 157 When such a privacy service is to be provided in a SIP environment, 158 it leads to two requirements. First, calling identity information 160 DCS Group Internet Draft - Expiration 9/30/00 3 161 present in SIP messages must not be delivered in an intelligible 162 form to the called party, yet it must be possible to determine the 163 identity of the call originator even in the case where the call is 164 routed through one or more untrusted intermediaries. Secondly, when 165 using SIP in an IP environment, IP addressing information must be 166 able to be hidden from the other party. Furthermore, in an IP 167 environment, these requirements apply equally well in the opposite 168 direction, i.e. the calling party may wish to identify the called 169 party and the called party may have privacy concerns as well. 171 4. SIP Extensions 173 In the following we present our proposed SIP extensions for Calling 174 and Called Identity Delivery, and Privacy as well as an extension 175 for requesting special call processing, e.g. for operator services. 176 We then present an example of how the privacy extensions may be used 177 to provide the privacy service. 179 The syntax specification in the following uses the augmented Backus- 180 Naur Form (BNF) as described in RFC-2234 [3]. 182 4.1 CALLING AND CALLED PARTY IDENTITY DELIVERY 184 For the Calling and Called Identity Delivery, we assume that a SIP 185 user agent can determine if invitations are arriving through its 186 DCS-proxy, and thereby can be trusted, or not. Furthermore, as in 187 the current telephone network, the trusted DCS-proxy is assumed to 188 either receive or possess calling party information that enables it 189 to determine the identity of the calling party. In the following, we 190 will use the term remote party to refer to calling and called party, 191 where a distinction is not important. 193 The calling party identity information could be provided to the 194 called party's DCS-proxy as the "display-name" in the "name-addr" 195 part of a From header field [4]. Even though the "display-name" is 196 part of the "From" header, it is not considered part of the call leg 197 identifier. SIP user agents and DCS-proxies would therefore be able 198 to manipulate the value of this parameter, including adding, 199 modifying, and deleting Calling Identity information. This was in 200 fact suggested in a previous version of this document, but based on 201 Working Group feedback, it was preferred to introduce a separate 202 header field for this. 204 The header field suggested is called Remote-Party-ID, which is added 205 to an INVITE message to identify the caller and provides a long- 206 lived identification of the caller. The header field may also be 207 added to the response to provide a long-lived identification of the 208 called party. The Remote-Party-ID header field is inserted by the 209 originating SIP user agent, and is verified and possibly modified by 210 its DCS Proxy. The DCS-proxy authenticates the information provided, 211 for example by digitally signing the Remote-Party-ID or simply 213 DCS Group Internet Draft - Expiration 9/30/00 4 214 providing a Message Authentication Code (MAC); the details depend on 215 the authentication scheme used. Whenever the call originator 216 requests privacy and the message crosses a trust boundary, the 217 Remote-Party-ID must be encrypted to ensure that its confidentiality 218 is maintained while still enabling the call originator to be 219 identified (by the encrypting proxy). 221 The terminating DCS Proxy forwards the Remote-Party-ID header to the 222 destination SIP user agent in an intelligible form (if possible) 223 only if the user agent has subscribed to Caller ID/Calling Name 224 delivery service, and the originator has not requested privacy. 225 Similar operation may be performed in the reverse direction. The 226 proposed header syntax follows: 228 Remote-Party-ID = "Remote-Party-ID" ":" [display-name] 229 "<" addr-spec ">" *(";" rpi-token) 231 rpi-token = rpi-id | rpi-type | rpi-auth | 232 other-rpi-token 234 rpi-id = "rpi-id" "=" ("private" | "unavailable" 235 | "na") 237 rpi-type = "rpi-type" "=" ("operator" | token) 239 rpi-auth = "auth" "=" auth-scheme #auth-param 240 auth-scheme = token 241 auth-param = token "=" (token | quoted-string) 243 other-rpi-token = token ["=" (token | quoted-string)] 245 Furthermore, we define the value "private" for "other-param" in an 246 "addr-spec", to indicate that the user part of an "addr-spec" is in 247 a non-intelligible form. The syntax for "other-param" is therefore 248 refined to: 250 other-param = (token | (token "=" (token | quoted-string))) 251 | "private" 253 The "display-name" in Remote-Party-ID is a text string that 254 identifies the account name of the party. The "addr-spec" contains 255 information identifying the party either in clear-text or encrypted 256 form. In the latter case, the "user" part of the "addr-spec" 257 contains the encrypted party information, whereas the "hostport" 258 identifies the entity that can decrypt the information. Furthermore, 259 an "other-param" value of "private" will be present to indicate that 260 the "addr-spec" is encrypted. 262 The following example illustrates this: 264 Remote-Party-ID: 266 where e(x) indicates that x is encrypted. 268 DCS Group Internet Draft - Expiration 9/30/00 5 269 When the called party subscribes to calling identity delivery 270 services, and the remote party information is not readily available, 271 the "rpi-id" token indicates the nature of the "addr-spec" provided. 272 The value "private" indicates that the remote party information is 273 encrypted, and consequently the user agent should not attempt to 274 display it. The value "unavailable" indicates that calling identity 275 information was not available and the addr-spec provided should be 276 ignored. When the called party does not subscribe to calling 277 identity delivery services, the value "na" may be provided. 279 The "rpi-type" token allows the SIP user agent to identify different 280 types of callers which may be used to determine if special 281 privileges should be extended to a given party. The string 282 "operator" is a reserved identifier indicating that a telephony 283 service provider operator is the remote party. The SIP user agent 284 may for instance decide to honor a request for Busy-Line 285 Verification or Emergency Interrupt by an operator; a request it 286 might otherwise refuse. 288 As noted above, calling identity information must be trustworthy in 289 order to be useful. In the absence of a trust relationship between 290 all the proxies involved in a call, it must therefore be possible to 291 add authenticity information to the Remote-Party-ID as well as 292 specify who authenticated the information. 294 The "auth" token provides this function by authenticating everything 295 in the Remote-Party-ID that precedes the "auth" token (up until but 296 not including the semi-colon). The actual syntax and semantics 297 depend on the authentication scheme used. Details on usage with pgp 298 is specified later in this document. 300 Multiple "auth" tokens may be present which allows proxies to state 301 that the Remote-Party-ID information provided is authentic without 302 necessarily claiming that the identity of the remote party is 303 correct. For example, a call between A and B where A is served by 304 Proxy PA and B is served by Proxy PB might have the following 305 Remote-Party-ID: 307 Remote-Party-ID: ; 308 auth=pgp signature="abc", signed-by="PA"; 309 auth=pgp signature="xyz", signed-by="PB" 311 which implies that PA certifies that the call was originated by A, 312 whereas PB certifies that PA certifies that the call was originated 313 by A. Had PB trusted PA, then PB could instead have removed the 314 "auth" token from PA, and simply have certified the information 315 itself. 317 Finally, it should be noted, that when a proxy encrypts the Remote- 318 Party-ID information, the proxy may choose to add additional "url- 319 parameters" (in the form of "other-param") to the "addr-spec" to 321 DCS Group Internet Draft - Expiration 9/30/00 6 322 identify the encryption algorithm used as well as integrity checks 323 for the "addr-spec". These parameters could be useful to the proxy 324 when the "addr-spec" is used for a subsequent call, e.g. call return 325 or call trace, however this would be internal to the proxy and is 326 consequently not specified. This operation should not be confused 327 with the authentication parameters specified above where the 328 authenticating party, e.g. proxy, may differ from the verifying 329 party, e.g. user agent. 331 4.1.1 Remote-Party-ID Authenticity with PGP 333 This section details the use of pgp for the rpi-token by refining 334 the auth syntax as follows: 336 rpi-auth = "auth" "=" auth-scheme #auth-param 337 auth-scheme = "pgp" 338 auth-param = pgp-response 340 where pgp-response is defined in RFC 2543, Section 15.1.2. 342 An example was provided in the previous section. 344 4.2 PRIVACY 346 In support of privacy, the originator of a call must have a way of 347 suppressing the delivery of calling identity information to the 348 called party. One way of achieving that could simply be to omit the 349 information from the Remote-Party-ID field. However, for DCS-proxy 350 to DCS-proxy communication, where the information would still need 351 to be passed, a presentation restriction indicator would then be 352 needed. 354 Also, in order to maintain complete privacy in an IP environment, 355 calling party IP-address information may have to be concealed from 356 the terminating party as well. The cost and complexity of providing 357 IP address level privacy rather than simply SIP level privacy is 358 likely to differ enough to warrant two separate services. The 359 calling party will thus need to signal the DCS-proxy which privacy 360 service it is requesting. 362 We therefore propose to extend SIP with a new header field called 363 Anonymity which allows an originating SIP user agent to indicate the 364 degree of privacy that should be provided by the DCS proxy. The 365 value "URI" requests the party's identity not be provided to the 366 destination. The value "Name" requests the calling name not be 367 provided. The value "IPAddr" requests IP privacy such that the 368 destination is not given the originator's IP address. The value 369 "Full" requests both URI and Name blocking and IP address privacy. 370 The header field also allows a receiving SIP user agent to indicate 371 its desire for privacy in its response to the first INVITE request. 373 DCS Group Internet Draft - Expiration 9/30/00 7 374 This will operate similarly to privacy requested by the originating 375 party. 377 The syntax for the proposed header field follows: 379 Anonymity = "Anonymity" ":" *privacy-tag 380 privacy-tag = "Full" | "URI" | "Name" | "IPAddr" | "Off" 382 If privacy is requested, it MUST be one or more of "Full", "URI", 383 "Name", or "IPAddr". The value "Off" indicates that no privacy is 384 requested, and MUST be the only value if present. 386 4.3 Operator Services Call Processing 388 Some calls have special call processing requirements that may not be 389 satisfied by normal user agent call processing. For example, when a 390 user is engaged in a call and another call arrives, such a call 391 might be rejected with a busy indication. However, some PSTN 392 operator services require special call processing. In particular, 393 the Busy line verification (BLV) and Emergency interrupt(EI) 394 services initiated by an operator from an Operator Services Position 395 System (OSPS) on the PSTN network have such a need. 397 In order to inform the SIP user agent, that special treatment should 398 be given to a call, we propose a new OSPS header field which may be 399 set to a value indicating when a special type of call processing is 400 requested. We define two values in this header, namely "BLV" for 401 busy line verification and "EI" for emergency interrupt: 403 OSPS = "OSPS" ":" OSPS-Tag 404 OSPS-Tag = "BLV" | "EI" | token 406 If the user agent decides to honor such a request, the response of 407 the user agent to an INVITE with either "BLV" or "EI" will not be a 408 busy indication. When such a request is received, the user agent may 409 look at the Remote-Party-ID, and decide only to honor the request if 410 "rpi-type" is "operator" and Remote-Party-ID was authenticated by 411 the user agent's DCS-proxy. 413 4.4 Example of Use 415 In this Section, we will illustrate how the request for privacy may 416 work in practice. It should be noted that the privacy service 417 described can be implemented in a number of ways; we merely describe 418 one possible solution in this section. 420 The Figure below illustrates a basic privacy example scenario 422 DCS Group Internet Draft - Expiration 9/30/00 8 423 +---------+ +--------+ 424 1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE 425 +------->| proxy-o |------------>| proxy-t|---------+ 426 | +---------+ +--------+ | 427 | | 428 | trust boundary | 429 . . |. . . . . . . . . . . . . . . . . . . . . . .. . . | . . . 430 | | 431 | \/ 432 +------+ RTP/RTCP +------+ 433 |MTA-o |<------------------------------------------->|MTA-t | 434 +------+ +------+ 436 Figure 1 - Basic Privacy Example 438 The originating user agent (MTA-o) sends an INVITE (1) message 439 requesting URI and name privacy to DCS-proxy-o. DCS-proxy-o ensures 440 that valid calling identity information is included in the message 441 before it sends INVITE (2) to DCS-proxy-t, which in this case is 442 trusted. DCS-proxy-t examines the Anonymity header field included in 443 the INVITE and sees that URI and name privacy is requested. DCS- 444 proxy-t therefore encrypts the "addr-spec" in the Remote-Party-ID, 445 puts the result in the "user" part, inserts itself as the 446 "hostport", and adds an "auth" parameter to the end, e.g. using a 447 pgp signature. If MTA-t subscribes to caller-id, DCS-proxy-t also 448 inserts "rpi-id=private" in the Remote-Party-ID. Finally, if a 449 "display-name" was provided in the Remote-Party-ID, DCS-proxy-t 450 simply removes it. 452 While this illustrates the basic operation of the service, there are 453 additional issues that need to be considered. In SIP, there are 454 additional fields that can reveal the identity of the calling party, 455 either in part or completely. In the cases of calling name and 456 calling number privacy, the "addr-spec", e.g. SIP-URL, as well as 457 "display-name" part of the From header field may contain calling 458 party information. This privacy problem can be overcome by having 459 MTA-o supply a cryptographically random identifier for the userinfo, 460 and a non-identifying hostname, e.g. "localhost". Also, when the 461 session description protocol (SDP) is used to describe the media in 462 the session, the use of SDP fields revealing calling identity 463 information needs to be considered as well. Similar concerns apply 464 to the use of RTCP. 466 The second example we look at is one where full privacy is 467 requested, i.e. both calling name and number privacy, as well as IP 468 address privacy. The Figure below illustrates how IP address privacy 469 can be achieved by inserting a trusted intermediary, an anonymizer, 470 for the media streams between MTA-o and MTA-t. 472 DCS Group Internet Draft - Expiration 9/30/00 9 473 +---------+ +--------+ 474 1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE 475 +------->| proxy-o |------------>| proxy-t|----------+ 476 | +---------+ +--------+ | 477 | \ / | 478 | \ / | 479 | SIP +--------+ SIP | 480 | +----------------->| anony- |-------------------+ | 481 | | +------>| mizer |--------+ | | 482 | | | +--------+ | | | 483 | | | | | | 484 | | | | | | 485 | | | trust boundary | | | 486 . . |.|. . . . . | . . . . . . . . . . . . | . . .. . |..| . . . 487 | | | | | | 488 | | | | \/ \/ 489 +------+ RTP/RTCP| |RTP/RTCP +------+ 490 |MTA-o |<--------+ +-------->|MTA-t | 491 +------+ +------+ 493 Figure 2 - Full Privacy Example 495 For all signaling and media exchange purposes, the anonymizer adds a 496 level of indirection thereby hiding the IP address(es) of MTA-o from 497 MTA-t. This indirection is used both for the media streams and SIP 498 signaling, beyond the initial INVITE, exchanged directly between 499 MTA-o and MTA-t. 501 Also, the following commonly used header fields may reveal privacy 502 information, which can be remedied as described: 504 @ The From header field must not reveal any calling identity 505 information in the SIP-URL. This can be remedied, e.g. by 506 supplying a cryptographically random identifier for the userinfo, 507 and a non-identifying hostname, e.g. "localhost". The "display- 508 name" must be anonymous. 509 @ A Contact header field must be set to point to the anonymizer to 510 prevent any direct signaling between MTA-o and MTA-t 511 @ Via header fields identifying either MTA-o or DCS-proxy-o must be 512 hidden, e.g. by encryption or simple stateful removal and re- 513 insertion by DCS-proxy-t. 514 @ Call-ID should not be based on MTA-o's IP-address 516 Furthermore, when SDP is used to describe the media in the session, 517 the session descriptions exchanged by the user agents need to be 518 modified to direct the media streams to the anonymizer. Again, the 519 use of SDP fields revealing calling identity information needs to be 520 considered as well. Similar concerns apply to the use of RTCP. 522 5. Security Considerations 524 DCS Group Internet Draft - Expiration 9/30/00 10 525 A user requesting complete privacy must still authenticate himself 526 to the DCS-Proxy, and therefore the SIP messages between MTA-o and 527 DCS-proxy-o must be protected. Likewise, it is necessary that the 528 proxies take precautions to protect the user identification 529 information from eavesdropping and interception. Use of IPSec 530 between MTA and DCS-proxy as well as between proxies is recommended. 532 6. References 534 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 535 9, RFC 2026, October 1996. 537 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 538 Levels", BCP 14, RFC 2119, March 1997 540 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 541 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 542 Demon Internet Ltd., November 1997 544 4 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 545 "SIP: Session Initiation Protocol," RFC 2543, March 1999. 547 7. Acknowledgments 549 The Distributed Call Signaling work in the PacketCable project is 550 the work of a large number of people, representing many different 551 companies. The authors would like to recognize and thank the 552 following for their assistance: John Wheeler, Motorola; David 553 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 554 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 555 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 556 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 557 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 558 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 559 Cable Communications. 561 8. Author's Addresses 563 Bill Marshall 564 AT&T 565 Florham Park, NJ 07932 566 Email: wtm@research.att.com 568 K. K. Ramakrishnan 569 AT&T 570 Florham Park, NJ 07932 571 Email: kkrama@research.att.com 573 DCS Group Internet Draft - Expiration 9/30/00 11 574 Ed Miller 575 CableLabs 576 Louisville, CO 80027 577 Email: E.Miller@Cablelabs.com 579 Glenn Russell 580 CableLabs 581 Louisville, CO 80027 582 Email: G.Russell@Cablelabs.com 584 Burcak Beser 585 3Com 586 Rolling Meadows, IL 60008 587 Email: Burcak_Beser@3com.com 589 Mike Mannette 590 3Com 591 Rolling Meadows, IL 60008 592 Email: Michael_Mannette@3com.com 594 Kurt Steinbrenner 595 3Com 596 Rolling Meadows, IL 60008 597 Email: Kurt_Steinbrenner@3com.com 599 Dave Oran 600 Cisco 601 Acton, MA 01720 602 Email: oran@cisco.com 604 Flemming Andreasen 605 Cisco 606 Edison, NJ 607 Email: fandreas@cisco.com 609 John Pickens 610 Com21 611 San Jose, CA 612 Email: jpickens@com21.com 614 Poornima Lalwaney 615 Motorola 616 San Diego, CA 92121 617 Email: plalwaney@gi.com 619 Jon Fellows 620 Motorola 621 San Diego, CA 92121 622 Email: jfellows@gi.com 624 Doc Evans 625 Secure Cable Solutions 627 DCS Group Internet Draft - Expiration 9/30/00 12 628 Westminster, CO 30120 629 Email: drevans@securecable.com 631 Keith Kelly 632 NetSpeak 633 Boca Raton, FL 33587 634 Email: keith@netspeak.com 636 DCS Group Internet Draft - Expiration 9/30/00 13 637 Full Copyright Statement 639 "Copyright (C) The Internet Society (date). All Rights Reserved. 640 This document and translations of it may be copied and furnished to 641 others, and derivative works that comment on or otherwise explain it 642 or assist in its implementation may be prepared, copied, published 643 and distributed, in whole or in part, without restriction of any 644 kind, provided that the above copyright notice and this paragraph 645 are included on all such copies and derivative works. However, this 646 document itself may not be modified in any way, such as by removing 647 the copyright notice or references to the Internet Society or other 648 Internet organizations, except as needed for the purpose of 649 developing Internet standards in which case the procedures for 650 copyrights defined in the Internet Standards process must be 651 followed, or as required to translate it into languages other than 652 English. The limited permissions granted above are perpetual and 653 will not be revoked by the Internet Society or its successors or 654 assigns. This document and the information contained herein is 655 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 656 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 657 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 658 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 659 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 661 Expiration Date This memo is filed as , and expires September 30, 2000. 664 DCS Group Internet Draft - Expiration 9/30/00 14