idnits 2.17.00 (12 Aug 2021) /tmp/idnits5131/draft-spbs-sip-negotiate-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 6 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 236: '...NEGOTIATE request it MUST send a final...' RFC 2119 keyword, line 239: '... 200 OK response MUST be sent by a UAS...' RFC 2119 keyword, line 240: '...sful. The 200 OK MUST carry the key se...' RFC 2119 keyword, line 334: '...ating keys, implementations SHOULD use...' RFC 2119 keyword, line 399: '... a minimum these two MUST be readable....' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 249 has weird spacing: '...r field whe...' == Line 339 has weird spacing: '...pped of all...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2002) is 7219 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: '0000 00XY' on line 478 == Unused Reference: '2' is defined on line 909, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 914, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Duplicate reference: RFC2543, mentioned in '2', was also mentioned in '1'. ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: draft-ietf-sip-session-timer has been published as RFC 4028 -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sriram Parameswar 2 Internet Draft Brian Stucker 3 Nortel Networks 4 March 2002 5 Expires August 2002 6 8 The SIP Negotiate Method 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or cite them other than as "work in 24 progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This document is an individual submission to the IETF. Comments 33 should be directed to the authors. 35 Abstract 36 There is a need to negotiate a multitude of parameters, settings, 37 and algorithms when setting up sessions using Session Initiated 38 Protocol (SIP). While SIP itself provides mechanisms for 39 negotiation of these parameters on a per-session basis through the 40 use of the INVITE method, it does not provide a ready mechanism 41 for meta-session negotiation. The closest mechanism provided is 42 the REGISTER method, however, this method is directed towards the 43 registrar alone, and cannot be used to conduct negotiation of 44 parameters between any two arbitrary SIP nodes. 46 Examples of parameters that may need to be negotiated (and thus, 47 the ready impetus for providing a simple mechanism to handle this) 48 include: compression algorithms, code book size, message integrity 49 mechanisms, encryption algorithms, etc. Many of these parameters 50 are not always eligible for use in an INVITE method, for two 51 reasons: 53 - The INVITE method describes the parameters for initiation of 54 a particular session. Once the session is over, the negotiated 55 settings (such as the RTP profile used, in the case of SDP) 56 are invalidated for future re-use. It would be inefficient to 57 have to renegotiate parameters that are the same from session 58 to session, or have to transmit large quantities of 59 persistent data (such as a code book) each time. 61 - Many meta-session applications (and therefore their attendant 62 negotiable parameters) are best utilized if they can be 63 applied for the first message of a session. 64 An example of this would be header compression. If the INVITE 65 were compressed, then the header that identifies the type of 66 compression in use would also be compressed, and therefore 67 unintelligible (assuming no shim mechanism). 69 This document seeks to solve these problems by introducing a SIP 70 extension that allows for meta-session parameters to be negotiated 71 in a generic manner. This negotiation would take place prior to 72 session establishment, between any two SIP entities 73 (User Agents, Proxies etc.). 75 1 Terminology 77 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 78 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 79 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] 80 and indicate requirement levels for compliant SIP guidelines 82 2 Introduction 84 SIP sets up multimedia sessions between User Agents. Given the 85 complexity of these sessions, and the variety of User Agents and 86 their capabilities, there are several session parameters that need 87 to be pre-defined or negotiated prior to establishing these 88 sessions. 90 There is a real need to have a generic mechanism that will help 91 negotiate these parameters a-priori. The initial goal was to 92 establish a generic approach to negotiation, which would be 93 applicable across all protocols used in the Internet world. Given 94 the difficulty in coming up with a sufficiently generic approach 95 that would be acceptable, the authors decided to attack a more 96 immediate problem in the SIP arena and establish a generic 97 negotiation mechanism. 99 This draft does not describe an extension which may be used 100 directly; it must be extended by other drafts by defining 101 payloads (preferably XML based) to perform the actual negotiation. 103 The result of the negotiation is a key that will be used in 104 subsequent transactions to maintain negotiation state. This key is 105 carried either as a shim i.e. between the transport and 106 application layers (SIP and UDP for example) or as a SIP header 107 (Key) in further SIP messages. 109 This new method may be used in both end-to-end and hop-by-hop 110 scenarios. 112 2.1. Overview of Operation 114 In general the network entity that needs to negotiate meta-session 115 parameters sends a NEGOTIATE with the payload indicating the 116 offered parameters/algorithms. 117 The NEGOTIATE follows the offer-answer model as described in 118 [4], the entity that offers the parameters must be willing and 119 able to support all parameters in the offer. 120 The offer is placed in a NEGOTIATE payload. The offer may be 121 accepted or rejected, in case the offer is accepted the answer 122 is returned in the payload of a 200 OK. In case of a rejection a 123 488 or 606 is returned. 125 UAC UAS 126 |-----NEGOTIATE---->| Make an offer on one or more session 127 | | parameters. Negotiate carries Key. 128 | | 129 |<-------200--------| Accept offer and key. Key used to 130 | | maintain negotiation state. 131 | | 132 |---INVITE(etc.)--->| Session establishment with 133 | | negotiated parameters and key. 135 Negotiations expire and must be refreshed in exactly the same 136 manner as registrations (see RFC 2543 [1] ). 138 3.0 NEGOTIATE Method 140 "NEGOTIATE" is added to the definition of the element "Method" in 141 the SIP message grammar. 143 The NEGOTIATE method is used to set up session parameters and 144 algorithms prior to session establishment. 146 As with other methods the NEGOTIATE method name is case sensitive. 148 This document specifies the named extension 'negotiate'. 150 This feature name is placed in the Proxy-Require, Require, or 151 Supported header in requests; and the Require, Supported, or 152 Unsupported header in responses. 154 Header Where NEGOTIATE 155 ------ ----- --------- 156 Accept R o 157 Accept 2xx o 158 Accept 415 c 159 Accept-Encoding R o 160 Accept-Encoding 2xx o 161 Accept-Encoding 415 c 162 Accept-Language R o 163 Accept-Language 2xx o 164 Accept-Language 415 c 165 Alert-Info R o 166 Alert-Info 180 - 167 Allow R o 168 Allow 2xx o 169 Allow 405 m 170 Allow r o 171 Authentication-Info 2xx o 172 Authorization R o 173 Call-ID gc m 174 Call-Info g o 175 Contact R m 176 Contact 1xx - 177 Contact 2xx m 178 Contact 3xx - 179 Contact 4xx - 180 Contact 5xx - 181 Contact 6xx - 182 Content-Encoding e o 183 Content-Length e o 184 Content-Type e * 185 CSeq gc m 186 Date g o 187 Error-Info 300-699 o 188 Encryption g o 189 Expires g o 190 From gc m 191 Hide R o 192 In-Reply-To R - 193 Max-Forwards R o 194 Min-Expires 423 m 195 MIME-Version g o 196 Organization g o 197 Priority R o 198 Proxy-Authenticate 407 o 199 Proxy-Authorization R o 200 Proxy-Require R o 201 Require R o 203 Table 1 Summary of header fields, A-R 204 Header Where NEGOTIATE 205 ------ ----- --------- 206 Retry-After R - 207 Retry-After 404,480,486 o 208 Retry-After 503 o 209 Retry-After 600,603 o 210 Response-Key R o 211 Record-Route R o 212 Route R - 213 Server r o 214 Subject R o 215 Supported g o 216 Timestamp g o 217 To gc(1) m 218 Unsupported 420 o 219 User-Agent g o 220 Via gc(2) m 221 Warning r o 222 WWW-Authenticate 401 o 224 Table 2 Summary of header fields, R-Z 226 3.1 Header Field Support for NEGOTIATE Method 228 Tables 1 and 2 add a column to tables 4 and 5 in the [rfc2543]. 229 Refer to Section 6 of [1] for a description of the content of the 230 tables. Note that the rules defined in the enc. and e-e columns 231 in tables 4 and 5 in [1] also apply to use of the headers in the 232 NEGOTIATE request and responses to the NEGOTIATE request. 234 3.2 Responses to the NEGOTIATE Request Method 236 If a server receives an NEGOTIATE request it MUST send a final 237 response. 239 A 200 OK response MUST be sent by a UAS for an NEGOTIATE request 240 that is successful. The 200 OK MUST carry the key sent in the 241 original NEGOTIATE (see section 6.0) that is used to maintain 242 negotiation state. 244 4.0 New Headers 246 This table expands on tables 4 and 5 in RFC 2543 [1], by adding 247 support for the SUBSCRIBE, NOTIFY and NEGOTIATE. 249 Header field where proxy ACK BYE CAN INV OPT REG SUB NOT NEG 250 ---------------------------------------------------------------- 251 Key g o o o o o o o o m 253 4.1 "Key" header 255 The following header is defined for the purposes of this 256 specification. 258 Key = [( "Key" | "y" ) 259 (":" key-format) 260 ("=" key-param)] 261 key-param = 1*( alphanum) 262 key-format = ( "Header" | "Key32" | "Key8" ) 264 Examples: 266 Key: Header=ab45c6d2811e4681 268 y: Key32=1e6f9a33 270 Key: Key8=2c 272 4.1.1 Semantics of the Key Header 274 The role of the Key header is critical to creating a meta-session 275 parameter sets that reflect the outcome of negotiations between 276 various end-points. It is used to identify the resultant set of 277 parameters stored at the endpoints after a completed negotiation. 279 Because SIP does not provide a generic, non-registration, method 280 of referring to parameters that are kept and used across multiple 281 sessions; identification of these parameters is requires an 282 extension to the existing SIP specification in order to work under 283 all circumstances. This becomes especially important when 284 parameters cause the general headers of the SIP message to be 285 unintelligible prior to some type of decoding (ie. decompression, 286 decryption, etc.). 288 Additionally, it may be important that a SIP message is routable 289 without exposing the entire contents of the message itself. This 290 was identified in SIP. However this requirement may need to take 291 a back seat to other considerations, for example bandwidth 292 efficiency concerns, where the contents of the entire message may 293 not be intelligible. As you can see, this becomes very tricky to 294 identify which set of meta-session parameters to use to handle any 295 given message between two endpoints. 297 As a result, we offer two mechanisms in order to provide a means 298 by which to transport the Key information: header format, and 299 shim format. The key is always transported in header format, as 300 a normal, general SIP header when present in a NEGOTIATE method 301 transaction. Thereafter, it may be transported in either format 302 as indicated by in the original NEGOTIATE method. 304 The key8 is an 8 bit Key and the key32 is a 32 bit Key, and either 305 maybe transported in a subsequent shim structure. The shims are 306 carried between the transport protocol (UDP, SCTP etc.) and SIP. 307 The use of the shim allows the entire SIP message to be treated in 308 the negotiated manner for example: the entire message may be 309 encrypted or compressed. The shim allows for the recipient to 310 perform the requisite decoding based on the negotiated algorithm. 312 Shims work well when they are negotiated hop-by-hop. However, 313 there exists a need to transit through a proxy and expose only 314 enough information for it to route on the message. In such 315 situations the header format is used. The header format places the 316 Key in clear text in a SIP message with any other pertinent 317 information required by a proxy in the clear. Thus end-to-end 318 negotiations may be performed in networks with intervening proxy 319 hops. 321 5.0 Key Generation 323 Keys must be relatively unique, and therefore must be generated 324 using an algorithm with distinct enough inputs to ensure that a 325 1-to-1 relationship exists between any single endpoint and the key 326 that maps to that endpoint. Keys are also symmetric. Meaning that 327 both endpoints use the same key value to describe the other 328 endpoint. 330 One way of ensuring this is to use an MD5 hash of values pertaining 331 to both the parties of a NEGOTIATE message. This could then be used 332 in the case that the key is transported in a header, or distilled 333 to an acceptable size for the shim in use. In order to provide a 334 consistent means of generating keys, implementations SHOULD use 335 the following algorithm: 337 The TO URL, FROM URL, Call-ID value, and Via Branch value (if 338 no branch is present, then an alphanumeric 0 should be used 339 instead) should be stripped of all 340 whitespace, and then concatenated together to form a 341 single string. This string should have the MD5 hash algorithm 342 applied to it, to create the negotiated key. This is the key 343 that is transported as part of the NEGOTIATE message. 345 The same callid should NOT be reused between two given 346 endpoints when sending NEGOTIATEs, in order to reduce the 347 likelihood that the same MD5 hash is generated. If an endpoint 348 receives a NEGOTIATE with a key value that already exists, 349 it should reject the request (with 400 "Bad Request" or 350 409 "Conflict"). 352 Example: 354 NEGOTIATE sip:broker@example.com SIP/2.0 355 Via: SIP/2.0/UDP client.example.com:5060 356 From: Endpoint ;tag=88a7s 357 To: sip:broker@example.com 358 Call-ID: 3248543@client.example.com 359 CSeq: 1 NEGOTIATE 360 Content-Type: application/xpidf+xml 361 Content-Length: 120 362 ... 364 Starter String fed in MD5: 366 SIP:Broker@example.comENDPOINT;TAG=88A7S3248543@client.example.com0 369 MD5 Key output (representation): 371 ab45c6d2811e4681f23513 373 5.1 Conversion to Key8 375 When Key8 is used, the negotiated key must be distilled into an 376 8-bit value in order to fit into the shim properly (thus the term 377 Key8). This may be done by selecting the 8 most significant bits 378 of the negotiated key. Note, that this format should only be used 379 between a VERY small set of user agents, as the potential for key 380 collision, and subsequent need to recalculate a new callid, and 381 therefore a new key to try the negotiation again, increases. 383 5.2 Conversion to Key32 385 When Key32 is used, the negotiated key must be distilled into a 386 32-bit value in order to fit into the shim properly (thus the term 387 Key32). This may be done by selecting the 32 most significant bits 388 of the negotiated key (in network byte format). In practice a 389 random 32 bit number is likely to yield similar results. 391 6.0 Key Transport 393 6.1 Key Transport By Header 395 When the Key has been setup to be transported via a general 396 header, both endpoints continue to send a valid, clear-text, SIP 397 start line followed immediately by the Key header, which is also 398 sent as clear text. More of the headers of the message may be in 399 the clear, but at a minimum these two MUST be readable. 401 This is done so that intermediary proxies may still be able to 402 route the request based off of the request URI in the start line, 403 and still be able to maintain some semblance of context by using 404 the Key header itself. Since the message data may not be readable 405 to such proxies, it should use the Key header alone to keep track 406 of context. This will likely not give enough information for the 407 proxy to be able to operate if it is call-stated, in which case a 408 hop-by-hop negotiation should be used so the proxy is able to 409 operate more completely. Note, that since only the Key header 410 form of transport has a notion of endpoint context, that the shim 411 should not be used to keep context alone. 413 It is recommended to allow the same headers used in the 414 construction of a key (TO, FROM, CALLID, and the top VIA), plus 415 the CSEQ to be in the clear in addition to the fields above if an 416 intermediate proxy is used. This is due to the fact that the key 417 is only sufficient to keep context in terms of a single 418 request/response pair, and is very limited in that regard for use 419 at a proxy. 421 When meta-session parameters which exhibit hop-by-hop nature are 422 to be supported - it is strongly recommended that intermediate 423 proxies insert themselves into the NEGOTIATE request process 424 (acting like a back-to-back UA) in order to ensure that all 425 requirements of the proxy are satisfied regardless of the 426 meta-session settings. This would require proxies to be 427 cognizant of the NEGOTIATE method and its payload. 429 6.2 Key Transport By Shim 431 The key, as stated before, may be sent as part of a shim to the 432 SIP protocol. This is offered in order to help minimize the 433 overhead to the message itself, particularly for environments 434 where every byte counts, and heavy compression is desirable. 435 This format also allows the entire message to have the meta- 436 session parameters applied to it, which can be useful in cases 437 where encryption is desired and all of the headers of the SIP 438 message must be included. 440 Additionally, keys must be prepended by a start byte. This is so 441 a key is not confused with a normal start character for any given 442 sip message. As a result, the top 6 bits of the first byte are 443 zeroed out so that no valid ASCII character may result, and the 444 shim can be detected by way of an illegal character. 446 6.2.1 Key32 Shim Format 448 The following shows the format of the Key32 shim (in which the 449 32-bit key is prepended by a shim start byte). Note that this 450 format is what is actually placed in all messages post-negotiation 451 i.e. 32-bit key with start byte. 453 Byte 0: (MSB->LSB) [0000 00XY] 455 X = Version bit: Should always be set to zero (0) 456 Y = Shim Format: 0 = Key32, 1 = Key8. 458 Byte 1..4 (key) 460 Example: 461 0:0000 0000 462 1:1010 1011 463 2:0100 0101 464 3:1100 0110 465 4:1101 0010 467 Would be the 5 byte Shim32 representation of the key: 469 ab45c6d2 471 6.2.2 Key8 Format 473 The following shows the format of the Key8 shim (in which the 474 8-bit key is prepended by a shim start byte). Note that this 475 format is what is actually placed in all messages post-negotiation 476 i.e. 38-bit key with start byte. 478 Byte 0: (MSB->LSB) [0000 00XY] 480 X = Version bit: Should always be set to zero (0) 481 Y = Shim Format: 0 = Key32, 1 = Key8. 483 Byte 1 (key) 485 Example: 486 0:0000 0001 487 1:1010 1011 489 Would be the 2 byte Shim8 representation of the key: 491 ab 493 7.0 NEGOTIATE operation 494 This section deals with the specifics of how the negotiation 495 mechanism works. 497 NEGOTIATE is suitable for use between any two SIP entities i.e they 498 may be used between User Agents, SIP Proxies, BBUAs in any 499 combination. Examples include UA to Proxy, Proxy to Proxy, UA to 500 UA, UA to BBUA etc. 502 There are no restrictions on when a NEGOTIATE method is sent, 503 however the authors recommend that if it is used in the middle of 504 an existing session that the resultant key and parameters NOT be 505 used in the context of the existing session. They may be used from 506 the next session onwards. 508 7.1 Message Body Inclusion 509 The NEGOTIATE method requires a Message body to carry meaningful 510 meta-session information. The answer is carried in the 200OK as a 511 similar message body. With this in mind the authors have make the 512 following recommendations: 514 (1) The NEGOTIATE/200 OK payload is in XML. 515 (2) Multiple NEGOTIATE payloads are permissible in a single 516 NEGOTIATE, they are enclosed using Multipart MIME. 517 (3) Body contents are not changed/manipulated by intermediate 518 proxies. 519 (4) Use of S-MIME for added security is permitted. 521 7.2 Negotiation Duration 523 It is recommended that the Expires header be used to impose a limit 524 on the duration of a negotiation. The use of a Key after the expiry 525 of the imposed time limit will result in a 4xx response (488 526 recommended). On expiry of the negotiation time limit, the expired 527 KEY is removed from the list of KEYs maintained. 529 7.3 Terminating a Negotiation 531 Either side may terminate a negotiation at any time. The 532 termination is achieved by sending a NEGOTIATE with the "Expires" 533 header set to "0." A successful termination will result in a 200 OK 534 from the other side. In case of Negotiation termination both the 535 request and response do not contain a message body. When a 536 negotiation is terminated that KEY is removed from the list of 537 KEYs maintained. 539 7.3 Refreshing of Negotiations 541 A negotiation may be refreshed at any time by the use of the 542 re-NEGOTIATE mechanism. As with the re-INVITE, it is RECOMMENDED 543 that re-NEGOTIATE be used only if the negotiated parameters need 544 to be changed or prior to expiry. The final expiration time is 545 placed in the Expires header in the response. Note that the 546 receiver of a NEGOTIATE may decrease the expiry time 547 - as in rfc2543bis-08 section 10.3. 549 The receiving party MAY reject the negotiation with a response of 550 423 (Registration Too Brief). This response MUST contain a 551 Min-Expires header field that states the minimum expiration interval 552 the receiver is willing to honor. 553 In general the behavior of NEGOTIATE shall follow that 554 of REGISTER in the rfc2543-bis08 section 10.3. 556 If no refresh for a negotiation - as identified by the KEY is 557 received before its expiration time, that KEY is removed from the 558 list of KEYs maintained. 560 An interesting point is whether re-NEGOTIATE is performed using 561 the already negotiated parameters or in clear text, for example 562 re-NEGOTIATE compressed with the negotiated compression algorithm. 563 It is our recommendation that a re-NEGOTIATE be treated as a 564 brand new NEGOTIATION (especially since it may be used to change 565 existing parameters) and be done in clear text. 567 8.0 Behavior of SIP User Agents 569 Depending on the applications requiring the negotiation of a 570 meta-session parameters and the implementation details of the UAC, 571 the type transport used could be either Shim or Header (or both). 572 However, a UAC MUST support the Key header transport format if it 573 is received. 575 The particular format of the key should be placed into the message 576 prior to sending. If a key is received that is not understood by 577 the recipient (maybe it never negotiated that key), an appropriate 578 400 class response should be returned to the request so that the 579 sender of the key can determine that the key is no longer valid 580 for use. 582 Additionally, because the NEGOTIATE has an expiry timer associated 583 with it, a UA MUST continue to allow the key to be used if a 584 transaction began while the key was still good, however, new 585 transactions MAY not be allowed to use the key during this period. 587 8.1 Behavior of SIP Proxy and Redirect Servers 589 8.1.1 Proxy Server 591 Unless stated otherwise, the protocol rules for the NEGOTIATE 592 request at a proxy are identical to those for a BYE request as 593 specified in [1]. 595 8.1.1.1 Stateless Proxy Server 597 The case where a stateless proxy server is involved can cause 598 problems. In particular, the statelessness of the proxy precludes 599 it from creating meta-session parameters since it has no notion of 600 transaction, much less session. This means that meta-session 601 parameters that cause the SIP message headers themselves to become 602 unroutable by a stateless proxy should be used with care. The only 603 way around this problem is to explicitly state all of the 604 meta-session parameters by way of some header that is always 605 readable by the stateless proxy. For example, in cases where 606 algorithms such as dynamic compression are employed, this would 607 involve sending the entire dictionary along with each message, 608 thereby defeating the whole purpose of the compression. For other 609 meta-session parameters, this may not pose a similar problem. 610 However, since this draft seeks to simply provide a method of 611 negotiation, and does not seek to recommend the particulars of 612 what is negotiated; it is left up to the implementor to decide 613 what is appropriate for their particular needs. 615 It is recommended, that where a stateless proxy is known to 616 likely exist, that the key be transported via the header mechanism 617 in order to better ensure that the stateless proxy is able to 618 correctly route the SIP message (assumes that routing information 619 is left readable by the stateless proxy). 621 8.1.1.2 Transparency of the Negotiation 623 An interesting case exists where a proxy wishes to view 624 information in subsequent session transactions, but may not support 625 the NEGOTIATE method, or it's content. 627 For example, the proxy should forward the NEGOTIATE, even 628 though it does not understand it, according to RFC 2543. As a 629 result of the NEGOTIATE, the two UA's decide to compress their SDP 630 content. Later, an INVITE hits the same proxy, only this time the 631 SDP is unreadable due to the meta-session parameters setup as part 632 of the NEGOTIATE. In this case, it may not be able to do it's job 633 (billing, for instance) because the NEGOTIATE was transparent, 634 but the effects of the negotiation are not. In this case, the proxy 635 should not act any differently than it normally would if an INVITE 636 came in with malformed SDP. 638 If a proxy cannot transparently process SIP transactions that are 639 affected by meta-session parameters, they should not simply pass 640 along a NEGOTIATE, and instead assert itself in order to ensure 641 that SIP messages passing through it can be processed without 642 interruption. 644 One method of doing this would be to act as a back to back user 645 agent in respect to the NEGOTIATE and it's meta-session parameters. 646 Another would be to intercept, and reject a NEGOTIATE that contains 647 parameters that are not acceptable to the proxy. A proxy, however, 648 MUST never alter the contents of the NEGOTIATE without causing a 649 new Key header to be generated. 651 8.1.2 Forking Proxy Server 653 In the case where a forking proxy server is involved in the 654 signaling path, such as sending a NEGOTIATE to a user's public 655 address, which is resolved into a contact list with several 656 entries, there exists the possibility for confusion on how 657 to apply the NEGOTIATE across the various contacts. 659 In particular, depending on the application that is using the 660 NEGOTIATE to set it's meta-session parameters, the application 661 may not be able to cope with multiple endpoints using the same 662 key. 664 An example of this would be using dynamic compression 665 where each entity keeping a dictionary to use for compression 666 is not aware of the dictionaries that are being update on 667 peer branches. Because of this, the originator of the NEGOTIATE 668 would wind up having to deal with two separate dynamic dictionaries 669 that are guaranteed to never be synchronized, causing compression 670 to intermittently fail. 672 Another example where no problem exists with forking a NEGOTIATE 673 would be where a static algorithm is being NEGOTIATED, and 674 application of that algorithm is entirely optional (thus not every 675 branch of the NEGOTIATE need accept the negotiation parameters). 676 This could easily be handled. An example of this would be the use 677 of a static, well-known, compression algorithm. 679 Because the problems with forking vary according to the application 680 that is employing the NEGOTIATE mechanism, it is recommended that 681 the UAC that initiates the NEGOTIATE request be aware of it's 682 specifics needs in this regard. If multiple responses are received, 683 indicating that a proxy forked somewhere, and the UAC's application 684 cannot handle this, the UAC SHOULD send another NEGOTIATE to the 685 contacts that it wishes to cancel the unintended negotiation with 686 the same key value used in the original NEGOTIATE, and an expiry 687 value of zero. 689 UAC's SHOULD NOT send a CANCEL in order to cause a negotiation 690 to be terminated, however UAS's MUST be prepared to receive a 691 CANCEL for a NEGOTIATE, and handle it as if it were a NEGOTIATE 692 with an expiry value of zero. 694 8.1.3 Redirection Server 696 Unless stated otherwise, the protocol rules for the NEGOTIATE 697 request at a proxy are identical to those for a BYE request as 698 specified in [1]. 700 9. Guidelines for extensions making use of NEGOTIATE 702 It is strongly recommended that prior to designing XML payloads 703 to use NEGOTIATE, the implementors ensure that a similar 704 function cannot be performed using existing SIP mechanisms. 706 The use of NEGOTIATE may be for uni-directional or bi-directional 707 meta-session information. For example using SCRIBE compression from 708 UAC to UAS only, and UAS chooses to use ROGER towards the UAC. 709 The XML payload SHOULD allow for negotiation of directionality. 711 10. Security Considerations 713 The worst damage that a mischievous intermediate could do would be 714 to intercept, and handle a NEGOTIATE as if it were the intended 715 recipient in order to gain access to information that it might 716 otherwise not have (encryption key, etc.). For this reason, 717 implementors should take care in how, and what they choose to 718 send in a NEGOTIATE or its responses. 720 Sending an 8-bit encryption key in a NEGOTIATE to be used to 721 encrypt sensitive information over the SIP signaling path for 722 the next 10 years, for instance, would be a poor implementation. 724 In general, the security precautions used to guard against 725 attacks against the sessions that the NEGOTIATE's meta-session 726 parameters will apply to SHOULD be applied to the actual 727 NEGOTIATE itself. Use of S-MIME for message body is encouraged. 729 Other types of attacks must also be taken into consideration, 730 such as an intermediate tampering with the key value (causing 731 sessions to be potentially compromised), or with the contents 732 of the NEGOTIATE itself (causing confusion between the endpoints 733 as to the value of the meta-session parameters). These, however 734 are no worse than an intermediary scrambling any given piece 735 of any SIP message, and are therefore, not unique outside of 736 the amount of time such an attack may cause problems. 738 OPEN ISSUE: Should a negotiation be authenticated first? That is 739 should the reply be a 407 with challenge and 740 negotiation proceeds post authentication? This 741 is interesting because the NEGOTIATE could be used 742 to negotiate authentication mechanisms themselves. 744 10.1 Message integrity and authenticity / Man-in-the-middle Attacks 746 One of the intended uses for the negotiation mechanism is to set 747 up authentication and message integrity algorithms. Thus the 748 NEGOTIATE method itself is not subject to these protections - this 749 makes the recipient vulnerable to the Man-in-the-middle attacks. 750 Views are solicited to mitigate this security consideration. 752 10.2 Denial of service attacks 754 The recipient of an offer is allowed to increase or decrease the 755 Expires value of a NEGOTIATE. This provides a measure of 756 protection against DOS attacks. The Min-SE header issue (see 7.3) 757 is of relevance here and the authors look for comments in this 758 area. 760 11.0 IANA Considerations 762 An option-tag "negotiate" is defined by this document. According to 763 [1] must register any new option with the IANA. The authors intend 764 to do this once the document has a measure of acceptance. 766 12 Example message flows 767 This section outlines some example flows to illustrate the use of 768 the new NEGOTIATE method and Key header. 770 12.1 Hop-by-Hop Negotiation 772 UAC Proxy UAS 773 --- ----- --- 774 | F1 NEGOTIATE | | 775 | ----------------------->| | 776 | F2 200 OK | | 777 |<------------------------| | 778 | | F3 NEGOTIATE | 779 | |------------------------->| 780 | | F4 200 OK | 781 | |<-------------------------| 782 | F5 INVITE | | 783 |------------------------>| | 784 | | F6 INVITE | 785 | |------------------------->| 787 In the scenario above the UAC wants to negotiate with an 788 intervening Proxy server, which is typically stateful or a BBUA. 789 The above also has applicability in wireless networks where the 790 mobile negotiates several meta-session parameters with the Proxy 791 Call State/Session Control Function (P-CSCF). It must be noted 792 that the XML documents carried in the messages below are just an 793 illustration, and the authors expect XML documents to be defined 794 that will suit the negotiation process. 796 In the messages the UAC offers ROGER and SCRIBE as possible 797 compression mechanisms. The Proxy responds with a 200 OK and picks 798 SCRIBE. The 200 OK returns the Key sent by the UAC, thus confirming 799 that the next set of messages may be compressed. Also note that the 800 negotiation from the Proxy to the UAS is not shown for brevity. 802 F1 NEGOTIATE UAC->Proxy 804 NEGOTIATE sip:proxy.visited.example.com SIP/2.0 805 Via: SIP/2.0/UDP bobmobile.example.com:5060 806 From: Bob ;tag=88a7s 807 To: Proxy 808 Key: Header=ab13984bdef 809 Expires: Fri, 01 Jan 2010 16:00:00 EST 810 Call-ID: 3248543@bobmobile.example.com 811 CSeq: 1 NEGOTIATE 812 Content-Type: application/xml 813 Content-Length: 120 815 816 817 818 819 821 F2 200 OK Proxy->UAC 822 SIP/2.0 200 OK 823 Via: SIP/2.0/UDP proxy.visited.example.com:5060 824 From: Bob ;tag=88a7s 825 To: Proxy ;tag=8321234356 826 Key: Header=ab13984bdef 827 Expires: Fri, 01 Jan 2010 16:00:00 EST 828 Call-ID: 3248543@bobmobile.example.com 829 CSeq: 1 NEGOTIATE 830 Contact: 831 Content-Type: application/xml 832 Content-Length: 95 834 835 836 837 838 840 F3 and F4 are similar to F1 and F2 respectively and thus not 841 reproduced. All content after Key in the INVITE (F5) is treated 842 as compressed and thus not readable. 844 F5 INVITE UAC->Proxy 845 INVITE sip:joe.example.com SIP/2.0 846 Key: Header=ab13984bdef 847 a14adbe84585abe878693956cde5995affc 848 994adbeccff9494fa91344ffcdefac9474b 849 ...... 850 ...... 852 F6 is not shown. 854 12.2 End-to-End Negotiation and termination of negotiation 856 UA1 Proxy UA2 857 ------- ------- ----------- 858 | F1 NEGOTIATE | | 859 | ----------------------|----------->| 860 | F2 200 OK | | 861 |<----------------------|------------| 862 | | | 863 | | | 864 | | | 865 | | | 866 | F3 NEGOTIATE | | 867 |<----------------------|------------| 868 | F4 200 OK | | 869 |-----------------------|----------->| 871 This example shows an end to end negotiation, with F1 and 872 F2 same as above. The example further goes on to show how 873 the UA2 can terminate the negotiation by sending the NOTIFY 874 with an Expires value of zero. Note that in this case the 875 NOTIFY MUST carry the Key and is not carrying the XML payload. 877 F1 and F2 similar to above except that Proxy simply routes the 878 methods between UA1 and UA2. 880 F3 NEGOTIATE UA2->UA1 882 NEGOTIATE sip:proxy.visited.example.com SIP/2.0 883 Via: SIP/2.0/UDP bobmobile.example.com:5060 884 From: Proxy ;tag=9345ab 885 To: Bob 886 Key: Header; ab13984bdef 887 Expires: 0 888 Call-ID: 978585@proxy.visited.example.com 889 CSeq: 1 NEGOTIATE 890 Content-Length: 0 892 F4 200 OK Proxy->UAC 893 SIP/2.0 200 OK 894 Via: SIP/2.0/UDP proxy.visited.example.com:5060 895 From: Proxy ;tag=9345ab 896 To: Bob ;tag=83ac6786 897 Key: Header; ab13984bdef 898 Expires: 0 899 Call-ID: 978585@proxy.visited.example.com 900 CSeq: 1 NEGOTIATE 901 Contact: 902 Content-Length: 0 904 13. References 906 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 907 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 909 [2] J. Rosenberg et.al., 910 "SIP: session initiation protocol" (RFC2543bis-08), Internet 911 Draft, Internet Engineering Task Force, February 21, 2002. 912 Work in progress 914 [3] S.Donovan,J.Rosenberg, "The SIP Session Timer", 915 draft-ietf-sip-session-timer-08. Oct 6, 2001. Work in Progress 917 [4] J.Rosenberg, H.Schulzrinne, "An Offer/Answer Model with SDP", 918 Internet Draft, Internet Engineering Task Force, 919 February 21, 2002 920 Work in progress 922 14. Author's Address 924 Sriram Parameswar 925 Nortel Networks 926 2380 Performance Drive 927 Richardson, Texas 75083 928 USA 930 Email: sriramp@nortelnetworks.com 932 Brian Stucker 933 Nortel Networks 934 2380 Performance Drive 935 Richardson, Texas 75083 936 USA 938 Email: bstucker@nortelnetworks.com