idnits 2.17.1 draft-ietf-sip-outbound-03.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 1357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1347. ** 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 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 (March 20, 2006) is 6610 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) -- Looks like a reference, but probably isn't: 'RFC AAAA' on line 1062 == Missing Reference: '23' is mentioned on line 1108, but not defined ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-02 ** Obsolete normative reference: RFC 2234 (ref. '8') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (ref. '11') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 3188 (ref. '15') (Obsoleted by RFC 8458) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-04 -- Obsolete informational reference (is this intentional?): RFC 3548 (ref. '18') (Obsoleted by RFC 4648) == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-route-construct-00 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 13 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: September 21, 2006 Plantronics 6 March 20, 2006 8 Managing Client Initiated Connections in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sip-outbound-03 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 September 21, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Session Initiation Protocol (SIP) allows proxy servers to initiate 44 TCP connections and send asynchronous UDP datagrams to User Agents in 45 order to deliver requests. However, many practical considerations, 46 such as the existence of firewalls and Network Address Translators 47 (NATs), prevent servers from connecting to User Agents in this way. 48 Even when a proxy server can open a TCP connection to a User Agent, 49 most User Agents lack a certificate suitable to act as a TLS 50 (Transport Layer Security) server. This specification defines 51 behaviors for User Agents, registrars and proxy servers that allow 52 requests to be delivered on existing connections established by the 53 User Agent. It also defines keep alive behaviors needed to keep NAT 54 bindings open and specifies the usage of multiple connections. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 60 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1 Summary of Mechanism . . . . . . . . . . . . . . . . . . . 5 63 3.2 Single Registrar and UA . . . . . . . . . . . . . . . . . 6 64 3.3 Multiple Connections from a User Agent . . . . . . . . . . 7 65 3.4 Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.5 Keep Alive Technique . . . . . . . . . . . . . . . . . . . 10 67 4. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 10 68 4.1 Instance ID Creation . . . . . . . . . . . . . . . . . . . 10 69 4.2 Initial Registrations . . . . . . . . . . . . . . . . . . 12 70 4.2.1 Registration by Other Instances . . . . . . . . . . . 13 71 4.3 Sending Requests . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.1 Selecting the First Hop . . . . . . . . . . . . . . . 13 73 4.3.2 Forming Flows . . . . . . . . . . . . . . . . . . . . 13 74 4.4 Detecting Flow Failure . . . . . . . . . . . . . . . . . . 14 75 4.4.1 Keep Alive with STUN . . . . . . . . . . . . . . . . . 14 76 4.4.2 Flow Recovery . . . . . . . . . . . . . . . . . . . . 15 77 5. Edge Proxy Mechanisms . . . . . . . . . . . . . . . . . . . . 15 78 5.1 Processing Register Requests . . . . . . . . . . . . . . . 15 79 5.2 Generating Flow Tokens . . . . . . . . . . . . . . . . . . 16 80 5.3 Forwarding Requests . . . . . . . . . . . . . . . . . . . 16 81 6. Registrar and Location Server Mechanisms . . . . . . . . . . . 17 82 6.1 Processing Register Requests . . . . . . . . . . . . . . . 17 83 6.2 Forwarding Requests . . . . . . . . . . . . . . . . . . . 18 84 7. Mechanisms for All Servers (Proxys, Registars, UAS) . . . . . 19 85 7.1 STUN Processing . . . . . . . . . . . . . . . . . . . . . 19 86 8. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 20 87 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 89 10.1 Contact Header Field . . . . . . . . . . . . . . . . . . . 24 90 10.2 SIP/SIPS URI Paramters . . . . . . . . . . . . . . . . . . 24 91 10.3 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 24 92 10.4 Media Feature Tag . . . . . . . . . . . . . . . . . . . . 25 93 11. Security Considerations . . . . . . . . . . . . . . . . . . 26 94 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 26 95 13. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 13.1 Changes from 02 Version . . . . . . . . . . . . . . . . . 27 97 13.2 Changes from 01 Version . . . . . . . . . . . . . . . . . 27 98 13.3 Changes from 00 Version . . . . . . . . . . . . . . . . . 27 99 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 100 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 15.1 Normative References . . . . . . . . . . . . . . . . . . . 28 102 15.2 Informative References . . . . . . . . . . . . . . . . . . 29 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 104 Intellectual Property and Copyright Statements . . . . . . . . 31 106 1. Introduction 108 There are many environments for SIP [5] deployments in which the User 109 Agent (UA) can form a connection to a Registrar or Proxy but in which 110 the connections in the reverse direction to the UA are not possible. 111 This can happen for several reasons. Connection to the UA can be 112 blocked by a firewall device between the UA and the proxy or 113 registrar, which will only allow new connections in the direction of 114 the UA to the Proxy. Similarly there may be a NAT, which are only 115 capable of allowing new connections from the private address side to 116 the public side. This specification allows SIP registration when the 117 UA is behind such a firewall or NAT. 119 Most IP phones and personal computers get their network 120 configurations dynamically via a protocol such as DHCP (Dynamic Host 121 Configuration Protocol). These systems typically do not have a 122 useful name in the Domain Name System (DNS), and they definitely do 123 not have a long-term, stable DNS name that is appropriate for binding 124 to a certificate. It is impractical for them to have a certificate 125 that can be used as a client-side TLS certificate for SIP. However, 126 these systems can still form TLS connections to a proxy or registrar 127 which authenticates with a server certificate. The server can 128 authenticate the UA using a shared secret in a digest challenge over 129 that TLS connection. 131 The key idea of this specification is that when a UA sends a REGISTER 132 request, the proxy can later use this same network "flow"--whether 133 this is a bidirectional stream of UDP datagrams, a TCP connection, or 134 an analogous concept of another transport protocol--to forward any 135 requests that need to go to this UA. For a UA to receive incoming 136 requests, the UA has to connect to a server. Since the server can't 137 connect to the UA, the UA has to make sure that a flow is always 138 active. This requires the UA to detect when a flow fails. Since, 139 such detection takes time and leaves a window of opportunity for 140 missed incoming requests, this mechanism allows the UA to use 141 multiple flows to the proxy or registrar. This mechanism also uses a 142 keep alive mechanism over each flow so that the UA can detect when a 143 flow has failed. 145 2. Conventions and Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [4]. 151 2.1 Definitions 152 Edge Proxy: An Edge Proxy is any proxy that is located topologically 153 between the registering User Agent and the registrar. 154 flow: A Flow is a network protocol layer (layer 4) association 155 between two hosts that is represented by the network address and 156 port number of both ends and by the protocol. For TCP, a flow is 157 equivalent to a TCP connection. For UDP a flow is a bidirectional 158 stream of datagrams between a single pair of IP addresses and 159 ports of both peers. With TCP, a flow often has a one to one 160 correspondence with a single file descriptor in the operating 161 system. 162 reg-id: This refers to the value of a new header field parameter 163 value for the Contact header field. When a UA registers multiple 164 times, each simultaneous registration gets a unique reg-id value. 165 instance-id: This specification uses the word instance-id to refer to 166 the value of the "sip.instance" media feature tag in the Contact 167 header field. This is a Uniform Resource Name (URN) that uniquely 168 identifies this specific UA instance. 169 outbound-proxy-set A configured set of SIP URIs (Uniform Resource 170 Identifiers) that represents each of the outbound proxies (often 171 Edge Proxies) with which the UA will attempt to maintain a direct 172 flow. 174 3. Overview 176 Several scenarios in which this technique is useful are discussed 177 below, including the simple co-located registrar and proxy, a User 178 Agent desiring multiple connections to a resource (for redundancy for 179 example), and a system that uses Edge Proxies. 181 3.1 Summary of Mechanism 183 The overall approach is fairly simple. Each UA has a unique 184 instance-id that stays the same for this UA even if the UA reboots or 185 is power cycled. Each UA can register multiple times over different 186 connections for the same SIP Address of Record (AOR) to achieve high 187 reliability. Each registration includes the instance-id for the UA 188 and a reg-id label that is different for each flow. The registrar 189 can use the instance-id to recognize that two different registrations 190 both reach the same UA. The registrar can use the reg-id label to 191 recognize that a UA is registering after a reboot. 193 When a proxy goes to route a message to a UA for which it has a 194 binding, it can use any one of the flows on which a successful 195 registration has been completed. A failure on a particular flow can 196 be tried again on an alternate flow. Proxies can determine which 197 flows go to the same UA by comparing the instance-id. Proxies can 198 tell that a flow replaces a previously abandoned flow by looking at 199 the reg-id. 201 UAs use the STUN (Simple Traversal of UDP through NATs) protocol as 202 the keep alive mechanism to keep their flow to the proxy or registrar 203 alive. 205 3.2 Single Registrar and UA 207 In this example, a single server is acting as both a registrar and 208 proxy. 210 +-----------+ 211 | Registrar | 212 | Proxy | 213 +-----+-----+ 214 | 215 | 216 +----+--+ 217 | User | 218 | Agent | 219 +-------+ 221 User Agents which form only a single flow continue to register 222 normally but include the instance-id as described in Section 4.1. 223 The UA can also include a reg-id parameter is used to allow the 224 registrar to detect and avoid using invalid contacts when a UA 225 reboots or reconnects after its old connection has failed for some 226 reason. 228 For clarity, here is an example. Bob's UA creates a new TCP flow to 229 the registrar and sends the following REGISTER request. 231 REGISTER sip:example.com SIP/2.0 232 Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bK-bad0ce-11-1036 233 Max-Forwards: 70 234 From: Bob ;tag=d879h76 235 To: Bob 236 Call-ID: 8921348ju72je840.204 237 CSeq: 1 REGISTER 238 Supported: path 239 Contact: ; reg-id=1; 240 ;+sip.instance="" 241 Content-Length: 0 243 The registrar challenges this registration to authenticate Bob. When 244 the registrar adds an entry for this contact under the AOR for Bob, 245 the registrar also keeps track of the connection over which it 246 received this registration. 248 The registrar saves the instance-id and reg-id along with the rest of 249 the Contact header field. If the instance-id and reg-id are the same 250 as a previous registration for the same AOR, the proxy uses the most 251 recently created registration first. This allows a UA that has 252 rebooted to replace its previous registration for each flow with 253 minimal impact on overall system load. 255 When Alice sends a request to Bob, his proxy selects the target set. 256 The proxy forwards the request to elements in the target set based on 257 the proxy's policy. The proxy looks at the target set and uses the 258 instance-id to understand that two targets both end up routing to the 259 same UA. When the proxy goes to forward a request to a given target, 260 it looks and finds the flows that received the registration. The 261 proxy then forwards the request on that flow instead of trying to 262 form a new flow to that contact. This allows the proxy to forward a 263 request to a particular contact over the same flow that the UA used 264 to register this AOR. If the proxy has multiple flows that all go to 265 this UA, it can choose any one of registration bindings for this AOR 266 that has the same instance-id as the selected UA. In general, if two 267 registrations have the same reg-id and instance-id, the proxy will 268 favor the most recently registered flow. This is so that if a UA 269 reboots, the proxy will prefer to use the most recent flow that goes 270 to this UA instead of trying one of the old flows which would 271 presumably fail. 273 3.3 Multiple Connections from a User Agent 275 There are various ways to deploy SIP to build a reliable and scalable 276 system. This section discusses one such design that is possible with 277 the mechanisms in this specification. Other designs are also 278 possible. 280 In this example system, the logical proxy/registrar for the domain is 281 running on two hosts that share the appropriate state and can both 282 provide registrar and proxy functionality for the domain. The UA 283 will form connections to two of the physical hosts that can perform 284 the proxy/registrar function for the domain. Reliability is achieved 285 by having the UA form two TCP connections to the domain. Scalability 286 is achieved by using DNS SRV to load balance the primary connection 287 across a set of machines that can service the primary connection and 288 also using DNS SRV to load balance across a separate set of machines 289 that can service the backup connection. The deployment here requires 290 that DNS is configured with one entry that resolves to all the 291 primary hosts and another entry that resolves to all the backup 292 hosts. Designs having only one set were also considered, but in this 293 case there would have to be some way to ensure that the two 294 connection did not accidentally resolve to the same host. Various 295 approaches for this are possible but all probably require extensions 296 to the SIP protocol so they were not included in this specification. 298 This approach can work with the disadvantage that slightly more 299 configuration of DNS is required. 301 +-------------------+ 302 | Domain | 303 | Logical Proxy/Reg | 304 | | 305 |+-----+ +-----+| 306 ||Host1| |Host2|| 307 |+-----+ +-----+| 308 +---\------------/--+ 309 \ / 310 \ / 311 \ / 312 \ / 313 +------+ 314 | User | 315 | Agent| 316 +------+ 318 The UA is configured with a primary and backup registration URI. 319 These URIs are configured into the UA through whatever the normal 320 mechanism is to configure the proxy or registrar address in the UA. 321 If the AOR is Alice@example.com, the outbound-proxy-set might look 322 something like "sip:primary.example.com;keepalive=stun" and "sip: 323 backup.example.com;keepalive=stun". The "keepalive=stun" tag 324 indicates that a SIP server supports STUN and SIP muxed over the same 325 flow, as described later in this specification. Note that each URI 326 in the outbound-proxy-set could resolve to several different physical 327 hosts. The administrative domain that created these URIs should 328 ensure that the two URIs resolve to separate hosts. These URIs are 329 handled according to normal SIP processing rules, so things like SRV 330 can be used to do load balancing across a proxy farm. 332 The domain also needs to ensure that a request for the UA sent to 333 host1 or host2 is then sent across the appropriate flow to the UA. 334 The domain might choose to use the Path header (as described in the 335 next section) approach to store this internal routing information on 336 host1 or host2. 338 When a single server fails, all the UAs that have a flow through it 339 will detect a flow failure and try to reconnect. This can cause 340 large loads on the server. When large numbers of hosts reconnect 341 nearly simultaneously, this is referred to as the avalanche restart 342 problem, and is further discussed in Section 4.4.2. The multiple 343 flows to many servers help reduce the load caused by the avalanche 344 restart. If a UA has multiple flows, and one of the servers fails, 345 it can delay some significant time before trying to form a new 346 connection to replace the flow to the server that failed. By 347 spreading out the time used for all the UAs to reconnect to a server, 348 the load on the server farm is reduced. 350 3.4 Edge Proxies 352 Some SIP deployments use edge proxies such that the UA sends the 353 REGISTER to an Edge Proxy that then forwards the REGISTER to the 354 Registrar. The Edge Proxy includes a Path header [12] so that when 355 the registrar later forwards a request to this UA, the request is 356 routed through the Edge Proxy. There could be a NAT or firewall 357 between the UA and the Edge Proxy. 358 +---------+ 359 |Registrar| 360 |Proxy | 361 +---------+ 362 / \ 363 / \ 364 / \ 365 +-----+ +-----+ 366 |Edge1| |Edge2| 367 +-----+ +-----+ 368 \ / 369 \ / 370 ----------------------------NAT/FW 371 \ / 372 \ / 373 +------+ 374 |User | 375 |Agent | 376 +------+ 378 These systems can use effectively the same mechanism as described in 379 the previous sections but need to use the Path header. When the Edge 380 Proxy receives a registration, it needs to create an identifier value 381 that is unique to this flow (and not a subsequent flow with the same 382 addresses) and put this identifier in the Path header URI. This can 383 be done by putting the value in the user portion of a loose route in 384 the path header. If the registration succeeds, the Edge Proxy needs 385 to map future requests that are routed to the identifier value from 386 the Path header, to the associated flow. 388 The term Edge Proxy is often used to refer to deployments where the 389 Edge Proxy is in the same administrative domain as the Registrar. 390 However, in this specification we use the term to refer to any proxy 391 between the UA and the Registrar. For example the Edge Proxy may be 392 inside an enterprise that requires its use and the registrar could be 393 a service provider with no relationship to the enterprise. 395 Regardless if they are in the same administrative domain, this 396 specification requires that Registrars and Edge proxies support the 397 Path header mechanism in RFC 3327 [12]. 399 3.5 Keep Alive Technique 401 A keep alive mechanism needs to detect failure of a connection and 402 changes to the NAT public mapping, as well as keeping any NAT 403 bindings refreshed. This specification describes using STUN [7] over 404 the same flow as the SIP traffic to perform the keep alive. For 405 connection-oriented transports (e.g. TCP and TLS over TCP), the UAC 406 MAY use TCP keep-alives to detect flow failure if the UAC can send 407 these keep alives and detect a keep alive failure according to the 408 timeframes described in Section 4.4. 410 For connection-less transports, a flow definition could change 411 because a NAT device in the network path reboots and the resulting 412 public IP address or port mapping for the UA changes. To detect 413 this, requests are sent over the same flow that is being used for the 414 SIP traffic. The proxy or registrar acts as a STUN server on the SIP 415 signaling port. 417 Note: The STUN mechanism is very robust and allows the detection 418 of a changed IP address. Many other options were considered, but 419 the SIP Working Group selected the STUN-based approach, since it 420 works over any transport. Approaches using SIP requests were 421 abandoned because to achieve the required performance, the server 422 needs to deviate from the SIP specification in significant ways. 423 This would result in many undesirable and non-deterministic 424 behaviors in some environments. The TCP KEEP_ALIVE mechanism will 425 not always work, since some operating systems and programming 426 environments do not allow the keep alive time to be set on a per 427 connection basis. 429 When the UA detects that a flow has failed or that the flow 430 definition has changed, the UA needs to re-register and will use the 431 back-off mechanism described in Section 4 to provide congestion 432 relief when a large number of agents simultaneously reboot. 434 4. User Agent Mechanisms 436 4.1 Instance ID Creation 438 Each UA MUST have an Instance Identifer URN that uniquely identifies 439 the device. Usage of a URN provides a persistent and unique name for 440 the UA instance. It also provides an easy way to guarantee 441 uniqueness within the AOR. This URN MUST be persitant across power 442 cylces of the device. 444 A UA SHOULD use a UUID URN [9]. The UUID URN allows for non- 445 centralized computation of a URN based on time, unique names (such as 446 a MAC address), or a random number generator. 448 A device like a soft-phone, when first installed, can generate a 449 UUID [9] and then save this in persistent storage for all future 450 use. For a device such as a hard phone, which will only ever have 451 a single SIP UA present, the UUID can include the MAC address and 452 be generated at any time because it is guaranteed that no other 453 UUID is being generated at the same time on that physical device. 454 This means the value of the time component of the UUID can be 455 arbitrarily selected to be any time less than the time when the 456 device was manufactured. A time of 0 (as shown in the example in 457 Section 3.2) is perfectly legal as long as the device knows no 458 other UUIDs were generated at this time. 460 If a URN scheme other than UUID is used, the URN MUST be selected 461 such that the instance can be certain that no other instance 462 registering against the same AOR would choose the same URN value. An 463 example of a URN that would not meet the requirements of this 464 specification is the national bibliographic number [15]. Since there 465 is no clear relationship between a SIP UA instance and a URN in this 466 namespace, there is no way a selection of a value can be performed 467 that guarantees that another UA instance doesn't choose the same 468 value. 470 The UA SHOULD include a "sip.instance" media feature tag as a UA 471 characteristic [10] in requests and responses. As described in [10], 472 this media feature tag will be encoded in the Contact header field as 473 the "+sip.instance" Contact header field parameter. The value of 474 this parameter MUST be a URN [3]. One case where a UA may not want 475 to include the URN in the sip.instance media feature tag is when it 476 is making an anoymous request or some other privacy concern requires 477 that the UA not reveal its identity. 479 RFC 3840 [10] defines equality rules for callee capabilities 480 parameters, and according to that specification, the 481 "sip.instance" media feature tag will be compared by case- 482 sensitive string comparison. This means that the URN will be 483 encapsulated by angle brackets ("<" and ">") when it is placed 484 within the quoted string value of the +sip.instance Contact header 485 field parameter. The case-sensitive matching rules apply only to 486 the generic usages defined in RFC 3840 [10] and in the caller 487 preferences specification [2]. When the instance ID is used in 488 this specification, it is effectively "extracted" from the value 489 in the "sip.instance" media feature tag. Thus, equality 490 comparisons are performed using the rules for URN equality that 491 are specific to the scheme in the URN. If the element performing 492 the comparisons does not understand the URN scheme, it performs 493 the comparisons using the lexical equality rules defined in RFC 494 2141 [3]. Lexical equality may result in two URNs being 495 considered unequal when they are actually equal. In this specific 496 usage of URNs, the only element which provides the URN is the SIP 497 UA instance identified by that URN. As a result, the UA instance 498 SHOULD provide lexically equivalent URNs in each registration it 499 generates. This is likely to be normal behavior in any case; 500 clients are not likely to modify the value of the instance ID so 501 that it remains functionally equivalent yet lexigraphically 502 different to previous registrations. 504 4.2 Initial Registrations 506 UAs are configured with one or more SIP URIs representing the default 507 outbound-proxy-set. The specification assumes the set is determined 508 via configuration but future specifications may define other 509 mechanisms such as using DNS to discover this set. How the UA is 510 configured is outside the scope of this specification. However, a UA 511 MUST support sets with at least two outbound proxy URIs (primary and 512 backup) and SHOULD support sets with up to four URIs. For each 513 outbound proxy URI in the set, the UA MUST send a REGISTER in the 514 normal way using this URI as the default outbound proxy. Forming the 515 route set for the request is outside the scope of this document, but 516 typically results in sending the REGISTER such that the topmost Route 517 header field contains a loose route to the outbound proxy URI. Other 518 issues related to outbound route construction are discussed in [20]. 520 Registration requests, other than those described in Section 4.2.1, 521 MUST include the instance-id media feature tag as specified in 522 Section 4.1. 524 These ordinary registration requests MUST also add a distinct reg-id 525 parameter to the Contact header field. Each one of these 526 registrations will form a new flow from the UA to the proxy. The 527 reg-id sequence does not have to be sequential but MUST be exactly 528 the same reg-id sequence each time the device power cycles or reboots 529 so that the reg-id values will collide with the previously used 530 reg-id values. This is so the proxy can realize that the older 531 registrations are probably not useful. 533 The UAC MUST indicate that it supports the Path header [12] 534 mechanism, by including the 'path' option-tag in a Supported header 535 field value in its REGISTER requests. Other than optionally 536 examining the Path vector in the response, this is all that is 537 required of the UAC to support Path. 539 The UAC MAY examine successful registrations for the presence of an 540 'outbound' option-tag in a Supported header field value. Presence of 541 this option-tag indicates that the registrar is compliant with this 542 specification. 544 Note that the UA needs to honor 503 responses to registrations as 545 described in RFC 3261 and RFC 3263 [6]. In particular, implementors 546 should note that when receiving a 503 response with a Retry-After 547 header field, the UA should wait the indicated amount of time and 548 retry the registration. A Retry-After header field value of 0 is 549 valid and indicates the UA should retry the REGISTER immediately. 550 Implementations need to ensure that when retrying the REGISTER they 551 revisit the DNS resolution results such that the UA can select an 552 alternate host from the one chosen the previous time the URI was 553 resolved. 555 4.2.1 Registration by Other Instances 557 A User Agent MUST NOT include an instance-id or reg-id in the Contact 558 header field of a registration if the registering UA is not the same 559 instance as the UA referred to by the target Contact header field. 560 (This practice is occasionally used to install forwarding policy into 561 registrars.) 563 Note that a UAC also MUST NOT include an instance-id or reg-id 564 parameter in a request to deregister all Contacts (a single Contact 565 header field value with the value of "*"). 567 4.3 Sending Requests 569 As described in Section 4.1, all requests need to include the 570 instance-id media feature tag unless privacy concerns require 571 otherwise. 573 4.3.1 Selecting the First Hop 575 When an UA is about to send a request, it first performs normal 576 processing to select the next hop URI. The UA can use a variety of 577 techniques to compute the route set and accordingly the next hop URI. 578 Discussion of these techniques is outside the scope of this document 579 but could include mechanisms specified in RFC 3608 [21] (Service 580 Route) and [20]. 582 4.3.2 Forming Flows 584 The UA performs normal DNS resolution on the next hop URI (as 585 described in RFC 3263 [6]) to find a protocol, IP address, and port. 586 For non TLS protocols, if the UA has an existing flow to this IP 587 address, and port with the correct protocol, then the UA MUST use the 588 existing connection. For TLS protocols, the existing flow is only 589 used if, in addition to matching the IP address, port, and protocol, 590 the host production in the next hop URI MUST match one of the URIs 591 contained in the subjectAltName in the peer certificate. If the UA 592 cannot use one of the existing flows, then it SHOULD form a new flow 593 by sending a datagram or opening a new connection to the next hop, as 594 appropriate for the transport protocol. 596 4.4 Detecting Flow Failure 598 The UA needs to detect when a specific flow fails. If a flow has 599 failed, the UA follows the procedures in Section 4.2 to form a new 600 flow to replace the failed one. The UA proactively tries to detect 601 failure by periodically sending keep alive messages using one of the 602 techniques described in this section. 604 The time between keep alive requests when using UDP based transports 605 SHOULD be a random number between 24 and 29 seconds while for TCP 606 based transports it SHOULD be a random number between 95 and 120 607 seconds. These times MAY be configurable. 609 o Note on selection of time values: For UDP, the upper bound of 29 610 seconds was selected so that multiple STUN packets could be sent 611 before 30 seconds based on information that many NATs have UDP 612 timeouts as low as 30 seconds. The 24 second lower bound was 613 selected so that after 10 minutes the jitter introduced by 614 different timers will the keep alive requests unsynchronized to 615 evenly spread the load on the servers. For TCP, the 120 seconds 616 was chosen based on the idea that for a good user experience, 617 failures should be detected in this amount of time and a new 618 connection set up. Operators that wish to change the relationship 619 between load on servers and the expected time that a user may not 620 receive inbound communications will probably adjust this time. 621 The 95 seconds lower bound was chosen so that the jitter 622 introduced will result in a relatively even load on the servers 623 after 30 minutes. 625 4.4.1 Keep Alive with STUN 627 User Agents that form flows MUST check if the configured URI they are 628 connecting to has a 'keepalive' URI parameter (defined in Section 10) 629 with the value of 'stun'. If the parameter is present, the UA needs 630 to periodically perform keep alive checks by sending a STUN [7] 631 Binding Requests over the flow. 633 If the XOR-MAPPED-ADDRESS in the STUN Binding Response changes, the 634 UA MUST treat this event as a failure on the flow. 636 4.4.2 Flow Recovery 638 When a flow to a particular URI in the outbound-proxy-set fails, the 639 UA needs to form a new flow to replace the old flow and replace any 640 registrations that were previously sent over this flow. Each new 641 registration MUST have the same reg-id as the registration it 642 replaces. This is done in much the same way as forming a brand new 643 flow as described in Section 4.3.2; however, if there is a failure in 644 forming this flow, the UA needs to wait a certain amount of time 645 before retrying to form a flow to this particular next hop. 647 The time to wait is computed in the following way. If all of the 648 flows to every URI in the proxy set have failed, the base time is set 649 to 30 seconds; otherwise, in the case where at least one of the flows 650 has not failed, the base time is set to 90 seconds. The wait time is 651 computed by taking two raised to power of the number of consecutive 652 registration failures for that URI, and multiplying this by the base 653 time, up to a maximum of 1800 seconds. 654 wait-time = min( 1800, (base-time * (2 ^ consecutive-failures))) 656 These three times MAY be configurable in the UA. The three times are 657 the max-time with a default of 1800 seconds, the base-time-all-fail 658 with a default of 30 seconds, and the base-time-not-failed with a 659 default of 60 seconds. For example if the base time was 30 seconds, 660 and there had been three failures, then the wait time would be 661 min(1800,30*(2^3)) or 240 seconds. The delay time is computed by 662 selecting a uniform random time between 50 and 100 percent of the 663 wait time. The UA MUST wait for the value of the delay time before 664 trying another registration to form a new flow for that URI. 666 To be explicitly clear on the boundary conditions: when the UA boots 667 it immediately tries to register. If this fails and no registration 668 on other flows succeed, the first retry happens somewhere between 30 669 and 60 seconds after the failure of the first registration request. 670 If the number of consecutive-failures is large enough that the 671 maximum of 1800 seconds is reached, the UA will keep trying forever 672 with a random time between 900 and 1800 seconds between the attempts. 674 5. Edge Proxy Mechanisms 676 5.1 Processing Register Requests 678 When an Edge Proxy receives a registration request with a 679 sip.instance media feature tag in the Contact header field, it MUST 680 form a flow identifier token that is unique to this network flow. 681 The Edge Proxy MUST insert this token into a URI referring to this 682 proxy and place this URI into a Path header field as described in RFC 683 3327 [12]. The token MAY be placed in the userpart of the URI. 685 5.2 Generating Flow Tokens 687 A trivial but impractical way to satisfy the flow token requirement 688 Section 5.1 involves storing a mapping between an incrementing 689 counter and the connection information; however this would require 690 the Edge Proxy to keep an impractical amount of state. It is unclear 691 when this state could be removed and the approach would have problems 692 if the proxy crashed and lost the value of the counter. Two 693 stateless examples are provided below. A proxy can use any algorithm 694 it wants as long as the flow token is unique to a flow, the flow can 695 be recovered from the token, and the token can not be modified by 696 attackers. 698 Algorithm 1: The proxy generates a flow token for connection-oriented 699 transports by concatenating the file descriptor (or equivalent) 700 with the NTP time the connection was created, and base64 encoding 701 the result. This results in an approximately 16 octet identifier. 702 The proxy generates a flow token for UDP by concatenating the file 703 descriptor and the remote IP address and port, then base64 704 encoding the result. This algorithm MUST NOT be used unless all 705 messages between the Edge proxy and Registrar use a SIPS protected 706 transport. If the SIPS level of integrity protection is not 707 available, an attacker can hijack another user's calls. 708 Algorithm 2: When the proxy boots it selects a 20 byte crypto random 709 key called K that only the Edge Proxy knows. A byte array, called 710 S, is formed that contains the following information about the 711 flow the request was received on: an enumeration indicating the 712 protocol, the local IP address and port, the remote IP address and 713 port. The HMAC of S is computed using the key K and the HMAC- 714 SHA1-80 algorithm, as defined in [16]. The concatenation of the 715 HMAC and S are base64 encoded, as defined in [18], and used as the 716 flow identifier. When using IPv4 addresses, this will result in a 717 32 octet identifier. 719 5.3 Forwarding Requests 721 When the Edge Proxy receives a request, it applies normal routing 722 procedures with the following addition. If the top-most Route header 723 refers to the Edge Proxy and contains a valid flow identifier token 724 created by this proxy, the proxy MUST forward the request over the 725 flow that received the REGISTER request that caused the flow 726 identifier token to be created. For connection-oriented transports, 727 if the flow no longer exists the proxy SHOULD send a 410 response to 728 the request. 730 The advantage to a stateless approach to managing the flow 731 information is that there is no state on the edge proxy that 732 requires clean up or that has to be synchronized with the 733 registrar. 735 Proxies which used one of the two algorithms described in this 736 document to form a flow token follow the procedures below to 737 determine the correct flow. 739 Algorithm 1: The proxy base64 decodes the user part of the Route 740 header. For TCP, if a connection specified by the file descriptor 741 is present and the creation time of the file descriptor matches 742 the creation time encoded in the Route header, the proxy forwards 743 the request over that connection. For UDP, the proxy forwards the 744 request from the encoded file descriptor to the source IP address 745 and port. 746 Algorithm 2: To decode the flow token take the flow identifier in the 747 user portion of the URI, and base64 decode it, then verify the 748 HMAC is correct by recomputing the HMAC and checking it matches. 749 If the HMAC is not correct, the proxy SHOULD send a 403 response. 750 If the HMAC was correct then the proxy should forward the request 751 on the flow that was specified by the information in the flow 752 identifier. If this flow no longer exists, the proxy SHOULD send 753 a 410 response to the request. 755 Note that techniques to ensure that mid-dialog requests are routed 756 over an existing flow are out of scope and therefore not part of this 757 specification. However, an approach such as having the Edge Proxy 758 Record-Route with a flow token is one way to ensure that mid-dialog 759 requests are routed over the correct flow. 761 6. Registrar and Location Server Mechanisms 763 6.1 Processing Register Requests 765 This specification updates the definition of a binding in RFC 3261 766 [5] Section 10 and RFC 3327 [12] Section 5.3. 768 When no instance-id is present in a Contact header field value in a 769 REGISTER request, the corresponding binding is still between an AOR 770 and the URI from that Contact header field value. When an 771 instance-id is present in a Contact header field value in a REGISTER 772 request, the corresponding binding is between an AOR and the 773 combination of instance-id and reg-id. For a binding with an 774 instance-id, the registrar still stores the Contact header field 775 value URI with the binding, but does not consider the Contact URI for 776 comparison purposes (the Contact URI is not part of the "key" for the 777 binding). The registrar MUST be prepared to receive, simultaneously 778 for the same AOR, some registrations that use instance-id and reg-id 779 and some that do not. 781 Registrars which implement this specification, MUST support the Path 782 header mechanism [12]. 784 In addition to the normal information stored in the binding record, 785 some additional information MUST be stored for any registration that 786 contains a reg-id header parameter in the Contact header field value. 787 The registrar MUST store enough information to uniquely identify the 788 network flow over which the request arrived. For common operating 789 systems with TCP, this would typically just be the file descriptor. 790 For common operating systems with UDP this would typically be the 791 file descriptor for the local socket that received the request, the 792 local interface, and the IP address and port number of the remote 793 side that sent the request. 795 The registrar MUST also store all the Contact header field 796 information including the reg-id and instance-id parameters and 797 SHOULD also store the time at which the binding was last updated. If 798 a Path header field is present, RFC 3327 [12] requires the registrar 799 to store this information as well. If the registrar receives a re- 800 registration, it MUST update the information that uniquely identifies 801 the network flow over which the request arrived and SHOULD update the 802 time the binding was last updated. 804 The Registrar MUST include the 'outbound' option-tag in a Supported 805 header field value in its responses to REGISTER requests. The 806 Registrar MAY be configured with local policy to reject any 807 registrations that do not include the instance-id and reg-id to 808 eliminate the amplification attack described in [19]. Note that the 809 requirements in this section applies to both REGISTER requests 810 received from an Edge Proxy as well as requests received directly 811 from the UAC. 813 6.2 Forwarding Requests 815 When a proxy uses the location service to look up a registration 816 binding and then proxies a request to a particular contact, it 817 selects a contact to use normally, with a few additional rules: 819 o The proxy MUST NOT populate the target set with more than one 820 contact with the same AOR and instance-id at a time. If a request 821 for a particular AOR and instance-id fails with a 410 response, 822 the proxy SHOULD replace the failed branch with another target (if 823 one is available) with the same AOR and instance-id, but a 824 different reg-id. 825 o If two bindings have the same instance-id and reg-id, the proxy 826 SHOULD prefer the contact that was most recently updated. 828 The proxy uses normal forwarding rules looking at the Route of the 829 message and the value of any stored Path header field vector in the 830 registration binding to decide how to forward the request and 831 populate the Route header in the request. Additionally, when the 832 proxy forwards a request to a binding that contains a reg-id, the 833 proxy MUST send the request over the same network flow that was saved 834 with the binding. This means that for TCP, the request MUST be sent 835 on the same TCP socket that received the REGISTER request. For UDP, 836 the request MUST be sent from the same local IP address and port over 837 which the registration was received, to the same IP address and port 838 from which the REGISTER was received. 840 If a proxy or registrar receives information from the network that 841 indicates that no future messages will be delivered on a specific 842 flow, then the proxy MUST invalidate all the bindings that use that 843 flow (regardless of AOR). Examples of this are a TCP socket closing 844 or receiving a destination unreachable ICMP error on a UDP flow. 845 Similarly, if a proxy closes a file descriptor, it MUST invalidate 846 all the bindings with flows that use that file descriptor. 848 7. Mechanisms for All Servers (Proxys, Registars, UAS) 850 A SIP device that receives SIP messages directly from a UA needs to 851 behave as specified in this section. Such devices would generally 852 include a Registrar and an Edge Proxy, as they both receive register 853 requests directly from a UA. 855 7.1 STUN Processing 857 This document defines a new STUN usage for inband connectivity 858 checks. The only STUN messages required by this usage are Binding 859 Requests, Binding Responses, and Error Responses. The UAC sends 860 Binding Requests over the same UDP flow, TCP connection, or TLS 861 channel used for sending SIP messages, once a SIP registration has 862 been successfully processed on that flow. These Binding Requests do 863 not require any STUN attributes. The UAS responds to a valid Binding 864 Request with a Binding Response which MUST include the XOR-MAPPED- 865 ADDRESS attribute. After a successful STUN response is received over 866 TCP or TLS over TCP, the underlying TCP connection is left in the 867 active state. 869 If the server receives SIP requests on a given interface and port, it 870 MUST also provide a limited version of a STUN server on the same 871 interface and port. Specifically it MUST be capable of receiving and 872 responding to STUN Binding Requests. 874 It is easy to distinguish STUN and SIP packets because the first 875 octet of a STUN packet has a value of 0 or 1 while the first octet 876 of a SIP message is never a 0 or 1. 878 When a URI is created that refers to a SIP device that supports STUN 879 as described in this section, the 'keepalive' URI parameter, as 880 defined in Section 10 MUST be added to the URI, with a value of 881 'stun'. This allows a UA to inspect the URI to decide if it should 882 attempt to send STUN requests to this location. The 'keepalive' tag 883 typically would be present in the URI in the Route header field value 884 of a REGISTER request and not be in the Request URI. 886 8. Example Message Flow 888 The following call flow shows a basic registration and an incoming 889 call. Part way through the call, the flow to the Primary proxy is 890 lost. The BYE message for the call is rerouted to the callee via the 891 Backup proxy. When connectivity to the primary proxy is established, 892 the Callee registers again to replace the lost flow as shown in 893 message 15. 895 [-----example.com domain -------------------] 896 Caller Backup Primary Callee 897 | | | (1) REGISTER | 898 | | |<-----------------| 899 | | |(2) 200 OK | 900 | | |----------------->| 901 | | | (3) REGISTER | 902 | |<------------------------------------| 903 | |(4) 200 OK | | 904 | |------------------------------------>| 905 |(5) INVITE | | | 906 |----------------------------------->| | 907 | | |(6) INVITE | 908 | | |----------------->| 909 | | | (7) 200 OK | 910 | | |<-----------------| 911 | | (8) 200 OK | | 912 |<-----------------------------------| | 913 |(9) ACK | | | 914 |----------------------------------->| | 915 | | |(10) ACK | 916 | | |----------------->| 917 | | CRASH X | 918 |(11) BYE | | 919 |---------------->| | 920 | | (12) BYE | 921 | |------------------------------------>| 922 | | (13) 200 OK | 923 | |<------------------------------------| 924 | (14) 200 OK | | 925 |<----------------| REBOOT | | 926 | | | (15) REGISTER | 927 | | |<-----------------| 928 | | |(16) 200 OK | 929 | | |----------------->| 931 This call flow assumes that the Callee has been configured with a 932 proxy set that consists of "sip: 933 primary.example.com;lr;keepalive=stun" and "sip: 934 backup.example.com;lr;keepalive=stun". The Callee REGISTER in 935 message (1) looks like: 937 REGISTER sip:example.com SIP/2.0 938 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 939 Max-Forwards: 70 940 From: Callee ;tag=a73kszlfl 941 To: Callee 942 Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 943 CSeq: 1 REGISTER 944 Supported: path 945 Route: 946 Contact: 947 ;+sip.instance="" 948 ;reg-id=1 949 Content-Length: 0 951 In the message, note that the Route is set and the Contact header 952 field value contains the instance-id and reg-id. The response to the 953 REGISTER in message (2) would look like: 955 SIP/2.0 200 OK 956 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 957 From: Callee ;tag=a73kszlfl 958 To: Callee ;tag=b88sn 959 Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 960 CSeq: 1 REGISTER 961 Supported: outbound 962 Contact: 963 ;+sip.instance="" 964 ;reg-id=1 965 ;expires=3600 966 Content-Length: 0 968 The second registration in message 3 and 4 are similar other than the 969 Call-ID has changed, the reg-id is 2, and the route is set to the 970 backup instead of the primary. They look like: 972 REGISTER sip:example.com SIP/2.0 973 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 974 Max-Forwards: 70 975 From: Callee ;tag=a73kszlfl 976 To: Callee 977 Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1 978 CSeq: 1 REGISTER 979 Supported: path 980 Route: 981 Contact: 982 ;+sip.instance="" 983 ;reg-id=2 984 Content-Length: 0 986 SIP/2.0 200 OK 987 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 988 From: Callee ;tag=a73kszlfl 989 To: Callee ;tag=b88sn 990 Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1 991 Supported: outbound 992 CSeq: 1 REGISTER 993 Contact: 994 ;+sip.instance="" 995 ;reg-id=1 996 ;expires=3600 997 Contact: 998 ;+sip.instance="" 999 ;reg-id=2 1000 ;expires=3600 1001 Content-Length: 0 1003 The messages in the call flow are very normal. The only interesting 1004 thing to note is that the INVITE in message 6 contains the following 1005 Record-Route header field: 1007 Record-Route: 1009 Message 11 seems seams strange in that it goes to the backup instead 1010 of the primary. The Caller actually sends the message to the domain 1011 of the callee to a host (primary or backup) that is currently 1012 available. How the domain does this is an implementation detail up 1013 to the domain and not part of this specification. 1015 The registrations in message 15 and 16 are the same as message 1 and 1016 2 other than the Call-ID has changed. 1018 9. Grammar 1020 This specification defines new Contact header field parameters, 1021 reg-id and +sip.instance. The grammar includes the definitions from 1022 RFC 3261 [5] and includes the definition of uric from RFC 2396 [11]. 1023 The ABNF[8] is: 1025 contact-params = c-p-q / c-p-expires / c-p-flow / c-p-instance 1026 / contact-extension 1028 c-p-flow = "reg-id" EQUAL 1*DIGIT ; 1 to 2**31 1030 c-p-instance = "+sip.instance" EQUAL LDQUOT "<" 1031 instance-val ">" RDQUOT 1033 instance-val = *uric ; defined in RFC 2396 1035 The value of the reg-id MUST NOT be 0 and MUST be less than 2**31. 1037 10. IANA Considerations 1039 10.1 Contact Header Field 1041 This specification defines a new Contact header field parameter 1042 called reg-id in the "Header Field Parameters and Parameter Values" 1043 sub-registry as per the registry created by [13] . The required 1044 information is: 1046 Header Field Parameter Name Predefined Reference 1047 Values 1048 ____________________________________________________________________ 1049 Contact reg-id Yes [RFC AAAA] 1051 [NOTE TO RFC Editor: Please replace AAAA with 1052 the RFC number of this specification.] 1054 10.2 SIP/SIPS URI Paramters 1056 This specification arguments the "SIP/SIPS URI Parameters" sub- 1057 registry as per the registry created by [14] . The required 1058 information is: 1060 Parameter Name Predefined Values Reference 1061 ____________________________________________ 1062 keealive stun [RFC AAAA] 1064 [NOTE TO RFC Editor: Please replace AAAA with 1065 the RFC number of this specification.] 1067 10.3 SIP Option Tag 1069 This specification registers a new SIP option tag, as per the 1070 guidelines in Section 27.1 of RFC 3261. 1072 Name: outbound 1073 Description: This option-tag is used to identify Registrars which 1074 support extensions for Client Initiated Connections. A Registrar 1075 places this option-tag in a Supported header to communicate to the 1076 registering User Agent the Registrars support for this extension. 1078 10.4 Media Feature Tag 1080 This section registers a new media feature tag, per the procedures 1081 defined in RFC 2506 [1]. The tag is placed into the sip tree, which 1082 is defined in RFC 3840 [10]. 1084 Media feature tag name: sip.instance 1086 ASN.1 Identifier: New assignment by IANA. 1088 Summary of the media feature indicated by this tag: This feature tag 1089 contains a string containing a URN that indicates a unique identifier 1090 associated with the UA instance registering the Contact. 1092 Values appropriate for use with this feature tag: String. 1094 The feature tag is intended primarily for use in the following 1095 applications, protocols, services, or negotiation mechanisms: This 1096 feature tag is most useful in a communications application, for 1097 describing the capabilities of a device, such as a phone or PDA. 1099 Examples of typical use: Routing a call to a specific device. 1101 Related standards or documents: RFC XXXX 1103 [[Note to IANA: Please replace XXXX with the RFC number of this 1104 specification.]] 1106 Security Considerations: This media feature tag can be used in ways 1107 which affect application behaviors. For example, the SIP caller 1108 preferences extension [23] allows for call routing decisions to be 1109 based on the values of these parameters. Therefore, if an attacker 1110 can modify the values of this tag, they may be able to affect the 1111 behavior of applications. As a result, applications which utilize 1112 this media feature tag SHOULD provide a means for ensuring its 1113 integrity. Similarly, this feature tag should only be trusted as 1114 valid when it comes from the user or user agent described by the tag. 1115 As a result, protocols for conveying this feature tag SHOULD provide 1116 a mechanism for guaranteeing authenticity. 1118 11. Security Considerations 1120 One of the key security concerns in this work is making sure that an 1121 attacker cannot hijack the sessions of a valid user and cause all 1122 calls destined to that user to be sent to the attacker. 1124 The simple case is when there are no edge proxies. In this case, the 1125 only time an entry can be added to the routing for a given AOR is 1126 when the registration succeeds. SIP already protects against 1127 attackers being able to successfully register, and this scheme relies 1128 on that security. Some implementers have considered the idea of just 1129 saving the instance-id without relating it to the AOR with which it 1130 registered. This idea will not work because an attacker's UA can 1131 impersonate a valid user's instance-id and hijack that user's calls. 1133 The more complex case involves one or more edge proxies. When a UA 1134 sends a REGISTER request through an Edge Proxy on to the registrar, 1135 the Edge Proxy inserts a Path header field value. If the 1136 registration is successfully authenticated, the proxy stores the 1137 value of the Path header field. Later when the registrar forwards a 1138 request destined for the UA, it copies the stored value of the Path 1139 header field into the route header field of the request and forwards 1140 the request to the Edge Proxy. 1142 The only time an Edge Proxy will route over a particular flow is when 1143 it has received a route header that has the flow identifier 1144 information that it has created. An incoming request would have 1145 gotten this information from the registrar. The registrar will only 1146 save this information for a given AOR if the registration for the AOR 1147 has been successful; and the registration will only be successful if 1148 the UA can correctly authenticate. Even if an attacker has spoofed 1149 some bad information in the path header sent to the registrar, the 1150 attacker will not be able to get the registrar to accept this 1151 information for an AOR that does not belong to the attacker. The 1152 registrar will not hand out this bad information to others, and 1153 others will not be misled into contacting the attacker. 1155 12. Requirements 1157 This specification was developed to meet the following requirements: 1159 1. Must be able to detect that a UA supports these mechanisms. 1160 2. Support UAs behind NATs. 1161 3. Support TLS to a UA without a stable DNS name or IP address. 1162 4. Detect failure of connection and be able to correct for this. 1163 5. Support many UAs simultaneously rebooting. 1165 6. Support a NAT rebooting or resetting. 1166 7. Minimize initial startup load on a proxy. 1167 8. Support architectures with edge proxies. 1169 13. Changes 1171 Note to RFC Editor: Please remove this whole section. 1173 13.1 Changes from 02 Version 1175 Removed Double CRLF Keepalive 1177 Changed ;sip-stun syntax to ;keepalive=stun 1179 Fixed incorrect text about TCP keepalives. 1181 13.2 Changes from 01 Version 1183 Moved definition of instance-id from GRUU[17] draft to this draft. 1185 Added tentative text about Double CRLF Keep Alive 1187 Removed pin-route stuff 1189 Changed the name of "flow-id" to "reg-id" 1191 Reorganized document flow 1193 Described the use of STUN as a proper STUN usage 1195 Added 'outbound' option-tag to detect if registrar supports outbound 1197 13.3 Changes from 00 Version 1199 Moved TCP keep alive to be STUN. 1201 Allowed SUBSCRIBE to create flow mappings. Added pin-route option 1202 tags to support this. 1204 Added text about updating dialog state on each usage after a 1205 connection failure. 1207 14. Acknowledgments 1209 Jonathan Rosenberg provided many comments and useful text. Dave Oran 1210 came up with the idea of using the most recent registration first in 1211 the proxy. Alan Hawrylyshen co-authored the draft that formed the 1212 initial text of this specification. Additionally, many of the 1213 concepts here originated at a connection reuse meeting at IETF 60 1214 that included the authors, Jon Peterson, Jonathan Rosenberg, Alan 1215 Hawrylyshen, and Paul Kyzivat. The TCP design team consisting of 1216 Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and 1217 Ganesh Jayadevan provided input and text. Nils Ohlmeier provided 1218 many fixes and initial implementation experience. In addition, 1219 thanks to the following folks for useful comments: Francois Audet, 1220 Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, and 1221 Lyndsay Campbell. 1223 15. References 1225 15.1 Normative References 1227 [1] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1228 Registration Procedure", BCP 31, RFC 2506, March 1999. 1230 [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1231 Preferences for the Session Initiation Protocol (SIP)", 1232 RFC 3841, August 2004. 1234 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 1236 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1237 Levels", BCP 14, RFC 2119, March 1997. 1239 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1240 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1241 Session Initiation Protocol", RFC 3261, June 2002. 1243 [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1244 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1246 [7] Rosenberg, J., "Simple Traversal of UDP Through Network Address 1247 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 1248 (work in progress), July 2005. 1250 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1251 Specifications: ABNF", RFC 2234, November 1997. 1253 [9] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 1254 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1256 [10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1257 User Agent Capabilities in the Session Initiation Protocol 1258 (SIP)", RFC 3840, August 2004. 1260 [11] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1261 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1262 August 1998. 1264 [12] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1265 Extension Header Field for Registering Non-Adjacent Contacts", 1266 RFC 3327, December 2002. 1268 [13] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1269 Header Field Parameter Registry for the Session Initiation 1270 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1272 [14] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1273 Uniform Resource Identifier (URI) Parameter Registry for the 1274 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 1275 December 2004. 1277 15.2 Informative References 1279 [15] Hakala, J., "Using National Bibliography Numbers as Uniform 1280 Resource Names", RFC 3188, October 2001. 1282 [16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1283 for Message Authentication", RFC 2104, February 1997. 1285 [17] Rosenberg, J., "Obtaining and Using Globally Routable User 1286 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1287 (SIP)", draft-ietf-sip-gruu-04 (work in progress), July 2005. 1289 [18] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1290 RFC 3548, July 2003. 1292 [19] Lawrence, S., Hawrylyshen, A., and R. Sparks, "Problems with 1293 Max-Forwards Processing (and Potential Solutions)", 1294 October 2005. 1296 [20] Rosenberg, J., "Clarifying Construction of the Route Header 1297 Field in the Session Initiation Protocol (SIP)", 1298 draft-rosenberg-sip-route-construct-00 (work in progress), 1299 July 2005. 1301 [21] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1302 Extension Header Field for Service Route Discovery During 1303 Registration", RFC 3608, October 2003. 1305 Authors' Addresses 1307 Cullen Jennings (editor) 1308 Cisco Systems 1309 170 West Tasman Drive 1310 Mailstop SJC-21/2 1311 San Jose, CA 95134 1312 USA 1314 Phone: +1 408 902-3341 1315 Email: fluffy@cisco.com 1317 Rohan Mahy (editor) 1318 Plantronics 1319 345 Encincal St 1320 Santa Cruz, CA 95060 1321 USA 1323 Email: rohan@ekabal.com 1325 Intellectual Property Statement 1327 The IETF takes no position regarding the validity or scope of any 1328 Intellectual Property Rights or other rights that might be claimed to 1329 pertain to the implementation or use of the technology described in 1330 this document or the extent to which any license under such rights 1331 might or might not be available; nor does it represent that it has 1332 made any independent effort to identify any such rights. Information 1333 on the procedures with respect to rights in RFC documents can be 1334 found in BCP 78 and BCP 79. 1336 Copies of IPR disclosures made to the IETF Secretariat and any 1337 assurances of licenses to be made available, or the result of an 1338 attempt made to obtain a general license or permission for the use of 1339 such proprietary rights by implementers or users of this 1340 specification can be obtained from the IETF on-line IPR repository at 1341 http://www.ietf.org/ipr. 1343 The IETF invites any interested party to bring to its attention any 1344 copyrights, patents or patent applications, or other proprietary 1345 rights that may cover technology that may be required to implement 1346 this standard. Please address the information to the IETF at 1347 ietf-ipr@ietf.org. 1349 Disclaimer of Validity 1351 This document and the information contained herein are provided on an 1352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1354 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1355 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1356 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1359 Copyright Statement 1361 Copyright (C) The Internet Society (2006). This document is subject 1362 to the rights, licenses and restrictions contained in BCP 78, and 1363 except as set forth therein, the authors retain all their rights. 1365 Acknowledgment 1367 Funding for the RFC Editor function is currently provided by the 1368 Internet Society.