idnits 2.17.1 draft-ietf-sip-connect-reuse-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (August 5, 2009) is 5340 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) == Unused Reference: 'RFC4960' is defined on line 788, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-ietf-sip-domain-certs-04 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Standards Track R. Mahy 5 Expires: February 6, 2010 Unaffiliated 6 B. Tate 7 BroadSoft 8 August 5, 2009 10 Connection Reuse in the Session Initiation Protocol (SIP) 11 draft-ietf-sip-connect-reuse-14 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 6, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document enables a pair of communicating proxies to reuse a 50 congestion-controlled connection between themselves for sending 51 requests in the forward and backwards direction. Because the 52 connection is essentially aliased for requests going in the backwards 53 direction, reuse is predicated upon both the communicating endpoints 54 authenticating themselves using X.509 certificates through TLS. For 55 this reason, we only consider connection reuse for TLS over TCP and 56 TLS over SCTP. This document also provides guidelines on connection 57 reuse and virtual SIP servers and the interaction of connection reuse 58 and DNS SRV lookups in SIP. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 64 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Benefits of TLS Connection Reuse . . . . . . . . . . . . . . . 5 66 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 67 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 10 71 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 12 72 8.3. Closing a TLS connection . . . . . . . . . . . . . . . . . 13 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 9.1. Authenticating TLS Connections: Client View . . . . . . . 13 75 9.2. Authenticating TLS Connections: Server View . . . . . . . 14 76 9.3. Connection reuse and Virtual servers . . . . . . . . . . . 14 77 10. Connection Reuse and SRV Interaction . . . . . . . . . . . . . 15 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 13.2. Informational References . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 Additional terminology used in this document: 93 Advertised address: The address that occurs in the Via header 94 field's sent-by production rule, including the port number and 95 transport. 96 Alias: Re-using an existing connection for sending requests in the 97 backwards direction; i.e., A opens a connection to B to send a 98 request, and B uses that connection to send requests in the 99 backwards direction to A. 100 Connection reuse: See "Alias". 101 Persistent connection: The process of sending multiple, possibly 102 unrelated requests on the same connection, and receiving responses 103 on that connection as well. More succinctly, A opens a connection 104 to B to send a request, and later reuses the same connection to 105 send other requests, possibly unrelated to the dialog established 106 by the first request. Responses will arrive over the same 107 connection. Persistent connection behavior is specified in 108 Section 18 of RFC3261 [RFC3261]. Persistent connections do not 109 imply connection reuse. 110 Resolved address: The network identifiers (IP address, port, 111 transport) associated with a user agent as a result of executing 112 RFC3263 [RFC3263] on a Uniform Resource Identifier (URI). 113 Shared connection: See "Persistent connection." 115 2. Applicability Statement 117 The applicability of the mechanism described in this document is for 118 two adjacent SIP entities to reuse connections when they are agnostic 119 about the direction of the connection, i.e., either end can initiate 120 the connection. SIP entities that can only open a connection in a 121 specific direction -- perhaps because of Network Address Translation 122 (NAT) and firewalls -- reuse their connections using the mechanism 123 described in the outbound document [I-D.ietf-sip-outbound]. 125 This memo concerns connection reuse, not persistent connections (see 126 definitions of these in Section 1). Behavior for persistent 127 connections is specified in Section 18 of RFC3261 [RFC3261] and is 128 not altered by this memo. 130 This memo documents that it is good practice to only reuse those 131 connections where the identity of the sender can be verified by the 132 receiver. Thus, TLS (RFC 5246 [RFC5246]) connections (over any 133 connection-oriented transport) formed by exchanging X.509 134 certificates can be reused because they authoritatively establish 135 identities of the communicating parties (see Section 5). 137 3. Introduction 139 SIP entities can communicate using either unreliable/connectionless 140 (e.g., UDP) or reliable/connection-oriented (e.g., TCP, SCTP) 141 transport protocols. When SIP entities use a connection-oriented 142 protocol (such as TCP or SCTP) to send a request, they typically 143 originate their connections from an ephemeral port. 145 In the following example, A listens for SIP requests over TLS on TCP 146 port 5061 (the default port for SIP over TLS over TCP), but uses an 147 ephemeral port (port 49160) for a new connection to B. These entities 148 could be SIP user agents or SIP proxy servers. 150 +-----------+ 49160 (UAC) 5061 (UAS) +-----------+ 151 | |--------------------------->| | 152 | Entity | | Entity | 153 | A | | B | 154 | | 5061 (UAS) | | 155 +-----------+ +-----------+ 157 Figure 1: Uni-directional connection for requests from A to B 159 The SIP protocol includes the notion of a persistent connection, 160 which is a mechanisms to insure that responses to a request reuse the 161 existing connection that is typically still available, as well as 162 reusing the existing connections for other requests sent by the 163 originator of the connection. However, new requests sent in the 164 backwards direction -- in the example above, requests from B destined 165 to A -- are unlikely to reuse the existing connection. This 166 frequently causes a pair of SIP entities to use one connection for 167 requests sent in each direction, as shown below. 169 +-----------+ 49160 5061 +-----------+ 170 | |.......................>| | 171 | Entity | | Entity | 172 | A | 5061 49170 | B | 173 | |<-----------------------| | 174 +-----------+ +-----------+ 176 Figure 2: Two connections for requests between A and B. 178 Unlike TCP, TLS connections can be reused to send requests in the 179 backwards direction since each end can be authenticated when the 180 connection is initially set up. Once the authentication step has 181 been performed, the situation can thought to resemble the picture in 182 Figure 1 except that A and B both use a single shared connection, for 183 example, between port 49160 on A and port 5061 on B. When A wants to 184 send a request to B, it will reuse this connection, and when B wants 185 to send a request to A, it will reuse the same connection. 187 4. Benefits of TLS Connection Reuse 189 Opening an extra connection where an existing one is sufficient can 190 result in potential scaling and performance problems. Each new 191 connection using TLS requires a TCP three-way handshake, a handful of 192 round-trips to establish TLS, typically expensive asymmetric 193 authentication and key generation algorithms, and certificate 194 verification. This can lead to a build up of considerable queues as 195 the server CPU saturates by the TLS handshakes it is already 196 performing (Section 6.19 of Rescorla [Book-Rescorla-TLS]). 198 Consider the call flow shown below where Proxy A and Proxy B use the 199 Record-Route mechanism to stay involved in a dialog. Proxy B will 200 establish a new TLS connection just to send a BYE request. 202 Proxy A Proxy B 203 | | 204 Create connection 1 +---INV--->| 205 | | 206 |<---200---+ Response over connection 1 207 | | 208 Re-use connection 1 +---ACK--->| 209 | | 210 = = 211 | | 212 |<---BYE---+ Create connection 2 213 | | 214 Response over +---200--->| 215 connection 2 217 Figure 3: Multiple connections for requests 219 Setting up a second connection (from B to A above) for subsequent 220 requests, even requests in the context of an existing dialog (e.g., 221 re-INVITE request or BYE request after an initial INVITE request, or 222 a NOTIFY request after a SUBSCRIBE request or a REFER request), can 223 also cause excessive delay (especially in networks with long round- 224 trip times). Thus, it is advantageous to reuse connections whenever 225 possible. 227 From the user expectation point of view, it is advantageous if the 228 re-INVITE requests or UPDATE requests are handled automatically and 229 rapidly in order to avoid media and session state from being out of 230 step. If a re-INVITE request requires a new TLS connection, the re- 231 INVITE request could be delayed by several extra round-trip times. 232 Depending on the round-trip time, this combined delay could be 233 perceptible or even annoying to a human user. This is especially 234 problematic for some common SIP call flows (for example, the 235 recommended example flow in figure number 4 in RFC3725 [RFC3725] use 236 many reINVITE requests). 238 The mechanism described in this document can mitigate the delays 239 associated with subsequent requests. 241 5. Overview of Operation 243 This section is tutorial in nature, and does not specify any 244 normative behavior. 246 We now explain this working in more detail in the context of 247 communication between two adjacent proxies. Without any loss of 248 generality, the same technique can be used for connection reuse 249 between a UAC and an edge proxy, or between an edge proxy and a UAS, 250 or between an UAC and an UAS. 252 P1 and P2 are proxies responsible for routing SIP requests to user 253 agents that use them as edge proxies (see Figure 4). 255 P1 <===================> P2 256 p1.example.com p2.example.net 257 (192.0.2.1) (192.0.2.128) 259 +---+ +---+ 260 | | 0---0 0---0 | | 261 |___| /-\ /-\ |___| 262 / / +---+ +---+ / / 263 +----+ +----+ 264 User Agents User Agents 265 example.com domain example.net domain 267 Figure 4: Proxy setup 269 For illustration purpose the discussion below uses TCP as a transport 270 for TLS operations. Another streaming transport -- such as SCTP -- 271 can be used as well. 273 The act of reusing a connection is initiated by P1 when it adds an 274 "alias" header field parameter (defined later) to the Via header 275 field. When P2 receives the request, it examines the topmost Via 276 header field. If the Via header contained an "alias" header field 277 parameter, P2 establishes a binding such that subsequent requests 278 going to P1 will reuse the connection; i.e., requests are sent over 279 the established connection. 281 With reference to Figure 4, in order for P2 to reuse a connection for 282 requests in the backwards direction, it is important that the 283 validation model for requests sent in this direction (i.e., P2 to P1) 284 is equivalent to the normal "connection in each direction" model, 285 wherein P2 acting as client would open up a new connection in the 286 backwards direction and validate the connection by examining the 287 X.509 certificate presented. The act of reusing a connection needs 288 the desired property that requests get delivered in the backwards 289 direction only if they would have been delivered to the same 290 destination had connection reuse not been employed. To guarantee 291 this property, the X.509 certificate presented by P1 to P2 when a TLS 292 connection is first authenticated are cached for later use. 294 To aid the discussion of connection reuse, this document defines a 295 data structure called the connection alias table (or simply, alias 296 table), which is used to store aliased addresses and is used by user 297 agents to search for an existing connection before a new one is 298 opened up to a destination. It is not the intent of this memo to 299 standardize the implementation of an alias table; rather we use it as 300 a convenience to aid subsequent discussions. 302 P1 gets a request from one of its upstream user agents, and after 303 performing RFC3263 [RFC3263] server selection, arrives at a resolved 304 address of P2. P1 maintains an alias table, and it populates the 305 alias table with the IP address, port number, and transport of P2 as 306 determined through RFC3263 server selection. P1 adds an "alias" 307 header field parameter to the topmost Via header field (inserted by 308 it) before sending the request to P2. The value in the sent-by 309 production rule of the Via header field (including the port number), 310 and the transport over which the request was sent becomes the 311 advertised address of P1: 313 Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias 315 Assuming that P1 does not already have an existing aliased connection 316 with P2, P1 now opens a connection with P2. P2 presents its X.509 317 certificate to P1 for validation (see Section 9.1). Upon connection 318 authentication and acceptance, P1 adds P2 to its alias table. P1's 319 alias table now looks like: 321 Destination Destination Destination Destination Alias 322 IP Address Port Transport Identity Descriptor 323 ... 324 192.0.2.128 5061 TLS sip:example.net 25 325 sip:p2.example.net 327 Subsequent requests that traverse from P1 to P2 will reuse this 328 connection; i.e., the requests will be sent over the descriptor 25. 330 The following columns in the alias table created at the client 331 warrant an explanation: 332 1. The IP address, port and transport are a result of executing 333 RFC3263 server resolution process on a next hop URI. 334 2. The entries in the fourth column consists of the identities of 335 the server as asserted in the X.509 certificate presented by the 336 server. These identities are cached by the client after the 337 server has been duly authenticated (see Section 9.1). 338 3. The entry in the last column is the socket descriptor over which 339 P1, acting as a client, actively opened a TLS connection. At 340 some later time, when P1 gets a request from one of the user 341 agents in its domain, it will reuse the aliased connection 342 accessible through socket descriptor 25 if and only if all of the 343 following conditions hold: 344 A. P1 determines through the RFC3263 server resolution process 345 that the {transport, IP-address, port} tuple of P2 to be 346 {TLS, 192.0.2.128, 5061}, and 347 B. The URI used for the RFC3263 server resolution matches one of 348 the identities stored in the cached certificate (fourth 349 column). 351 When P2 receives the request it examines the topmost Via header field 352 to determine whether P1 is willing to use this connection as an 353 aliased connection (i.e., accept requests from P2 towards P1.) The 354 Via header field at P2 now looks like the following (the "received" 355 header field parameter is added by P2): 357 Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias; 358 received=192.0.2.1 360 The presence of the "alias" Via header field parameter indicates that 361 P1 supports aliasing on this connection. P2 now authenticates the 362 connection (see Section 9.2) and if the authentication was 363 successful, P2 creates an alias to P1 using the advertised address in 364 the topmost Via header field. P2's alias table looks like the 365 following: 367 Destination Destination Destination Destination Alias 368 IP Address Port Transport Identity Descriptor 369 ... 370 192.0.2.1 5061 TLS sip:example.com 18 371 sip:p1.example.com 373 There are a few items of interest here: 374 1. The IP address field is populated with the source address of the 375 client. 376 2. The port field is populated from the advertised address (topmost 377 Via header field), if a port is present in it, or 5061 if it is 378 not. 379 3. The transport field is populated from the advertised address 380 (topmost Via header field). 381 4. The entries in the fourth column consist of the identities of the 382 client as asserted in the X.509 certificate presented by the 383 client. These identities are cached by the server after the 384 client has been duly authenticated (see Section 9.2). 385 5. The entry in the last column is the socket descriptor over which 386 the connection was passively accepted. At some later time, when 387 P2 gets a request from one of the user agents in its domain, it 388 will reuse the aliased connection accessible through socket 389 descriptor 18 if and only if all of the following conditions 390 hold: 391 A. P2 determines through RFC3263 server resolution process that 392 the {transport, IP-address, port} tuple of P1 to be {TLS, 393 192.0.2.1, 5061}, and 394 B. The URI used for RFC3263 server resolution matches one of the 395 identities stored in the cached certificate (fourth column). 396 6. The network address inserted in the "Destination IP Address" 397 column is the source address as seen by P2 (i.e., the "received" 398 header field parameter). It could be the case that the host name 399 of P1 resolves to different IP addresses due to round-robin DNS. 400 However, the aliased connection is to be established with the 401 original sender of the request. 403 6. Requirements 405 The following are the requirements that motivated this specification: 407 1. A connection sharing mechanism should allow SIP entities to reuse 408 existing connections for requests and responses originated from 409 either peer in the connection. 411 2. A connection sharing mechanism must not require clients to send 412 all traffic from well-know SIP ports. 413 3. A connection sharing mechanism must not require configuring 414 ephemeral port numbers in DNS. 415 4. A connection sharing mechanism must prevent unauthorized 416 hijacking of other connections. 417 5. Connection sharing should persist across SIP transactions and 418 dialogs. 419 6. Connection sharing must work across name-based virtual SIP 420 servers. 421 7. There is no requirement to share a complete path for ordinary 422 connection reuse. Hop-by-hop connection sharing is more 423 appropriate. 425 7. Formal Syntax 427 The following syntax specification uses the augmented Backus-Naur 428 Form (BNF) as described in RFC 5234 [RFC5234]. This document extends 429 the via-params to include a new via-alias defined below. 431 via-params =/ via-alias 432 via-alias = "alias" 434 8. Normative Behavior 436 8.1. Client Behavior 438 Clients SHOULD keep connections up as long as they are needed. 439 Connection reuse works best when the client and the server maintain 440 their connections for long periods of time. Clients, therefore, 441 SHOULD NOT automatically drop connections on completion of a 442 transaction or termination of a dialog. 444 The mechanism for connection reuse uses a new Via header field 445 parameter. The "alias" header field parameter is included in a Via 446 header field value to indicate that the client wants to create a 447 transport layer alias. The client places its advertised address in 448 the Via header field value (in the "sent-by" production). 450 If the client places an "alias" header field parameter in the topmost 451 Via header of the request, the client SHOULD keep the connection open 452 for as long as the resources on the host operating system allow it 453 to, and that the client MUST accept requests over this connection -- 454 in addition to the default listening port -- from its downstream 455 peer. And furthermore, the client SHOULD reuse the connection when 456 subsequent requests in the same or different transactions are 457 destined to the same resolved address. 459 Note that RFC3261 states that a response arrives over the same 460 connection that was opened for a request. 462 Whether or not to allow an aliased connection ultimately depends on 463 the recipient of the request; i.e., the client does not get any 464 confirmation that its downstream peer created the alias, or indeed 465 that it even supports this specification. Thus, clients MUST NOT 466 assume that the acceptance of a request by a server automatically 467 enables connection aliasing. Clients MUST continue receiving 468 requests on their default port. 470 Clients MUST authenticate the connection before forming an alias; 471 Section 9.1 discusses the authentication steps in more detail. Once 472 the server has been authenticated, the client MUST cache, in the 473 alias table, the identity (or identities) of the server as determined 474 in Section 7.1 of RFC YYYY [I-D.domain-certs] (Note to RFC Editor: 475 Please replace RFC YYYY with the RFC number assigned to the this 476 reference.) The client MUST also populate the destination IP 477 address, port, and transport of the server in the alias table; these 478 fields are retrieved from executing RFC3263 server resolution process 479 on the next hop URI. And finally, the client MUST populate the alias 480 descriptor field with the connection handle (or identifier) used to 481 connect to the server. 483 Once the alias table has been updated with a resolved address, and 484 the client wants to send a new request in the direction of the 485 server, the client reuses the connection only if all of the following 486 conditions hold: 487 1. The client uses the RFC3263 resolution on a URI and arrives at a 488 resolved address contained in the alias table, and 489 2. The URI used for RFC3263 server resolution matches one of the 490 identities stored in the alias table row corresponding to that 491 resolved address. 493 Clients MUST be prepared for the case that the connection no longer 494 exists when they are ready to send a subsequent request over it. In 495 such a case, a new connection MUST be opened to the resolved address 496 and the alias table updated accordingly. 498 This behavior has an adverse side effect when a CANCEL request or an 499 ACK request for a non-2xx response is sent downstream. Normally, 500 these would be sent over the same connection that the INVITE request 501 was sent over. However, if between the sending of the INVITE request 502 and subsequent sending of the CANCEL request or ACK request to a non- 503 2xx response, the connection was closed, then the client SHOULD open 504 a new connection to the resolved address and send the CANCEL request 505 or ACK request there instead. The client MAY insert the newly opened 506 connection into the alias table. 508 8.2. Server Behavior 510 Servers SHOULD keep connections up unless they need to reclaim 511 resources. Connection reuse works best when the client and the 512 server maintain their connections for long periods of time. Servers, 513 therefore, SHOULD NOT automatically drop connections on completion of 514 a transaction or termination of a dialog. 516 When a server receives a request over TLS whose topmost Via header 517 field contains an "alias" header field parameter, it signifies that 518 the upstream client will leave the connection open beyond the 519 transaction and dialog lifetime, and that subsequent transactions and 520 dialogs that are destined to a resolved address that matches the 521 identifiers in the advertised address in the topmost Via header field 522 can reuse this connection. 524 Whether or not to use in the reverse direction a connection marked 525 with the "alias" Via header field parameter ultimately depends on the 526 policies of the server. It can choose to honor it, and thereby send 527 subsequent requests over the aliased connection. If the server 528 chooses not to honor an aliased connection, the server MUST allow the 529 request to proceed as though the "alias" header field parameter was 530 not present in the topmost Via header. 532 This assures interoperability with RFC3261 server behavior. 533 Clients can include the "alias" header field parameter without 534 fear that the server will reject the SIP request because of its 535 presence. 537 Servers MUST be prepared to deal with the case that the aliased 538 connection no longer exist when they are ready to send a subsequent 539 request over it. This can happen if the peer ran out of operating 540 system resources and had to close the connection. In such a case, 541 the server MUST open a new connection to the resolved address and the 542 alias table updated accordingly. 544 If the sent-by production of the Via header field contains a port, 545 the server MUST use it as a destination port. Otherwise the default 546 port is the destination port. 548 Servers MUST follow the authentication steps outlined in Section 9.2 549 to authenticate the connection before forming an alias. 551 The server, if it decides to reuse the connection, MUST cache in the 552 alias table the identity (or identities) of the client as they appear 553 in the X.509 certificate subjectAlternativeName extension field. The 554 server also populates the destination IP address, port and transport 555 in the alias table from the topmost Via header field (using the 556 ";received" parameter for the destination IP address). If the port 557 number is omitted, a default port number of 5061 is to be used. And 558 finally, the server populates the alias descriptor field with the 559 connection handle (or identifier) used to accept the connection from 560 the client (see Section 5 for the contents of the alias table.) 562 Once the alias table has been updated, and the server wants to send a 563 request in the direction of the client, it reuses the connection only 564 if all of the following conditions hold: 565 1. The server, which acts as a client for this transaction, uses the 566 RFC3263 resolution process on a URI and arrives at a resolved 567 address contained in the alias table, and 568 2. The URI used for RFC3263 server resolution matches one of the 569 identities stored in the alias table row corresponding to that 570 resolved address. 572 8.3. Closing a TLS connection 574 Either the client or the server may terminate a TLS session by 575 sending a TLS closure alert. Before closing a TLS connection, the 576 initiator of the closure MUST either wait for any outstanding SIP 577 transactions to complete, or explicitly abandon them. 579 After the initiator of the close has sent a closure alert, it MUST 580 discard any TLS messages until it has received a similar alert from 581 its peer. The receiver of the closure alert MUST NOT start any new 582 SIP transactions after the receipt of the closure alert. 584 9. Security Considerations 586 This document presents requirements and a mechanism for reusing 587 existing connections easily. Unauthenticated connection reuse would 588 present many opportunities for rampant abuse and hijacking. 589 Authenticating connection aliases is essential to prevent connection 590 hijacking. For example, a program run by a malicious user of a 591 multiuser system could attempt to hijack SIP requests destined for 592 the well-known SIP port from a large relay proxy. 594 9.1. Authenticating TLS Connections: Client View 596 When a TLS client establishes a connection with a server, it is 597 presented with the server's X.509 certificate. Authentication 598 proceeds as described in Section 7.3 ("Client behavior") of RFC YYYY 599 [I-D.domain-certs]. 601 Note to RFC Editor: Please replace RFC YYYY with the RFC number 602 assigned to the above reference. 604 9.2. Authenticating TLS Connections: Server View 606 A TLS server conformant to this specification MUST ask for a client 607 certificate; if the client possesses a certificate, it will be 608 presented to the server for mutual authentication, and authentication 609 proceeds as described in Section 7.4 ("Server behavior") of RFC YYYY 610 [I-D.domain-certs]. 611 Note to RFC Editor: Please replace RFC YYYY with the RFC number 612 assigned to the above reference. 614 If the client does not present a certificate, the server MUST proceed 615 as if the "alias" header field parameter was not present in the 616 topmost Via header. In this case, the server MUST NOT update the 617 alias table. 619 9.3. Connection reuse and Virtual servers 621 Virtual servers present special considerations for connection reuse. 622 Under the name-based virtual server scheme, one SIP proxy can host 623 many virtual domains using one IP address and port number. If 624 adequate defenses are not put in place, a connection opened to a 625 downstream server on behalf of one domain can be reused to send 626 requests in the backwards direction to a different domain. The 627 Destination Identity column in the alias table has been added to aid 628 in such defenses. 630 Virtual servers MUST only perform connection reuse for TLS 631 connections; virtual servers MUST NOT perform connection reuse for 632 other connection-oriented transports. To understand why this is the 633 case, note that the alias table caches not only which connections go 634 to which destination addresses, but also which connections have 635 authenticated themselves as responsible for which domains. If a 636 message is to be sent in the backwards direction to a new SIP domain 637 that resolves to an address with a cached connection, the cached 638 connection cannot be used because it is not authenticated for the new 639 domain. 641 As an example, consider a proxy P1 that hosts two virtual domains -- 642 example.com and example.net -- on the same IP address and port. 643 RFC3263 server resolution is set up such that a DNS lookup of 644 example.com and example.net both resolve to an {IP-address, port, 645 transport} tuple of {192.0.2.1, 5061, TLS}. A user agent in the 646 example.com domain sends a request to P1 causing it to make a 647 downstream connection to its peering proxy, P2, and authenticating 648 itself as a proxy in the example.com domain by sending it a X.509 649 certificate asserting such an identity. P2's alias table now looks 650 like the following: 652 Destination Destination Destination Destination Alias 653 IP Address Port Transport Identity Descriptor 654 ... 655 192.0.2.1 5061 TLS sip:example.com 18 657 At some later point in time, a user agent in P2's domain wants to 658 send a request to a user agent in the example.net domain. P2 659 performs a RFC3263 server resolution process on sips:example.net to 660 derive a resolved address tuple {192.0.2.1, 5061, TLS}. It appears 661 that a connection to this network address is already cached in the 662 alias table, however, P2 cannot reuse this connection because the 663 destination identity (sip:example.com) does not match the server 664 identity used for RFC3261 resolution (sips:example.net). Hence, P2 665 will open up a new connection to the example.net virtual domain 666 hosted on P1. P2's alias table will now look like: 668 Destination Destination Destination Destination Alias 669 IP Address Port Transport Identity Descriptor 670 ... 671 192.0.2.1 5061 TLS sip:example.com 18 672 192.0.2.1 5061 TLS sip:example.net 54 674 The identities conveyed in an X.509 certificate are associated with a 675 specific TLS connection. Absent such a guarantee of an identity tied 676 to a specific connection, a normal TCP or SCTP connection cannot be 677 used to send requests in the backwards direction without a 678 significant risk of inadvertent (or otherwise) connection hijacking. 680 The above discussion details the impact on P2 when connection reuse 681 is desired for virtual servers. There is a subtle, but important 682 impact on P1 as well. 684 P1 should keep separate alias tables for the requests served from the 685 UAs in the example.com domain from those served by the UAs in the 686 example.net domain. This is so that the boundary between the two 687 domains is preserved; P1 MUST NOT open a connection on behalf of one 688 domain and reuse it to send a new request on behalf of another 689 domain. 691 10. Connection Reuse and SRV Interaction 693 Connection reuse has an interaction with the DNS SRV load balancing 694 mechanism. To understand the interaction, consider the following 695 figure: 697 /+---- S1 698 +-------+/ 699 | Proxy |------- S2 700 +-------+\ 701 \+---- S3 703 Figure 5: Load balancing 705 Here, the proxy uses DNS SRV to load balance across the three 706 servers, S1, S2, and S3. Using the connect reuse mechanism specified 707 in this document, over time the proxy will maintain a distinct 708 aliased connection to each of the servers. However, once this is 709 done, subsequent traffic is load balanced across the three downstream 710 servers in the normal manner. 712 11. IANA Considerations 714 This specification defines a new Via header field parameter called 715 "alias" in the "Header Field Parameters and Parameter Values" sub- 716 registry as per the registry created by RFC 3968 [RFC3968]. The 717 required information is: 719 Header Field Parameter Name Predefined Values Reference 720 ___________________________________________________________________ 721 Via alias No RFCXXXX 723 RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of 724 this specification.] 726 12. Acknowledgments 728 Thanks to Jon Peterson for helpful answers about certificate behavior 729 with SIP, Jonathan Rosenberg for his initial support of this concept, 730 and Cullen Jennings for providing a sounding board for this idea. 731 Other members of the SIP WG that contributed to this document include 732 Jeroen van Bemmel, Keith Drage, Matthew Gardiner, Rajnish Jain, Benny 733 Prijono, and Rocky Wang. 735 Dale Worley and Hadriel Kaplan graciously performed a WGLC review of 736 the draft. The resulting revision has benefited tremendously from 737 their feedback. 739 13. References 741 13.1. Normative References 743 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 744 A., Peterson, J., Sparks, R., Handley, M., and E. 745 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 746 June 2002. 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", RFC 2119, March 1997. 751 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 752 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 754 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 755 Protocol (SIP): Locating SIP Servers", RFC 3263, 756 June 2002. 758 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 759 Specifications: ABNF", RFC 5234, January 2008. 761 [I-D.domain-certs] 762 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 763 Certificates in the Session Initiation Protocol (SIP)", 764 draft-ietf-sip-domain-certs-04 (work in progress), 765 May 2009. 767 13.2. Informational References 769 [RFC3968] Camarillo, G., "The Internet Assigned Numbers Authority 770 (IANA) Header Field Parameter Registry for the Session 771 Initiation Protocol (SIP)", BCP 98, RFC 3968, 772 December 2004. 774 [I-D.ietf-sip-outbound] 775 Jennings, C. and R. Mahy, "Managing Client Initiated 776 Connections in the Session Initiation Protocol (SIP)", 777 draft-ietf-sip-outbound-20 (work in progress), June 2009. 779 [Book-Rescorla-TLS] 780 Rescorla, E., "SSL and TLS: Designing and Building Secure 781 Systems", Addison-Wesley Publishing , 2001. 783 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and H. 784 Camarillo, "Best Current Practices for Third Party Call 785 Control (3pcc) in the Session Initiation Protocol (SIP)", 786 RFC 3725, April 2004. 788 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 789 RFC 4960, September 2007. 791 Authors' Addresses 793 Vijay K. Gurbani (editor) 794 Bell Laboratories, Alcatel-Lucent 796 Email: vkg@alcatel-lucent.com 798 Rohan Mahy 799 Unaffiliated 801 Email: rohan@ekabal.com 803 Brett Tate 804 BroadSoft 806 Email: brett@broadsoft.com