idnits 2.17.1 draft-ietf-mmusic-connection-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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: While session establishment is suspended due to connection-establishment preconditions, user agents SHOULD not send any user data over the media streams affected by the preconditions. Additionally, the UAS (User Agent Server) SHOULD NOT alert the called user. -- 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 (December 2, 2004) is 7085 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: 'RFCXXXX' on line 227 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: June 2, 2005 December 2, 2004 5 Connection-Establishment Preconditions in the Session Initiation 6 Protocol (SIP) 7 draft-ietf-mmusic-connection-precon-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 2, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document defines the connection-establishment precondition type 43 for the SIP preconditions framework. Connection-establishment 44 preconditions are met when a transport connection (e.g., a TCP 45 connection) is successfully established between two endpoints. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Precondition Tag . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Status Type . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Direction Tag . . . . . . . . . . . . . . . . . . . . . . . . 3 54 6. Precondition Strength . . . . . . . . . . . . . . . . . . . . 4 55 7. Suspending and Resuming Session Establishment . . . . . . . . 4 56 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 59 11. Normative References . . . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . 8 63 1. Introduction 65 RFC 3312 [3] defines a framework for preconditions for SIP [2], 66 which is updated by [5]. This document defines a new precondition 67 type for that framework: connection-establishment preconditions. 69 UAs (User Agents) use connection-establishment preconditions when 70 they need to know whether a transport connection (e.g., a TCP 71 connection) has been established successfully and is ready to carry 72 user data. 74 We define the connection-establishment precondition type following 75 the guidelines provided in [5] to extend the SIP preconditions 76 framework. 78 2. Terminology 80 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 81 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 82 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 83 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 84 compliant implementations. 86 3. Precondition Tag 88 The precondition tag associated with the connection-establishment 89 preconditions is "conn". This precondition tag is registered with 90 the IANA in Section 10. 92 4. Status Type 94 RFC 3312 [3] defines two status types, end-to-end and segmented, but 95 only the end-to-end status type applies to connection-establishment 96 preconditions. So, connection-establishment preconditions MUST use 97 the end-to-end status type and MUST NOT use the segmented status 98 type. 100 5. Direction Tag 102 RFC 3312 [3] defines four direction tags: none, send, recv, and 103 sendrecv. Once a transport connection is established, they indicate 104 in which directions the connection can carry user data. For example, 105 a successfully-established TCP connection (i.e., in ESTABLISHED 106 statate) would have an associated direction tag of sendrecv because 107 it can carry data in both directions. 109 6. Precondition Strength 111 RFC 3312 [3] defines optional and mandatory preconditions, but only 112 mandatory preconditions apply to connection-establishment 113 preconditions. So, connection-establishment preconditions MUST NOT 114 use optional preconditions. 116 7. Suspending and Resuming Session Establishment 118 According to [5], documents defining new precondition types need to 119 describe the behavior of UAs from the moment session establishment is 120 suspended due to a set of preconditions until is resumed when these 121 preconditions are met. 123 While session establishment is suspended due to 124 connection-establishment preconditions, user agents SHOULD not send 125 any user data over the media streams affected by the preconditions. 126 Additionally, the UAS (User Agent Server) SHOULD NOT alert the called 127 user. 129 Offers with connection-establishment preconditions in re-INVITEs or 130 UPDATEs follow the rules given in Section 6 of RFC 3312 [3]. 132 Both user agents SHOULD continue using the old session parameters 133 until all the mandatory preconditions are met. At that moment, 134 the user agents can begin using the new session parameters. 136 8. Example 138 The following example uses connection-establishment preconditions. 139 Both UAs use a radio access network that does not allow them to send 140 any data (not even a TCP SYN) until a radio bearer has been setup for 141 the connection. Figure 1 shows the message flow of this example (the 142 PRACK transaction has been omitted for clarity): 144 A B 145 | INVITE | 146 | a=curr:conn e2e none | 147 | a=des:conn mandatory e2e sendrecv | 148 | a=setup:holdconn | 149 |----------------------------------->| 150 | | 151 | 183 Session Progress | 152 | a=curr:conn e2e none | 153 | a=des:conn mandatory e2e sendrecv | 154 | a=setup:holdconn | 155 |<-----------------------------------| 156 | | 157 | UPDATE | 158 | a=curr:conn e2e none | 159 | a=des:conn mandatory e2e sendrecv | 160 A's radio | a=setup:actpass | 161 bearer is +----------------------------------->| 162 up | | 163 | 200 OK | 164 | a=curr:conn e2e none | 165 | a=des:conn mandatory e2e sendrecv | 166 | a=setup:active | 167 |<-----------------------------------| 168 | | 169 | | 170 | | 171 | | B's radio 172 |<---TCP Connection Establishment--->+ bearer is up 173 | | B sends TCP SYN 174 | | 175 | | 176 | 180 Ringing | TCP connection 177 |<-----------------------------------+ is up 178 | | B alerts the user 179 | | 181 Figure 1: Message flow with two types of preconditions 183 A sends an INVITE requesting connection-establishment preconditions. 184 The setup attribute in the offer is set to holdconn because A cannot 185 send or receive any data before setting up a radio bearer for the 186 connection. 188 B agrees to use connection-establishment preconditions by sending a 189 183 (Session Progress) response. The setup attribute in the answer 190 is also set to holdconn because B, like A, cannot send or receive any 191 data before setting up a radio bearer for the connection. 193 When A's radio bearer is ready, A sends an UPDATE to B with a setup 194 attribute with a value of actpass. This attribute indicates that A 195 can perform an active or a passive TCP open. A is letting B choose 196 which endpoint will initiate the connection. 198 Since B's radio bearer is not ready yet, B chooses to be the one 199 initiating the connection and indicates so with a setup attribute 200 with a value of active. At a later point, when B's radio bearer is 201 ready, B initiates the TCP connection towards A. 203 Once the TCP connection is established successfully, B alerts the 204 callee and sends a 180 (Ringing) response. 206 9. Security Considerations 208 An attacker adding preconditions to a session description or 209 modifying existing preconditions could keep sessions from being 210 established. An attacker removing preconditions from a session 211 description could force sessions to be established without meeting 212 mandatory preconditions. 214 It is thus strongly RECOMMENDED that integrity protection be applied 215 to the SDP session descriptions. S/MIME [4] is the natural choice to 216 provide such end-to-end integrity protection, as described in RFC 217 3261 [2]. 219 10. IANA Considerations 221 This document defines a new precondition type: 222 connection-establishment. It needs to be registered by the IANA 223 under the registry for Precondition Types used with SIP. 225 Pecondition-Type Description Reference 226 ---------------- ----------------------------------- --------- 227 conn Connection-establishment preconditions [RFCXXXX] 229 11 Normative References 231 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 232 Levels", BCP 14, RFC 2119, March 1997. 234 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 235 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 236 Session Initiation Protocol", RFC 3261, June 2002. 238 [3] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 239 Resource Management and Session Initiation Protocol (SIP)", RFC 240 3312, October 2002. 242 [4] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 243 Requirement for the Session Initiation Protocol (SIP)", RFC 244 3853, July 2004. 246 [5] Camarillo, G., "Update to the Session Initiation Protocol (SIP) 247 Preconditions Framework", draft-ietf-sip-rfc3312-update-03 (work 248 in progress), September 2004. 250 Author's Address 252 Gonzalo Camarillo 253 Ericsson 254 Hirsalantie 11 255 Jorvas 02420 256 Finland 258 EMail: Gonzalo.Camarillo@ericsson.com 260 Intellectual Property Statement 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at 282 ietf-ipr@ietf.org. 284 Disclaimer of Validity 286 This document and the information contained herein are provided on an 287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 289 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 290 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 291 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Copyright Statement 296 Copyright (C) The Internet Society (2004). This document is subject 297 to the rights, licenses and restrictions contained in BCP 78, and 298 except as set forth therein, the authors retain all their rights. 300 Acknowledgment 302 Funding for the RFC Editor function is currently provided by the 303 Internet Society.