idnits 2.17.00 (12 Aug 2021) /tmp/idnits6625/draft-ietf-sip-connect-reuse-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 303 has weird spacing: '..., which could...' -- 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.) -- The document date (Feb 2004) is 6669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2617 (ref. '5') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Outdated reference: draft-ietf-sipping-3pcc has been published as RFC 3725 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '8') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '10') (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '11') (Obsoleted by RFC 4960) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG R. Mahy 3 Internet-Draft Cisco Systems, Inc. 4 Expires: August 1, 2004 Feb 2004 6 Connection Reuse in the Session Initiation Protocol (SIP) 7 draft-ietf-sip-connect-reuse-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 1, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 When SIP entities use a connection oriented protocol to send a 38 request, they typically originate their connections from an ephemeral 39 port. The SIP protocol includes mechanisms which insure that 40 responses to a request, and new requests sent in the original 41 direction reuse an existing connection. However, new requests sent 42 in the opposite direction are unlikely to reuse the existing 43 connection. This frequently causes a pair of SIP entities to use one 44 connection for requests sent in each direction, and can result in 45 potential scaling and performance problems. This document proposes 46 requirements and a mechanism which address this deficiency. 48 Table of Contents 50 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction and Problem Statement . . . . . . . . . . . . . . 3 52 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1 Authorizing an alias request . . . . . . . . . . . . . . . . . 8 55 4.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 59 Normative References . . . . . . . . . . . . . . . . . . . . . 11 60 Informational References . . . . . . . . . . . . . . . . . . . 11 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 62 Intellectual Property and Copyright Statements . . . . . . . . 13 64 1. Conventions 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 [2]. 70 2. Introduction and Problem Statement 72 SIP [1] entities can communicate using either unreliable/ 73 connectionless (ex: UDP) or reliable/connection-oriented (ex: TCP, 74 SCTP [11]) transport protocols. When SIP entities use a 75 connection-oriented protocol (such as TCP or SCTP) to send a request, 76 they typically originate their connections from an ephemeral port. 78 In the following example, Entity A listens for SIP requests over TLS 79 [4] on TCP port 5061 (the default port for SIP over TLS over TCP), 80 but uses an ephemeral port (port 8293) for a new connection to Entity 81 B. These entities could be SIP User Agents or SIP Proxy Servers. 83 +-----------+ 8293 (UAC) 5061 (UAS) +-----------+ 84 | |--------------------------->| | 85 | Entity | | Entity | 86 | A | | B | 87 | | 5061 (UAS) | | 88 +-----------+ +-----------+ 90 The SIP protocol includes mechanisms which insure that responses to a 91 request reuse the existing connection which is typically still 92 available, and also includes provisions for reusing existing 93 connections for other requests sent by the originator of the 94 connection. However, new requests sent in the opposite direction 95 (routed from the target of the original connection toward the 96 originator of the original connection) are unlikely to reuse the 97 existing connection. This frequently causes a pair of SIP entities 98 to use one connection for requests sent in each direction, as shown 99 below. 101 +-----------+ 8293 5061 +-----------+ 102 | |.......................>| | 103 | Entity | | Entity | 104 | A | 5061 9741 | B | 105 | |<-----------------------| | 106 +-----------+ +-----------+ 108 This extra pair of connections can result in potential scaling and 109 performance problems. For example, each new connection using TLS 110 requires a TCP 3-way handshake, a handful of round-trips to establish 111 TLS, and (typically) expensive asymetric authentication and key 112 generation algorithms, and certificate verification. This 113 effectively doubles the load on each entity. Setting up a second 114 connection can also cause excessive delay (especially in networks 115 with long round-trip times) for subsequent requests, even requests in 116 the context of an existing dialog (for example a reINVITE or BYE 117 after an initial INVITE, or a NOTIFY after a SUBSCRIBE [8] or a REFER 118 [9]). 120 Consider the call flow shown below where Proxy A and Proxy B use the 121 Record-Route mechanism to stay involved in a dialog. Proxy B will 122 establish a new TLS connection just to send a BYE request. 124 INVITE -> create connection 1 125 <- 200 response over connection 1 126 ACK -> reuse connection 1 128 <- BYE create connection 2 129 -> 200 response over connection 2 131 ReINVITEs are expected to be handled automatically and rapidly in 132 order to avoid media and session state from being out of step. If a 133 reINVITE requires a new TLS connection, the reINVITE could be delayed 134 by several extra round-trip times. Depending on the round-trip time, 135 this combined delay could be perceptible or even annoying to a human 136 user. This is especially problematic for some common SIP call flows 137 (for example, the recommended example flow in figure number 4 in 3pcc 138 [7]) use many reINVITEs. 140 Consider also a call flow where a handheld organizer sends a REFER 141 request which establishes a dialog to a SIP phone. Typically this 142 would require a second connection back to the handheld to be 143 established. 145 REFER -> connection 1 146 <- 202 connection 1 147 <- NOTIFY connection 2 148 200 -> connection 2 149 INVITE -> 150 <- 200 151 <- NOTIFY connection 2 152 200 -> connection 2 154 Likewise when clusters or farms of cooperating SIP servers (for 155 example proxy servers) are configured together, SIP entities have no 156 way to prefer a server with an existing connection. For example, 157 Proxy server B has no mechanism to choose an existing connection with 158 Proxy cluster A. 160 +-----------+ 161 | | 162 | Proxy | 163 | A1 | +-----------+ 164 | | | | 165 +-----------+ | Proxy | 166 +-----------+ 8293 5061 | B | 167 | |----------------------->| | 168 | Proxy | +-----------+ 169 | A2 | 170 | | 171 +-----------+ 173 As a result, Proxy B might open a new connection to another proxy 174 server for requests sent in the opposite direction. 176 +-----------+ 177 | | 178 | Proxy | 179 | A1 | 5061 9741 +-----------+ 180 | |<.......................| | 181 +-----------+ | Proxy | 182 +-----------+ 8293 5061 | B | 183 | |----------------------->| | 184 | Proxy | +-----------+ 185 | A2 | 186 | | 187 +-----------+ 189 The rules for handling the Transport layer described in Section 18 of 190 SIP [1] do not associate incoming connections with the listening port 191 which corresponds to the same SIP entity. If the Tranport layer had 192 some way to associate these connections, then request and responses 193 originated from either node could reuse existing connections as shown 194 below. 196 +-----------+ +-----------+ 197 | | | | 198 | Node A | 8293 5061 | Node B | 199 | |<======================>| | 200 | | | | 201 +-----------+ +-----------+ 203 3. Requirements 205 1. A connection sharing mechanism SHOULD allow SIP entities to reuse 206 existing connections for requests and repsonses originated from 207 either peer in the connection. 209 2. A connection sharing mechanism SHOULD allow SIP entities to reuse 210 existing connections with closely coupled nodes which act as a 211 single SIP entity (for example a cluster of nodes acting as a 212 proxy server). 214 3. A connection sharing mechanism MUST NOT require UACs (clients) to 215 send all traffic from well-know SIP ports. 217 4. A connection sharing mechanism MUST NOT require configuring 218 ephemeral port numbers in DNS. 220 5. A connection sharing mechanism MUST prevent unauthorized 221 hijacking of other connections. 223 6. Connection sharing SHOULD persist across SIP transactions and 224 dialogs. 226 4. Behavior 228 The proposed mechanism uses a new Via header field parameter. The 229 "alias" parameter is included in a Via header field value to indicate 230 that the originator of the request wants to create a transport layer 231 alias, so that the sent-by address becomes mapped to the current 232 connection. 234 Assuming the Via header field value shown below from the most recent 235 request arrived over a connection from 10.54.32.1 port 8241: 237 Via: SIP/2.0/TLS 10.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias 239 The transport layer creates an alias, such that any requests going to 240 the "advertised address" (10.54.32.1 port 5061) are instead sent over 241 the existing connection (to the "target" of the alias) which is 242 coming from port 8241. This sharing continues as long as the target 243 connection stays up. The SIP community recommends that servers keep 244 connections up unless they need to reclaim resources, and that 245 clients keep connections up as long as they are needed. Connection 246 reuse works best when the client and the server maintain their 247 connections for long periods of time. SIP entities therefore SHOULD 248 NOT drop connections on completion of a transaction or termination of 249 a dialog. 251 Likewise when clusters or farms of cooperating SIP servers (for 252 example proxy servers) are configured together, the proposed 253 mechanism allows a SIP entity to select a server with an existing 254 connection. With the proposed mechanism, Proxy B sends requests for 255 Proxy cluster A to node A2 with whom it shares an existing 256 connection. 258 +-----------+ 259 | | 260 | Proxy | 261 | A1 | +-----------+ 262 | | | | 263 +-----------+ | Proxy | 264 +-----------+ 8293 5061 | B | 265 | |<======================>| | 266 | Proxy | +-----------+ 267 | A2 | 268 | | 269 +-----------+ 271 For example, on receipt of a message with the topmost Via header 272 shown below, the transport layer creates an alias such that requests 273 going to the advertised address (proxy-farm-a.example.com) are sent 274 over the target connection (from 10.54.32.1:8241). 276 Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias 278 As a result, this has an important interaction with the DNS 279 resolution mechanisms for SIP described in RFC3263 [6]. When new 280 requests arrive for proxy-farm-a.example.com, proxy B still needs to 281 perform a DNS NAPTR lookup to select the transport. Once the 282 transport is selected, an SRV lookup would ordinarily occur to find 283 the appropriate port number. In this case, the transport layer uses a 284 connection reuse alias instead of performing the SRV query. 286 Below is a partial DNS zone file for atlanta.com. 288 ; NAPTR queries for the current domain (example.com) 289 ; 290 ; order pref flags service regexp replacement 291 proxy-farm-a IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp. 293 ; SRV records for the proxy use 5060/5061 294 ; 295 ;; Priority Weight Port Target 296 _sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a1 297 _sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a2 299 host-a1 IN A 10.54.32.1 300 host-a2 IN A 10.54.32.2 301 The existence of an alias parameter is treated as a request which 302 asks the transport layer to create an alias (named by the sent-by 303 parameter, which could be a hostname) that points to the alias 304 target (the current connection) 306 This mechanism is fully backwards compatible with existing 307 implementations. If the proposed Via parameter is not understood by 308 the recipient, it will be ignored and the two implementations will 309 revert to current behavior (two connections). 311 4.1 Authorizing an alias request 313 Authorizing connection aliases is essential to prevent connection 314 hijacking. For example a program run by a malicious user of a 315 multiuser system could attempt to hijack SIP requests destined for 316 the well-known SIP port from a large relay proxy. 318 To correctly authorize an alias, both the active connection and the 319 alias need to authenticate using the same credentials. This could be 320 accomplished using one of two mechanisms. The first (and preferred) 321 mechanism is using TLS mutual authentication, such that the 322 subjectAltName of the originator certificate corresponds to both the 323 current connection and the target address of the alias. The Via 324 sent-by address needs to be within the scope protected by the 325 certificate presented by the originator during TLS mutual 326 authentication and the received IP address needs be a valid IP 327 address for the sent-by host or hosts. In other words, the sent-by 328 address MUST be resolvable from the subjectAltName of the originator 329 certificate, and the received IP address MUST be resolvable from the 330 sent-by address. This is in addition to other requirements for TLS 331 authentication and authorization discussed in SIP [1] and Locating 332 SIP Servers [6]. 334 Following this logic step-by-step: 336 1. Verify that the certificate presented is not expired and is 337 rooted in a trusted certificate chain. 339 2. Verify that the subjectAltName in the certificate covers the 340 "advertised address" (the address in the Via sent-by production). 341 If the advertised address and the subjectAltName match exactly 342 then the certificate covers the address. Also, use DNS to 343 resolve if the advertised name is resolvable from the 344 subjectAltName (start by resolving the subjectAltName with first 345 NAPTR, next SRV, then finally address records). If any of the 346 resolved addresses (port numbers can be ignored in this case) 347 matches the advertised address, then the certificate covers the 348 address. 350 3. Finally, Verify that the advertised address can resolve to the IP 351 address over which the connection was received. 353 For example, take the example in the previous section of proxy B 354 receiving an alias request from host-a2.example.com. Proxy B 355 verifies that the presented certificate is valid and trusted. Proxy B 356 checks that proxy-farm-a.example.com is both the advertised name and 357 the subjectAltName in the certificate. Finally, proxy B verifies 358 that this connection is coming from 10.54.32.2, which is one of the 359 addresses in DNS for proxy-farm-a.example.com 361 The second mechanism is to accept an alias if the target address of 362 the alias is equivalent (using SIP comparison rules) to a valid 363 Contact already registered by the same user. This user could be 364 authenticated through any SIP or TLS mechanism (ex: user certificate, 365 or Kerberos [10]), but would typically use Digest authentication [5]. 366 For example, if Alice registers a Contact of 198.168.67.89:5061, she 367 could inform Proxy 1 of the existence of a connection to her from 368 Proxy 2. This would allow her to preemptively originate TLS 369 connections, as her user agent may not have access to a site 370 certificate with which to authenticate incoming TLS connections. 372 The Proxy takes the following steps to authorize these requests: 374 1. The Proxy authenticates or authorizes the sender for an otherwise 375 ordinary SIP request. 377 2. The Proxy looks for any Contacts in the location/registration 378 service which have a hostport and transport that matches exactly 379 the advertised address. 381 3. The Proxy checks if the user who sent the request would be 382 authorized to change the Contact found when looking up the 383 Contact URI in the location/registration service. 385 For example, Alice advertises the address "198.168.67.89:5061" in a 386 request sent over a connection from "198.168.67.89:8293" to Proxy 2. 387 The Proxy otherwise authenticates Alice's request (for example an 388 INVITE request). The Proxy looks up 198.168.67.89:5061 and finds the 389 following Contact: "Alice" . Alice is 390 authorized to modify Alice's contact, so Alice is authorized to alias 391 an advertised address "reserved" by one of her Contacts. Alice then 392 sends another request (this time an OPTIONS request for example) to 393 Proxy 1 from "198.168.67.89.8672" with the same Via header. Proxy 1 394 similarly authorizes Alice's request and stores the alias. Now if 395 either proxy receives a request for 198.168.67.89:5061, it will 396 forward the request over the appropriate existing connection with 397 Alice. 399 Via: SIP/2.0/TLS 198.168.67.89:5061;branch=z9hG4bK7c8dze ;alias 401 +-----------+ 402 | | 403 | Proxy | 404 +-----------+ 8672 5061 | 1 | 405 | |----------------------->| | 406 | Alice | +-----------+ 407 | | +-----------+ 408 | |----------------------->| | 409 +-----------+ 8293 5061 | Proxy | 410 | 2 | 411 | | 412 +-----------+ 414 4.2 Formal Syntax 416 The following syntax specification uses the augmented Backus-Naur 417 Form (BNF) as described in RFC-2234 [3]. This document proposes to 418 extend via-params to include a a new via-alias defined below. 420 via-params = via-ttl / via-maddr / via-received / via-branch / 421 via-alias / via-extension 423 via-alias = "alias" 425 5. Security Considerations 427 This document presents requirements and a mechanism for reusing 428 existing connections easily. Connection reuse presents many 429 opportunities for abuse and hijacking, but these attacks can be 430 prevented if the guidelines in the authorization section are 431 followed. 433 6. IANA Considerations 435 This document adds a parameter to the SIP header field parameters 436 registry: 438 Header field in which parameter can appear: Via 439 Name of the parameter: alias 440 Reference: This document (RFC editor, please replace 441 with the RFC number of this document) 443 7. Acknowledgments 445 Thanks to Jon Peterson for helpful answers about certificate behavior 446 with SIP, Jonathan Rosenberg for his initial support of this concept, 447 and Cullen Jennings for providing a sounding board for this idea. 449 Normative References 451 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 452 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 453 Session Initiation Protocol", RFC 3261, June 2002. 455 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 456 Levels", BCP 14, RFC 2119, March 1997. 458 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 459 Specifications: ABNF", RFC 2234, November 1997. 461 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 462 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 463 1999. 465 [5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 466 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 467 Basic and Digest Access Authentication", RFC 2617, June 1999. 469 [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 470 (SIP): Locating SIP Servers", RFC 3263, June 2002. 472 Informational References 474 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, 475 "Best Current Practices for Third Party Call Control in the 476 Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work 477 in progress), March 2003. 479 [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 480 Notification", RFC 3265, June 2002. 482 [9] Sparks, R., "The Session Initiation Protocol (SIP) Refer 483 Method", RFC 3515, April 2003. 485 [10] Kohl, J. and B. Neuman, "The Kerberos Network Authentication 486 Service (V5)", RFC 1510, September 1993. 488 [11] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 489 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 490 "Stream Control Transmission Protocol", RFC 2960, October 2000. 492 Author's Address 494 Rohan Mahy 495 Cisco Systems, Inc. 496 5617 Scotts Valley Dr 497 Scotts Valley, CA 95066 498 USA 500 EMail: rohan@cisco.com 502 Intellectual Property Statement 504 The IETF takes no position regarding the validity or scope of any 505 intellectual property or other rights that might be claimed to 506 pertain to the implementation or use of the technology described in 507 this document or the extent to which any license under such rights 508 might or might not be available; neither does it represent that it 509 has made any effort to identify any such rights. Information on the 510 IETF's procedures with respect to rights in standards-track and 511 standards-related documentation can be found in BCP-11. Copies of 512 claims of rights made available for publication and any assurances of 513 licenses to be made available, or the result of an attempt made to 514 obtain a general license or permission for the use of such 515 proprietary rights by implementors or users of this specification can 516 be obtained from the IETF Secretariat. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights which may cover technology that may be required to practice 521 this standard. Please address the information to the IETF Executive 522 Director. 524 Full Copyright Statement 526 Copyright (C) The Internet Society (2004). All Rights Reserved. 528 This document and translations of it may be copied and furnished to 529 others, and derivative works that comment on or otherwise explain it 530 or assist in its implementation may be prepared, copied, published 531 and distributed, in whole or in part, without restriction of any 532 kind, provided that the above copyright notice and this paragraph are 533 included on all such copies and derivative works. However, this 534 document itself may not be modified in any way, such as by removing 535 the copyright notice or references to the Internet Society or other 536 Internet organizations, except as needed for the purpose of 537 developing Internet standards in which case the procedures for 538 copyrights defined in the Internet Standards process must be 539 followed, or as required to translate it into languages other than 540 English. 542 The limited permissions granted above are perpetual and will not be 543 revoked by the Internet Society or its successors or assignees. 545 This document and the information contained herein is provided on an 546 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 547 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 548 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 549 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 550 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Acknowledgement 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.