idnits 2.17.1 draft-ietf-mmusic-connectivity-precon-00.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 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. ** 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 376 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 (April 24, 2005) is 6935 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 91 -- Looks like a reference, but probably isn't: 'STUN' on line 156 == Unused Reference: '10' is defined on line 577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '7') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3309 (ref. '8') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '9') (Obsoleted by RFC 5389) == Outdated reference: A later version (-03) exists of draft-wing-avt-rtp-noop-01 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-04 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreason 3 Internet-Draft Cisco System, Inc. 4 Expires: October 26, 2005 G. Camarillo 5 Ericsson 6 D. Oran 7 Cisco Systems, Inc 8 D. Wing 9 Cisco Systems, Inc. 10 April 24, 2005 12 Connectivity Preconditions for Session Description Protocol Media 13 Streams 14 draft-ietf-mmusic-connectivity-precon-00.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 October 26, 2005. 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 NOTE: This document is the result of a merge of two prior documents 59 with overlapping scope: draft-ietf-mmusic-connectivityprecondition-02 60 and draft-ietf-mmusic-connection-precon-02. The former covered the 61 case of datagram unreliable transports; the latter the case of 62 connection-oriented reliable transports. The merged version covers 63 these two but also describes operations in hybrid cases of unreliable 64 connection-oriented transports and reliable datagram transports. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Connectivity Precondition Definition . . . . . . . . . . . . . 4 71 3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.2 Operational semantics . . . . . . . . . . . . . . . . . . 5 73 3.3 Status type . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.4 Direction tag . . . . . . . . . . . . . . . . . . . . . . 5 75 3.5 Precondition strength . . . . . . . . . . . . . . . . . . 6 76 4. Verifying connectivity . . . . . . . . . . . . . . . . . . . . 7 77 4.1 Procedures for connection-oriented transports . . . . . . 8 78 4.2 Procedures for datagram transports . . . . . . . . . . . . 8 79 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 84 8.2 Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 86 Intellectual Property and Copyright Statements . . . . . . . . 17 88 1. Introduction 90 The concept of a Session Description Protocol (SDP) [2] precondition 91 in the Session Initiation Protocol (SIP) [SIP] is defined in RFC3312 92 [4] (updated by RFC4032 [6]). A precondition is a condition that has 93 to be satisfied for a given media stream in order for session 94 establishment or modification to proceed. When the precondition is 95 not met, session progress is delayed until the precondition is 96 satisfied, or the session establishment fails. For example, RFC3312 97 defines the Quality of Service precondition, which is used to ensure 98 availability of network resources prior to establishing (i.e. 99 alerting) a call. 101 SIP sessions are typically established in order to setup one or more 102 media streams. Even though a media stream may be negotiated 103 successfully, through an SDP offer-answer exchange, the actual media 104 stream itself may fail. For example, when there is one or more 105 Network Address Translators (NATs) or firewalls in the media path, 106 the media stream may not be received by the far end. In cases where 107 the media is carried over a connection-oriented transport such as TCP 108 [7], the connection-establishment procedures may fail. The 109 connectivity precondition defined in this document ensures that 110 session progress is delayed until media stream connectivity has been 111 verified, or the session itself is abandoned. 113 The connectivity precondition type defined in this document follows 114 the guidelines provided in RFC4032 [6] to extend the SIP 115 preconditions framework. 117 2. Terminology 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 121 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 122 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 123 compliant implementations. 125 3. Connectivity Precondition Definition 127 3.1 Syntax 129 The connectivity precondition type is defined by the string "conn" 130 and hence we modify the grammar found in RFC 3312 as follows: 132 precondition-type = "conn" | "qos" | token 134 This precondition tag is registered with the IANA in Section 7. 136 3.2 Operational semantics 138 According to RFC4032 [6], documents defining new precondition types 139 need to describe the behavior of UAs from the moment session 140 establishment is suspended due to a set of preconditions until is 141 resumed when these preconditions are met. An entity that wishes to 142 delay session establishment or modification until media stream 143 connectivity has been established uses this precondition-type in an 144 offer. When a mandatory connectivity precondition is received in an 145 offer, session establishment or modification is delayed until the 146 connectivity precondition has been met, i.e., media stream 147 connectivity has been established in the desired direction(s). The 148 delay of session establishment defined here implies that alerting of 149 the called party does not occur until the precondition has been 150 satisfied. 152 Packets may be both sent and received on the media streams in 153 question, however such packets SHOULD be limited to packets that are 154 necessary to verify connectivity between the two endpoints involved 155 on the media stream, i.e. the underlying media stream SHOULD NOT be 156 cut through. For example, STUN packets [STUN], RTP No-Op packets and 157 corresponding RTCP reports, as well as TCP SYN and ACK packets can be 158 exchanged on media streams that support them as a way of verifying 159 connectivity. 161 When the media stream consists of multiple destination addresses, 162 connectivity to all of them MUST be verified in order for the 163 precondition to be met. In the case of RTP-based media streams, RTCP 164 connectivity however is not a requirement. 166 3.3 Status type 168 RFC 3312 defines support for two kinds of status types, namely 169 segmented and end-to-end. The connectivity precondition-type defined 170 here MUST be used with the end-to-end status type; use of the 171 segmented status type is undefined. 173 3.4 Direction tag 175 The direction attributes defined in RFC 3312 are interpreted as 176 follows: 178 o send: The party who generated the session description (the offerer 179 in an offer-answer exchange) is sending packets on the media 180 stream to the other party, and the other party has received at 181 least one of those packets, i.e., there is connectivity in the 182 forward (sending) direction. 183 o recv: The other party (the answerer in an offer-answer exchange) 184 is sending packets on the media stream to this party, and this 185 party has received at least one of those packets, i.e., there is 186 connectivity in the backwards (receiving) direction. 187 o sendrecv: Both the send and recv conditions hold. In the case of 188 a connection-oriented transport such as TCP, once established the 189 connection would usually have an associated direction tag of 190 sendrecv because it can carry data in both directions. 192 Note that a "send" connectivity precondition from the offerer's point 193 of view corresponds to a "recv" connectivity precondition from the 194 answerer's point of view, and vice versa. If media stream 195 connectivity in both directions is required before session 196 establishment or modification continues, the desired status MUST be 197 set to "sendrecv". 199 3.5 Precondition strength 201 Connectivity preconditions may have a strength-tag of either 202 "mandatory" or "optional". 204 When a mandatory connectivity precondition is offered, and the 205 answerer cannot satisfy the connectivity precondition, e.g., because 206 the offer does not include parameters that enable connectivity to be 207 verified without media cut through, the offer MUST be rejected as 208 described in RFC 3312. 210 When an optional connectivity precondition is offered, the answerer 211 MUST generate its answer SDP as soon as possible; since session 212 progress is not delayed in this case, it is not known whether the 213 associated media streams will have connectivity. If the answerer 214 wants to delay session progress until connectivity has been verified, 215 the answerer MUST increase the strength of the connectivity 216 precondition by using a strength-tag of "mandatory" in the answer. 217 Note that use of a "mandatory" precondition requires the presence of 218 a SIP "Require" header with the option tag "precondition": Any SIP UA 219 that does not support a mandatory precondition will reject such 220 requests. To get around this issue, an optional connectivity 221 precondition and the SIP "Supported" header with the option tag 222 "precondition" can be used instead. Offers with connectivity 223 preconditions in re-INVITEs or UPDATEs follow the rules given in 224 Section 6 of RFC 3312, i.e.: 226 "Both user agents SHOULD continue using the old session parameters 227 until all the mandatory preconditions are met. At that moment, 228 the user agents can begin using the new session parameters." 230 It should be noted, that connectivity may not exist between two 231 entities initially, e.g., when one or both entities are behind a 232 symmetric NAT. Subsequent packet exchanges however may create the 233 necessary address bindings in the NAT(s) thereby creating 234 connectivity. The ICE [12] methodology for example ensures that such 235 bindings are created following an offer/answer exchange. 237 4. Verifying connectivity 239 The above definitions of send and receive connectivity preconditions 240 beg two questions: How does the sender of a packet know the other 241 party received it, and how does the receiver of a packet know who 242 sent it (in particular, the correlation between an incoming media 243 packet and a particular SIP dialog may not be obvious). 245 Media stream connectivity can be ascertained in a variety of ways. 246 This document does not mandate any particular mechanism for doing so, 247 however the appropriate machinery is likely to vary depending on the 248 type of transport used for media carriage. In order to comply with 249 the intent of an endpoint requiring connectivity preconditions, the 250 following general principles apply: 252 o The 3-way handshake connection establishment procedures of a 253 reliable transport protocol such as TCP are usually adequate to 254 demonstrate bi-directional connectivity (and hence "sendrecv" 255 media capability). Probe packets sent over the connection are 256 generally not required to satisfy the precondition. 257 o A pure datagram transport such as UDP (whether carrying RTP or 258 some other protocol) by itself provides no useful feedback about 259 connectivity. Hence, some sort of probe traffic is necessary to 260 ascertain whether packets are being received successfully. 261 o Some connection-oriented transport protocols may allow the data 262 transfer phase to operate in an unreliable mode (today there is no 263 standards-track IETF protocol which exhibits this characteristic). 264 In such cases the success of connection establishment may not 265 definitively demonstrate connectivity in the data phase, and hence 266 probe traffic MAY be necessary to ascertain if the precondition is 267 met. 268 o Hybrid protocols such as DCCP [13] provide their own feedback 269 channel and initialization procedures, which can serve to verify 270 connectivity without the use of explicit probe traffic. 272 The determination depends on the exact method being used to verify 273 connectivity. 275 4.1 Procedures for connection-oriented transports 277 TCP connections are bidirectional and hence there is no difference 278 between send and recv connectivity preconditions. Once the TCP 279 three-way hand shake has completed (SYN, SYN-ACK, ACK), the TCP 280 connection is established and data can be sent and received by either 281 party, i.e. both a send and a receive connectivity precondition has 282 been satisfied. Implementations SHOULD NOT require the receipt of 283 probe traffic in order to consider the precondition satisfied. 285 SCTP [8] connections have similar semantics as TCP and SHOULD be 286 treated the same as TCP. 288 4.2 Procedures for datagram transports 290 Verification of connectivity on datagram transports usually entail 291 the sending of probe traffic with some form of feedback to inform the 292 sender whether reception was successful. Any of the following 293 techniques MAY be used. Other techniques which meet the requirement 294 of Section 4 above MAY also be used. 296 o RTP no-op [11]: The sender of an RTP No-Op payload can verify send 297 connectivity by examining the RTCP report(s) being returned. In 298 particular, the source SSRC in the RTCP report block is used for 299 correlation. The RTCP report block also contains the SSRC of the 300 sender of the report and the SSRC of incoming RTP No-Op packets 301 identifies the sender of the RTP packet. Thus, once send 302 connectivity has been ascertained, receipt of an RTP No-Op packet 303 from the same SSRC provides the necessary correlation to determine 304 receive connectivity. Alternatively, the duality of send and 305 receive preconditions can be exploited, with one side confirming 306 when his send precondition is satisfied, which in turn implies the 307 other sides recv precondition is satisfied. 308 o STUN [2]: The STUN binding request message sent to check 309 connectivity contains a transaction ID which is returned in the 310 STUN binding response, thus send connectivity is verified easily. 311 STUN binding requests also contain a username and a password which 312 ICE [12] communicates via SIP. When an incoming STUN message is 313 received, it is therefore easy to determine the source of that 314 message and hence receive connectivity can be determined that way. 315 ICE presents the peer with a number of alternative candidate 316 addresses for a particular media stream. Once connectivity has 317 been verified for one of those candidate addresses, connectivity 318 has been verified, regardless of whether this candidate address is 319 the one that ends up being used. If a media stream consists of 320 multiple destination addresses, verification of a candidate 321 address for each must occur in order for the precondition to be 322 satisfied. 324 It is however RECOMMENDED that the No-Op RTP payload format be 325 supported by entities that support connectivity preconditions. This 326 will ensure that all entities that require probe traffic to support 327 the connectivity preconditions have at least one common way of 328 ascertaining connectivity. 330 5. Examples 332 The first example uses the connectivity precondition with TCP in the 333 context of a session involving a wireless access medium. Both UAs 334 use a radio access network that does not allow them to send any data 335 (not even a TCP SYN) until a radio bearer has been setup for the 336 connection. Figure 1 shows the message flow of this example (the 337 PRACK transaction has been omitted for clarity): 339 A B 340 | INVITE | 341 | a=curr:conn e2e none | 342 | a=des:conn mandatory e2e sendrecv | 343 | a=setup:holdconn | 344 |----------------------------------->| 345 | | 346 | 183 Session Progress | 347 | a=curr:conn e2e none | 348 | a=des:conn mandatory e2e sendrecv | 349 | a=setup:holdconn | 350 |<-----------------------------------| 351 | | 352 | UPDATE | 353 | a=curr:conn e2e none | 354 | a=des:conn mandatory e2e sendrecv | 355 A's radio | a=setup:actpass | 356 bearer is +----------------------------------->| 357 up | | 358 | 200 OK | 359 | a=curr:conn e2e none | 360 | a=des:conn mandatory e2e sendrecv | 361 | a=setup:active | 362 |<-----------------------------------| 363 | | 364 | | 365 | | 366 | | B's radio 367 |<---TCP Connection Establishment--->+ bearer is up 368 | | B sends TCP SYN 369 | | 370 | | 371 | 180 Ringing | TCP connection 372 |<-----------------------------------+ is up 373 | | B alerts the user 374 | | 376 Figure 1: Message flow with two types of preconditions 378 A sends an INVITE requesting connection-establishment preconditions. 379 The setup attribute in the offer is set to holdconn because A cannot 380 send or receive any data before setting up a radio bearer for the 381 connection. 383 B agrees to use the connectivity precondition by sending a 183 384 (Session Progress) response. The setup attribute in the answer is 385 also set to holdconn because B, like A, cannot send or receive any 386 data before setting up a radio bearer for the connection. 388 When A's radio bearer is ready, A sends an UPDATE to B with a setup 389 attribute with a value of actpass. This attribute indicates that A 390 can perform an active or a passive TCP open. A is letting B choose 391 which endpoint will initiate the connection. 393 Since B's radio bearer is not ready yet, B chooses to be the one 394 initiating the connection and indicates so with a setup attribute 395 with a value of active. At a later point, when B's radio bearer is 396 ready, B initiates the TCP connection towards A. 398 Once the TCP connection is established successfully, B alerts the 399 callee and sends a 180 (Ringing) response. 401 The second example shows a basic SIP session establishment using SDP 402 connectivity preconditions and RTP No-Op. Note that not all SDP 403 details are provided in the following. below shows the message flow 404 for this scenario shown in Figure 2 below. 406 A B 408 | | 409 |-------------(1) INVITE SDP1--------------->| 410 | | 411 |<------(2) 183 Session Progress SDP2--------| 412 | | 413 |<~~~~~ Connectivity check to A ~~~~~~~~~~~~~| 414 | | 415 |----------------(3) PRACK------------------>| 416 | | 417 |~~~~~ Connectivity to A OK ~~~~~~~~~~~~~~~~>| 418 | | 419 |<-----------(4) 200 OK (PRACK)--------------| 420 | | 421 |~~~~~ Connectivity check to B ~~~~~~~~~~~~~>| 422 |<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~| 423 | | 424 |-------------(5) UPDATE SDP3--------------->| 425 | | 426 |<--------(6) 200 OK (UPDATE) SDP4-----------| 427 | | 428 |<-------------(7) 180 Ringing---------------| 429 | | 430 | | 431 | | 433 Figure 2: Connectivity precondition with RTP no-op 435 SDP1: A includes a mandatory end-to-end connectivity precondition 436 with a desired status of "sendrecv"; this will ensure media stream 437 connectivity in both directions before continuing with the session 438 setup. Since media stream connectivity in either direction is 439 unknown at this point, the current status is set to "none". A's 440 local status table (see RFC 3312) for the connectivity precondition 441 is as follows: 443 Direction | Current | Desired Strength | Confirm 444 -----------+----------+------------------+---------- 445 send | no | mandatory | no 446 recv | no | mandatory | no 448 and the resulting offer SDP is: 450 m=audio 20000 RTP/AVP 0 96 451 c=IN IP4 192.0.2.1 452 a=rtpmap:96 no-op/8000 453 a=curr:conn e2e none 454 a=des:conn mandatory e2e sendrecv 456 SDP2: When B receives the offer, B sees the mandatory sendrecv 457 connectivity precondition. B can ascertain connectivity to A ("send" 458 from B's point of view) by use of the RTP No-Op, however B wants A to 459 inform it about connectivity in the other direction ("recv" from B's 460 point of view). B's local status table therefore looks as follows: 462 Direction | Current | Desired Strength | Confirm 463 -----------+----------+------------------+---------- 464 send | no | mandatory | no 465 recv | no | mandatory | no 467 Since B wants to ask A for confirmation about the "recv" (from B's 468 point of view) connectivity precondition, the resulting answer SDP 469 becomes: 471 m=audio 30000 RTP/AVP 0 96 472 a=rtpmap:96 no-op/8000 473 c=IN IP4 192.0.2.4 474 a=curr:conn e2e none 475 a=des:conn mandatory e2e sendrecv 476 a=conf:conn e2e recv 478 Meanwhile, B performs a connectivity check to A, which succeeds and 479 hence B's local status table is updated as follows: 481 Direction | Current | Desired Strength | Confirm 482 -----------+----------+------------------+---------- 483 send | yes | mandatory | no 484 recv | no | mandatory | no 486 Since the "recv" connectivity precondition (from B's point of view) 487 is still not satisfied, session establishment remains suspended. 488 SDP3: When A receives the answer SDP, A notes that confirmation was 489 requested for B's "recv" connectivity precondition, which is the 490 "send" precondition from A's point of view. A performs a 491 connectivity check to B, which succeeds, and A's local status table 492 becomes: 494 Direction | Current | Desired Strength | Confirm 495 -----------+----------+------------------+---------- 496 send | yes | mandatory | yes 497 recv | no | mandatory | no 499 Since B asked for confirmation about the "send" connectivity (from 500 A's point of view), A now sends an UPDATE (5) to B to confirm the 501 connectivity from A to B: 503 m=audio 20000 RTP/AVP 0 96 504 a=rtpmap:96 no-op/8000 505 c=IN IP4 192.0.2.1 506 a=curr:conn e2e send 507 a=des:conn mandatory e2e sendrecv 509 6. Security Considerations 511 In addition to the general security considerations for preconditions 512 provided in RFC 3312, the following security issues, which are 513 specific to connectivity preconditions, should be considered. 515 Connectivity preconditions rely on mechanisms beyond SDP, e.g. 516 TCP[7] connection establishment, RTP No-Op [11] or STUN [9], to 517 establish and verify connectivity between an offerer and an answerer. 518 An attacker that prevents those mechanism from succeeding can prevent 519 media sessions from being established and hence it is RECOMMENDED 520 that such mechanisms are adequately secured by message authentication 521 and integrity protection. Also, the mechanisms SHOULD consider how 522 to prevent denial of service attacks. Similarly, an attacker that 523 can forge packets for these mechanisms can enable sessions to be 524 established when there in fact is no media connectivity, which may 525 lead to a poor user experience. Authentication and integrity 526 protection of such mechanisms can prevent this type of attacks and 527 hence use of it is RECOMMENDED. 529 It is also strongly RECOMMENDED that integrity protection be applied 530 to the SDP session descriptions. S/MIME [5] is the natural choice to 531 provide such end-to-end integrity protection, as described in RFC 532 3261 [3]. 534 7. IANA Considerations 536 IANA is hereby requested to register a RFC 3312 precondition type 537 called "conn" with the name "Connectivity precondition". The 538 reference for this precondition type is the current document. 540 8. References 541 8.1 Normative References 543 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 544 Levels", BCP 14, RFC 2119, March 1997. 546 [2] Handley, M. and V. Jacobson, "SDP: Session Description 547 Protocol", RFC 2327, April 1998. 549 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 550 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 551 Session Initiation Protocol", RFC 3261, June 2002. 553 [4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 554 Resource Management and Session Initiation Protocol (SIP)", 555 RFC 3312, October 2002. 557 [5] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 558 Requirement for the Session Initiation Protocol (SIP)", 559 RFC 3853, July 2004. 561 [6] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation 562 Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. 564 8.2 Informative References 566 [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 567 September 1981. 569 [8] Stone, J., Stewart, R., and D. Otis, "Stream Control 570 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 571 September 2002. 573 [9] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 574 - Simple Traversal of User Datagram Protocol (UDP) Through 575 Network Address Translators (NATs)", RFC 3489, March 2003. 577 [10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 578 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 580 [11] Andreasen, F., "RTP No-Op Payload Format", 581 draft-wing-avt-rtp-noop-01 (work in progress), October 2004. 583 [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 584 Methodology for Network Address Translator (NAT) Traversal for 585 Multimedia Session Establishment Protocols", 586 draft-ietf-mmusic-ice-04 (work in progress), February 2005. 588 [13] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 589 draft-ietf-dccp-spec-11 (work in progress), March 2005. 591 Authors' Addresses 593 Flemming Andreasen 594 Cisco System, Inc. 595 499 Thornall Street, 8th Floor 596 Edison, NJ 08837 597 USA 599 Email: fandreas@cisco.com 601 Gonzalo Camarillo 602 Ericsson 603 Hirsalantie 11 604 Jorvas 02420 605 Finland 607 Email: Gonzalo.Camarillo@ericsson.com 609 David Oran 610 Cisco Systems, Inc 611 7 Ladyslipper Lane 612 Acton, MA 01720 613 USA 615 Email: oran@cisco.com 617 Dan Wing 618 Cisco Systems, Inc. 619 170 West Tasman Drive 620 San Jose, CA 94301 621 USA 623 Email: dwing@cisco.com 625 Intellectual Property Statement 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed to 629 pertain to the implementation or use of the technology described in 630 this document or the extent to which any license under such rights 631 might or might not be available; nor does it represent that it has 632 made any independent effort to identify any such rights. Information 633 on the procedures with respect to rights in RFC documents can be 634 found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use of 639 such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository at 641 http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at 647 ietf-ipr@ietf.org. 649 Disclaimer of Validity 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 654 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 655 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 656 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Copyright Statement 661 Copyright (C) The Internet Society (2005). This document is subject 662 to the rights, licenses and restrictions contained in BCP 78, and 663 except as set forth therein, the authors retain all their rights. 665 Acknowledgment 667 Funding for the RFC Editor function is currently provided by the 668 Internet Society.