idnits 2.17.1 draft-ietf-sip-outbound-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1455. ** 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 : ---------------------------------------------------------------------------- -- 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? -- The draft header indicates that this document updates RFC3327, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 (June 25, 2006) is 6513 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) == Missing Reference: 'RFC AAAA' is mentioned on line 1105, but not defined == Unused Reference: 'I-D.ietf-sipping-config-framework' is defined on line 1387, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-02 ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-04 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-08 == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-route-construct-00 -- Obsolete informational reference (is this intentional?): RFC 3188 (Obsoleted by RFC 8458) -- Obsolete informational reference (is this intentional?): RFC 3548 (Obsoleted by RFC 4648) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 3261,3327 (if approved) R. Mahy, Ed. 5 Expires: December 27, 2006 Plantronics 6 June 25, 2006 8 Managing Client Initiated Connections in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sip-outbound-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The Session Initiation Protocol (SIP) allows proxy servers to 44 initiate TCP connections and send asynchronous UDP datagrams to User 45 Agents in order to deliver requests. However, many practical 46 considerations, such as the existence of firewalls and Network 47 Address Translators (NATs), prevent servers from connecting to User 48 Agents in this way. This specification defines behaviors for User 49 Agents, registrars and proxy servers that allow requests to be 50 delivered on existing connections established by the User Agent. It 51 also defines keep alive behaviors needed to keep NAT bindings open 52 and specifies the usage of multiple connections. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 5 61 3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 6 62 3.3. Multiple Connections from a User Agent . . . . . . . . . . 7 63 3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. Keepalive Technique . . . . . . . . . . . . . . . . . . . 10 65 4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 11 66 4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 11 67 4.2. Initial Registrations . . . . . . . . . . . . . . . . . . 13 68 4.2.1. Registration by Other Instances . . . . . . . . . . . 14 69 4.3. Sending Requests . . . . . . . . . . . . . . . . . . . . . 14 70 4.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . . 14 71 4.4.1. Keepalive with STUN . . . . . . . . . . . . . . . . . 15 72 4.4.2. Flow Recovery . . . . . . . . . . . . . . . . . . . . 15 73 5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 16 74 5.1. Processing Register Requests . . . . . . . . . . . . . . . 16 75 5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 16 76 5.3. Forwarding Requests . . . . . . . . . . . . . . . . . . . 17 77 6. Registrar and Location Server Mechanisms . . . . . . . . . . . 18 78 6.1. Processing REGISTER Requests . . . . . . . . . . . . . . . 18 79 6.2. Forwarding Requests . . . . . . . . . . . . . . . . . . . 19 80 7. Mechanisms for All Servers (Proxys, Registars, UASs) . . . . . 20 81 7.1. STUN Processing . . . . . . . . . . . . . . . . . . . . . 20 82 8. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 21 83 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 85 10.1. Contact Header Field . . . . . . . . . . . . . . . . . . . 25 86 10.2. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 25 87 10.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 26 88 10.4. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 26 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 90 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 13.1. Changes from 03 Version . . . . . . . . . . . . . . . . . 28 93 13.2. Changes from 02 Version . . . . . . . . . . . . . . . . . 29 94 13.3. Changes from 01 Version . . . . . . . . . . . . . . . . . 29 95 13.4. Changes from 00 Version . . . . . . . . . . . . . . . . . 29 97 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 98 Appendix A. Default Flow Registration Backoff Times . . . . . . . 30 99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 15.1. Normative References . . . . . . . . . . . . . . . . . . . 30 101 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 103 Intellectual Property and Copyright Statements . . . . . . . . . . 34 105 1. Introduction 107 There are many environments for SIP [RFC3261] deployments in which 108 the User Agent (UA) can form a connection to a Registrar or Proxy but 109 in which connections in the reverse direction to the UA are not 110 possible. This can happen for several reasons. Connections to the 111 UA can be blocked by a firewall device between the UA and the proxy 112 or registrar, which will only allow new connections in the direction 113 of the UA to the Proxy. Similarly there may be a NAT, which are only 114 capable of allowing new connections from the private address side to 115 the public side. This specification allows SIP registration when the 116 UA is behind such a firewall or NAT. 118 Most IP phones and personal computers get their network 119 configurations dynamically via a protocol such as DHCP (Dynamic Host 120 Configuration Protocol). These systems typically do not have a 121 useful name in the Domain Name System (DNS), and they definitely do 122 not have a long-term, stable DNS name that is appropriate for use in 123 the subjectAltName of a certificate, as required by [RFC3261]. 124 However, these systems can still act as a TLS client and form 125 connections to a proxy or registrar which authenticates with a server 126 certificate. The server can authenticate the UA using a shared 127 secret in a digest challenge over that TLS connection. 129 The key idea of this specification is that when a UA sends a REGISTER 130 request, the proxy can later use this same network "flow", whether 131 this is a bidirectional stream of UDP datagrams, a TCP connection, or 132 an analogous concept of another transport protocol to forward any 133 requests that need to go to this UA. For a UA to receive incoming 134 requests, the UA has to connect to a server. Since the server can't 135 connect to the UA, the UA has to make sure that a flow is always 136 active. This requires the UA to detect when a flow fails. Since 137 such detection takes time and leaves a window of opportunity for 138 missed incoming requests, this mechanism allows the UA to use 139 multiple flows to the proxy or registrar. This mechanism also uses a 140 keep alive mechanism over each flow so that the UA can detect when a 141 flow has failed. 143 2. Conventions and Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 2.1. Definitions 150 Edge Proxy: An Edge Proxy is any proxy that is located topologically 151 between the registering User Agent and the registrar. 152 Flow: A Flow is a network protocol layer (layer 4) association 153 between two hosts that is represented by the network address and 154 port number of both ends and by the protocol. For TCP, a flow is 155 equivalent to a TCP connection. For UDP a flow is a bidirectional 156 stream of datagrams between a single pair of IP addresses and 157 ports of both peers. With TCP, a flow often has a one to one 158 correspondence with a single file descriptor in the operating 159 system. 160 reg-id: This refers to the value of a new header field parameter 161 value for the Contact header field. When a UA registers multiple 162 times, each simultaneous registration gets a unique reg-id value. 163 instance-id: This specification uses the word instance-id to refer to 164 the value of the "sip.instance" media feature tag in the Contact 165 header field. This is a Uniform Resource Name (URN) that uniquely 166 identifies this specific UA instance. 167 outbound-proxy-set A set of SIP URIs (Uniform Resource Identifiers) 168 that represents each of the outbound proxies (often Edge Proxies) 169 with which the UA will attempt to maintain a direct flow. The 170 first URI in the set is often refereed to as the primary outbound 171 proxy and the second as the secondary outbound proxy. There is no 172 difference between any of the URIs in this set, nor does the 173 primary/secondary terminology imply that one is preferred over the 174 other. 176 3. Overview 178 Several scenarios in which this technique is useful are discussed 179 below, including the simple co-located registrar and proxy, a User 180 Agent desiring multiple connections to a resource (for redundancy, 181 for example), and a system that uses Edge Proxies. 183 3.1. Summary of Mechanism 185 The overall approach is fairly simple. Each UA has a unique 186 instance-id that stays the same for this UA even if the UA reboots or 187 is power cycled. Each UA can register multiple times over different 188 connections for the same SIP Address of Record (AOR) to achieve high 189 reliability. Each registration includes the instance-id for the UA 190 and a reg-id label that is different for each flow. The registrar 191 can use the instance-id to recognize that two different registrations 192 both reach the same UA. The registrar can use the reg-id label to 193 recognize that a UA is registering after a reboot or a network 194 failure. 196 When a proxy goes to route a message to a UA for which it has a 197 binding, it can use any one of the flows on which a successful 198 registration has been completed. A failure on a particular flow can 199 be tried again on an alternate flow. Proxies can determine which 200 flows go to the same UA by comparing the instance-id. Proxies can 201 tell that a flow replaces a previously abandoned flow by looking at 202 the reg-id. 204 UAs use the STUN (Simple Traversal of UDP through NATs) protocol as 205 the keepalive mechanism to keep their flow to the proxy or registrar 206 alive. 208 3.2. Single Registrar and UA 210 In the topology shown below, a single server is acting as both a 211 registrar and proxy. 213 +-----------+ 214 | Registrar | 215 | Proxy | 216 +-----+-----+ 217 | 218 | 219 +----+--+ 220 | User | 221 | Agent | 222 +-------+ 224 User Agents which form only a single flow continue to register 225 normally but include the instance-id as described in Section 4.1. 226 The UA can also include a reg-id parameter which is used to allow the 227 registrar to detect and avoid using invalid contacts when a UA 228 reboots or reconnects after its old connection has failed for some 229 reason. 231 For clarity, here is an example. Bob's UA creates a new TCP flow to 232 the registrar and sends the following REGISTER request. 234 REGISTER sip:example.com SIP/2.0 235 Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bK-bad0ce-11-1036 236 Max-Forwards: 70 237 From: Bob ;tag=d879h76 238 To: Bob 239 Call-ID: 8921348ju72je840.204 240 CSeq: 1 REGISTER 241 Supported: path 242 Contact: ; reg-id=1; 243 ;+sip.instance="" 244 Content-Length: 0 245 The registrar challenges this registration to authenticate Bob. When 246 the registrar adds an entry for this contact under the AOR for Bob, 247 the registrar also keeps track of the connection over which it 248 received this registration. 250 The registrar saves the instance-id 251 ("urn:uuid:00000000-0000-0000-0000-000A95A0E128") and reg-id ("1") 252 along with the rest of the Contact header field. If the instance-id 253 and reg-id are the same as a previous registration for the same AOR, 254 the proxy uses the most recently created registration first. This 255 allows a UA that has rebooted to replace its previous registration 256 for each flow with minimal impact on overall system load. 258 When Alice sends a request to Bob, his proxy selects the target set. 259 The proxy forwards the request to elements in the target set based on 260 the proxy's policy. The proxy looks at the target set and uses the 261 instance-id to understand that two targets both end up routing to the 262 same UA. When the proxy goes to forward a request to a given target, 263 it looks and finds the flows over which it received the registration. 264 The proxy then forwards the request on that flow instead of trying to 265 form a new flow to that contact. This allows the proxy to forward a 266 request to a particular contact over the same flow that the UA used 267 to register this AOR. If the proxy has multiple flows that all go to 268 this UA, it can choose any one of registration bindings for this AOR 269 that has the same instance-id as the selected UA. In general, if two 270 registrations have the same reg-id and instance-id, the proxy uses 271 the most recently registered flow. This is so that if a UA reboots, 272 the proxy uses the most recent flow that goes to this UA instead of 273 trying one of the old flows which would presumably fail. 275 3.3. Multiple Connections from a User Agent 277 There are various ways to deploy SIP to build a reliable and scalable 278 system. This section discusses one such design that is possible with 279 the mechanisms in this specification. Other designs are also 280 possible. 282 In the example system below, the logical outbound proxy/registrar for 283 the domain is running on two hosts that share the appropriate state 284 and can both provide registrar and outbound proxy functionality for 285 the domain. The UA will form connections to two of the physical 286 hosts that can perform the outbound proxy/registrar function for the 287 domain. Reliability is achieved by having the UA form two TCP 288 connections to the domain. 290 Scalability is achieved by using DNS SRV to load balance the primary 291 connection across a set of machines that can service the primary 292 connection and also using DNS SRV to load balance across a separate 293 set of machines that can service the secondary connection. The 294 deployment here requires that DNS is configured with one entry that 295 resolves to all the primary hosts and another entry that resolves to 296 all the secondary hosts. While this introduces additional DNS 297 configuration, the approach works and requires no addition SIP 298 extensions. 300 Note: Approaches which select multiple connections from a single 301 DNS SRV set were also considered, but cannot prevent two 302 connections from accidentally resolving to the same host. The 303 approach in this document does not prevent future extensions, such 304 as the SIP UA configuration framework [I-D.ietf-sipping-config- 305 framework], from adding other ways for a User Agent to discover 306 its outbound-proxy-set. 308 +-------------------+ 309 | Domain | 310 | Logical Proxy/Reg | 311 | | 312 |+-----+ +-----+| 313 ||Host1| |Host2|| 314 |+-----+ +-----+| 315 +---\------------/--+ 316 \ / 317 \ / 318 \ / 319 \ / 320 +------+ 321 | User | 322 | Agent| 323 +------+ 325 The UA is configured with multiple outbound proxy registration URIs. 326 These URIs are configured into the UA through whatever the normal 327 mechanism is to configure the proxy or registrar address in the UA. 328 If the AOR is Alice@example.com, the outbound-proxy-set might look 329 something like "sip:primary.example.com;keepalive=stun" and "sip: 330 secondary.example.com;keepalive=stun". The "keepalive=stun" tag 331 indicates that a SIP server supports STUN and SIP multiplexed over 332 the same flow, as described later in this specification. Note that 333 each URI in the outbound-proxy-set could resolve to several different 334 physical hosts. The administrative domain that created these URIs 335 should ensure that the two URIs resolve to separate hosts. These 336 URIs are handled according to normal SIP processing rules, so 337 mechanisms like SRV can be used to do load balancing across a proxy 338 farm. 340 The domain also needs to ensure that a request for the UA sent to 341 host1 or host2 is then sent across the appropriate flow to the UA. 342 The domain might choose to use the Path header approach (as described 343 in the next section) to store this internal routing information on 344 host1 or host2. 346 When a single server fails, all the UAs that have a flow through it 347 will detect a flow failure and try to reconnect. This can cause 348 large loads on the server. When large numbers of hosts reconnect 349 nearly simultaneously, this is referred to as the avalanche restart 350 problem, and is further discussed in Section 4.4.2. The multiple 351 flows to many servers help reduce the load caused by the avalanche 352 restart. If a UA has multiple flows, and one of the servers fails, 353 the UA delays the specified time before trying to form a new 354 connection to replace the flow to the server that failed. By 355 spreading out the time used for all the UAs to reconnect to a server, 356 the load on the server farm is reduced. 358 When used in this fashion to achieve high reliability, the operator 359 will need to configure DNS such that the various URIs in the outbound 360 proxy set do not resolve to the same host. 362 3.4. Edge Proxies 364 Some SIP deployments use edge proxies such that the UA sends the 365 REGISTER to an Edge Proxy that then forwards the REGISTER to the 366 Registrar. The Edge Proxy includes a Path header [RFC3327] so that 367 when the registrar later forwards a request to this UA, the request 368 is routed through the Edge Proxy. There could be a NAT or firewall 369 between the UA and the Edge Proxy. 370 +---------+ 371 |Registrar| 372 |Proxy | 373 +---------+ 374 / \ 375 / \ 376 / \ 377 +-----+ +-----+ 378 |Edge1| |Edge2| 379 +-----+ +-----+ 380 \ / 381 \ / 382 ----------------------------NAT/FW 383 \ / 384 \ / 385 +------+ 386 |User | 387 |Agent | 388 +------+ 390 These systems can use effectively the same mechanism as described in 391 the previous sections but need to use the Path header. When the Edge 392 Proxy receives a registration, it needs to create an identifier value 393 that is unique to this flow (and not a subsequent flow with the same 394 addresses) and put this identifier in the Path header URI. This 395 identifier has two purposes. First, it allows the Edge Proxy to map 396 future requests back to the correct flow. Second, because the 397 identifier will only be returned if the user authentication with the 398 registrar succeeds, it allows the Edge Proxy to indirectly check the 399 user's authentication information via the registrar. The identifier 400 SHOULD be placed in the user portion of a loose route in the Path 401 header. If the registration succeeds, the Edge Proxy needs to map 402 future requests that are routed to the identifier value from the Path 403 header, to the associated flow. 405 The term Edge Proxy is often used to refer to deployments where the 406 Edge Proxy is in the same administrative domain as the Registrar. 407 However, in this specification we use the term to refer to any proxy 408 between the UA and the Registrar. For example the Edge Proxy may be 409 inside an enterprise that requires its use and the registrar could be 410 a service provider with no relationship to the enterprise. 411 Regardless if they are in the same administrative domain, this 412 specification requires that Registrars and Edge proxies support the 413 Path header mechanism in RFC 3327 [RFC3327]. 415 3.5. Keepalive Technique 417 A keepalive mechanism needs to detect failure of a connection and 418 changes to the NAT public mapping, as well as keeping any NAT 419 bindings refreshed. This specification describes using STUN 420 [I-D.ietf-behave-rfc3489bis] over the same flow as the SIP traffic to 421 perform the keepalive. For connection-oriented transports (e.g. TCP 422 and TLS over TCP), the UAC MAY use TCP keepalives to detect flow 423 failure if the UAC can send these keepalives and detect a keepalive 424 failure according to the time frames described in Section 4.4. 426 Note: when TCP is being used, it's natural to think of using TCP 427 KEEPALIVE. Unfortunately, many operating systems and programming 428 environments do not allow the keepalive time to be set on a per- 429 connection basis. Thus, applications may not be able to set an 430 appropriate time. 432 For connection-less transports, a flow definition could change 433 because a NAT device in the network path reboots and the resulting 434 public IP address or port mapping for the UA changes. To detect 435 this, requests are sent over the same flow that is being used for the 436 SIP traffic. The proxy or registrar acts as a STUN server on the SIP 437 signaling port. 439 Note: The STUN mechanism is very robust and allows the detection 440 of a changed IP address. Many other options were considered, but 441 the SIP Working Group selected the STUN-based approach, since it 442 works over any transport. Approaches using SIP requests were 443 abandoned because to achieve the required performance, the server 444 needs to deviate from the SIP specification in significant ways. 445 This would result in many undesirable and non-deterministic 446 behaviors in some environments. 447 Another approach considered to detect a changed flow was using 448 OPTIONS messages and the rport parameter. Although the OPTIONS 449 approach has the advantage of being backwards compatible, it also 450 significantly increases the load on the proxy or registrar server. 451 Related to this idea was an idea of creating a new SIP PING method 452 that was like OPTIONS but faster. It would be critical that this 453 PING method did not violate the processing requirements of a 454 proxies and UAS so it was never clear how it would be 455 significantly faster than OPTIONS given it would still have to 456 obey things like checking the Proxy-Require header. After 457 considerable consideration the working group came to some 458 consensus that the STUN approach was a better solution that these 459 alternative designs. 461 When the UA detects that a flow has failed or that the flow 462 definition has changed, the UA needs to re-register and will use the 463 back-off mechanism described in Section 4 to provide congestion 464 relief when a large number of agents simultaneously reboot. 466 4. User Agent Mechanisms 468 4.1. Instance ID Creation 470 Each UA MUST have an Instance Identifier URN that uniquely identifies 471 the device. Usage of a URN provides a persistent and unique name for 472 the UA instance. It also provides an easy way to guarantee 473 uniqueness within the AOR. This URN MUST be persistent across power 474 cycles of the device. The Instance ID MUST NOT change as the device 475 moves from one network to another. 477 A UA SHOULD use a UUID URN [RFC4122]. The UUID URN allows for non- 478 centralized computation of a URN based on time, unique names (such as 479 a MAC address), or a random number generator. 481 A device like a soft-phone, when first installed, can generate a 482 UUID [RFC4122] and then save this in persistent storage for all 483 future use. For a device such as a hard phone, which will only 484 ever have a single SIP UA present, the UUID can include the MAC 485 address and be generated at any time because it is guaranteed that 486 no other UUID is being generated at the same time on that physical 487 device. This means the value of the time component of the UUID 488 can be arbitrarily selected to be any time less than the time when 489 the device was manufactured. A time of 0 (as shown in the example 490 in Section 3.2) is perfectly legal as long as the device knows no 491 other UUIDs were generated at this time. 493 If a URN scheme other than UUID is used, the URN MUST be selected 494 such that the instance can be certain that no other instance 495 registering against the same AOR would choose the same URN value. An 496 example of a URN that would not meet the requirements of this 497 specification is the national bibliographic number [RFC3188]. Since 498 there is no clear relationship between a SIP UA instance and a URN in 499 this namespace, there is no way a selection of a value can be 500 performed that guarantees that another UA instance doesn't choose the 501 same value. 503 The UA SHOULD include a "sip.instance" media feature tag as a UA 504 characteristic [RFC3840] in requests and responses. As described in 505 [RFC3840], this media feature tag will be encoded in the Contact 506 header field as the "+sip.instance" Contact header field parameter. 507 The value of this parameter MUST be a URN [RFC2141]. One case where 508 a UA may not want to include the URN in the sip.instance media 509 feature tag is when it is making an anonymous request or some other 510 privacy concern requires that the UA not reveal its identity. 512 RFC 3840 [RFC3840] defines equality rules for callee capabilities 513 parameters, and according to that specification, the 514 "sip.instance" media feature tag will be compared by case- 515 sensitive string comparison. This means that the URN will be 516 encapsulated by angle brackets ("<" and ">") when it is placed 517 within the quoted string value of the +sip.instance Contact header 518 field parameter. The case-sensitive matching rules apply only to 519 the generic usages defined in RFC 3840 [RFC3840] and in the caller 520 preferences specification [RFC3841]. When the instance ID is used 521 in this specification, it is effectively "extracted" from the 522 value in the "sip.instance" media feature tag. Thus, equality 523 comparisons are performed using the rules for URN equality that 524 are specific to the scheme in the URN. If the element performing 525 the comparisons does not understand the URN scheme, it performs 526 the comparisons using the lexical equality rules defined in RFC 527 2141 [RFC2141]. Lexical equality may result in two URNs being 528 considered unequal when they are actually equal. In this specific 529 usage of URNs, the only element which provides the URN is the SIP 530 UA instance identified by that URN. As a result, the UA instance 531 SHOULD provide lexically equivalent URNs in each registration it 532 generates. This is likely to be normal behavior in any case; 533 clients are not likely to modify the value of the instance ID so 534 that it remains functionally equivalent yet lexigraphically 535 different from previous registrations. 537 4.2. Initial Registrations 539 UAs obtain at configuration time one or more SIP URIs representing 540 the default outbound-proxy-set. This specification assumes the set 541 is determined via any of a number of configuration mechanisms and 542 future specifications may define additional mechanisms such as using 543 DNS to discover this set. How the UA is configured is outside the 544 scope of this specification. However, a UA MUST support sets with at 545 least two outbound proxy URIs and SHOULD support sets with up to four 546 URIs. For each outbound proxy URI in the set, the UA MUST send a 547 REGISTER in the normal way using this URI as the default outbound 548 proxy. Forming the route set for the request is outside the scope of 549 this document, but typically results in sending the REGISTER such 550 that the topmost Route header field contains a loose route to the 551 outbound proxy URI. Other issues related to outbound route 552 construction are discussed in [I-D.rosenberg-sip-route-construct]. 554 Registration requests, other than those described in Section 4.2.1, 555 MUST include an instance-id media feature tag as specified in 556 Section 4.1. 558 These ordinary registration requests MUST also add a distinct reg-id 559 parameter to the Contact header field. Each one of these 560 registrations will form a new flow from the UA to the proxy. The 561 reg-id sequence does not have to be sequential but MUST be exactly 562 the same reg-id sequence each time the device power cycles or reboots 563 so that the reg-id values will collide with the previously used 564 reg-id values. This is so the proxy can realize that the older 565 registrations are probably not useful. 567 The UAC MUST indicate that it supports the Path header [RFC3327] 568 mechanism, by including the 'path' option-tag in a Supported header 569 field value in its REGISTER requests. Other than optionally 570 examining the Path vector in the response, this is all that is 571 required of the UAC to support Path. 573 The UAC MAY examine successful registrations for the presence of an 574 'outbound' option-tag in a Supported header field value. Presence of 575 this option-tag indicates that the registrar is compliant with this 576 specification. 578 Note that the UA needs to honor 503 responses to registrations as 579 described in RFC 3261 and RFC 3263 [RFC3263]. In particular, 580 implementors should note that when receiving a 503 response with a 581 Retry-After header field, the UA should wait the indicated amount of 582 time and retry the registration. A Retry-After header field value of 583 0 is valid and indicates the UA should retry the REGISTER 584 immediately. Implementations need to ensure that when retrying the 585 REGISTER they revisit the DNS resolution results such that the UA can 586 select an alternate host from the one chosen the previous time the 587 URI was resolved. 589 4.2.1. Registration by Other Instances 591 A User Agent MUST NOT include a reg-id header parameter in the 592 Contact header field of a registration if the registering UA is not 593 the same instance as the UA referred to by the target Contact header 594 field. (This practice is occasionally used to install forwarding 595 policy into registrars.) 597 Note that a UAC also MUST NOT include an instance-id or reg-id 598 parameter in a request to unregister all Contacts (a single Contact 599 header field value with the value of "*"). 601 4.3. Sending Requests 603 When a UA is about to send a request, it first performs normal 604 processing to select the next hop URI. The UA can use a variety of 605 techniques to compute the route set and accordingly the next hop URI. 606 Discussion of these techniques is outside the scope of this document 607 but could include mechanisms specified in RFC 3608 [RFC3608] (Service 608 Route) and [I-D.rosenberg-sip-route-construct]. 610 The UA performs normal DNS resolution on the next hop URI (as 611 described in RFC 3263 [RFC3263]) to find a protocol, IP address, and 612 port. For non-TLS protocols, if the UA has an existing flow to this 613 IP address, and port with the correct protocol, then the UA MUST use 614 the existing connection. For TLS protocols, there must also be a 615 match between the host production in the next hop and one of the URIs 616 contained in the subjectAltName in the peer certificate. If the UA 617 cannot use one of the existing flows, then it SHOULD form a new flow 618 by sending a datagram or opening a new connection to the next hop, as 619 appropriate for the transport protocol. 621 4.4. Detecting Flow Failure 623 The UA needs to detect when a specific flow fails. The UA actively 624 tries to detect failure by periodically sending keepalive messages 625 using one of the techniques described in this section. If a flow has 626 failed, the UA follows the procedures in Section 4.2 to form a new 627 flow to replace the failed one. 629 The time between keepalive requests when using UDP-based transports 630 SHOULD be a random number between 24 and 29 seconds while for TCP- 631 based transports it SHOULD be a random number between 95 and 120 632 seconds. These times MAY be configurable. 634 o Note on selection of time values: For UDP, the upper bound of 29 635 seconds was selected so that multiple STUN packets could be sent 636 before 30 seconds based on information that many NATs have UDP 637 timeouts as low as 30 seconds. The 24 second lower bound was 638 selected so that after 10 minutes the jitter introduced by 639 different timers will make the keepalive requests unsynchronized 640 to evenly spread the load on the servers. For TCP, the 120 641 seconds upper bound was chosen based on the idea that for a good 642 user experience, failures should be detected in this amount of 643 time and a new connection set up. Operators that wish to change 644 the relationship between load on servers and the expected time 645 that a user may not receive inbound communications will probably 646 adjust this time. The 95 seconds lower bound was chosen so that 647 the jitter introduced will result in a relatively even load on the 648 servers after 30 minutes. 650 4.4.1. Keepalive with STUN 652 User Agents that form flows MUST check if the configured URI they are 653 connecting to has a 'keepalive' URI parameter (defined in Section 10) 654 with the value of 'stun'. If the parameter is present, the UA needs 655 to periodically perform keepalive checks by sending a STUN [I-D.ietf- 656 behave-rfc3489bis] Binding Requests over the flow. 658 If the XOR-MAPPED-ADDRESS in the STUN Binding Response changes, the 659 UA MUST treat this event as a failure on the flow. 661 4.4.2. Flow Recovery 663 When a flow to a particular URI in the outbound-proxy-set fails, the 664 UA needs to form a new flow to replace the old flow and replace any 665 registrations that were previously sent over this flow. Each new 666 registration MUST have the same reg-id as the registration it 667 replaces. This is done in much the same way as forming a brand new 668 flow as described in Section 4.2; however, if there is a failure in 669 forming this flow, the UA needs to wait a certain amount of time 670 before retrying to form a flow to this particular next hop. 672 The time to wait is computed in the following way. If all of the 673 flows to every URI in the outbound proxy set have failed, the base 674 time is set to 30 seconds; otherwise, in the case where at least one 675 of the flows has not failed, the base time is set to 90 seconds. The 676 wait time is computed by taking two raised to the power of the number 677 of consecutive registration failures for that URI, and multiplying 678 this by the base time, up to a maximum of 1800 seconds. 680 wait-time = min( max-time, (base-time * (2 ^ consecutive-failures))) 682 These three times MAY be configurable in the UA. The three times 683 are: 684 o max-time with a default of 1800 seconds 685 o base-time-all-fail with a default of 30 seconds 686 o base-time-not-failed with a default of 90 seconds 687 For example, if the base time was 30 seconds, and there had been 688 three failures, then the wait time would be min(1800,30*(2^3)) or 240 689 seconds. The delay time is computed by selecting a uniform random 690 time between 50 and 100 percent of the wait time. The UA MUST wait 691 for the value of the delay time before trying another registration to 692 form a new flow for that URI. 694 To be explicitly clear on the boundary conditions: when the UA boots 695 it immediately tries to register. If this fails and no registration 696 on other flows succeed, the first retry happens somewhere between 30 697 and 60 seconds after the failure of the first registration request. 698 If the number of consecutive-failures is large enough that the 699 maximum of 1800 seconds is reached, the UA will keep trying forever 700 with a random time between 900 and 1800 seconds between the attempts. 702 5. Edge Proxy Mechanisms 704 5.1. Processing Register Requests 706 When an Edge Proxy receives a registration request with a reg-id 707 header parameter in the Contact header field, it MUST form a flow 708 identifier token that is unique to this network flow. The Edge Proxy 709 MUST insert this token into a URI referring to this proxy and place 710 this URI into a Path header field as described in RFC 3327 [RFC3327]. 711 The token MAY be placed in the userpart of the URI. 713 5.2. Generating Flow Tokens 715 A trivial but impractical way to satisfy the flow token requirement 716 in Section 5.1 involves storing a mapping between an incrementing 717 counter and the connection information; however this would require 718 the Edge Proxy to keep an impractical amount of state. It is unclear 719 when this state could be removed and the approach would have problems 720 if the proxy crashed and lost the value of the counter. Two 721 stateless examples are provided below. A proxy can use any algorithm 722 it wants as long as the flow token is unique to a flow, the flow can 723 be recovered from the token, and the token can not be modified by 724 attackers. 726 Algorithm 1: The proxy generates a flow token for connection-oriented 727 transports by concatenating the file descriptor (or equivalent) 728 with the NTP time the connection was created, and base64 encoding 729 the result. This results in an identifier approximately 16 octets 730 long. The proxy generates a flow token for UDP by concatenating 731 the file descriptor and the remote IP address and port, then 732 base64 encoding the result. (No NTP time is needed for UDP.) 733 This algorithm MUST NOT be used unless all messages between the 734 Edge proxy and Registrar use a SIPS protected transport. If the 735 SIPS level of integrity protection is not available, an attacker 736 can hijack another user's calls. 737 Algorithm 2: When the proxy boots it selects a 20-octet crypto random 738 key called K that only the Edge Proxy knows. A byte array, called 739 S, is formed that contains the following information about the 740 flow the request was received on: an enumeration indicating the 741 protocol, the local IP address and port, the remote IP address and 742 port. The HMAC of S is computed using the key K and the HMAC- 743 SHA1-80 algorithm, as defined in [RFC2104]. The concatenation of 744 the HMAC and S are base64 encoded, as defined in [RFC3548], and 745 used as the flow identifier. When using IPv4 addresses, this will 746 result in a 32-octet identifier. 748 5.3. Forwarding Requests 750 When the Edge Proxy receives a request, it applies normal routing 751 procedures with the following addition. If the Edge Proxy receives a 752 request over a flow already represented in a flow token in the top- 753 most Route header field value, the Edge Proxy pops the Route header 754 and continues processing the request. Otherwise, if the top-most 755 Route header refers to the Edge Proxy and contains a valid flow 756 identifier token created by this proxy, the proxy MUST forward the 757 request over the flow that received the REGISTER request that caused 758 the flow identifier token to be created. For connection-oriented 759 transports, if the flow no longer exists the proxy SHOULD send a 410 760 response to the request. 762 The advantage to a stateless approach to managing the flow 763 information is that there is no state on the Edge Proxy that 764 requires clean up or that has to be synchronized with the 765 registrar. 767 Proxies which used one of the two algorithms described in this 768 document to form a flow token follow the procedures below to 769 determine the correct flow. 771 Algorithm 1: The proxy base64 decodes the user part of the Route 772 header. For a TCP-based transport, if a connection specified by 773 the file descriptor is present and the creation time of the file 774 descriptor matches the creation time encoded in the Route header, 775 the proxy forwards the request over that connection. For a UDP- 776 based transport, the proxy forwards the request from the encoded 777 file descriptor to the source IP address and port. 778 Algorithm 2: To decode the flow token, take the flow identifier in 779 the user portion of the URI and base64 decode it, then verify the 780 HMAC is correct by recomputing the HMAC and checking it matches. 781 If the HMAC is not correct, the proxy SHOULD send a 403 response. 782 If the HMAC is correct then the proxy SHOULD forward the request 783 on the flow that was specified by the information in the flow 784 identifier. If this flow no longer exists, the proxy SHOULD send 785 a 410 response to the request. 787 Note that this specification needs mid-dialog requests to be routed 788 over the same flow but techniques to ensure that mid-dialog requests 789 are routed over an existing flow are not part of this specification. 790 However, an approach such as having the Edge Proxy Record-Route with 791 a flow token is one way to ensure that mid-dialog requests are routed 792 over the correct flow. 794 6. Registrar and Location Server Mechanisms 796 6.1. Processing REGISTER Requests 798 This specification updates the definition of a binding in RFC 3261 799 [RFC3261] Section 10 and RFC 3327 [RFC3327] Section 5.3. 801 When no reg-id header parameter is present in a Contact header field 802 value in a REGISTER request, the corresponding binding is still 803 between an AOR and the URI from that Contact header field value. 804 When a reg-id header parameter is present in a Contact header field 805 value in a REGISTER request, the corresponding binding is between an 806 AOR and the combination of instance-id and reg-id. For a binding 807 with an instance-id, the registrar still stores the Contact header 808 field value URI with the binding, but does not consider the Contact 809 URI for comparison purposes. The registrar MUST be prepared to 810 receive, simultaneously for the same AOR, some registrations that use 811 instance-id and reg-id and some registrations that do not. 813 Registrars which implement this specification MUST support the Path 814 header mechanism [RFC3327]. 816 In addition to the normal information stored in the binding record, 817 some additional information MUST be stored for any registration that 818 contains a reg-id header parameter in the Contact header field value. 819 The registrar MUST store enough information to uniquely identify the 820 network flow over which the request arrived. For common operating 821 systems with TCP, this would typically just be the file descriptor. 822 For common operating systems with UDP this would typically be the 823 file descriptor for the local socket that received the request, the 824 local interface, and the IP address and port number of the remote 825 side that sent the request. 827 The registrar MUST also store all the Contact header field 828 information including the reg-id and instance-id parameters and 829 SHOULD also store the time at which the binding was last updated. If 830 a Path header field is present, RFC 3327 [RFC3327] requires the 831 registrar to store this information as well. If the registrar 832 receives a re-registration, it MUST update the information that 833 uniquely identifies the network flow over which the request arrived 834 and SHOULD update the time the binding was last updated. 836 The Registrar MUST include the 'outbound' option-tag (defined in 837 Section (Section 10.1)) in a Supported header field value in its 838 responses to REGISTER requests. The Registrar MAY be configured with 839 local policy to reject any registrations that do not include the 840 instance-id and reg-id. Note that the requirements in this section 841 applies to both REGISTER requests received from an Edge Proxy as well 842 as requests received directly from the UAC. 844 6.2. Forwarding Requests 846 When a proxy uses the location service to look up a registration 847 binding and then proxies a request to a particular contact, it 848 selects a contact to use normally, with a few additional rules: 850 o The proxy MUST NOT populate the target set with more than one 851 contact with the same AOR and instance-id at a time. If a request 852 for a particular AOR and instance-id fails with a 410 response, 853 the proxy SHOULD replace the failed branch with another target (if 854 one is available) with the same AOR and instance-id, but a 855 different reg-id. 856 o If two bindings have the same instance-id and reg-id, the proxy 857 SHOULD prefer the contact that was most recently updated. 859 The proxy uses normal forwarding rules looking at the next-hop target 860 of the message and the value of any stored Path header field vector 861 in the registration binding to decide how to forward the request and 862 populate the Route header in the request. Additionally, when the 863 proxy forwards a request to a binding that contains a reg-id, the 864 proxy MUST send the request over the same network flow that was saved 865 with the binding. This means that for TCP, the request MUST be sent 866 on the same TCP socket that received the REGISTER request. For UDP, 867 the request MUST be sent from the same local IP address and port over 868 which the registration was received, to the same IP address and port 869 from which the REGISTER was received. 871 If a proxy or registrar receives information from the network that 872 indicates that no future messages will be delivered on a specific 873 flow, then the proxy MUST invalidate all the bindings that use that 874 flow (regardless of AOR). Examples of this are a TCP socket closing 875 or receiving a destination unreachable ICMP error on a UDP flow. 876 Similarly, if a proxy closes a file descriptor, it MUST invalidate 877 all the bindings with flows that use that file descriptor. 879 7. Mechanisms for All Servers (Proxys, Registars, UASs) 881 Any SIP device that receives SIP messages directly from a UA needs to 882 behave as specified in this section. Such devices would generally 883 include a Registrar and an Edge Proxy, as they both receive REGISTER 884 requests directly from a UA. 886 7.1. STUN Processing 888 This document defines a new STUN usage for connectivity checks. The 889 only STUN messages required by this usage are Binding Requests, 890 Binding Responses, and Error Responses. The UAC sends Binding 891 Requests over the same UDP flow, TCP connection, or TLS channel used 892 for sending SIP messages, once a SIP registration has been 893 successfully processed on that flow. These Binding Requests do not 894 require any STUN attributes. The UAS responds to a valid Binding 895 Request with a Binding Response which MUST include the XOR-MAPPED- 896 ADDRESS attribute. After a successful STUN response is received over 897 TCP or TLS over TCP, the underlying TCP connection is left in the 898 active state. 900 If the server receives SIP requests on a given interface and port, it 901 MUST also provide a limited version of a STUN server on the same 902 interface and port. Specifically it MUST be capable of receiving and 903 responding to STUN Binding Requests. 905 It is easy to distinguish STUN and SIP packets because the first 906 octet of a STUN packet has a value of 0 or 1 while the first octet 907 of a SIP message is never a 0 or 1. 909 When a URI is created that refers to a SIP device that supports STUN 910 as described in this section, the 'keepalive' URI parameter, as 911 defined in Section 10 MUST be added to the URI, with a value of 912 'stun'. This allows a UA to inspect the URI to decide if it should 913 attempt to send STUN requests to this location. The 'keepalive' tag 914 typically would be present in the URI in the Route header field value 915 of a REGISTER request and not be in the Request URI. 917 8. Example Message Flow 919 The following call flow shows a basic registration and an incoming 920 call. At some point, the flow to the Primary proxy is lost. An 921 incoming INVITE tries to reach the Callee through the Primary flow, 922 but receives an ICMP Unreachable message. The Caller retries using 923 the Secondary Edge Proxy, which uses a separate flow. Later, after 924 the Primary reboots, The Callee discovers the flow failure and 925 reestablishes a new flow to the Primary. 927 [-----example.com domain -------------------] 928 Caller Secondary Primary Callee 929 | | | (1) REGISTER | 930 | | |<-----------------| 931 | | |(2) 200 OK | 932 | | |----------------->| 933 | | | (3) REGISTER | 934 | |<------------------------------------| 935 | |(4) 200 OK | | 936 | |------------------------------------>| 937 | | | | 938 | | CRASH X | 939 |(5) INVITE | | | 940 |----------------------------------->| | 941 |(6) ICMP Unreachable | | 942 |<-----------------------------------| | 943 |(7) INVITE | | | 944 |---------------->| | | 945 | |(8) INVITE | | 946 | |------------------------------------>| 947 | |(9) 200 OK | | 948 | |<------------------------------------| 949 |(10) 200 OK | | | 950 |<----------------| | | 951 |(11) ACK | | | 952 |---------------->| | | 953 | |(12) ACK | | 954 | |------------------------------------>| 955 | | | | 956 | | REBOOT | | 957 | | |(13) REGISTER | 958 | | |<-----------------| 959 | | |(14) 200 OK | 960 | | |----------------->| 961 | | | | 962 |(15) BYE | | | 963 |---------------->| | | 964 | | (16) BYE | | 965 | |------------------------------------>| 966 | | | (17) 200 OK | 967 | |<------------------------------------| 968 | (18) 200 OK | | | 969 |<----------------| | | 970 | | | | 972 This call flow assumes that the Callee has been configured with a 973 proxy set that consists of "sip: 974 primary.example.com;lr;keepalive=stun" and "sip: 976 secondary.example.com;lr;keepalive=stun". The Callee REGISTER in 977 message (1) looks like: 979 REGISTER sip:example.com SIP/2.0 980 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 981 Max-Forwards: 70 982 From: Callee ;tag=7F94778B653B 983 To: Callee 984 Call-ID: 16CB75F21C70 985 CSeq: 1 REGISTER 986 Supported: path 987 Route: 988 Contact: 989 ;+sip.instance="" 990 ;reg-id=1 991 Content-Length: 0 993 In the message, note that the Route is set and the Contact header 994 field value contains the instance-id and reg-id. The response to the 995 REGISTER in message (2) would look like: 997 SIP/2.0 200 OK 998 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 999 From: Callee ;tag=7F94778B653B 1000 To: Callee ;tag=6AF99445E44A 1001 Call-ID: 16CB75F21C70 1002 CSeq: 1 REGISTER 1003 Supported: outbound 1004 Contact: 1005 ;+sip.instance="" 1006 ;reg-id=1 1007 ;expires=3600 1008 Content-Length: 0 1010 The second registration in message 3 and 4 are similar other than the 1011 Call-ID has changed, the reg-id is 2, and the route is set to the 1012 secondary instead of the primary. They look like: 1014 REGISTER sip:example.com SIP/2.0 1015 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnqr9bym 1016 Max-Forwards: 70 1017 From: Callee ;tag=755285EABDE2 1018 To: Callee 1019 Call-ID: E05133BD26DD 1020 CSeq: 1 REGISTER 1021 Supported: path 1022 Route: 1023 Contact: 1024 ;+sip.instance="" 1025 ;reg-id=2 1026 Content-Length: 0 1028 SIP/2.0 200 OK 1029 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnqr9bym 1030 From: Callee ;tag=755285EABDE2 1031 To: Callee ;tag=49A9AD0B3F6A 1032 Call-ID: E05133BD26DD 1033 Supported: outbound 1034 CSeq: 1 REGISTER 1035 Contact: 1036 ;+sip.instance="" 1037 ;reg-id=1 1038 ;expires=3600 1039 Contact: 1040 ;+sip.instance="" 1041 ;reg-id=2 1042 ;expires=3600 1043 Content-Length: 0 1045 The messages in the call flow are very normal. The only interesting 1046 thing to note is that the INVITE in message 8 contains a Record-Route 1047 header for the Secondary proxy, with its flow token. 1049 Record-Route: 1050 1052 The registrations in message 13 and 14 are the same as message 1 and 1053 2 other than the Call-ID and tags have changed. Because these 1054 messages will contain the same instance-id and reg-id as those in 1 1055 and 2, this flow will partially supersede that for messages 1 and 2 1056 and will be tried first by Primary. 1058 9. Grammar 1059 This specification defines new Contact header field parameters, 1060 reg-id and +sip.instance. The grammar includes the definitions from 1061 RFC 3261 [RFC3261] and includes the definition of uric from RFC 2396 1062 [RFC2396]. 1064 Note: The "=/" syntax used in this ABNF indicates an extension of 1065 the production on the left hand side. 1067 The ABNF[RFC4234] is: 1069 contact-params =/ c-p-reg / c-p-instance 1071 c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to 2**31 1073 c-p-instance = "+sip.instance" EQUAL 1074 LDQUOT "<" instance-val ">" RDQUOT 1076 instance-val = *uric ; defined in RFC 2396 1078 The value of the reg-id MUST NOT be 0 and MUST be less than 2**31. 1080 10. IANA Considerations 1082 10.1. Contact Header Field 1084 This specification defines a new Contact header field parameter 1085 called reg-id in the "Header Field Parameters and Parameter Values" 1086 sub-registry as per the registry created by [RFC3968]. The required 1087 information is: 1089 Header Field Parameter Name Predefined Reference 1090 Values 1091 ____________________________________________________________________ 1092 Contact reg-id Yes [RFC AAAA] 1094 [NOTE TO RFC Editor: Please replace AAAA with 1095 the RFC number of this specification.] 1097 10.2. SIP/SIPS URI Parameters 1099 This specification arguments the "SIP/SIPS URI Parameters" sub- 1100 registry as per the registry created by [RFC3969]. The required 1101 information is: 1103 Parameter Name Predefined Values Reference 1104 ____________________________________________ 1105 keepalive stun [RFC AAAA] 1107 [NOTE TO RFC Editor: Please replace AAAA with 1108 the RFC number of this specification.] 1110 10.3. SIP Option Tag 1112 This specification registers a new SIP option tag, as per the 1113 guidelines in Section 27.1 of RFC 3261. 1115 Name: outbound 1116 Description: This option-tag is used to identify Registrars which 1117 support extensions for Client Initiated Connections. A Registrar 1118 places this option-tag in a Supported header to communicate the 1119 Registrar's support for this extension to the registering User 1120 Agent. 1122 10.4. Media Feature Tag 1124 This section registers a new media feature tag, per the procedures 1125 defined in RFC 2506 [RFC2506]. The tag is placed into the sip tree, 1126 which is defined in RFC 3840 [RFC3840]. 1128 Media feature tag name: sip.instance 1130 ASN.1 Identifier: New assignment by IANA. 1132 Summary of the media feature indicated by this tag: This feature tag 1133 contains a string containing a URN that indicates a unique identifier 1134 associated with the UA instance registering the Contact. 1136 Values appropriate for use with this feature tag: String. 1138 The feature tag is intended primarily for use in the following 1139 applications, protocols, services, or negotiation mechanisms: This 1140 feature tag is most useful in a communications application, for 1141 describing the capabilities of a device, such as a phone or PDA. 1143 Examples of typical use: Routing a call to a specific device. 1145 Related standards or documents: RFC XXXX 1147 [[Note to IANA: Please replace XXXX with the RFC number of this 1148 specification.]] 1150 Security Considerations: This media feature tag can be used in ways 1151 which affect application behaviors. For example, the SIP caller 1152 preferences extension [RFC3841] allows for call routing decisions to 1153 be based on the values of these parameters. Therefore, if an 1154 attacker can modify the values of this tag, they may be able to 1155 affect the behavior of applications. As a result, applications which 1156 utilize this media feature tag SHOULD provide a means for ensuring 1157 its integrity. Similarly, this feature tag should only be trusted as 1158 valid when it comes from the user or user agent described by the tag. 1159 As a result, protocols for conveying this feature tag SHOULD provide 1160 a mechanism for guaranteeing authenticity. 1162 11. Security Considerations 1164 One of the key security concerns in this work is making sure that an 1165 attacker cannot hijack the sessions of a valid user and cause all 1166 calls destined to that user to be sent to the attacker. 1168 The simple case is when there are no edge proxies. In this case, the 1169 only time an entry can be added to the routing for a given AOR is 1170 when the registration succeeds. SIP already protects against 1171 attackers being able to successfully register, and this scheme relies 1172 on that security. Some implementers have considered the idea of just 1173 saving the instance-id without relating it to the AOR with which it 1174 registered. This idea will not work because an attacker's UA can 1175 impersonate a valid user's instance-id and hijack that user's calls. 1177 The more complex case involves one or more edge proxies. When a UA 1178 sends a REGISTER request through an Edge Proxy on to the registrar, 1179 the Edge Proxy inserts a Path header field value. If the 1180 registration is successfully authenticated, the registrar stores the 1181 value of the Path header field. Later when the registrar forwards a 1182 request destined for the UA, it copies the stored value of the Path 1183 header field into the Route header field of the request and forwards 1184 the request to the Edge Proxy. 1186 The only time an Edge Proxy will route over a particular flow is when 1187 it has received a Route header that has the flow identifier 1188 information that it has created. An incoming request would have 1189 gotten this information from the registrar. The registrar will only 1190 save this information for a given AOR if the registration for the AOR 1191 has been successful; and the registration will only be successful if 1192 the UA can correctly authenticate. Even if an attacker has spoofed 1193 some bad information in the Path header sent to the registrar, the 1194 attacker will not be able to get the registrar to accept this 1195 information for an AOR that does not belong to the attacker. The 1196 registrar will not hand out this bad information to others, and 1197 others will not be misled into contacting the attacker. 1199 12. Requirements 1201 This specification was developed to meet the following requirements: 1203 1. Must be able to detect that a UA supports these mechanisms. 1204 2. Support UAs behind NATs. 1205 3. Support TLS to a UA without a stable DNS name or IP address. 1206 4. Detect failure of a connection and be able to correct for this. 1207 5. Support many UAs simultaneously rebooting. 1208 6. Support a NAT rebooting or resetting. 1209 7. Minimize initial startup load on a proxy. 1210 8. Support architectures with edge proxies. 1212 13. Changes 1214 Note to RFC Editor: Please remove this whole section. 1216 13.1. Changes from 03 Version 1218 Added non-normative text motivating STUN vs. SIP PING, OPTIONS, and 1219 Double CRLF. Added discussion about why TCP Keepalives are not 1220 always available. 1222 Explained more clearly that outbound-proxy-set can be "configured" 1223 using any current or future, manual or automatic configuration/ 1224 discovery mechanism. 1226 Added a sentence which prevents an Edge Proxy from forwarding back 1227 over the flow over which the request is received if the request 1228 happens to contain a flow token for that flow. This was an 1229 oversight. 1231 Updated example message flow to show a failover example using a new 1232 dialog-creating request instead of a mid-dialog request. The old 1233 scenario was leftover from before the outbound/gruu reorganization. 1235 Fixed tags, Call-IDs, and branch parameters in the example messages. 1237 Made the ABNF use the "=/" production extension mechanism recommended 1238 by Bill Fenner. 1240 Added a table in an appendix expanding the default flow recovery 1241 timers. 1243 Incorporated numerous clarifications and rewordings for better 1244 comprehension. 1246 Fixed many typos and spelling misteaks. 1248 13.2. Changes from 02 Version 1250 Removed Double CRLF Keepalive 1252 Changed ;sip-stun syntax to ;keepalive=stun 1254 Fixed incorrect text about TCP keepalives. 1256 13.3. Changes from 01 Version 1258 Moved definition of instance-id from GRUU[I-D.ietf-sip-gruu] draft to 1259 this draft. 1261 Added tentative text about Double CRLF Keepalive 1263 Removed pin-route stuff 1265 Changed the name of "flow-id" to "reg-id" 1267 Reorganized document flow 1269 Described the use of STUN as a proper STUN usage 1271 Added 'outbound' option-tag to detect if registrar supports outbound 1273 13.4. Changes from 00 Version 1275 Moved TCP keepalive to be STUN. 1277 Allowed SUBSCRIBE to create flow mappings. Added pin-route option 1278 tags to support this. 1280 Added text about updating dialog state on each usage after a 1281 connection failure. 1283 14. Acknowledgments 1285 Jonathan Rosenberg provided many comments and useful text. Dave Oran 1286 came up with the idea of using the most recent registration first in 1287 the proxy. Alan Hawrylyshen co-authored the draft that formed the 1288 initial text of this specification. Additionally, many of the 1289 concepts here originated at a connection reuse meeting at IETF 60 1290 that included the authors, Jon Peterson, Jonathan Rosenberg, Alan 1291 Hawrylyshen, and Paul Kyzivat. The TCP design team consisting of 1292 Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and 1293 Ganesh Jayadevan provided input and text. Nils Ohlmeier provided 1294 many fixes and initial implementation experience. In addition, 1295 thanks to the following folks for useful comments: Francois Audet, 1296 Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, Dale 1297 Worely, Juha Heinanen, Eric Rescorla, and Lyndsay Campbell. 1299 Appendix A. Default Flow Registration Backoff Times 1301 The base-time used for the flow re-registration backoff times 1302 described in Section 4.4.2 are configurable. If the base-time-all- 1303 fail value is set to the default of 30 seconds and the base-time-not- 1304 failed value is set to the default of 90 seconds, the following table 1305 shows the resulting delay values. 1307 +-------------------+--------------------+--------------------+ 1308 | # of reg failures | all flows unusable | >1 non-failed flow | 1309 +-------------------+--------------------+--------------------+ 1310 | 0 | 0 secs | 0 secs | 1311 | 1 | 30-60 secs | 90-180 secs | 1312 | 2 | 1-2 mins | 3-6 mins | 1313 | 3 | 2-4 mins | 6-12 mins | 1314 | 4 | 4-8 mins | 12-24 mins | 1315 | 5 | 8-16 mins | 15-30 mins | 1316 | 6 or more | 15-30 mins | 15-30 mins | 1317 +-------------------+--------------------+--------------------+ 1319 15. References 1321 15.1. Normative References 1323 [I-D.ietf-behave-rfc3489bis] 1324 Rosenberg, J., "Simple Traversal of UDP Through Network 1325 Address Translators (NAT) (STUN)", 1326 draft-ietf-behave-rfc3489bis-02 (work in progress), 1327 July 2005. 1329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1330 Requirement Levels", BCP 14, RFC 2119, March 1997. 1332 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1334 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1335 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1336 August 1998. 1338 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1339 Registration Procedure", BCP 31, RFC 2506, March 1999. 1341 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1342 A., Peterson, J., Sparks, R., Handley, M., and E. 1343 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1344 June 2002. 1346 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1347 Protocol (SIP): Locating SIP Servers", RFC 3263, 1348 June 2002. 1350 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1351 (SIP) Extension Header Field for Registering Non-Adjacent 1352 Contacts", RFC 3327, December 2002. 1354 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1355 "Indicating User Agent Capabilities in the Session 1356 Initiation Protocol (SIP)", RFC 3840, August 2004. 1358 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1359 Preferences for the Session Initiation Protocol (SIP)", 1360 RFC 3841, August 2004. 1362 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 1363 (IANA) Header Field Parameter Registry for the Session 1364 Initiation Protocol (SIP)", BCP 98, RFC 3968, 1365 December 2004. 1367 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1368 (IANA) Uniform Resource Identifier (URI) Parameter 1369 Registry for the Session Initiation Protocol (SIP)", 1370 BCP 99, RFC 3969, December 2004. 1372 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1373 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1374 July 2005. 1376 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1377 Specifications: ABNF", RFC 4234, October 2005. 1379 15.2. Informative References 1381 [I-D.ietf-sip-gruu] 1382 Rosenberg, J., "Obtaining and Using Globally Routable User 1383 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1384 (SIP)", draft-ietf-sip-gruu-04 (work in progress), 1385 July 2005. 1387 [I-D.ietf-sipping-config-framework] 1388 Petrie, D., "A Framework for Session Initiation Protocol 1389 User Agent Profile Delivery", 1390 draft-ietf-sipping-config-framework-08 (work in progress), 1391 Mar 2006. 1393 [I-D.rosenberg-sip-route-construct] 1394 Rosenberg, J., "Clarifying Construction of the Route 1395 Header Field in the Session Initiation Protocol (SIP)", 1396 draft-rosenberg-sip-route-construct-00 (work in progress), 1397 July 2005. 1399 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1400 Hashing for Message Authentication", RFC 2104, 1401 February 1997. 1403 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 1404 Uniform Resource Names", RFC 3188, October 2001. 1406 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1407 Encodings", RFC 3548, July 2003. 1409 [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1410 (SIP) Extension Header Field for Service Route Discovery 1411 During Registration", RFC 3608, October 2003. 1413 Authors' Addresses 1415 Cullen Jennings (editor) 1416 Cisco Systems 1417 170 West Tasman Drive 1418 Mailstop SJC-21/2 1419 San Jose, CA 95134 1420 USA 1422 Phone: +1 408 902-3341 1423 Email: fluffy@cisco.com 1425 Rohan Mahy (editor) 1426 Plantronics 1427 345 Encincal St 1428 Santa Cruz, CA 95060 1429 USA 1431 Email: rohan@ekabal.com 1433 Intellectual Property Statement 1435 The IETF takes no position regarding the validity or scope of any 1436 Intellectual Property Rights or other rights that might be claimed to 1437 pertain to the implementation or use of the technology described in 1438 this document or the extent to which any license under such rights 1439 might or might not be available; nor does it represent that it has 1440 made any independent effort to identify any such rights. Information 1441 on the procedures with respect to rights in RFC documents can be 1442 found in BCP 78 and BCP 79. 1444 Copies of IPR disclosures made to the IETF Secretariat and any 1445 assurances of licenses to be made available, or the result of an 1446 attempt made to obtain a general license or permission for the use of 1447 such proprietary rights by implementers or users of this 1448 specification can be obtained from the IETF on-line IPR repository at 1449 http://www.ietf.org/ipr. 1451 The IETF invites any interested party to bring to its attention any 1452 copyrights, patents or patent applications, or other proprietary 1453 rights that may cover technology that may be required to implement 1454 this standard. Please address the information to the IETF at 1455 ietf-ipr@ietf.org. 1457 Disclaimer of Validity 1459 This document and the information contained herein are provided on an 1460 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1461 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1462 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1463 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1464 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1465 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1467 Copyright Statement 1469 Copyright (C) The Internet Society (2006). This document is subject 1470 to the rights, licenses and restrictions contained in BCP 78, and 1471 except as set forth therein, the authors retain all their rights. 1473 Acknowledgment 1475 Funding for the RFC Editor function is currently provided by the 1476 Internet Society.