idnits 2.17.1 draft-ietf-mmusic-connectivity-precon-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 423 has weird spacing: '...ypes of preco...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1, 2006) is 6539 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: 'SIP' on line 85 -- Looks like a reference, but probably isn't: 'STUN' on line 150 == Unused Reference: '11' is defined on line 636, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-08 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '8') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3309 (ref. '9') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '10') (Obsoleted by RFC 5389) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 13 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 System, Inc. 4 Expires: December 3, 2006 G. Camarillo 5 Ericsson 6 D. Oran 7 Cisco Systems, Inc 8 D. Wing 9 Cisco Systems, Inc. 10 June 1, 2006 12 Connectivity Preconditions for Session Description Protocol Media 13 Streams 14 draft-ietf-mmusic-connectivity-precon-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 3, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document defines a new connectivity precondition for the Session 48 Description Protocol precondition framework described in RFC 3312 49 (and its update, RFC4032). A connectivity precondition can be used 50 to delay session establishment or modification until media stream 51 connectivity has been verified successfully. The method of 52 verification may vary depending on the type of transport used for the 53 media. For reliable connection-oriented transports such as TCP 54 verification is achieved by successful connection establishment. For 55 unreliable datagram transports such as UDP, verification involves 56 probing the stream with data or control packets. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Connectivity Precondition Definition . . . . . . . . . . . . . 3 63 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Operational semantics . . . . . . . . . . . . . . . . . . 4 65 3.3. Status type . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.4. Direction tag . . . . . . . . . . . . . . . . . . . . . . 4 67 3.5. Precondition strength . . . . . . . . . . . . . . . . . . 5 68 4. Verifying connectivity . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Procedures for connection-oriented transports . . . . . . 7 70 4.2. Procedures for datagram transports . . . . . . . . . . . . 8 71 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 Intellectual Property and Copyright Statements . . . . . . . . . . 18 82 1. Introduction 84 The concept of a Session Description Protocol (SDP) [2] precondition 85 in the Session Initiation Protocol (SIP) [SIP] is defined in RFC3312 86 [4] (updated by RFC4032 [6]). A precondition is a condition that has 87 to be satisfied for a given media stream in order for session 88 establishment or modification to proceed. When the precondition is 89 not met, session progress is delayed until the precondition is 90 satisfied, or the session establishment fails. For example, RFC3312 91 defines the Quality of Service precondition, which is used to ensure 92 availability of network resources prior to establishing (i.e. 93 alerting) a call. 95 SIP sessions are typically established in order to setup one or more 96 media streams. Even though a media stream may be negotiated 97 successfully, through an SDP offer-answer exchange, the actual media 98 stream itself may fail. For example, when there is one or more 99 Network Address Translators (NATs) or firewalls in the media path, 100 the media stream may not be received by the far end. In cases where 101 the media is carried over a connection-oriented transport such as TCP 102 [8], the connection-establishment procedures may fail. The 103 connectivity precondition defined in this document ensures that 104 session progress is delayed until media stream connectivity has been 105 verified, or the session itself is abandoned. 107 The connectivity precondition type defined in this document follows 108 the guidelines provided in RFC4032 [6] to extend the SIP 109 preconditions framework. 111 2. Terminology 113 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 115 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 116 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 117 compliant implementations. 119 3. Connectivity Precondition Definition 121 3.1. Syntax 123 The connectivity precondition type is defined by the string "conn" 124 and hence we modify the grammar found in RFC 3312 as follows: 126 precondition-type = "conn" | "qos" | token 128 This precondition tag is registered with the IANA in Section 7. 130 3.2. Operational semantics 132 According to RFC4032 [6], documents defining new precondition types 133 need to describe the behavior of UAs from the moment session 134 establishment is suspended due to a set of preconditions until is 135 resumed when these preconditions are met. An entity that wishes to 136 delay session establishment or modification until media stream 137 connectivity has been established uses this precondition-type in an 138 offer. When a mandatory connectivity precondition is received in an 139 offer, session establishment or modification is delayed until the 140 connectivity precondition has been met, i.e., media stream 141 connectivity has been established in the desired direction(s). The 142 delay of session establishment defined here implies that alerting of 143 the called party does not occur until the precondition has been 144 satisfied. 146 Packets may be both sent and received on the media streams in 147 question, however such packets SHOULD be limited to packets that are 148 necessary to verify connectivity between the two endpoints involved 149 on the media stream, i.e. the underlying media stream SHOULD NOT be 150 cut through. For example, STUN packets [STUN], RTP No-Op packets and 151 corresponding RTCP reports, as well as TCP SYN and ACK packets can be 152 exchanged on media streams that support them as a way of verifying 153 connectivity. 155 When the media stream consists of multiple destination addresses, 156 connectivity to all of them MUST be verified in order for the 157 precondition to be met. In the case of RTP-based media streams, RTCP 158 connectivity however is not a requirement. 160 3.3. Status type 162 RFC 3312 defines support for two kinds of status types, namely 163 segmented and end-to-end. The connectivity precondition-type defined 164 here MUST be used with the end-to-end status type; use of the 165 segmented status type is undefined. 167 3.4. Direction tag 169 The direction attributes defined in RFC 3312 are interpreted as 170 follows: 172 o send: The party who generated the session description (the offerer 173 in an offer-answer exchange) is sending packets on the media 174 stream to the other party, and the other party has received at 175 least one of those packets, i.e., there is connectivity in the 176 forward (sending) direction. 177 o recv: The other party (the answerer in an offer-answer exchange) 178 is sending packets on the media stream to this party, and this 179 party has received at least one of those packets, i.e., there is 180 connectivity in the backwards (receiving) direction. 181 o sendrecv: Both the send and recv conditions hold. In the case of 182 a connection-oriented transport such as TCP, once established the 183 connection would usually have an associated direction tag of 184 sendrecv because it can carry data in both directions. 186 Note that a "send" connectivity precondition from the offerer's point 187 of view corresponds to a "recv" connectivity precondition from the 188 answerer's point of view, and vice versa. If media stream 189 connectivity in both directions is required before session 190 establishment or modification continues, the desired status MUST be 191 set to "sendrecv". 193 3.5. Precondition strength 195 Connectivity preconditions may have a strength-tag of either 196 "mandatory" or "optional". 198 When a mandatory connectivity precondition is offered, and the 199 answerer cannot satisfy the connectivity precondition, e.g., because 200 the offer does not include parameters that enable connectivity to be 201 verified without media cut through, the offer MUST be rejected as 202 described in RFC 3312. 204 When an optional connectivity precondition is offered, the answerer 205 MUST generate its answer SDP as soon as possible; since session 206 progress is not delayed in this case, it is not known whether the 207 associated media streams will have connectivity. If the answerer 208 wants to delay session progress until connectivity has been verified, 209 the answerer MUST increase the strength of the connectivity 210 precondition by using a strength-tag of "mandatory" in the answer. 211 Note that use of a "mandatory" precondition requires the presence of 212 a SIP "Require" header with the option tag "precondition": Any SIP UA 213 that does not support a mandatory precondition will reject such 214 requests. To get around this issue, an optional connectivity 215 precondition and the SIP "Supported" header with the option tag 216 "precondition" can be used instead. Offers with connectivity 217 preconditions in re-INVITEs or UPDATEs follow the rules given in 218 Section 6 of RFC 3312, i.e.: 220 "Both user agents SHOULD continue using the old session parameters 221 until all the mandatory preconditions are met. At that moment, 222 the user agents can begin using the new session parameters." 224 It should be noted, that connectivity may not exist between two 225 entities initially, e.g., when one or both entities are behind a 226 symmetric NAT. Subsequent packet exchanges however may create the 227 necessary address bindings in the NAT(s) thereby creating 228 connectivity. The ICE [7] methodology for example ensures that such 229 bindings are created following an offer/answer exchange. 231 4. Verifying connectivity 233 The above definitions of send and receive connectivity preconditions 234 beg two questions: How does the sender of a packet know the other 235 party received it, and how does the receiver of a packet know who 236 sent it (in particular, the correlation between an incoming media 237 packet and a particular SIP dialog may not be obvious) ? 239 Media stream connectivity can be ascertained in a variety of ways. 240 This document does not mandate any particular mechanism for doing so, 241 however the appropriate machinery is likely to vary depending on the 242 type of transport used for media carriage. In order to comply with 243 the intent of an endpoint requiring connectivity preconditions, the 244 following general principles apply: 246 o The 3-way handshake connection establishment procedures of a 247 reliable transport protocol such as TCP are usually adequate to 248 demonstrate bi-directional connectivity (and hence "sendrecv" 249 media capability). Probe packets sent over the connection are 250 generally not required to satisfy the precondition. 251 o A pure datagram transport such as UDP (whether carrying RTP or 252 some other protocol) by itself provides no useful feedback about 253 connectivity. Hence, some sort of probe traffic is necessary to 254 ascertain whether packets are being received successfully. 255 o Connectivity preconditions are used to verify connectivity based 256 on the address information exchanged in offers and answers. When 257 overlapping IP address spaces are used (e.g. because one or both 258 endpoints are behind a Network Address Translator), it is possible 259 to inadvertently verify connectivity with an unrelated entity. In 260 order to address this issue, a correlation mechanism is needed 261 between media stream packets on one side and offers and answers on 262 the other side. ICE [7] defines one such correlation mechanism, 263 however use of it is above and beyond the connection-oriented 264 connectivity preconditions defined here. 266 o Some connection-oriented transport protocols may allow the data 267 transfer phase to operate in an unreliable mode (today there is no 268 standards-track IETF protocol which exhibits this characteristic). 269 In such cases the success of connection establishment may not 270 definitively demonstrate connectivity in the data phase, and hence 271 probe traffic MAY be necessary to ascertain if the precondition is 272 met. 273 o Hybrid protocols such as DCCP [14] provide their own feedback 274 channel and initialization procedures, which can serve to verify 275 connectivity without the use of explicit probe traffic. 277 The determination depends on the exact method being used to verify 278 connectivity. 280 4.1. Procedures for connection-oriented transports 282 TCP connections are bidirectional and hence there is no difference 283 between send and recv connectivity preconditions. Once the TCP 284 three-way hand shake has completed (SYN, SYN-ACK, ACK), the TCP 285 connection is established and data can be sent and received by either 286 party, i.e. both a send and a receive connectivity precondition has 287 been satisfied. Implementations SHOULD NOT require the receipt of 288 probe traffic in order to consider the precondition satisfied. 290 SCTP [9] connections have similar semantics as TCP and SHOULD be 291 treated the same as TCP. 293 When a connection-oriented transport is part of an offer, it may be 294 passive, active, or active/passive [12]. When it is passive, the 295 offerer expects the answerer to initiate the connection 296 establishment, and when it is active, the offerer wants to initiate 297 the connection establishment. When it is active/passive, the 298 answerer decides. 300 SIP and SDP do not provide any inherent capabilities for associating 301 an incoming media stream packet with a particular dialog. Thus, when 302 the offerer is passive and an incoming connection is being 303 established, the offerer cannot guarantee that the packet is 304 associated with a particular dialog. When SIP forking is being used, 305 this implies that the offerer cannot determine which of the early 306 dialogs now has its recv connectivity precondition satisfied - a 307 correlation mechanism is missing. This turns out not to be a problem 308 however, since the successful completion of the connection- 309 establishment procedure itself (e.g. receipt of SYN-ACK in the case 310 of TCP) informs the answerer that the precondition has been 311 satisfied, and hence there is no need for the offerer to explicitly 312 inform the answerer of this (by sending a SIP UPDATE message). In 313 the absence of a correlation mechanism (e.g. ICE), an answerer 314 therefore MUST NOT require the offerer to confirm a connectivity 315 precondition on a connection-oriented transport. 317 4.2. Procedures for datagram transports 319 Verification of connectivity on datagram transports usually entails 320 the sending of probe traffic with some form of feedback to inform the 321 sender whether reception was successful. Techniques that can be used 322 to verify connectivity on datagram transports include: 324 o ICE [7]: ICE provides one or more candidate addresses in signaling 325 between the offerer and the answerer and then uses STUN Binding 326 Requests to determine which pairs of candidate addresses have 327 connectivity. Each STUN Binding Request contains a password which 328 is communicated in the SDP as well; this enables correlation 329 between STUN Binding Requests and candidate addresses for a 330 particular media stream. In ICE, connectivity is always checked 331 in both directions by following a state machine with a set of 332 states for the offerer and a set of states for the answerer: The 333 offerer ascertains "recv" connectivity for a particular transport 334 address pair by transitioning into the "validating" state, whereas 335 "send" connectivity is ascertained by transitioning into the 336 "valid" state. The answerer ascertains both "send" and "recv" 337 connectivity for a particular transport address pair by 338 transitioning into the "send-valid" state. As a consequence of 339 this, there is never a need for the answerer to request 340 confirmation of the connectivity precondition when using ICE: the 341 answerer can determine the status locally. When ICE is used to 342 verify connectivity preconditions, the precondition is satisfied 343 as soon as one of the candidates becomes valid, i.e. connectivity 344 has been verified for all the component transport addresses used 345 by the media stream. For example, with an RTP-based media stream 346 where RTCP is not suppressed, connectivity must be ascertained for 347 both RTP and RTCP; this is a tightening of the general operational 348 semantics provided in Section 3.2 imposed by ICE. Finally, it 349 should be noted, that though connectivity has been ascertained, a 350 new offer/answer exchange may be required before media can 351 actually flow (per ICE). 352 o RTP no-op [13]: The sender of an RTP No-Op payload can verify send 353 connectivity by examining the RTCP report(s) being returned. In 354 particular, the source SSRC in the RTCP report block is used for 355 correlation. The RTCP report block also contains the SSRC of the 356 sender of the report and the SSRC of incoming RTP No-Op packets 357 identifies the sender of the RTP packet. Thus, once send 358 connectivity has been ascertained, receipt of an RTP No-Op packet 359 from the same SSRC provides the necessary correlation to determine 360 receive connectivity. Alternatively, the duality of send and 361 receive preconditions can be exploited, with one side confirming 362 when his send precondition is satisfied, which in turn implies the 363 other sides recv precondition is satisfied. 365 The above are merely examples of techniques that can be used. Other 366 techniques which meet the requirements of Section 4 above can be used 367 as well. It is however RECOMMENDED that ICE be supported by entities 368 that support connectivity preconditions for datagram transports. Use 369 of ICE has the benefit of working for all datagram based media 370 streams (not just RTP) as well as facilitate NAT and firewall 371 traversal, which may otherwise interfere with connectivity. 372 Furthermore, the ICE recommendation provides a baseline to ensure 373 that all entities that require probe traffic to support the 374 connectivity preconditions have at least one common way of 375 ascertaining connectivity. 377 5. Examples 379 The first example uses the connectivity precondition with TCP in the 380 context of a session involving a wireless access medium. Both UAs 381 use a radio access network that does not allow them to send any data 382 (not even a TCP SYN) until a radio bearer has been setup for the 383 connection. Figure 1 shows the message flow of this example (the 384 PRACK transaction has been omitted for clarity): 386 A B 387 | INVITE | 388 | a=curr:conn e2e none | 389 | a=des:conn mandatory e2e sendrecv | 390 | a=setup:holdconn | 391 |----------------------------------->| 392 | | 393 | 183 Session Progress | 394 | a=curr:conn e2e none | 395 | a=des:conn mandatory e2e sendrecv | 396 | a=setup:holdconn | 397 |<-----------------------------------| 398 | | 399 | UPDATE | 400 | a=curr:conn e2e none | 401 | a=des:conn mandatory e2e sendrecv | 402 A's radio | a=setup:actpass | 403 bearer is +----------------------------------->| 404 up | | 405 | 200 OK | 406 | a=curr:conn e2e none | 407 | a=des:conn mandatory e2e sendrecv | 408 | a=setup:active | 409 |<-----------------------------------| 410 | | 411 | | 412 | | 413 | | B's radio 414 |<---TCP Connection Establishment--->+ bearer is up 415 | | B sends TCP SYN 416 | | 417 | | 418 | 180 Ringing | TCP connection 419 |<-----------------------------------+ is up 420 | | B alerts the user 421 | | 423 Figure 1: Message flow with two types of preconditions 425 A sends an INVITE requesting connection-establishment preconditions. 426 The setup attribute in the offer is set to holdconn because A cannot 427 send or receive any data before setting up a radio bearer for the 428 connection. 430 B agrees to use the connectivity precondition by sending a 183 431 (Session Progress) response. The setup attribute in the answer is 432 also set to holdconn because B, like A, cannot send or receive any 433 data before setting up a radio bearer for the connection. 435 When A's radio bearer is ready, A sends an UPDATE to B with a setup 436 attribute with a value of actpass. This attribute indicates that A 437 can perform an active or a passive TCP open. A is letting B choose 438 which endpoint will initiate the connection. 440 Since B's radio bearer is not ready yet, B chooses to be the one 441 initiating the connection and indicates so with a setup attribute 442 with a value of active. At a later point, when B's radio bearer is 443 ready, B initiates the TCP connection towards A. 445 Once the TCP connection is established successfully, B alerts the 446 callee and sends a 180 (Ringing) response. 448 The second example shows a basic SIP session establishment using SDP 449 connectivity preconditions and RTP No-Op. Note that not all SDP 450 details are provided in the following. below shows the message flow 451 for this scenario shown in Figure 2 below. 453 A B 455 | | 456 |-------------(1) INVITE SDP1--------------->| 457 | | 458 |<------(2) 183 Session Progress SDP2--------| 459 | | 460 |<~~~~~ Connectivity check to A ~~~~~~~~~~~~~| 461 | | 462 |----------------(3) PRACK------------------>| 463 | | 464 |~~~~~ Connectivity to A OK ~~~~~~~~~~~~~~~~>| 465 | | 466 |<-----------(4) 200 OK (PRACK)--------------| 467 | | 468 |~~~~~ Connectivity check to B ~~~~~~~~~~~~~>| 469 |<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~| 470 | | 471 |-------------(5) UPDATE SDP3--------------->| 472 | | 473 |<--------(6) 200 OK (UPDATE) SDP4-----------| 474 | | 475 |<-------------(7) 180 Ringing---------------| 476 | | 477 | | 478 | | 480 Figure 2: Connectivity precondition with RTP no-op 482 SDP1: A includes a mandatory end-to-end connectivity precondition 483 with a desired status of "sendrecv"; this will ensure media stream 484 connectivity in both directions before continuing with the session 485 setup. Since media stream connectivity in either direction is 486 unknown at this point, the current status is set to "none". A's 487 local status table (see RFC 3312) for the connectivity precondition 488 is as follows: 490 Direction | Current | Desired Strength | Confirm 491 -----------+----------+------------------+---------- 492 send | no | mandatory | no 493 recv | no | mandatory | no 495 and the resulting offer SDP is: 497 m=audio 20000 RTP/AVP 0 96 498 c=IN IP4 192.0.2.1 499 a=rtpmap:96 no-op/8000 500 a=curr:conn e2e none 501 a=des:conn mandatory e2e sendrecv 503 SDP2: When B receives the offer, B sees the mandatory sendrecv 504 connectivity precondition. B can ascertain connectivity to A ("send" 505 from B's point of view) by use of the RTP No-Op, however B wants A to 506 inform it about connectivity in the other direction ("recv" from B's 507 point of view). B's local status table therefore looks as follows: 509 Direction | Current | Desired Strength | Confirm 510 -----------+----------+------------------+---------- 511 send | no | mandatory | no 512 recv | no | mandatory | no 514 Since B wants to ask A for confirmation about the "recv" (from B's 515 point of view) connectivity precondition, the resulting answer SDP 516 becomes: 518 m=audio 30000 RTP/AVP 0 96 519 a=rtpmap:96 no-op/8000 520 c=IN IP4 192.0.2.4 521 a=curr:conn e2e none 522 a=des:conn mandatory e2e sendrecv 523 a=conf:conn e2e recv 525 Meanwhile, B performs a connectivity check to A, which succeeds and 526 hence B's local status table is updated as follows: 528 Direction | Current | Desired Strength | Confirm 529 -----------+----------+------------------+---------- 530 send | yes | mandatory | no 531 recv | no | mandatory | no 533 Since the "recv" connectivity precondition (from B's point of view) 534 is still not satisfied, session establishment remains suspended. 535 SDP3: When A receives the answer SDP, A notes that confirmation was 536 requested for B's "recv" connectivity precondition, which is the 537 "send" precondition from A's point of view. A performs a 538 connectivity check to B, which succeeds, and A's local status table 539 becomes: 541 Direction | Current | Desired Strength | Confirm 542 -----------+----------+------------------+---------- 543 send | yes | mandatory | yes 544 recv | no | mandatory | no 546 Since B asked for confirmation about the "send" connectivity (from 547 A's point of view), A now sends an UPDATE (5) to B to confirm the 548 connectivity from A to B: 550 m=audio 20000 RTP/AVP 0 96 551 a=rtpmap:96 no-op/8000 552 c=IN IP4 192.0.2.1 553 a=curr:conn e2e send 554 a=des:conn mandatory e2e sendrecv 556 6. Security Considerations 558 In addition to the general security considerations for preconditions 559 provided in RFC 3312, the following security issues, which are 560 specific to connectivity preconditions, should be considered. 562 Connectivity preconditions rely on mechanisms beyond SDP, e.g. 563 TCP[8] connection establishment, RTP No-Op [13] or STUN [10], to 564 establish and verify connectivity between an offerer and an answerer. 565 An attacker that prevents those mechanism from succeeding can prevent 566 media sessions from being established and hence it is RECOMMENDED 567 that such mechanisms are adequately secured by message authentication 568 and integrity protection. Also, the mechanisms SHOULD consider how 569 to prevent denial of service attacks. Similarly, an attacker that 570 can forge packets for these mechanisms can enable sessions to be 571 established when there in fact is no media connectivity, which may 572 lead to a poor user experience. Authentication and integrity 573 protection of such mechanisms can prevent this type of attacks and 574 hence use of it is RECOMMENDED. 576 It is also strongly RECOMMENDED that integrity protection be applied 577 to the SDP session descriptions. S/MIME [5] is the natural choice to 578 provide such end-to-end integrity protection, as described in RFC 579 3261 [3]. 581 7. IANA Considerations 583 IANA is hereby requested to register a RFC 3312 precondition type 584 called "conn" with the name "Connectivity precondition". The 585 reference for this precondition type is the current document. 587 8. Change Log 589 8.1. Changes since -01 591 There are no changes since the previous version of the document. 593 9. References 595 9.1. Normative References 597 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 598 Levels", BCP 14, RFC 2119, March 1997. 600 [2] Handley, M. and V. Jacobson, "SDP: Session Description 601 Protocol", RFC 2327, April 1998. 603 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 604 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 605 Session Initiation Protocol", RFC 3261, June 2002. 607 [4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 608 Resource Management and Session Initiation Protocol (SIP)", 609 RFC 3312, October 2002. 611 [5] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 612 Requirement for the Session Initiation Protocol (SIP)", 613 RFC 3853, July 2004. 615 [6] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation 616 Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. 618 [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 619 Methodology for Network Address Translator (NAT) Traversal for 620 Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in 621 progress), March 2006. 623 9.2. Informative References 625 [8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 626 September 1981. 628 [9] Stone, J., Stewart, R., and D. Otis, "Stream Control 629 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 630 September 2002. 632 [10] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 633 - Simple Traversal of User Datagram Protocol (UDP) Through 634 Network Address Translators (NATs)", RFC 3489, March 2003. 636 [11] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 637 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 639 [12] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 640 Session Description Protocol (SDP)", RFC 4145, September 2005. 642 [13] Andreasen, F., "A No-Op Payload Format for RTP", 643 draft-wing-avt-rtp-noop-03 (work in progress), May 2005. 645 [14] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 646 draft-ietf-dccp-spec-13 (work in progress), December 2005. 648 Authors' Addresses 650 Flemming Andreasen 651 Cisco System, Inc. 652 499 Thornall Street, 8th Floor 653 Edison, NJ 08837 654 USA 656 Email: fandreas@cisco.com 658 Gonzalo Camarillo 659 Ericsson 660 Hirsalantie 11 661 Jorvas 02420 662 Finland 664 Email: Gonzalo.Camarillo@ericsson.com 666 David Oran 667 Cisco Systems, Inc 668 7 Ladyslipper Lane 669 Acton, MA 01720 670 USA 672 Email: oran@cisco.com 674 Dan Wing 675 Cisco Systems, Inc. 676 170 West Tasman Drive 677 San Jose, CA 94301 678 USA 680 Email: dwing@cisco.com 682 Intellectual Property Statement 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Disclaimer of Validity 708 This document and the information contained herein are provided on an 709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 711 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 712 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 713 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Copyright Statement 718 Copyright (C) The Internet Society (2006). This document is subject 719 to the rights, licenses and restrictions contained in BCP 78, and 720 except as set forth therein, the authors retain all their rights. 722 Acknowledgment 724 Funding for the RFC Editor function is currently provided by the 725 Internet Society.