idnits 2.17.1 draft-rescorla-mmusic-ice-lite-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 364. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 25, 2007) is 6268 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) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '5') (Obsoleted by RFC 5389) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Network Resonance 4 Intended status: Standards Track February 25, 2007 5 Expires: August 29, 2007 7 Implementing Interactive Connectivity Establishment (ICE) in Lite Mode 8 draft-rescorla-mmusic-ice-lite-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Interactive Connectivity Establishment (ICE) is a technique for 42 discovering a set of addresses which two peers can use to 43 communicate, even in the face of topological obstacles such as NATs. 44 Because the topologies in which ICE may be used are complex, a full 45 ICE implementation is also fairly complex. Implementation which will 46 only be deployed in settings where they have public addresses (e.g., 47 SIP-PSTN gateways) can, however, be substantially simpler. This 48 document describes a subset of ICE suitable for such implementations. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 54 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3 55 4. How to Read This Document . . . . . . . . . . . . . . . . . . . 5 56 5. Lite ICE Specification . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 5 58 5.2. Setting Priorities . . . . . . . . . . . . . . . . . . . . 5 59 5.3. Encoding Candidates in SDP . . . . . . . . . . . . . . . . 6 60 5.4. Receiving SDP Offers/Answers . . . . . . . . . . . . . . . 6 61 5.5. Processing Periodic Checks . . . . . . . . . . . . . . . . 6 62 5.6. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 8.2. Informational References . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Intellectual Property and Copyright Statements . . . . . . . . . . 9 71 1. Introduction 73 Network Address Translation (NAT) devices are a major obstacle to 74 protocols in which a pair of network elements need to form a direct 75 connection. In many cases, such elements are able to talk to each 76 other directly using a signalling protocol such as SIP [4] but for 77 efficiency reasons want to send data (e.g., media over RTP [1]) 78 directly. 80 A number of techniques are available for traversing NATs, but 81 entities need a mechanism for discovering which technique will work 82 in its specific environment (and its peer's environment). Internet 83 Connectivity Establishment (ICE) [3] is such a technique. 85 The basic principle behind ICE is that each entity collects all the 86 addresses on which it might potentially be able to send and receive 87 data. These may include its local address, addresses discovered via 88 STUN [5] or addresses provided by media relays [6]. The peers then 89 exchange these candidate addresses and try each potential pairing in 90 priority order until they find one that is satisfactory. 92 During the design of ICE, many implementors expressed concern about 93 the complexity of the protocol and the difficulty of implementing it. 94 This draft specifies a compatible simplified subset of ICE called 95 "ICE Lite" which is suitable for implementations which will always be 96 operated with public IP addresses. One particular environment where 97 ICE Lite is intended to be useful is in SIP-PSTN gateways which are 98 generally directly connected to the Internet. 100 2. Conventions Used In This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [2]. 106 3. Overview of Operation 108 A Lite Ice Implementation (LII) behaves much like a normal ICE 109 implementation, with three major differences: 110 o It only gathers candidate addresses from its own interfaces. 111 o It cannot be a controlling endpoint. 112 o It does not generate checks but only responds to periodic checks 113 from other endpoints. 115 A LII can interoperate with a Full ICE Implementation (FII). there is 116 a subtle point here; ICE is intended to establish bi-directional 117 connectivity and the LII must have a way to know that its messages 118 are getting through to the other endpoint. Ordinarily this would be 119 done by having both sides perform checks but in order to optimize for 120 simplicity of the LII, the LII does not do so. Rather, we use the 121 fact that the FII receives the LII's STUN response as an implicit 122 check. This requires that the LII receive some message from the peer 123 that its message was received. This is accomplished by having the 124 FII issue two checks. The first check omits the USE-CANDIDATE flag 125 and so the LII will not attempt to use the candidate pair. The 126 second check includes the USE-CANDIDATE flag and so tells the LII 127 that the pair is safe to use. 129 The interaction of an LII and an FII is shown below. 131 FII LII 132 --- --- 133 SDP Offer -> \ 134 <- SDP Answer > First offer/answer 135 + lite flag / 137 STUN request -> \ Periodic 138 <- STUN response / Check 140 STUN request -> \ Candidate 141 + USE-CANDIDATE flag > Selection 142 <- STUN response / 144 As with any ICE implementation, the first thing that happens is that 145 the peers exchange SDP offer and answer. The LII attaches the a=ice- 146 lite attribute to indicate that it does ICE Lite. This has two 147 implications for the peer: 149 1. It must be the controlling endpoint. 150 2. It must not send the USE-CANDIDATE flag the first time it 151 performs any check. 153 As indicated above, the LII does not perform any checks. Thus, they 154 must all be driven by the FII. The FII follows its usual behavior of 155 creating the check list and starts performing checks. It sends all 156 of its checks without the USE-CANDIDATE flag and only once it has a 157 successful check on a candidate that it was willing to use does it 158 send a second check on that candidate pair with the USE-CANDIDATE 159 flag. 161 Two LIIs will interoperate but will not do ICE. 163 4. How to Read This Document 165 This document is intended to mostly relieve the implementor of a Lite 166 ICE implementation from the burden of having to read and understand 167 all of RFC XXXX [[Insert ICE RFC # here] [3]. However, it is not 168 intended to be a standalone document. Rather it is intended to be 169 read in conjunction with RFC XXXX. We assume that the reader is 170 roughly familiar with how ICE works and has read at least Sections 171 1-3 of RFC XXXX. 173 Section Section 5, contains a description of the responsibilities of 174 a Lite Ice Implementation (LII). Each section follows the same 175 pattern: expository text followed by a pointer to the relevant 176 section of RFC XXXX. 178 5. Lite ICE Specification 180 A LII performs the following tasks: 182 1. Gathering candidates. 183 2. Sending an SDP offer/answer 184 3. Processing the peer's offer/answer 185 4. Responding to checks from peer endpoints. 186 5. Determining that candidate pairs are valid and/or favored 188 5.1. Gathering Candidates 190 Like any ICE implementation, a LII gathers candidates. However, 191 unlike full ICE implementations, a LII gathers them only from its 192 locally attached interfaces (host candidates). Other kinds of 193 candidates are not necessary because a LII by definition has a public 194 IP address. A LII may offer only one candidate per component. Note 195 that this process is the same as what a non-ICE implementation does, 196 namely allocating ports from the local interface. 198 See: Sections 2.1 (paragraphs 1,2), 4.1 (paragraphs 1-4), 4.2 200 5.2. Setting Priorities 202 As with full-mode ICE, the candidates must be prioritized, using the 203 algorithm defined in RFC XXX S 4.1.2. However, a LII will only have 204 one candidate type: host. The type preference SHOULD be set to 126. 206 The endpoint SHOULD set the local preference to 65535. 208 The component IDs are set as in RFC XXXX. For RTP this means 209 component ID 1 and RTCP component ID 2. 211 Using these settings, an endpoint which wished to do RTP only would 212 have a single candidate with priority 2130706431 (0x7effffff). 214 An endpoint which to do both RTP and RTCP would have priotities 215 2130706431 (0x7effffff) for RTP and 2130706430 (0x7efffffe) for RTCP. 217 See: Section 4.1.2 219 5.3. Encoding Candidates in SDP 221 Once the candidates are gathered, a LII must encode them in an SDP 222 offer or answer. Each candidate contains the IP address and port of 223 the candidate and the priority computed in the previous sectoin. 224 There will be one candidate for each component. All candidates MUST 225 be marked as host candidates. 227 In addition, a LII must set the "a=ice-lite" session-level attribute 228 in order to indicate that it is not a full ICE implementation. 230 See: Sections 4.3 232 5.4. Receiving SDP Offers/Answers 234 When an LII receives an SDP offer or answer from a peer, it MUST 235 first verify that the peer did not offer the "a=ice-lite" attribute. 236 If it did, ICE processing MUST be terminated. 238 Although an LII does not maintain a check list, when it receives an 239 offer or answer it needs to extract all the ufrag/upass values from 240 the SDP in order to use them to verify the STUN integrity checks. It 241 also must identify the set of all media streams and components for 242 which ICE must be established. 244 See: Section 5.1. 246 5.5. Processing Periodic Checks 248 During ICE discovery, a LII will receive Binding Requests on the 249 bases of some or all of the candidates it included in its most recent 250 offer or answer. When such a Binding Request is received, the LII 251 MUST: 253 o Generate a STUN binding response. 254 o If the request contains the USE-CANDIDATE flag, create a new 255 candidate pair corresponding to the addresses in the STUN request, 256 add it to the Valid list and mark it "favored". 258 As with ordinary ICE, the LII must combine its ufrag with the peers 259 ufrag and use the correct password (from the SDP) to integrity check 260 the STUN request. Once the request has been integrity checked, the 261 LII generates a STUN response containing the transport-level source 262 address in the XOR-MAPPED-ADDRESS field. 264 Media may be sent on a candidate pair as soon as it is added to the 265 Valid list. Once there is at least one entry on the Valid list for 266 each component of each media stream, ICE processing is finished. 268 See: Sections 7.2, 7.2.2, Section 8. 270 5.6. Keepalives 272 Like all ICE implementations, all LIIs must send keepalives on active 273 candiate pairs and be prepared to receive keepalives. 275 See: Section 11. 277 6. Security Considerations 279 The security considerations for this document are the same as those 280 for full ICE. 282 7. IANA Considerations 284 This document has no actions for IANA. 286 8. References 288 8.1. Normative References 290 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 291 "RTP: A Transport Protocol for Real-Time Applications", 292 RFC 1889, January 1996. 294 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 295 Levels", BCP 14, RFC 2119, March 1997. 297 [3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 298 Methodology for Network Address Translator (NAT) Traversal for 299 Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in 300 progress), January 2007. 302 8.2. Informational References 304 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 305 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 306 Session Initiation Protocol", RFC 3261, June 2002. 308 [5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - 309 Simple Traversal of User Datagram Protocol (UDP) Through Network 310 Address Translators (NATs)", RFC 3489, March 2003. 312 [6] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 313 Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in 314 progress), October 2006. 316 Author's Address 318 Eric Rescorla 319 Network Resonance 320 2483 E. Bayshore #212 321 Palo Alto, CA 94303 322 USA 324 Email: ekr@networkresonance.com 326 Full Copyright Statement 328 Copyright (C) The IETF Trust (2007). 330 This document is subject to the rights, licenses and restrictions 331 contained in BCP 78, and except as set forth therein, the authors 332 retain all their rights. 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Intellectual Property 344 The IETF takes no position regarding the validity or scope of any 345 Intellectual Property Rights or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; nor does it represent that it has 349 made any independent effort to identify any such rights. Information 350 on the procedures with respect to rights in RFC documents can be 351 found in BCP 78 and BCP 79. 353 Copies of IPR disclosures made to the IETF Secretariat and any 354 assurances of licenses to be made available, or the result of an 355 attempt made to obtain a general license or permission for the use of 356 such proprietary rights by implementers or users of this 357 specification can be obtained from the IETF on-line IPR repository at 358 http://www.ietf.org/ipr. 360 The IETF invites any interested party to bring to its attention any 361 copyrights, patents or patent applications, or other proprietary 362 rights that may cover technology that may be required to implement 363 this standard. Please address the information to the IETF at 364 ietf-ipr@ietf.org. 366 Acknowledgment 368 Funding for the RFC Editor function is provided by the IETF 369 Administrative Support Activity (IASA).