idnits 2.17.1 draft-ietf-mmusic-connectivity-precon-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2010) is 5160 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 648, but not defined ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-08 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreasen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track G. Camarillo 5 Expires: September 5, 2010 Ericsson 6 D. Oran 7 D. Wing 8 Cisco Systems 9 March 4, 2010 11 Connectivity Preconditions for Session Description Protocol (SDP) Media 12 Streams 13 draft-ietf-mmusic-connectivity-precon-07.txt 15 Abstract 17 This document defines a new connectivity precondition for the Session 18 Description Protocol (SDP) precondition framework. A connectivity 19 precondition can be used to delay session establishment or 20 modification until media stream connectivity has been successfully 21 verified. The method of verification may vary depending on the type 22 of transport used for the media. For unreliable datagram transports 23 such as UDP, verification involves probing the stream with data or 24 control packets. For reliable connection-oriented transports such as 25 TCP, verification can be achieved simply by successful connection 26 establishment or by probing the connection with data or control 27 packets, depending on the situation. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 5, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 72 Without obtaining an adequate license from the person(s) controlling 73 the copyright in such materials, this document may not be modified 74 outside the IETF Standards Process, and derivative works of it may 75 not be created outside the IETF Standards Process, except to format 76 it for publication as an RFC or to translate it into languages other 77 than English. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 3. Connectivity Precondition Definition . . . . . . . . . . . . . 4 84 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 5 86 3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 5 87 3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5 88 3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 6 89 4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 7 90 4.1. Media Stream to Dialog Correlation . . . . . . . . . . . . 7 91 4.2. Explicit Connectivity Verification Mechanisms . . . . . . 8 92 4.3. Verifying Connectivity for Connection-Oriented 93 Transports . . . . . . . . . . . . . . . . . . . . . . . . 9 94 5. Connectivity and Other Precondition Types . . . . . . . . . . 10 95 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 The concept of a Session Description Protocol (SDP) [RFC4566] 106 precondition in the Session Initiation Protocol (SIP) [RFC3261] is 107 defined in RFC 3312 [RFC3312] (updated by RFC 4032 [RFC4032]). A 108 precondition is a condition that has to be satisfied for a given 109 media stream in order for session establishment or modification to 110 proceed. When the precondition is not met, session progress is 111 delayed until the precondition is satisfied or the session 112 establishment fails. For example, RFC 3312 [RFC3312] defines the 113 Quality of Service precondition, which is used to ensure availability 114 of network resources prior to establishing a session (i.e., prior to 115 starting alerting the callee). 117 SIP sessions are typically established in order to setup one or more 118 media streams. Even though a media stream may be negotiated 119 successfully through an SDP offer-answer exchange, the actual media 120 stream itself may fail. For example, when there is one or more 121 Network Address Translators (NATs) or firewalls in the media path, 122 the media stream may not be received by the far end. In cases where 123 the media is carried over a connection-oriented transport such as TCP 124 [RFC0793], the connection-establishment procedures may fail. The 125 connectivity precondition defined in this document ensures that 126 session progress is delayed until media stream connectivity has been 127 verified. 129 The connectivity precondition type defined in this document follows 130 the guidelines provided in RFC 4032 [RFC4032] to extend the SIP 131 preconditions framework. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Connectivity Precondition Definition 141 3.1. Syntax 143 The connectivity precondition type is defined by the string "conn" 144 and hence we modify the grammar found in RFC 3312 [RFC3312] and RFC 145 5027 [RFC5027] as follows: 147 precondition-type = "conn" / "sec" / "qos" / token 149 This precondition tag is registered with the IANA in Section 8. 151 3.2. Operational Semantics 153 According to RFC 4032 [RFC4032], documents defining new precondition 154 types need to describe the behavior of UAs (User Agents) from the 155 moment session establishment is suspended due to a set of 156 preconditions, until it is resumed when these preconditions are met. 157 An entity that wishes to delay session establishment or modification 158 until media stream connectivity has been established uses this 159 precondition-type in an offer. When a mandatory connectivity 160 precondition is received in an offer, session establishment or 161 modification is delayed until the connectivity precondition has been 162 met (i.e., until media stream connectivity has been established in 163 the desired direction or directions). The delay of session 164 establishment defined here implies that alerting of the called party 165 does not occur until the precondition has been satisfied. 167 Packets may be both sent and received on the media streams in 168 question. However, such packets SHOULD be limited to packets that 169 are necessary to verify connectivity between the two endpoints 170 involved on the media stream. That is, the underlying media stream 171 SHOULD NOT be cut through. For example, ICE connectivity checks 172 [I-D.ietf-mmusic-ice] and TCP SYN and ACK packets can be exchanged on 173 media streams that support them as a way of verifying connectivity. 175 Some media streams are described by a single 'm' line but, 176 nevertheless, involve multiple addresses. For example, RFC 5109 177 [RFC5109] specifies how to send FEC (Forward Error Correction) 178 information as a separate stream (the address for the FEC stream is 179 provided in an 'a=fmtp' line). When a media stream consists of 180 multiple destination addresses, connectivity to all of them MUST be 181 verified in order for the precondition to be met. 183 3.3. Status Type 185 RFC 3312 [RFC3312] defines support for two kinds of status types, 186 namely segmented and end-to-end. The connectivity precondition-type 187 defined here MUST be used with the end-to-end status type; use of the 188 segmented status type is undefined. 190 3.4. Direction Tag 192 The direction attributes defined in RFC 3312 [RFC3312] are 193 interpreted as follows: 195 o send: the party that generated the session description is sending 196 packets on the media stream to the other party, and the other 197 party has received at least one of those packets. That is, there 198 is connectivity in the forward (sending) direction. 200 o recv: the other party is sending packets on the media stream to 201 the party that generated the session description, and this party 202 has received at least one of those packets. That is, there is 203 connectivity in the backwards (receiving) direction. 205 o sendrecv: both the send and recv conditions hold. 207 Note that a "send" connectivity precondition from the offerer's point 208 of view corresponds to a "recv" connectivity precondition from the 209 answerer's point of view, and vice versa. If media stream 210 connectivity in both directions is required before session 211 establishment or modification continues, the desired status needs to 212 be set to "sendrecv". 214 3.5. Precondition Strength 216 Connectivity preconditions may have a strength-tag of either 217 "mandatory" or "optional". 219 When a mandatory connectivity precondition is offered and the 220 answerer cannot satisfy the connectivity precondition (e.g., because 221 the offer does not include parameters that enable connectivity to be 222 verified without media cut through) the offer MUST be rejected as 223 described in RFC 3312 [RFC3312]. 225 When an optional connectivity precondition is offered, the answerer 226 MUST generate its answer SDP as soon as possible. Since session 227 progress is not delayed in this case, it is not known whether the 228 associated media streams will have connectivity. If the answerer 229 wants to delay session progress until connectivity has been verified, 230 the answerer MUST increase the strength of the connectivity 231 precondition by using a strength-tag of "mandatory" in the answer. 233 Note that use of a "mandatory" precondition requires the presence of 234 a SIP "Require" header with the option tag "precondition". Any SIP 235 UA that does not support a mandatory precondition will reject such 236 requests. To get around this issue, an optional connectivity 237 precondition and the SIP "Supported" header with the option tag 238 "precondition" can be used instead. 240 Offers with connectivity preconditions in re-INVITEs or UPDATEs 241 follow the rules given in Section 6 of RFC 3312 [RFC3312]. That is: 243 "Both user agents SHOULD continue using the old session parameters 244 until all the mandatory preconditions are met. At that moment, 245 the user agents can begin using the new session parameters." 247 4. Verifying Connectivity 249 Media stream connectivity is ascertained by use of a connectivity 250 verification mechanism between the media endpoints. A connectivity 251 verification mechanism may be an explicit mechanism, such as ICE 252 [I-D.ietf-mmusic-ice] or ICE TCP [I-D.ietf-mmusic-ice-tcp], or it may 253 be an implicit mechanism, such as TCP. Explicit mechanisms provide 254 specifications for when connectivity between two endpoints using an 255 offer/answer exchange is ascertained, whereas implicit mechanisms do 256 not. The verification mechanism is negotiated as part of the normal 257 offer/answer exchange, however it is not identified explicitly. More 258 than one mechanism may be negotiated, but the offerer and answerer 259 need not use the same. The following rules guide which connectivity 260 verification mechanism to use: 262 1. if an explicit connectivity verification mechanism (e.g., ICE) is 263 negotiated, the precondition is met when the mechanism verifies 264 connectivity successfully, otherwise 266 2. if a connection-oriented transport (e.g., TCP) is negotiated, the 267 precondition is met when the connection is established, otherwise 269 3. if an implicit verification mechanism is provided by the 270 transport itself or the media stream data using the transport, 271 the precondition is met when the mechanism verifies connectivity 272 successfully, otherwise 274 4. connectivity cannot be verified reliably and the connectivity 275 precondition will never be satisfied if requested. 277 This document does not mandate any particular connectivity 278 verification mechanism; however, in the following, we provide 279 additional considerations for verification mechanisms. 281 4.1. Media Stream to Dialog Correlation 283 SIP and SDP do not provide any inherent capabilities for associating 284 an incoming media stream packet with a particular dialog. Thus, when 285 an offerer is trying to ascertain connectivity, and an incoming media 286 stream packet is received, the offerer may not know which dialog had 287 its "recv" connectivity verified. Explicit connectivity verification 288 mechanisms therefore typically provide a means to correlate the media 289 stream, whose connectivity is being verified, with a particular SIP 290 dialog. However, some connectivity verification mechanisms may not 291 provide such a correlation. In the absence of a dialog-to-media- 292 stream correlation mechanism (e.g., ICE), a UAS (User Agent Server) 293 MUST NOT require the offerer to confirm a connectivity precondition. 295 4.2. Explicit Connectivity Verification Mechanisms 297 Explicit connectivity verification mechanisms typically use probe 298 traffic with some sort of feedback to inform the sender whether 299 reception was successful. Below we provide two examples of such 300 mechanisms, and how they are used with connectivity preconditions: 302 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice] 303 provides one or more candidate addresses in signaling between the 304 offerer and the answerer and then uses STUN Binding Requests to 305 determine which pairs of candidate addresses have connectivity. Each 306 STUN Binding Request contains a password which is communicated in the 307 SDP as well; this enables correlation between STUN Binding Requests 308 and candidate addresses for a particular media stream. It also 309 provides correlation with a particular SIP dialog. 311 ICE implementations may be either Full or Lite (see 312 [I-D.ietf-mmusic-ice]). Full implementations generate and respond to 313 STUN Binding Requests, whereas Lite implementations only respond to 314 them. With ICE, one side is a controlling agent, and the other side 315 is a controlled agent. A Full implementation can take on either 316 role, whereas a Lite implementation can only be a controlled agent. 317 The controlling agent decides which valid candidate to use and 318 informs the controlled agent of it by identifying the pair as the 319 nominated pair. This leads to the following connectivity 320 precondition rules: 322 o A Full implementation ascertains both "send" and "recv" 323 connectivity when it operates as a STUN client and has sent a STUN 324 Binding Request that resulted in a successful check for all the 325 components of the media stream (as defined further in ICE). 327 o A Full or a Lite implementation ascertains "recv" connectivity 328 when it operates as a STUN server and has received a STUN Binding 329 Request that resulted in a successful response for all the 330 components of the media stream (as defined further in ICE). 332 o A Lite implementation ascertains "send" and "recv" connectivity 333 when the controlling agent has informed it of the nominated pair 334 for all the components of the media stream. 336 A simpler and slightly more delay-prone alternative to the above 337 rules is for all ICE implementations to ascertain "send" and "recv" 338 connectivity for a media stream when the ICE state for that media 339 stream has moved to Completed. 341 Note that there is never a need for the answerer to request 342 confirmation of the connectivity precondition when using ICE: the 343 answerer can determine the status locally. Also note, that when ICE 344 is used to verify connectivity preconditions, the precondition is not 345 satisfied until connectivity has been verified for all the component 346 transport addresses used by the media stream. For example, with an 347 RTP-based media stream where RTCP is not suppressed, connectivity 348 MUST be ascertained for both RTP and RTCP; this is a tightening of 349 the general operational semantics provided in Section 3.2, which is 350 imposed by ICE. Finally, it should be noted, that although 351 connectivity has been ascertained, a new offer/answer exchange may be 352 required before media can flow (per ICE). 354 The above are merely examples of explicit connectivity verification 355 mechanisms. Other techniques can be used as well. It is however 356 RECOMMENDED that ICE be supported by entities that support 357 connectivity preconditions. Use of ICE has the benefit of working 358 for all media streams (not just RTP) as well as facilitate NAT and 359 firewall traversal, which may otherwise interfere with connectivity. 360 Furthermore, the ICE recommendation provides a baseline to ensure 361 that all entities that require probe traffic to support the 362 connectivity preconditions have a common way of ascertaining 363 connectivity. 365 4.3. Verifying Connectivity for Connection-Oriented Transports 367 Connection-oriented transport protocols generally provide an implicit 368 connectivity verification mechanism. Connection establishment 369 involves sending traffic in both directions thereby verifying 370 connectivity at the transport protocol level. When a three-way (or 371 more) handshake for connection establishment succeeds, bi-directional 372 communication is confirmed and both the "send" and "recv" 373 preconditions are satisfied whether requested or not. In the case of 374 TCP for example, once the TCP three-way handshake has completed (SYN, 375 SYN-ACK, ACK), the TCP connection is established and data can be sent 376 and received by either party (i.e., both a send and a receive 377 connectivity precondition has been satisfied). SCTP [RFC4960] 378 connections have similar semantics as TCP and SHOULD be treated the 379 same. 381 When a connection-oriented transport is part of an offer, it may be 382 passive, active, or active/passive [RFC4145]. When it is passive, 383 the offerer expects the answerer to initiate the connection 384 establishment, and when it is active, the offerer wants to initiate 385 the connection establishment. When it is active/passive, the 386 answerer decides. As noted earlier, lack of a media-stream-to-dialog 387 correlation mechanism can make it difficult to guarantee with whom 388 connectivity has been ascertained. When the offerer takes on the 389 passive role, the offerer will not necessarily know which SIP dialog 390 originated an incoming connection request. If the offerer instead is 391 active, this problem is avoided. 393 5. Connectivity and Other Precondition Types 395 The role of a connectivity precondition is to ascertain media stream 396 connectivity before establishing or modifying a session. The 397 underlying intent is for the two parties to be able to exchange media 398 packets successfully. Connectivity by itself however may not fully 399 satisfy this. Quality of Service for example may be required for the 400 media stream; this can be addressed by use of the "qos" precondition 401 defined in RFC 3312 [RFC3312]. Similarly, successful security 402 parameter negotiation may be another prerequisite; this can be 403 addressed by use of the "sec" precondition defined in RFC 5027 404 [RFC5027]. 406 6. Examples 408 The first example uses the connectivity precondition with TCP in the 409 context of a session involving a wireless access medium. Both UAs 410 use a radio access network that does not allow them to send any data 411 (not even a TCP SYN) until a radio bearer has been setup for the 412 connection. Figure 1 shows the message flow of this example (the 413 required PRACK transaction has been omitted for clarity): 415 A B 416 | INVITE | 417 | a=curr:conn e2e none | 418 | a=des:conn mandatory e2e sendrecv | 419 | a=setup:holdconn | 420 |----------------------------------->| 421 | | 422 | 183 Session Progress | 423 | a=curr:conn e2e none | 424 | a=des:conn mandatory e2e sendrecv | 425 | a=setup:holdconn | 426 |<-----------------------------------| 427 | | 428 | UPDATE | 429 | a=curr:conn e2e none | 430 | a=des:conn mandatory e2e sendrecv | 431 A's radio | a=setup:actpass | 432 bearer is +----------------------------------->| 433 up | | 434 | 200 OK | 435 | a=curr:conn e2e none | 436 | a=des:conn mandatory e2e sendrecv | 437 | a=setup:active | 438 |<-----------------------------------| 439 | | 440 | | 441 | | 442 | | B's radio 443 |<---TCP Connection Establishment--->+ bearer is up 444 | | B sends TCP SYN 445 | | 446 | | 447 | 180 Ringing | TCP connection 448 |<-----------------------------------+ is up 449 | | B alerts the user 450 | | 452 Figure 1: Message flow with two types of preconditions 454 A sends an INVITE requesting connection-establishment preconditions. 455 The setup attribute in the offer is set to holdconn [RFC4145] because 456 A cannot send or receive any data before setting up a radio bearer 457 for the connection. 459 B agrees to use the connectivity precondition by sending a 183 460 (Session Progress) response. The setup attribute in the answer is 461 also set to holdconn because B, like A, cannot send or receive any 462 data before setting up a radio bearer for the connection. 464 When A's radio bearer is ready, A sends an UPDATE to B with a setup 465 attribute with a value of actpass. This attribute indicates that A 466 can perform an active or a passive TCP open. A is letting B choose 467 which endpoint will initiate the connection. 469 Since B's radio bearer is not ready yet, B chooses to be the one 470 initiating the connection and indicates so with a setup attribute 471 with a value of active. At a later point, when B's radio bearer is 472 ready, B initiates the TCP connection towards A. 474 Once the TCP connection is established successfully, B knows the 475 "sendrecv" precondition is satisfied, and B proceeds with the session 476 (i.e., alerts the Callee), and sends a 180 (Ringing) response. 478 The second example shows a basic SIP session establishment using SDP 479 connectivity preconditions and ICE (the required PRACK transaction 480 and some SDP details have been omitted for clarity). The message 481 flow for this scenario is shown in Figure 2 below. 483 A B 485 | | 486 |-------------(1) INVITE SDP1--------------->| 487 | | 488 |<------(2) 183 Session Progress SDP2--------| 489 | | 490 |<~~~~~ Connectivity check to A ~~~~~~~~~~~~~| 491 |~~~~~ Connectivity to A OK ~~~~~~~~~~~~~~~~>| 492 | | 493 |~~~~~ Connectivity check to B ~~~~~~~~~~~~~>| 494 |<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~| 495 | | 496 |-------------(3) UPDATE SDP3--------------->| 497 | | 498 |<--------(4) 200 OK (UPDATE) SDP4-----------| 499 | | 500 |<-------------(5) 180 Ringing---------------| 501 | | 502 | | 504 Figure 2: Connectivity precondition with ICE Connectivity Checks 506 SDP1: A includes a mandatory end-to-end connectivity precondition 507 with a desired status of "sendrecv"; this will ensure media stream 508 connectivity in both directions before continuing with the session 509 setup. Since media stream connectivity in either direction is 510 unknown at this point, the current status is set to "none". A's 511 local status table (see [RFC3312]) for the connectivity precondition 512 is as follows: 514 Direction | Current | Desired Strength | Confirm 515 -----------+----------+------------------+---------- 516 send | no | mandatory | no 517 recv | no | mandatory | no 519 and the resulting offer SDP is: 521 a=ice-pwd:asd88fgpdd777uzjYhagZg 522 a=ice-ufrag:8hhY 523 m=audio 20000 RTP/AVP 0 524 c=IN IP4 192.0.2.1 525 a=curr:conn e2e none 526 a=des:conn mandatory e2e sendrecv 527 a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host 529 SDP2: When B receives the offer, B sees the mandatory sendrecv 530 connectivity precondition. B can ascertain connectivity to A ("send" 531 from B's point of view) by use of the ICE connectivity check, however 532 B wants A to inform it about connectivity in the other direction 533 ("recv" from B's point of view). B's local status table therefore 534 looks as follows: 536 Direction | Current | Desired Strength | Confirm 537 -----------+----------+------------------+---------- 538 send | no | mandatory | no 539 recv | no | mandatory | no 541 Since B wants to ask A for confirmation about the "recv" (from B's 542 point of view) connectivity precondition, the resulting answer SDP 543 becomes: 545 a=ice-pwd:qrCA8800133321zF9AIj98 546 a=ice-ufrag:H92p 547 m=audio 30000 RTP/AVP 0 548 c=IN IP4 192.0.2.4 549 a=curr:conn e2e none 550 a=des:conn mandatory e2e sendrecv 551 a=conf:conn e2e recv 552 a=candidate:1 1 UDP 2130706431 192.0.2.4 30000 typ host 554 Meanwhile, B performs a successful send connectivity check to A by 555 sending an ICE connectivity check packet to A and receiving the 556 corresponding response. B's local status table is updated as 557 follows: 559 Direction | Current | Desired Strength | Confirm 560 -----------+----------+------------------+---------- 561 send | yes | mandatory | no 562 recv | no | mandatory | no 564 Since the "recv" connectivity precondition (from B's point of view) 565 is still not satisfied, session establishment remains suspended. 567 SDP3: When A receives the answer SDP, A notes that confirmation was 568 requested for B's "recv" connectivity precondition, which is the 569 "send" precondition from A's point of view. A performs a successful 570 send connectivity check to B by sending an ICE connectivity check to 571 B and receiving the corresponding response. A's local status table 572 becomes: 574 Direction | Current | Desired Strength | Confirm 575 -----------+----------+------------------+---------- 576 send | yes | mandatory | yes 577 recv | no | mandatory | no 579 Since B asked for confirmation about the "send" connectivity (from 580 A's point of view), A now sends an UPDATE (5) to B to confirm the 581 connectivity from A to B: 583 a=ice-pwd:asd88fgpdd777uzjYhagZg 584 a=ice-ufrag:8hhY 585 m=audio 20000 RTP/AVP 0 586 c=IN IP4 192.0.2.1 587 a=curr:conn e2e send 588 a=des:conn mandatory e2e sendrecv 589 a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host 591 B has both send and recv connectivity confirmed at this point and the 592 session can continue. 594 7. Security Considerations 596 General security considerations for preconditions are discussed in 597 RFC 3312 [RFC3312] and RFC 4032 [RFC4032]. As discussed in RFC 4032 598 [RFC4032], it is strongly RECOMMENDED that integrity protection be 599 applied to the SDP session descriptions. S/MIME [RFC3853] 600 protection, as described in RFC 3261 [RFC3261]. When the user agent 601 provides identity services (rather than the proxy server), the SIP 602 identity mechanism specified in RFC 4474 [RFC4474] provides an 603 alternative end-to-end integrity protection. Additionally, the 604 following security issues relate specifically to connectivity 605 preconditions. 607 Connectivity preconditions rely on mechanisms beyond SDP such as TCP 608 [RFC0793] connection establishment, or ICE connectivity checks 609 [I-D.ietf-mmusic-ice] to establish and verify connectivity between an 610 offerer and an answerer. An attacker that prevents those mechanisms 611 from succeeding (e.g., by keeping ICE connectivity checks from 612 arriving to their destination) can prevent media sessions from being 613 established. While this attack relates to connectivity 614 preconditions, it is actually an attack against the connection 615 establishment mechanisms used by the endpoints. This attack can be 616 performed in the presence or in the absence of connectivity 617 preconditions. In their presence, the whole session setup will be 618 disrupted. In their absence, only the establishment of the 619 particular stream under attack will be disrupted. This specification 620 does not provide any mechanism against attackers able to block 621 traffic between the endpoints involved in the session because such an 622 attacker will always be able to launch DoS (Denial of Service) 623 attacks. 625 Instead of blocking the connectivity checks, the attacker can 626 generate forged connectivity checks that would cause the endpoints to 627 assume that there was connectivity when there was actually no 628 connectivity. This attack would result in a poor user's experience 629 because the session would be established without all the media 630 streams being ready. The same attack can be used, regardless of 631 whether or not connectivity preconditions are used, to attempt to 632 hijack a connection. The forged connectivity checks would trick the 633 endpoints into sending media to the wrong direction. To prevent 634 these attacks, it is RECOMMENDED that the mechanisms used to check 635 connectivity are adequately secured by message authentication and 636 integrity protection. For example, Section 2.5 of 637 [I-D.ietf-mmusic-ice] discusses how message integrity and data origin 638 authentication are implemented in ICE connectivity checks. 640 8. IANA Considerations 642 IANA is hereby requested to register a new precondition type under 643 the Precondition Types used with SIP subregistry, which is located 644 under the Session Initiation Protocol (SIP) Parameters registry. 646 Precondition-Type Description Reference 647 ----------------- ----------------------------------- --------- 648 conn Connectivity precondition [RFCxxxx] 650 [Note to the RFC Editor: replace RFCxxxx with the number assigned to 651 this RFC.] 653 9. References 655 9.1. Normative References 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, March 1997. 660 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 661 A., Peterson, J., Sparks, R., Handley, M., and E. 662 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 663 June 2002. 665 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 666 "Integration of Resource Management and Session Initiation 667 Protocol (SIP)", RFC 3312, October 2002. 669 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 670 Requirement for the Session Initiation Protocol (SIP)", 671 RFC 3853, July 2004. 673 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 674 Initiation Protocol (SIP) Preconditions Framework", 675 RFC 4032, March 2005. 677 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 678 Authenticated Identity Management in the Session 679 Initiation Protocol (SIP)", RFC 4474, August 2006. 681 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 682 Description Protocol", RFC 4566, July 2006. 684 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 685 Session Description Protocol (SDP) Media Streams", 686 RFC 5027, October 2007. 688 [I-D.ietf-mmusic-ice] 689 Rosenberg, J., "Interactive Connectivity Establishment 690 (ICE): A Protocol for Network Address Translator (NAT) 691 Traversal for Offer/Answer Protocols", 692 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 694 9.2. Informative References 696 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 697 RFC 793, September 1981. 699 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 700 the Session Description Protocol (SDP)", RFC 4145, 701 September 2005. 703 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 704 RFC 4960, September 2007. 706 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 707 Correction", RFC 5109, December 2007. 709 [I-D.ietf-mmusic-ice-tcp] 710 Perreault, S. and J. Rosenberg, "TCP Candidates with 711 Interactive Connectivity Establishment (ICE)", 712 draft-ietf-mmusic-ice-tcp-08 (work in progress), 713 October 2009. 715 Authors' Addresses 717 Flemming Andreasen 718 Cisco Systems, Inc. 719 499 Thornall Street, 8th Floor 720 Edison, NJ 08837 721 USA 723 Email: fandreas@cisco.com 725 Gonzalo Camarillo 726 Ericsson 727 Hirsalantie 11 728 Jorvas 02420 729 Finland 731 Email: Gonzalo.Camarillo@ericsson.com 733 David Oran 734 Cisco Systems, Inc. 735 7 Ladyslipper Lane 736 Acton, MA 01720 737 USA 739 Email: oran@cisco.com 741 Dan Wing 742 Cisco Systems, Inc. 743 170 West Tasman Drive 744 San Jose, CA 95134 745 USA 747 Email: dwing@cisco.com