idnits 2.17.1 draft-ietf-sip-connect-reuse-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 RFC 3978 Section 5.4 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 (February 2006) is 6616 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) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-01 ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4234 (ref. '6') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '10') (Obsoleted by RFC 6665) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG R. Mahy 3 Internet-Draft SIP Edge LLC 4 Expires: August 5, 2006 V. Gurbani, Ed. 5 Lucent Technologies, Inc./Bell 6 Laboratories 7 B. Tate 8 BroadSoft 9 February 2006 11 Connection Reuse in the Session Initiation Protocol (SIP) 12 draft-ietf-sip-connect-reuse-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 5, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 When SIP entities use a connection oriented protocol to send a 46 request, they typically originate their connections from an ephemeral 47 port. The SIP protocol includes mechanisms which insure that 48 responses to a request, and new requests sent in the original 49 direction reuse an existing connection. However, new requests sent 50 in the opposite direction are unlikely to reuse the existing 51 connection. This frequently causes a pair of SIP entities to use one 52 connection for requests sent in each direction, and can result in 53 potential scaling and performance problems. This document proposes 54 requirements and a mechanism which address this deficiency in 55 environments where the connection could be opened in either 56 direction. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Applicability Statement . . . . . . . . . . . . . . . . . . 3 62 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Benefits of Connection Reuse . . . . . . . . . . . . . . . . 5 64 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 6 65 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8 68 8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 9 69 8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 10 70 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 71 9.1 Authenticating TLS Client Connections . . . . . . . . . . 11 72 9.2 Authenticating TLS Server Connections . . . . . . . . . . 11 73 9.3 Security Considerations for the TCP Transport . . . . . . 11 74 10. Connection Reuse and SRV Interaction . . . . . . . . . . . . 13 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 76 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 13.1 Normative References . . . . . . . . . . . . . . . . . . 14 79 13.2 Informational References . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 81 Intellectual Property and Copyright Statements . . . . . . . 16 83 1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [3]. 89 Additional terminology used in this document: 91 Advertised address: The address that occurs in the Via sent-by 92 production rule, including the port number and transport. 94 Alias: A transport layer connection associated with a resolved 95 address. 97 Resolved address: The address of a user agent (including port 98 number and transport) retrieved from the DNS resolution contained 99 in RFC3263 [5]. 101 2. Applicability Statement 103 The applicability of the mechanism described in this document is for 104 two adjacent SIP entities to reuse connections when they are agnostic 105 about the direction of the connection, i.e., either end can initiate 106 the connection. SIP entities that can only open a connection in a 107 specific direction -- perhaps because of Network Address Translation 108 (NAT) and firewall reasons -- reuse their connections using the 109 mechanism described in [1]. 111 The connect reuse mechanism described in this document is defined 112 only for Transport Layer Security (TLS) transports. Specifically, 113 implementations MUST NOT use this mechanism for the TCP transport due 114 to the possible attacks that can be launched with connection reuse 115 over TCP. Such attacks and alternative methods for connection reuse 116 over TCP are described in Section 9.3. 118 3. Introduction 120 SIP [2] entities can communicate using either unreliable/ 121 connectionless (e.g., UDP) or reliable/connection-oriented (e.g., 122 TCP, SCTP [11]) transport protocols. When SIP entities use a 123 connection-oriented protocol (such as TCP or SCTP) to send a request, 124 they typically originate their connections from an ephemeral port. 126 In the following example, Entity A listens for SIP requests over TLS 127 [4] on TCP port 5061 (the default port for SIP over TLS over TCP), 128 but uses an ephemeral port (port 8293) for a new connection to Entity 129 B. These entities could be SIP User Agents or SIP Proxy Servers. 131 +-----------+ 8293 (UAC) 5061 (UAS) +-----------+ 132 | |--------------------------->| | 133 | Entity | | Entity | 134 | A | | B | 135 | | 5061 (UAS) | | 136 +-----------+ +-----------+ 138 Figure 1: Uni-directional connection for requests from A to B. 140 The SIP protocol includes mechanisms which insure that responses to a 141 request reuse the existing connection which is typically still 142 available, and also includes provisions for reusing existing 143 connections for other requests sent by the originator of the 144 connection. However, new requests sent in the opposite direction -- 145 in the example above, requests from B destined to A -- are unlikely 146 to reuse the existing connection. This frequently causes a pair of 147 SIP entities to use one connection for requests sent in each 148 direction, as shown below. 150 +-----------+ 8293 5061 +-----------+ 151 | |.......................>| | 152 | Entity | | Entity | 153 | A | 5061 9741 | B | 154 | |<-----------------------| | 155 +-----------+ +-----------+ 157 Figure 2: Two connections for requests between A and B. 159 Opening an extra connection where an existing one is sufficient can 160 result in potential scaling and performance problems. Consider the 161 call flow shown below where Proxy A and Proxy B use the Record-Route 162 mechanism to stay involved in a dialog. Proxy B will establish a new 163 TLS connection just to send a BYE request. 165 Proxy A Proxy B 166 | | 167 Create connection 1 +---INV--->| 168 | | 169 |<---200---+ Response over connection 1 170 | | 171 Re-use connection 1 +---ACK--->| 172 | | 173 = = 174 | | 175 |<---BYE---+ Create connection 2 176 | | 177 Response over +---200--->| 178 connection 2 180 Figure 3: Multiple connections for requests. 182 Thus, it is advantageous to reuse connections whenever possible. 184 4. Benefits of Connection Reuse 186 Opening an extra connection where an existing one is sufficient can 187 result in potential scaling and performance problems. For example, 188 each new connection using TLS requires a TCP 3-way handshake, a 189 handful of round-trips to establish TLS, typically expensive 190 asymmetric authentication and key generation algorithms, and 191 certificate verification. This effectively doubles the load on each 192 entity. Setting up a second connection (from B to A above) for 193 subsequent requests, even requests in the context of an existing 194 dialog (e.g., re-INVITE or BYE after an initial INVITE, or a NOTIFY 195 after a SUBSCRIBE [10] or a REFER [9]), can also cause excessive 196 delay (especially in networks with long round-trip times). 198 ReINVITEs or UPDATE [7] requests are expected to be handled 199 automatically and rapidly in order to avoid media and session state 200 from being out of step. If a reINVITE requires a new TLS connection, 201 the reINVITE could be delayed by several extra round-trip times. 202 Depending on the round-trip time, this combined delay could be 203 perceptible or even annoying to a human user. This is especially 204 problematic for some common SIP call flows (for example, the 205 recommended example flow in figure number 4 in RFC3725 [8] use many 206 reINVITEs). 208 The mechanism described in this document can mitigate the delays 209 associated with subsequent requests. 211 5. Overview of Operation 213 This section is tutorial in nature, and does not specify any 214 normative behavior. 216 The act of reusing a connection is initiated by an user agent client 217 (UAC, or the proxy half of the UAC) when it adds an "alias" parameter 218 to the added Via header (the parameter itself is defined later). 219 When a user agent server (UAS, or the proxy half of the UAS) receives 220 the request, it examines the topmost Via header. If the header 221 contained an "alias" parameter, the UAS establishes a binding such 222 that subsequent requests going to the UAC will reuse the connection. 223 We now explain this working in more detail in the context of 224 communication between two adjacent proxies. Without any loss of 225 generality, it should be clear that the same technique can be used 226 for connection reuse between a UAC and an edge proxy, or between an 227 edge proxy and a UAS, or between an UAC and an UAS. 229 P1 and P2 are proxies responsible for routing SIP requests through 230 user agents that use them as edge proxies (see Figure 4). 232 P1 P2 233 p1.example.com p2.example.com 234 (192.0.2.1) (192.0.2.128) 236 Figure 4: Proxy setup. 238 This document is concerned with specifying an extension to SIP for 239 connection reuse at the receiving end; i.e., reusing the connection 240 when P2 wants to send a request to P1. However, it should be clear 241 that P1 can reuse a connection previously established with P2. In 242 fact, the SIP community recommends that clients reuse a connection 243 previously established with a server for subsequent transactions 244 going to the same resolved address. Thus, the reuse property of a 245 connection, once it is established, is bi-directional and alias 246 tables may be maintained at both P1 and P2. 248 P1 gets a request from one of its upstream user agents, and after 249 performing RFC3263 server selection, arrives at a destination address 250 of P2. P1 maintains an alias table, and it populates the alias table 251 with the IP address, port number, and transport of P2 as determined 252 through RFC3263 server selection. P1 adds an "alias" parameter to 253 the topmost Via header (inserted by it) before sending the request to 254 P2. The value in the sent-by production rule of the Via header 255 (including the port number), and the transport over which the request 256 was sent becomes the advertised address of P1: 258 Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias 259 Assuming that P1 does not have an existing aliased connection with 260 P2, P1 now opens a connection with P2. Upon connection 261 authentication and acceptance, it adds P2s to its alias table. P1's 262 alias table now looks like: 264 Destination Destination Destination Alias Connection 265 IP Address Port Transport Descriptor 266 ... 267 192.0.2.128 5061 TLS 25 269 Subsequent requests that traverse from P1 to P2 will reuse this 270 connection; i.e., the requests will be sent over the descriptor 25. 272 When P2 receives the request, it may add a "received" parameter to 273 the topmost Via and examines the topmost Via to determine whether P1 274 supports aliased connections. The Via at P2 now looks like: 276 Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias; 277 received=192.0.2.1 279 The presence of the "alias" parameter indicates that P1 does support 280 aliasing. P2 now authenticates the connection and if the 281 authentication was successful, P2 creates an alias to P1 using the 282 advertised address in the topmost Via. P2's alias table looks like: 284 Destination Destination Destination Alias Connection 285 IP Address Port Transport Descriptor 286 ... 287 192.0.2.1 5061 TLS 18 289 There are two items of interest here: 290 1. Note that the entry in the last column for P2's alias table is 291 the descriptor over which the connection was passively accepted. 292 When P2 gets a request from one of its user agents, and 293 determines through RFC3263 server resolution that the request 294 should be sent to P1 over TLS using the default port (5061), it 295 will reuse the aliased connection accessible to it through 296 descriptor 18 instead of opening a new connection. 297 2. The network address inserted in the "Destination IP Address" 298 column should be the source address as seen by P2 (i.e., the 299 "received" parameter). It could be the case that the host name 300 of P1 resolves to different IP addresses due to round-robin DNS. 301 However, the aliased connection is to be established with the 302 original sender of the request. 304 To implement connection aliases for resolved addresses, a SIP node 305 could (for example) search an additional data structure (the alias 306 table) prior to opening a new connection, or could modify the data 307 structure in which it keeps active connection state so that aliases, 308 active connections, and blacklisted nodes are all discovered when 309 looking for an active connection. 311 6. Requirements 313 1. A connection sharing mechanism SHOULD allow SIP entities to reuse 314 existing connections for requests and responses originated from 315 either peer in the connection. 316 2. A connection sharing mechanism MUST NOT require UACs (clients) to 317 send all traffic from well-know SIP ports. 318 3. A connection sharing mechanism MUST NOT require configuring 319 ephemeral port numbers in DNS. 320 4. A connection sharing mechanism MUST prevent unauthorized 321 hijacking of other connections. 322 5. Connection sharing SHOULD persist across SIP transactions and 323 dialogs. 324 6. There is no requirement to share a complete path for ordinary 325 connection reuse. Hop-by-hop connection sharing is more 326 appropriate. 328 7. Formal Syntax 330 The following syntax specification uses the augmented Backus-Naur 331 Form (BNF) as described in RFC 4234 [6]. This document extends the 332 via-params to include a new via-alias defined below. 334 via-params = via-ttl / via-maddr / via-received / via-branch / 335 via-alias / via-extension 337 via-alias = "alias" 339 8. Normative Behavior 341 This document specifies how to reuse connections. The SIP community 342 recommends that servers keep connections up unless they need to 343 reclaim resources, and that clients keep connections up as long as 344 they are needed. Connection reuse works best when the client and the 345 server maintain their connections for long periods of time. SIP 346 entities therefore SHOULD NOT automatically drop connections on 347 completion of a transaction or termination of a dialog. 349 An alias is formed at the receiver of a request when it gets a 350 request with the "alias" parameter in the topmost Via header. If the 351 receiver decides to accept the alias, then the alias corresponds to 352 the source IP address, transport, and port (if one exists in the Via 353 sent-by, or the default port if it does not) of the sender of the 354 request. Whenever the RFC3263 server selection mechanism executed at 355 the receiver results in the choice of this IP address, port, and 356 transport tuple, the alias MUST be used instead. 358 Note that at the receiver, the responses are sent over the same 359 connection as specified by RFC3261. The aliasing mechanism at the 360 receiver allows subsequent requests going from the receiver to the 361 original sender of the request to reuse the same connection. 363 An alias is formed at the sender of the request when it executes the 364 RFC3263 server selection mechanism to arrive at an IP address, port, 365 and transport tuple to send a request to. Subsequent requests going 366 to the same destination address MUST use the alias instead. 368 Only one alias SHOULD exist for the resolved address. If more than 369 one alias is requested because of race conditions (or any other 370 reasons), the receiver SHOULD consider the latest alias to be the 371 desired alias. The receiver MUST NOT interpret the situation as a 372 desire for load balancing between the aliases. 374 Because an alias connection might be reclaimed during a transaction, 375 clients SHOULD NOT enforce the RFC 3261 requirement of sending CANCEL 376 and ACK (for non 2xx responses) to the same port. If the alias 377 connection no longer exists, the client SHOULD open a new connection 378 to the resolved address and send the CANCEL or ACK there instead. 379 The newly opened connection MAY be inserted into the alias table. 381 8.1 Client Behavior 383 The proposed mechanism uses a new Via header field parameter. The 384 "alias" parameter is included in a Via header field value to indicate 385 that the client wants to create a transport layer alias. The client 386 places its advertised address in the Via header field value (in the 387 "sent-by" production). 389 The implications of placing an "alias" parameter in the topmost Via 390 header of a request must be understood by the client. Specifically, 391 this means that the client MUST keep the connection open for as long 392 as the resources on the host operating system allow it to, and that 393 it MUST accept requests over this connection -- as opposed to a 394 default listening port -- from its downstream peer. And furthermore, 395 it MUST reuse the connection when subsequent requests in the same or 396 different transactions are destined to the same resolved address. 398 Note that RFC3261 states that a response should arrive over the 399 same connection that was opened for a request. 401 Whether or not to allow an aliased connection ultimately depends on 402 the recepient of the request. Thus, clients MUST NOT assume that the 403 acceptance of a request by a server automatically enables connection 404 aliasing. They MUST continue receiving requests on their default 405 port. 407 Clients must be prepared for the case that the connection no longer 408 exists when they are ready to send a subsequent request over it. 409 This may happen if the peer ran out of operating system resources and 410 had to close the connection. In such a case, a new connection MUST 411 be opened to the resolved address and the alias table updated 412 accordingly. 414 Clients must authenticate the connection before forming an alias. 415 Section 9.1 discusses the authentication steps in more detail. 417 8.2 Server Behavior 419 When a server receives a request whose topmost Via header contains an 420 "alias" parameter, it signifies that the upstream client will leave 421 the connection open beyond the transaction and dialog lifetime, and 422 that subsequent transactions and dialogs that are destined to a 423 resolved address that matches the identifiers in the advertised 424 address in the topmost Via header can reuse this connection. 426 Whether or not to honor an aliased connection ultimately depends on 427 the policies of the server. It MAY choose to honor it, and thereby 428 send subsequent requests over the aliased connection. If the server 429 chooses not to honor an aliased connection, it MUST allow the request 430 to proceed as though the "alias" parameter was not present in the 431 topmost Via header. 433 This assures interoperability with RFC3261 server behavior. 434 Clients should feel comfortable including the "alias" parameter 435 without fear that the server will reject the SIP request because 436 of its presence. 438 Servers MUST be prepared to deal with the case that the aliased 439 connection no longer exist when they are ready to send a subsequent 440 request over it. This may happen if the peer ran out of operating 441 system resources and had to close the connection. In such a case, a 442 new connection MUST be opened to the resolved address and the alias 443 table updated accordingly. 445 If the Via sent-by contains a port, it MUST be used as a destination 446 port. Otherwise the default port is the destination port. 448 Servers must authenticate the connection before forming an alias. 449 Section 9.2 discusses the authentication steps in more detail. 451 9. Security Considerations 453 This document presents requirements and a mechanism for reusing 454 existing connections easily. Unauthenticated connection reuse would 455 present many opportunities for rampant abuse and hijacking. 456 Authenticating connection aliases is essential to prevent connection 457 hijacking. For example, a program run by a malicious user of a 458 multiuser system could attempt to hijack SIP requests destined for 459 the well-known SIP port from a large relay proxy. 461 9.1 Authenticating TLS Client Connections 463 When a TLS client establishes a connection with a server, it is 464 presented with the server's X.509 certificate. The client MUST 465 ensure that the canonical host name of the server is present either 466 as the distinguished name (DN) of the Subject field or as a DNS URI 467 in the subjectAltName X.509v3 extension before updating its alias 468 table with the resolved address. 470 9.2 Authenticating TLS Server Connections 472 A TLS server conformant to this specification MUST ask for a client 473 certificate; if the client possesses a certificate, it will be 474 presented to the server for mutual authentication. The server MUST 475 ensure that the canonical host name of the client is present either 476 as the distinguished name (DN) of the Subject field or as a DNS URI 477 in the subjectAltName X.509v3 extension before updating its alias 478 table. If the client does not have a certificate, it is RECOMMENDED 479 that servers issue a 403 response with the reason phrase set to 480 "Certificate Required for Alias" to provide a more descriptive reason 481 for rejection to a human user. The TLS connection should be closed 482 immediately since accepting such a connection and establishing an 483 alias would be tantamount to using an encrypted channel for TCP but 484 still exposing the server to the same types of attacks described in 485 Section 9.3. 487 9.3 Security Considerations for the TCP Transport 489 Connection reuse over TCP is inherently insecure. Because the nature 490 of the aliasing mechanism is such that it redirects requests destined 491 for one port at a host to another port, service hi-jacking can result 492 if adequate care is not taken to ensure that the redirected port is 493 indeed authorized to receive the requests that would normally have 494 gone to another, authorized port. Consider the following scenario to 495 understand the service hi-jacking attack that can be mounted when 496 using connection reuse over TCP. 498 A TCP server receives a request with the "alias" parameter as follows 499 (the "received" parameter is added by the server after getting the 500 request): 502 Via: SIP/2.0/TCP uac.example.com;branch=z9hG4bKa7c8dze;alias; 503 received=192.0.4.33 505 From the server's perspective, its alias table is updated such that 506 whenever a request is destined to 192.0.4.33, port 5060, it will 507 instead be sent to the peer at the end of the aliased connection. 508 The security attack can now be mounted as follows: assume a malware 509 program is running on a multi-user computer. The malware program 510 knows that a user on the computer runs a SIP user agent, but the SIP 511 user agent is currently not active (possibly by scanning ports on the 512 local machine to seek a busy port 5060). Note that the malware 513 program does not need to wait until the legitimate user agent was not 514 running, however, doing so increases the chances that the server will 515 not reject the malware program's request. Once the malware program 516 decides that a legitimate user agent is not running, it sends sends a 517 request to the server with an "alias" parameter. The server believes 518 it is accepting a request from a legitimate user agent and sends 519 subsequent requests to the aliased connection. The SIP service on 520 the computer has now effectively been hi-jacked for the default port. 521 The malware program does not need administrative privileges to 522 execute, and in fact, can masquerade as any user (legitimate or not) 523 of the computer. 525 Later on, when the legitimate user agent is started, it may also send 526 a request with an "alias" parameter to the server, which may detect 527 that it now has two aliased connections. Making matters much worse, 528 it cannot determine which of the two is the legitimate one and may 529 well reject the request from the legitimate user. 531 In another form of this attack, the legitimate user agent may not 532 support connection aliasing, but the malware program may use the 533 mechanism to usurp the SIP service on the computer. 535 In yet another form of an attack, the malware program uses the 536 aliasing mechanism to shortcut registering with a proxy to receive 537 requests. In this case, it sends a request to the edge proxy (who 538 may also substitute as the inbound proxy with access to a location 539 service for that domain). In the request is a bogus request URI that 540 will cause the edge proxy to fail the request, however, the edge 541 proxy keeps the connection open and any subsequent requests destined 542 to that host on the default port are instead sent to the malware 543 program. Registration is thus not needed in order to receive 544 incoming requests. 546 HTTP Digest is useful to mitigate only a subset of these attacks over 547 TCP. For instance, HTTP Digest helps in authenticating a user agent 548 to a proxy server before the alias table is updated. However, HTTP 549 Digest is of no help when one proxy desires to enter an aliasing 550 agreement with another downstream proxy. 552 Keeping in view the possible attacks for TCP connection reuse 553 documented here and the limited help provided by HTTP Digest to 554 mitigate these attacks, it is recommended that TCP peers that want to 555 avail of connection reuse do so such that each peer actively opens up 556 a TCP connection in the direction of the other (as depicted in Figure 557 2). This manner of opening connections, while still not secure, is 558 at least much more apparent and direct than using the connection 559 reuse mechanism over TCP in an unauthenticated fashion. 561 10. Connection Reuse and SRV Interaction 563 Connection reuse has an interaction with the DNS SRV load balancing 564 mechanism. To understand the interaction, consider the following 565 figure: 567 /+---- S1 568 +-------+/ 569 | Proxy |------- S2 570 +-------+\ 571 \+---- S3 573 Figure 5: Load balancing. 575 Here, the proxy uses DNS SRV to load balance across the three 576 servers, S1, S2, and S3. Using the connect reuse mechanism specified 577 in this document, over time the proxy will maintain a distinct 578 aliased connection to each of the servers. However, once this is 579 done, subsequent traffic is load balanced across the three downstream 580 servers in the normal manner. 582 11. IANA Considerations 584 This document adds a parameter to the SIP header field parameters 585 registry: 587 Header field in which parameter can appear: Via 588 Name of the parameter: alias 589 Reference: This document 591 12. Acknowledgments 593 Thanks to Jon Peterson for helpful answers about certificate behavior 594 with SIP, Jonathan Rosenberg for his initial support of this concept, 595 and Cullen Jennings for providing a sounding board for this idea. 597 13. References 599 13.1 Normative References 601 [1] Jennings, C. and R. Mahy, "Managing Client Initiated Connections 602 in the Session Initiation Protocol (SIP)", 603 draft-ietf-sip-outbound-01.txt (work in progress), October 2005. 605 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 606 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 607 Session Initiation Protocol", RFC 3261, June 2002. 609 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 610 Levels", RFC 2119, March 1997. 612 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 613 RFC 2246, January 1999. 615 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 616 (SIP): Locating SIP Servers", RFC 3263, June 2002. 618 [6] Crocker, D. and P. Overell, "ABNF for Syntax 619 Specifications'>Augmented BNF for Syntax Specifications: ABNF", 620 RFC 4234, October 2005. 622 13.2 Informational References 624 [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 625 Method", RFC 3311, September 2002. 627 [8] Rosenberg, J., Peterson, J., Schulzrinne, H., and H. Camarillo, 628 "Best Current Practices for Third Party Call Control (3pcc) in 629 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 631 [9] Sparks, R., "The Session Initiation Protocol (SIP) Refer 632 Method", RFC 3515, April 2003. 634 [10] Roach, A., "The Session Initiation Protocol (SIP)-Specific 635 Event Notification", RFC 3265, June 2002. 637 [11] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 638 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 640 Paxson, "The Session Initiation Protocol (SIP)-Specific Event 641 Notification", RFC 2960, October 2000. 643 Authors' Addresses 645 Rohan Mahy 646 SIP Edge LLC 648 Email: rohan@ekabal.com 650 Vijay K. Gurbani (editor) 651 Lucent Technologies, Inc./Bell Laboratories 653 Email: vkg at acm dot org 655 Brett Tate 656 BroadSoft 658 Email: brett@broadsoft.com 660 Intellectual Property Statement 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Disclaimer of Validity 686 This document and the information contained herein are provided on an 687 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 688 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 689 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 690 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 691 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 692 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 694 Copyright Statement 696 Copyright (C) The Internet Society (2006). This document is subject 697 to the rights, licenses and restrictions contained in BCP 78, and 698 except as set forth therein, the authors retain all their rights. 700 Acknowledgment 702 Funding for the RFC Editor function is currently provided by the 703 Internet Society.