idnits 2.17.1 draft-peterson-pidf-ice-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 386. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 402), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. 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). -- 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 (July 12, 2004) is 7227 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) == Unused Reference: '3' is defined on line 314, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 318, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 322, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 325, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-01 ** Obsolete normative reference: RFC 3489 (ref. '2') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-04 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-07 == Outdated reference: A later version (-10) exists of draft-ietf-simple-prescaps-ext-01 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '10') (Obsoleted by RFC 4566) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE WG J. Peterson 2 Internet-Draft NeuStar 3 Expires: January 10, 2005 July 12, 2004 5 Advertising Interactive Connectivity Establishment (ICE) Services 6 with Presence 7 draft-peterson-pidf-ice-00 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 10, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Many presence applications use availability information about a 41 presentity to show a watcher their readiness to communicate. In the 42 case of real-time multimedia communications, the readiness of the 43 presentity to communicate does not entail that the network topography 44 will permit communication to occur. Accordingly, this document 45 specifies a means to integrate Interactive Connectivity Establishment 46 (ICE) with presence. Presentities employing the Presence Information 47 Data Format (PIDF) can use the extensions in this draft to advertise 48 their ability to undergo a preliminary ICE check, and thus allow 49 watchers to instigate ICE tests to ascertain whether or not the 50 intervening network is friendly to real-time multimedia 51 communication. In a presence application, the results of this test 52 could be displayed to watchers as the relative "connectivity status" 53 of the presentity. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The 'ice' Presence Capability . . . . . . . . . . . . . . . . 3 59 3. Using ICE Prior to Session Establishment . . . . . . . . . . . 4 60 4. Using the Results of ICE in a Presence Application . . . . . . 5 61 5. XML Schema for the 'ice' Stanza . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 68 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 69 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 Intellectual Property and Copyright Statements . . . . . . . . 10 72 1. Introduction 74 Interactive Connectivity Establishment (ICE, [1]) is a mechanism that 75 employs the testing algorithms of STUN (Simple Traversal of UDP for 76 NATs, [2]) to determine how two applications on the Internet can 77 exchange real-time multimedia traffic through network topologies that 78 include Network Address Translators (NATs, [8]) and other impediments 79 to direct end-to-end connectivity. It is based on the use of a 80 higher-layer signaling protocol (such as SIP, [9]) which carries 81 session descriptions (such as SDP, [10]) between endpoints. The 82 description of the session, which includes the network address and 83 port at which media will be received by the respective endpoints, 84 serves as input to the ICE process, and is used to make a bilateral 85 determination of endpoint reachability. The results of these ICE 86 tests might influence the selection of a network address (when 87 multiple network interfaces are present), the usage of relays to 88 circumvent NATs, and so on. 90 In its initially-envisioned use, ICE is employed immediately prior to 91 the establishment of a real-time media session between endpoints. 92 For example, when a SIP INVITE is sent, and an offer/answer exchange 93 of SDP is shared, both parties to a session employ the ICE mechanism 94 to determine whether or not end-to-end connectivity is possible. 96 Presence [11]) information depicts the status and disposition of a 97 presentity towards a particular watcher. It encompasses availability 98 on the network (can I be reached now?), attitude towards 99 communication (do I want to be reached now?), and to some degree 100 application capability (what kinds of communication do I support 101 now?). However, these traditional attributes do not give any 102 indication of whether or not network topology allows communication to 103 be possible. 105 Accordingly, this specification provides a means for presence to 106 communicate a presentity's capability to perform ICE tests prior to 107 any session establishment. The results of ICE tests could be 108 rendered to the watcher to give them some idea of whether or not the 109 initiation of a real-time multimedia session with a protocol like SIP 110 is likely to be successful. This mechanism communicates a 111 presentity's ability to receive ICE tests by extending the Presence 112 Information Data Format (PIDF), a document format for transmitting 113 presence information. 115 2. The 'ice' Presence Capability 117 This specification extends the Presence Capabilities (or 'prescaps') 118 framework [7] for PIDF with a new element called 'ice'. Transmission 119 of the 'ice' stanza in a PIDF presence notification takes the place 120 of the 'initiate' message in ICE processing. The 'ice' element 121 contains an XML representation of all the data that would appear in 122 an 'initiate' message - in fact, this schema is imported directly 123 from the canonical syntax of the 'initiate' message. 125 The construction of the 'ice' element follows the rules of the ICE 126 specification, section 5.4. Since the presentity is not actually 127 formulating an SDP message with a bounded set of desired media 128 streams, the presentity must find some other way of determining how 129 to populate the media-streams element. When the 'ice' element is 130 used in concert with the remainder of the prescaps framework, 131 implementations SHOULD advertise the availability of one media stream 132 per media capability advertised by prescaps. The advertised media 133 capabilities of prescaps are, broadly, the top-level MIME types 134 advertised in the m= lines of an SDP offer. Consequently, this is 135 roughly comparable to mirroring what an SDP offer might show. 137 Network addresses and ports to be used in the media-streams element 138 SHOULD be selected in the same manner as the presentity application 139 would ordinarily select ports for constructing a session description. 140 Note that this can entail the use of STUN or other mechanisms that 141 help endpoints to unilaterally discover appropriate relay addresses. 143 3. Using ICE Prior to Session Establishment 145 As stated above, the transmission of the 'ice' stanza of prescaps 146 serves the same purpose as the ICE 'initiate' message, and contains 147 the same information. The remaining ICE procedures are largely 148 identical to those described in the ICE specification - except that 149 ICE tests are only performed by the responder. 151 Prior to sending a presence notification with an 'ice' stanza, 152 presentities MUST perform the steps described in Section 5.1, 5.2 and 153 5.3 of the ICE specification. The steps in Section 5.4 are followed 154 as the presence notification is constructed. Similarly, when a 155 compliant watcher receives a NOTIFY containing a PIDF document with 156 an 'ice' stanza, it MUST perform the steps described in Section 5.5 157 of the ICE specification. However, the watcher SHOULD NOT perform 158 the responder steps described in Section 5.6 of the ICE 159 specification, including the transmission of an ICE 'accept' message, 160 nor any of the steps specified in subsequent subsections of Section 161 5. 163 While this makes the use of ICE in this context somewhat 164 unidirectional, even the unidirectional ICE tests determine whether 165 or not round-trip connectivity is possible. For presence, only a 166 watcher requires that the connectivity status of their presence-list 167 be determined and displayed; since presence subscriptions are not 168 necessarily reciprocal, it might not be the case that any given 169 presentity would be interested to know the connectivity status of 170 some of their watchers. Presentities that are interested in the 171 connectivity status of watchers should maintain reciprocal presence 172 subscriptions with those watchers (this situation is, in most 173 presence applications, the norm anyway). 175 Note that the mechanism above will trigger an ICE test in a watcher 176 whenever a presence notification containing a PIDF document with an 177 'ice' stanza is received - no more or less frequently. Thus, if the 178 network topology surrounding the watcher or presentity changes 179 without the transmission of any new presence notification from the 180 presentity, the results of the ICE test may become outdated. There 181 is, however, no reasonable way for the presentity to monitor overall 182 network topology with respect to each potential watcher in order to 183 time the transmission of presence notifications. This is, therefore, 184 a limitation of the mechanism. It is RECOMMENDED that applications 185 transmit new presence notifications when there are known changes to 186 the manner in which they interface with the network, including 187 expiration of DHCP leases or acquisition of new network interfaces, 188 including VPNs. However, implementations SHOULD NOT attempt to 189 monitor network topology through other means, and MUST NOT use 190 constant pings or similar invasive monitoring techniques to determine 191 the necessity of triggering a new ICE test. 193 On the flip side, sending presence notifications expressing ICE 194 capability too frequently could results in redundant and unnecessary 195 ICE tests, which could unnecessarily burden the applications or 196 intervening network. The frequency of presence notifications is 197 generally bounded by applications, but could have a minimum interval 198 as low a second. Presence notifications containing a 'ice' stanza 199 SHOULD NOT be sent more frequently than once a minute. 201 4. Using the Results of ICE in a Presence Application 203 Once the ICE tests have been performed, a watcher's application MAY 204 render the results of the tests to the watcher. The manner in which 205 it does so is application-specific, and not a subject of 206 standardization. For informative purposes, an example application 207 result is given here. 209 A watcher application might express four states associated with a 210 presentity in a presence-list: question-mark, green, yellow, and red. 211 These states could be displayed as icons alongside the presentity's 212 name, where: 213 question-mark signifies that the presentity does not support the 214 'ice' prescap, or that no presence notifications have been 215 received containing that prescap, and therefore the connectivity 216 status of the presentity is unknown 217 green signifies that there is a clean path of connectivity between 218 the presentity and the watcher; the establishment of real-time 219 multimedia sessions between the two would most likely be 220 successful 221 yellow signifies that there are network or transport-layer 222 disparities between the presentity and the watcher, but that known 223 and available relays can be used to traverse these disparities; 224 connectivity is possible through these relays 225 red signifies that there are network or transport-layer 226 disparities between the presentity and the watcher than cannot be 227 circumvented with the tools known to the watcher; new relays or 228 other middleboxes would need to be engaged to make real-time 229 multimedia sessions possible 231 When a presentity publishes presence from multiple sources, rendering 232 of the results of an ICE test naturally lends itself to the 'device 233 view' of presence. For example, it could be used in concert with 234 other preference information in presence to prioritize the devices at 235 which the presentity could be reached. 237 5. XML Schema for the 'ice' Stanza 239 The ICE specification already gives an XML Schema for the ICE 240 'initiate' message (in Section 7). Accordingly, this schema is 241 imported into the 'ice' prescaps element. Note that the only valid 242 message type that can appear in the 'ice' prescap element is the 243 'initiate' message. 245 246 253 255 256 257 258 259 260 262 6. Security Considerations 264 Providing network addresses and ports in presence potentially exposes 265 device information that end users might not want to divulge. In this 266 respect, the information provided in the 'ice' presence capability 267 shares the privacy concerns common to most forms of presence 268 information. Fortunately, presence authorization has been 269 well-studied, and numerous mechanisms exist to prevent the 270 distribution of presence attributes to undesired parties. 271 Implementers and end-users of presence applications employing this 272 mechanism should be careful to treat the 'ice' presence capability 273 with the same privacy preferences as other forms of presence. 274 Presence notifications in SIP can supply confidentiality properties 275 (through baseline security mechanisms, including S/MIME) that prevent 276 eavesdroppers from overhearing addresses sent to authorization 277 watchers. 279 The Security Considerations of the ICE specification note the 280 importance of integrity protection to the ICE process. Without 281 integrity protection, it would be possible for an attacker to modify 282 the 'ice' stanza of a presence notification in transit, and by 283 substituting bad addresses the attacker might persuade the watcher 284 that connectivity with the presentity is impossible. Presence 285 notifications in SIP can supply integrity properties (through 286 baseline security mechanisms, including S/MIME) that prevent 287 men-in-the-middle from modifying the contents of a presence 288 notification. 290 7. Examples 292 [Ed. Note: TBD] 294 8. IANA Considerations 296 This document registers a new XML namespaces for the 'ice' stanza of 297 the prescaps extension to PIDF. 299 [Ed. Note: Registration details TBD] 301 9. References 303 9.1 Normative References 305 [1] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 306 Methodology for Network Address Translator (NAT) Traversal for 307 Multimedia Session Establishment Protocols", 308 draft-ietf-mmusic-ice-01 (work in progress), February 2004. 310 [2] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 311 Simple Traversal of User Datagram Protocol (UDP) Through Network 312 Address Translators (NATs)", RFC 3489, March 2003. 314 [3] Rosenberg, J., Huitema, C. and R. Mahy, "Traversal Using Relay 315 NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress), 316 February 2004. 318 [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 319 J. Peterson, "CPIM Presence Information Data Format", 320 draft-ietf-impp-cpim-pidf-07 (work in progress), August 2001. 322 [5] Bradner, S., "Key words for use in RFCs to indicate requirement 323 levels", RFC 2119, March 1997. 325 [6] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 326 2004. 328 [7] Lonnfors, M. and K. Kiss, "User Agent Capability Extension to 329 Presence Information Data Format (PIDF)", 330 draft-ietf-simple-prescaps-ext-01 (work in progress), May 2004. 332 9.2 Informative References 334 [8] Senie, D., "Network Address Translator (NAT)-Friendly 335 Application Design Guidelines", RFC 3235, January 2002. 337 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 338 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 339 Session Initiation Protocol", RFC 3261, May 2002. 341 [10] Handley, M. and V. Jacobson, "SDP: Session Description 342 Protocol", RFC 2327, April 1998. 344 [11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 345 Instant Messaging", RFC 2778, February 2000. 347 Author's Address 349 Jon Peterson 350 NeuStar, Inc. 351 1800 Sutter St 352 Suite 570 353 Concord, CA 94520 354 US 356 Phone: +1 925/363-8720 357 EMail: jon.peterson@neustar.biz 358 URI: http://www.neustar.biz/ 360 Appendix A. Acknowledgments 362 Thanks to Jonathan Rosenberg for some useful advice on ICE. 364 Intellectual Property Statement 366 The IETF takes no position regarding the validity or scope of any 367 Intellectual Property Rights or other rights that might be claimed to 368 pertain to the implementation or use of the technology described in 369 this document or the extent to which any license under such rights 370 might or might not be available; nor does it represent that it has 371 made any independent effort to identify any such rights. Information 372 on the procedures with respect to rights in RFC documents can be 373 found in BCP 78 and BCP 79. 375 Copies of IPR disclosures made to the IETF Secretariat and any 376 assurances of licenses to be made available, or the result of an 377 attempt made to obtain a general license or permission for the use of 378 such proprietary rights by implementers or users of this 379 specification can be obtained from the IETF on-line IPR repository at 380 http://www.ietf.org/ipr. 382 The IETF invites any interested party to bring to its attention any 383 copyrights, patents or patent applications, or other proprietary 384 rights that may cover technology that may be required to implement 385 this standard. Please address the information to the IETF at 386 ietf-ipr@ietf.org. 388 Disclaimer of Validity 390 This document and the information contained herein are provided on an 391 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 392 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 393 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 394 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 395 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 396 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 398 Copyright Statement 400 Copyright (C) The Internet Society (2004). This document is subject 401 to the rights, licenses and restrictions contained in BCP 78, and 402 except as set forth therein, the authors retain all their rights. 404 Acknowledgment 406 Funding for the RFC Editor function is currently provided by the 407 Internet Society.