idnits 2.17.1 draft-jennings-sipping-outbound-01.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 727. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: User Agents that form flows with stream oriented protocols such as TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection to detect liveness of the flow. It is RECOMMENDED that a CRLF be sent if the flow has not had any data sent or received in the previous 600 seconds. The UA SHOULD not send a CRLF if data has been sent or received in the previous 30 seconds. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2005) is 6999 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 663, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 680, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3489 (ref. '4') (Obsoleted by RFC 5389) == Outdated reference: A later version (-05) exists of draft-mealling-uuid-urn-03 ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-02 == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-02 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG C. Jennings, Ed. 3 Internet-Draft Cisco Systems 4 Expires: August 20, 2005 A. Hawrylyshen 5 Jasomi Networks 6 February 19, 2005 8 SIP Conventions for UAs with Outbound Only Connections 9 draft-jennings-sipping-outbound-01 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 20, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 Often with SIP a request can only be routed over an existing 45 connection or flow, such as when there is a firewall or network 46 address translation (NAT) device in the network path. TLS is also 47 affected when the user agent (UA) does not have a certificate 48 suitable for mutual TLS authentication. This draft addresses how 49 user agents and proxies need to behave to work in these environments. 51 This work shows how existing SIP mechanisms can be used to allow the 52 UA to register multiple times over different connections or flows and 53 the proxies can use the instance-id in the contact header to identify 54 that the multiple flows go to the same UA. It can then choose which 55 flow to use to route requests to this UA. 57 This work is being discussed on the sipping@ietf.org mailing list. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 64 3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1 Single Registrar and UA . . . . . . . . . . . . . . . . . 5 67 4.2 Multiple Connections from a User Agent . . . . . . . . . . 7 68 4.3 Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1 User Agent . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.2 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.3 Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.4 Receivers of REGISTER Requests . . . . . . . . . . . . . . 12 74 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 9. Changes from 00 Version . . . . . . . . . . . . . . . . . . . 14 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 81 11.2 Informative References . . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . . 17 85 1. Introduction 87 There are many environments for SIP deployments in which the 88 user-agent (UA) can form a connection to the Registrar or Proxy but 89 in which the connections in the reverse sense are not possible. This 90 can happen for several reasons. It is important to understand that 91 most IP phones and and soft-phones get their network configurations 92 via a host-configuration protocol such as DHCP; they typically do not 93 have a useful name in DNS; and they definitely do not have a 94 long-term, stable DNS name that is appropriate for binding to a 95 certificate. It is impractical for them to have a certificate that 96 can be used as a client-side TLS certificate. However, they do 97 support TLS and form TLS connections to a proxy or registrar which 98 the UA authenticates using TLS, and the server authenticates the UA 99 using a digest challenge. 101 Sometimes a firewall device between the UA and proxy or registrar 102 will only allow connections in the "outbound" direction. Similarly 103 there may be a NAT that is only capable of allowing connections in 104 the "outbound" direction. It is worth noting that most UAs in the 105 world are deployed behind a firewall or NAT. 107 This document describes several concepts that are used to solve this 108 problem using a key idea from the connection reuse draft [10]: A 109 proxy that wishes to route a request to a particular AOR, say 110 alice@example.com, may use any connection to Alice's UA which has 111 been previously authenticated at an appropriate level to allow it to 112 change the registration bindings for Alice. 114 Secondly, for high reliability systems, the UA needs to keep a 115 connection to the proxy or registrar that it can use at any time. 116 This is achieved by having the UA keep multiple connections, referred 117 to as "flows", to the proxy or registrar and using a keep alive 118 mechanism on each flow so that the UA can detect when it has failed 119 and establish a new one. 121 The overall approach can be summarized simply: UAs use a keep alive 122 mechanism to keep their flow to the proxy or registrar alive. For 123 TCP, TLS, and other connection oriented protocols this is a burst 124 containing a CRLF payload, and for UDP it is a STUN request over the 125 flow. A UA can create more than one flow using multiple 126 registrations for the same contact and AOR. The instance in the 127 contact is used to identify the UA that a connection is associated 128 with. A new contact parameter called flow-id is used to allow the 129 proxy and registrar to tell the difference between a UA 130 re-registering and registering an additional connection. The proxies 131 keep track of the "flows" or connection mappings for successful 132 registrations. 134 When a proxy goes to route a message to a UA for which it has a 135 mapping, it can use any one of the flows on which a successful 136 registration has been completed for that contact. A failure on a 137 particular flow can be tried again on an alternate flow. 139 2. Requirements 141 Must be able to detect that a UA supports these mechanisms. 143 Support UAs behind NATs. 145 Support UAs behind firewalls. 147 Support TLS to a UA without stable DNS name or IP. 149 Detect failure of connection and be able to correct for this. 151 Support many UAs simultaneously rebooting. 153 Support a NAT rebooting or resetting. 155 Support proxy farms with multiple hosts for scaling and reliability 156 purposes. 158 Minimize initial startup load on a proxy. 160 3. Conventions & Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [1]. 166 3.1 Definitions 167 'Edge Proxy': An Edge Proxy is any proxy that is located 168 topologically between the registering user agent and the 169 registrar. 170 'Flow': A Flow is a network protocol level connection between two 171 endpoints that is represented by the network address of both ends 172 and the protocol. For TCP and UDP this would include the IP 173 addresses and ports of both ends and the protocol (TCP or UDP). 174 With TCP, a flow would often correspond with a single file 175 descriptor in the OS. 176 'Outbound Connection': An Outbound Connection is a connection 177 between two network elements that can only be established by one 178 party. Typically this is due to network policy from a firewall or 179 NAT device or to issues with TLS where one end does not have a 180 certificate that can be used as a server certificate so cannot act 181 as a TLS server. 183 'Third party registration ': A third party registration is defined 184 in section 10.2 of RFC 3261. It is a REGISTER request in which 185 the value of the To header field is not the same as that of the 186 From header field. 188 4. Overview 190 Several scenarios in which this technique is useful are discussed 191 below, including the simple collocated registrar and proxy, a user 192 agent desiring multiple connections to a resource (for redundancy for 193 example), and an system that uses Edge Proxies. This section 194 explains the details of the approach while section (Section 5) has 195 the exact details of how various elements handle messages. 197 4.1 Single Registrar and UA 199 The network's topology in this example is that there is single server 200 acting as a registrar and proxy, with which the user agent registers. 202 +---------+ 203 |Registrar| 204 |Proxy | 205 +----+----+ 206 | 207 | 208 +---+--+ 209 |User | 210 |Agent | 211 +------+ 213 User Agents forming only a single connection continue to register in 214 the normal way but include the instance identifier as described in 215 the GRUU [8] and can also add a flow-id parameter to the Contact 216 header field value. The flow-id parameters are used to allow the 217 registrar to detect and avoid using invalid contacts when a UA 218 reboots, as described later in this section. 220 For clarity, here is an example. Alice's UA creates a new TCP flow 221 to the registrar and sends the following register. 223 REGISTER sip:example.com SIP/2.0 224 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK-bad0ce 225 Max-Forwards: 70 226 From: Bob ;tag=d879h76 227 To: Bob 228 Call-ID: 8921348ju72je840.204 229 CSeq: 1 REGISTER 230 Contact: ; flow-id=1; 231 ;+sip.instance="" 232 Content-Length: 0 234 The registrar would, as usual, challenge this registration to 235 authenticate the sender. When the registrar adds an entry for this 236 contact under the AOR for Bob, the registrar also needs to form a 237 sublist under this contact that keeps track of the flow that received 238 this registration and the flow-id value. 240 Later when Alice sends a request to Bob at the registrar, it acts as 241 a proxy and follows [2] to select a contact to forward the request 242 to. The proxy then looks and finds the flows that have registrations 243 to this contact. It forwards the request on that flow instead of 244 trying to form a new flow to that contact. This allows the proxy to 245 forward a request to a particular contact down the same flow that did 246 the registration for this AOR. If the proxy had multiple flows that 247 all went to this contact, it could choose any one of them that had 248 registered for this AOR and had the same instance value as the 249 selected contact. In general, if two flows have the same flow-id 250 value, the proxy would favor the most recently registered flow. This 251 is so that if a UA reboots, the proxy will prefer to use the most 252 recent flow that goes to this UA instead of trying one of the old 253 flows which will presumably fail. 255 The keep alive mechanism needs to detect both failure of a connection 256 and changes to the NAT public mapping. When a residential NAT is 257 rebooted, the UA needs to understand that its bindings are no longer 258 valid and it needs to reregister. Simply sending keep alive packets 259 will not detect this failure when using UDP. With connection 260 oriented transports such as TCP or TLS, the keep alive will detect 261 failure after a NAT reboot. Connection oriented transport failures 262 are detected as the UA periodically sends a CRLF over the connection; 263 if the connection has failed, a connection level error will be 264 reported to the UA. A CRLF can be considered the beginning of the 265 next message that will be sent and therefore this approach is 266 backwards compatible with existing standards. The TCP KEEP_ALIVE 267 mechanism is not used because many operating systems do not allow 268 this to be set on a per connection basis. 270 The keep alive mechanism for UDP is quite different. The UA needs to 271 detect when the connection is working but also when the flow 272 definition has changed. A flow definition could change because a NAT 273 device in the network path reboots and the resulting pubic address 274 mapping for the UA changes. STUN [4] requests are sent over the 275 connection that is being used for the UDP SIP traffic. The proxy or 276 registrar acts as a STUN server on the SIP signaling port. 278 The STUN mechanism is very robust and allows the detection of a 279 changed IP address. It may also be possible to do this with OPTIONS 280 messages and rport; although this approach has the advantage of being 281 backwards compatible, it also significantly increases the load on the 282 proxy or registrar server. 284 If the UA detects that the connection has failed or that the flow 285 definition has changed, it will re-register using a back-off 286 mechanism described in Section 5.1 in order to provide congestion 287 relief when a large number of agents simultaneously reboot. 289 The registrar saves the instance id (as defined in GRUU [8]) and 290 flow-id (as defined in Section 6) along with the rest of the contact 291 Header. If the instance id and flow-id are the same as a previous 292 registration, the proxy or registrar can decide to fork requests to 293 these contacts' registrations in serial and to choose to use the most 294 recently created registration first. This allows a UA that has 295 rebooted to replace its previous registration for each flow with 296 minimal impact on overall system load. 298 If the TCP flow to the registrar is closed, any map entries referring 299 to that flow must be removed. Similarly, if the registration 300 expires, any map entries created by it need to be removed. 302 A note about the UUID: a device like a soft-phone, when first 303 installed, should generate a UUID [6] and then save this in 304 persistent storage for all future use. For a device such as a hard 305 phone, which will only ever have a single SIP UA present, the UUID 306 can be generated at any time because it is guaranteed that no other 307 UUID is being generated at the same time on that physical device. 308 This means the value of the time component of the UUID can be 309 arbitrarily selected to be any time less than the time when the 310 device was manufactured. A time of 0 (as shown in the example) is 311 perfectly legal as long as the device knows no other UUIDs were 312 generated at this time. 314 4.2 Multiple Connections from a User Agent 316 In this example system, the logical proxy/registrar for the domain is 317 running on two hosts that share appropriate state and can both 318 provide registrar and proxy functionality for the domain. The UA 319 will form connections to two of the physical hosts for the domain. 321 +-------------------+ 322 | Domain | 323 | Logical Proxy/Reg | 324 | | 325 |+-----+ +-----+| 326 ||Host1| |Host2|| 327 |+-----+ +-----+| 328 +---\------------/--+ 329 \ / 330 \ / 331 \ / 332 \ / 333 +------+ 334 |User | 335 |Agent | 336 +------+ 338 A UA that forms two or more flows has similar behavior to a UA that 339 forms a single connection but has some additional requirements. The 340 UA MAY be configured with a primary and backup outbound proxy or it 341 MAY select two flows to form using the DNS selection mechanism 342 described in this section. The registration on each flow needs to 343 contain the instance identifier from the GRUU mechanisms and also 344 needs to add a different flow-id parameter to the Contact header so 345 that the Registrar can differentiate the flows as being distinct 346 connections from the same instance. For example, the flow-id value 347 might be set to 1 for the primary connection and 2 for the backup 348 connection. 350 A UA that needs to establish multiple flows needs a way to use DNS to 351 select candidate addresses for the formation of flows. The 352 recommended way to do this is to look at the DNS records resulting 353 from the algorithm described in RFC 3263 [3] and select distinct 354 addresses from the target set. 356 Hosts that are multi-homed can avoid complications by ensuring that 357 interfaces that are in separate routing domains have distinct DNS 358 names for each routing domain. Having different SRV records point to 359 the same host record should also be avoided when deploying proxies. 360 Multiple interfaces in a single network should either be absent from 361 DNS or preferably share an address. These guidelines will help 362 prevent a UA from establishing flows that connect to the same 363 resource and thereby unintentionally eliminating the desired 364 redundancy. 366 When a proxy goes to route a call to a particular contact, it can use 367 the flow for any registration to that contact that has the same 368 instance value of the selected contact. If it detects that a flow 369 has failed, it needs to remove that mapping and use the others. 371 4.3 Edge Proxies 373 Some SIP deployments use edge proxies such that the UA sends the 374 REGISTER to an edge proxy that then forwards the REGISTER to the 375 Registrar. The edge proxy can include a path header as defined in 376 RFC 3327 [9] so that when the registrar later retargets a request to 377 this UA, the request is routed through the edge proxy. 379 +---------+ 380 |Registrar| 381 |Proxy | 382 +---------+ 383 / \ 384 / \ 385 +-----+ +-----+ 386 |Edge1| |Edge2| 387 +-----+ +-----+ 388 \ / 389 \ / 390 \ / 391 \ / 392 \ / 393 +------+ 394 |User | 395 |Agent | 396 +------+ 398 These systems can use effectively the same mechanism as described in 399 the previous sections but need to use the Path header. When the edge 400 proxy receives a registration, it needs to create an identifier value 401 that is unique to this AOR, contact, flow, and instance-id and put 402 this identifier in the path header. This is done by putting the 403 value in the user portion of a loose route in the path header. If 404 the registration succeeds, the edge proxy needs to map future 405 requests that are routed to the identifier value that was put in the 406 path header to the associated flow. The edge proxy needs to ensure 407 that a 200 response to a register request represents a successful 408 registration and not some spoofed traffic to the edge proxy. One way 409 this can be done is by ensuring that it only pays attention to 410 responses received over a TLS connection from a proxy that is 411 authoritative for the domain of the registration. 413 As an alternative to actually storing the state for the mapping in 414 the edge proxy, the proxy can form an encrypted version of the flow 415 identifier and put it in the path header so that the edge proxy will 416 get it back from the registrar at the time it needs it. 418 5. Mechanisms 420 5.1 User Agent 422 User Agents MUST support the the instance identifier as described in 423 the GRUU [8] mechanism. If the UA detects that the binding on a NAT 424 has changed, it MUST treat this as a connection failure and 425 re-register. When registration fails due to a network problem or the 426 Registrar does not respond, the UA maintains a range value for 427 computing when it should next attempt to register. This range value 428 SHOULD have an initial value of 1 minute and SHOULD double after each 429 consecutive failed registration attempt, up to a maximum of 30 430 minutes. When a registration fails due to network problems, the UA 431 MUST randomly select a time to re-register that is between 50 and 100 432 percent of the current range value. 434 User Agents that form two or more connections behave similarly to 435 User Agents that form single connections but also have some 436 additional requirements. All User Agents SHOULD support forming 437 multiple connections. The UA MAY be configured with a primary and 438 backup outbound proxy. It MUST support selecting at least two 439 connections using the mechanism described in Location of SIP Servers 440 [3]. When DNS is used, the UA finds IP addresses used for 441 registration the normal way, but if it discovers more than one 442 possible IP address, it SHOULD connect to two distinct addresses, 443 among the possible IP addresses. If the UA finds multiple records 444 that correspond to different A or AAAA records, it SHOULD select 445 address corresponding to different A or AAAA records. 447 Each connection MUST contain the instance identifier from the GRUU 448 mechanisms but MUST also add a distinct flow-id parameter to the 449 contact header field value so that the Registrar can differentiate 450 the two connections as being from the same instance but different 451 connections. The flow-id MAY be set to 1 for the primary connection 452 and 2 for the backup connection. Each time the UA is rebooted, it 453 SHOULD use the same flow-id values it previously used. 455 On connection oriented transports such as TCP or TLS, if no other 456 traffic has been sent for 600 seconds, then the UA MUST send a CRLF 457 to detect whether the connection has failed. On UDP connections, the 458 UA MUST send a STUN [4] request every 30 seconds over the same flow 459 as the SIP signaling. If the UA detects that the flow has changed, 460 it MUST reregister. 462 The text in this section does not apply to third party registration. 464 A UA doing third party registration would proceed as described in RFC 465 3261. 467 User Agents that form flows with stream oriented protocols such as 468 TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection 469 to detect liveness of the flow. It is RECOMMENDED that a CRLF be 470 sent if the flow has not had any data sent or received in the 471 previous 600 seconds. The UA SHOULD not send a CRLF if data has been 472 sent or received in the previous 30 seconds. 474 User Agents that form flows with UDP SHOULD perform STUN requests 475 over the flow every 30 seconds. If the mapped address in the STUN 476 response changes, the UA must treat this as a transport error on the 477 flow. This will cause the UA to form a new registration on a new 478 flow. 480 5.2 Registrar 482 The registrar MUST check if the registration is a 3rd party 483 registration. If so it would process it normally and none of the 484 other text in this section would apply. 486 When a registrar receives a registration that does not contain a path 487 header, it processes the registration as normal; and if the 488 registration is successful, the registrar MUST store the flow-id, 489 instance value and reference to the flow to a list that is maintained 490 for this particular AOR and contact. The reference to flow is the 491 information it needs to send a message back to the UA over this same 492 flow. Typically it would be something like the file descriptor for 493 TCP or the full source and destination addresses and ports for UDP. 495 This document does not require a registrar to support the path 496 header, but if registrar does there is some special processing based 497 on the path header. Specifically, when a registrar that supports 498 path receives a registration that contains a path header, the 499 registrar still stores the instance value and flow id but does not 500 save the reference information to the flow. 502 When the registrar, acting as a proxy, proxies a request to a 503 particular contact, it selects a contact to use in the normal way. 504 Next the registrar selects a flow to reach this contact. It forms 505 the list of possible flows by looking at the contacts registered for 506 this AOR and selecting the ones that have the same instance value. 507 The registrar MAY decide, when two flows have the same flow-id, to 508 choose the one that registered most recently. Once a flow is 509 selected, the registrar needs to forward to that flow. If a path 510 header was used for the registration of that flow, the registrar 511 populates the request in the normal way and forwards it. If there 512 was no path header, then the registrar looks at the flow reference 513 information for that flow and forwards the request over the same flow 514 that was used to receive the registration. 516 If the registrar receives a transport level error using this flow, it 517 must remove the flow and any associated registration information. 519 5.3 Edge Proxy 521 When an edge proxy receives a registration request that does not 522 contain a path header, it MUST form a registration identifier that is 523 unique to this flow and then include that identifier in the path 524 header it adds to the registration. This is done by inserting the 525 unique identifier in the user portion of the path header URI for this 526 edge proxy. 528 If the edge proxy receives a request that is routed to a registration 529 identifier that it has created, then it MUST forward the request on 530 the flow that created the registration. This can be implemented 531 either by storing the mapping from the unique identifier to the flow 532 when the identifier is created or, if the edge proxy does not wish to 533 save this state information, it can take the flow reference 534 information and encrypt it with a secret known only to the edge proxy 535 and put it in the user portion of the path header. Later when the 536 edge proxy receives a request, it can decrypt this information and 537 use it to route the request over the correct flow. 539 The edge proxy MUST ensure that data sent from the edge proxy to the 540 registrar or other edge proxies is integrity protected against 541 attackers. This could be achieved by using TLS between the edge 542 proxy and the registrar. 544 5.4 Receivers of REGISTER Requests 546 A device that receives register requests directly from a UA needs to 547 behave as specified in this section. Such devices would generally 548 include a Registrar and and an Edge Proxy, as they both receive 549 register requests directly from a UA. 551 If the server receives UDP SIP requests on a given interface and 552 port, it MUST also provide a limited version of the STUN server on 553 the same interface and port. Specifically it MUST support all of 554 STUN with the exception that it does not need to support STUN 555 requests with the changed port or changed address flag set. This 556 allows the STUN server to run with only one port and IP address. 558 It is easy to demux STUN and SIP packets because the first byte of a 559 STUN packet is 0 or 1 while the first byte of a SIP packet is in the 560 range of 'A' to 'Z'. 562 6. Grammar 564 This specification defines a new Contact header field parameter, 565 flow-id. The grammar for pvalue and EQUAL is obtained from RFC 3261 566 [2]. 568 contact-params = c-p-q / c-p-expires / contact-extension 569 c-p-connection 570 c-p-connection = "flow-id" EQUAL pvalue 571 ; defined in RFC3261 573 7. IANA 575 This specification defines a new Contact header field parameter 576 called flow-id, as per the registry created by [5]. The required 577 information is as follows: 579 Header field in which the parameter can appear: Contact 581 Name of the Parameter: flow-id 583 RFC Reference: RFC AAAA [NOTE TO IANA: Please replace AAAA with 584 the RFC number of this specification.] 586 8. Security Considerations 588 One of the key security concerns in this work is making sure that an 589 attacker cannot hijack the sessions of a valid user and cause all 590 calls destined to that user to be sent to the attacker. 592 The simple case is when there are no edge proxies. In this case, the 593 only time an entry can be added to the routing for a given AOR is 594 when the registration succeeds. SIP protects against attackers being 595 able to successfully register, and this scheme relies on that 596 security. Some implementers have considered the idea of just saving 597 the instance without relating it to the AOR with which it registered. 598 This idea will not work because an attacker's UA can impersonate a 599 valid user's instance value and hijack that user's calls. 601 The more complex case involves one or more edge proxies. The only 602 time an edge proxy will route over a particular flow is when it has 603 received a route header that has the instance information it has 604 created. An incoming request would have gotten this information from 605 the registrar. The registrar will only save this information for a 606 given AOR if the registration for the AOR has been successful; and 607 the registration will only be successful if the UA can correctly 608 authenticate. Even if an attacker has spoofed some bad information 609 in the path header sent to the registrar, the attacker will not be 610 able to get the registrar to accept this information for an AOR that 611 does not belong to the attacker. The registrar will not hand out 612 this bad information to others, and others would not be misled into 613 contacting the attacker. 615 9. Changes from 00 Version 617 Changed the behavior of the proxy so that it does not automatically 618 remove registrations with the same instance and flow-id but instead 619 just uses the most recently created registration first. 621 Changed the connection-id to flow-id. 623 Fixed expiry of edge proxies and rewrote mechanism section to be 624 clearer. 626 10. Acknowledgments 628 Rohan Mahy had the insight key to this draft, that registration can 629 be used to authorize connection reuses. Dave Oran came up with the 630 idea of using the most recent registration first in the proxy. The 631 TCP design team consisting of Chris Boulton, Scott Lawrence, Rajnish 632 Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input. 633 Additionally, many of the concepts here originated at a connection 634 reuse meeting at IETF 60 that included Jon Peterson, Jonathan 635 Rosenberg, Paul Kyzivat and Rohan Mahy. 637 11. References 639 11.1 Normative References 641 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 642 Levels", BCP 14, RFC 2119, March 1997. 644 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 645 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 646 Session Initiation Protocol", RFC 3261, June 2002. 648 [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 649 (SIP): Locating SIP Servers", RFC 3263, June 2002. 651 [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 652 Simple Traversal of User Datagram Protocol (UDP) Through Network 653 Address Translators (NATs)", RFC 3489, March 2003. 655 [5] Camarillo, G., "The Internet Assigned Number Authority (IANA) 656 Header Field Parameter Registry for the Session Initiation 657 Protocol (SIP)", draft-ietf-sip-parameter-registry-02 (work in 658 progress), June 2004. 660 [6] Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03 661 (work in progress), March 2004. 663 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 664 Specifications: ABNF", RFC 2234, November 1997. 666 [8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 667 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 668 draft-ietf-sip-gruu-02 (work in progress), July 2004. 670 [9] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 671 Extension Header Field for Registering Non-Adjacent Contacts", 672 RFC 3327, December 2002. 674 11.2 Informative References 676 [10] Mahy, R., "Connection Reuse in the Session Initiation Protocol 677 (SIP)", draft-ietf-sip-connect-reuse-02 (work in progress), 678 July 2004. 680 [11] Mahy, R., "Requirements for Connection Reuse in the Session 681 Initiation Protocol (SIP)", 682 draft-ietf-sipping-connect-reuse-reqs-00 (work in progress), 683 October 2002. 685 Authors' Addresses 687 Cullen Jennings (editor) 688 Cisco Systems 689 170 West Tasman Drive 690 Mailstop SJC-21/2 691 San Jose, CA 95134 692 USA 694 Phone: +1 408 902-3341 695 EMail: fluffy@cisco.com 696 Alan Hawrylyshen 697 Jasomi Networks 698 310, 602 - 11 Ave SW 699 Calgary, Alberta T2R 1J8 700 Canada 702 Phone: +1 866 617 8647 703 EMail: alan@jasomi.com 705 Intellectual Property Statement 707 The IETF takes no position regarding the validity or scope of any 708 Intellectual Property Rights or other rights that might be claimed to 709 pertain to the implementation or use of the technology described in 710 this document or the extent to which any license under such rights 711 might or might not be available; nor does it represent that it has 712 made any independent effort to identify any such rights. Information 713 on the procedures with respect to rights in RFC documents can be 714 found in BCP 78 and BCP 79. 716 Copies of IPR disclosures made to the IETF Secretariat and any 717 assurances of licenses to be made available, or the result of an 718 attempt made to obtain a general license or permission for the use of 719 such proprietary rights by implementers or users of this 720 specification can be obtained from the IETF on-line IPR repository at 721 http://www.ietf.org/ipr. 723 The IETF invites any interested party to bring to its attention any 724 copyrights, patents or patent applications, or other proprietary 725 rights that may cover technology that may be required to implement 726 this standard. Please address the information to the IETF at 727 ietf-ipr@ietf.org. 729 Disclaimer of Validity 731 This document and the information contained herein are provided on an 732 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 733 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 734 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 735 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 736 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 737 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 739 Copyright Statement 741 Copyright (C) The Internet Society (2005). This document is subject 742 to the rights, licenses and restrictions contained in BCP 78, and 743 except as set forth therein, the authors retain all their rights. 745 Acknowledgment 747 Funding for the RFC Editor function is currently provided by the 748 Internet Society.