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