idnits 2.17.1 draft-finlayson-umtp-09.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 613 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 37 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 175 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 572, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ross Finlayson 2 Internet-Draft LIVE.COM 3 Expire in six months 2003.11.21 5 The UDP Multicast Tunneling Protocol 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 Many Internet hosts - such as PCs - while capable of running multicast 34 applications, cannot access the MBone (or other wide-area multicast 35 network) because the router(s) that connect them to the Internet 36 do not yet support IP multicast routing. The ''UDP Multicast Tunneling 37 Protocol'' (UMTP) enables such a host to establish an 'ad hoc' connection 38 to the MBone by tunneling multicast UDP datagrams inside unicast UDP 39 datagrams. By using UDP, this tunneling can be implemented as a 40 'user level' application, without requiring changes to the host's 41 operating system. 43 3. Revision History 45 November 2003: draft-finlayson-umtp-09.txt 46 Bumped the file's version number, to get the I-D editor to 47 accept it this time. 49 October 2003: draft-finlayson-umtp-08.txt 50 Updated the references to the RTP RFC, 51 and the "Source-Specific Multicast" I-D. 53 September 2002: draft-finlayson-umtp-07.txt 54 Made it clear that UMTP does not include a tunnel endpoint 55 location protocol. 56 Expanded the "Security Considerations" section to better explain 57 the 'cookies' mechanism. 58 Updated the reference to the "Source-Specific Multicast" I-D. 60 March 2001: draft-finlayson-umtp-06.txt 61 Removed the word "encapsulation", because it was not strictly 62 accurate, and was confusing some people into thinking 63 that the original packet's UDP/IP headers were being 64 carried within a DATA packet. (Instead, only the orignal 65 UDP payload is carried, plus the "tunneling trailer" 66 that carries the important information from the original 67 headers.) 68 Cleaned up and shortened the abstract, to fit in one paragraph. 70 February 2001: draft-finlayson-umtp-05.txt 71 Corrected the version numbers in this revision history. 73 December 2000: draft-finlayson-umtp-04.txt 74 Added an example to illustrate the operation of the protocol. 75 Added a description of the extended trailer (and commands) 76 that are used to tunnel Source-Specific Multicast ("SSM") 77 Corrected a URL 79 September 1998: draft-finlayson-umtp-03.txt 80 Added descriptions of two new commands: JOIN_RTP_GROUP 81 and LEAVE_RTP_GROUP, for optimizing the control of 82 RTP/RTCP sessions. 84 February 1998: draft-finlayson-umtp-02.txt 85 Rearranged the fields in the "tunneling trailer" to allow for 86 possible variable-sized trailers in the future. 88 December 1997: draft-finlayson-umtp-01.txt 89 Changed the "tunneling header" into a "tunneling trailer". 90 Added 'cookie' fields as nonces to prevent source address 91 spoofing. 93 December 1997: draft-finlayson-umtp-01.txt 94 Original draft. 96 4. Overview 98 UMTP operates using (unicast) UDP datagrams between pairs of nodes - each 99 pair forming the endpoints of a "tunnel". Each datagram is either a 100 "command" (e.g., instructing the destination endpoint to join or leave a 101 group address & port); or "data": an enclosed multicast UDP datagram 102 payload, along with the destination (group, port) tuple. 104 For each (group, port) being tunneled, a tunnel endpoint can act either as 105 a "master" or a "slave". A tunnel master (for a particular (group, port)) 106 periodically sends a JOIN_GROUP command to the remote endpoint (a slave), 107 instructing it that this (group, port) is still of interest, and should be 108 tunneled (or continue to be tunneled). A slave will stop tunneling a 109 (group, port) if it either (i) receives a LEAVE_GROUP command from the 110 master, or (ii) has not received any JOIN_GROUP commands for some period of 111 time (currently, 60 seconds). Typically, a host that is trying to access 112 the MBone (e.g., a PC) will be a master, and its remote endpoint (a host 113 already on the MBone) will be a slave. (It is also possible, however, for 114 both endpoints of a tunnel to be masters.) 116 Whenever a tunnel endpoint - whether a master or a slave - receives a 117 multicast UDP datagram addressed to a (group, port) that is currently 118 being tunneled, it resends its payload (along with a "tunneling trailer") 119 as a unicast datagram addressed to the other end of the tunnel. 120 Conversely, whenever a tunnel endpoint receives, over the tunnel, a 121 tunneled unicast datagram for a (group, port) of interest, it resends 122 its payload as a multicast datagram (with a TTL that was specified as 123 a parameter in the "tunneling trailer"). 125 A node (typically a slave server) can be the endpoint of several different 126 UMTP tunnels - i.e., each with a different endpoint master. Although, 127 superficially, such a system appears similar to a multicast<->unicast 128 reflector, it differs in two ways: 129 (i) The tunneling is application-independent, and handles any (UDP) 130 multicast packets. 131 (ii) After traversing a tunnel, a tunneled payload is delivered to the 132 endpoint's application(s) via multicast, not unicast. This allows regular 133 multicast-based applications to make use of a UMTP tunnels (subject to some 134 restrictions described below). 136 UMTP does not define the means by which each node chooses a remote node 137 to act as a tunnel endpoint. Tunnels could be set up 'by hand', or else 138 a separate (unspecified) tunnel endpoint location protocol might be used. 140 5. Restrictions 142 UMTP allows a multicast-capable - but otherwise non-MBone-connected - host 143 to run multicast-based applications. Such applications, however, must 144 satisfy the following conditions: 145 1/ Their multicast packets must all be UDP - not 'raw' IP 146 2/ The UMTP implementation (i.e., a tunnel endpoint) must have 147 a way of knowing each (group, port) that the application uses. 148 3/ The application must not rely upon the source address of its 149 incoming multicast packets being different for different 150 original data sources. In particular, the application must not 151 use source addresses to identify these original data sources. 153 Most multicast-based applications - especially those based on RTP [2] - 154 satisfy these requirements. If the multicast-based applications are 155 launched from a separate 'session directory' application, then the UMTP 156 implementation may be built into the session directory. For some multicast 157 applications, however, the (group, port) is not specified in advance, but 158 instead is determined by the application itself - e.g., by querying a 159 separate 'licensing' server. Depending on the host operating system, a 160 separate UMTP implementation might not be able to independently determine 161 this (group, port). In this case, UMTP could not be used, unless it were 162 incorporated into the application itself. 164 Note that for Source-Specific Multicast ("SSM") sessions [6], condition 165 3/ above will be violated: SSM uses a source address (as well as a 166 regular group address) to identify a SSM "channel", but the act of 167 tunneling a multicast packet (using UMTP) changes its source address. 168 Therefore, any SSM-receiving application that uses UMTP to deliver 169 its incoming multicast packets must be made aware of this change of 170 source address. 172 These application restrictions reinforce the point that UMTP should be used 173 *only* if full multicast routing cannot be provided instead. 175 6. Packet Format, and Command Codes 177 The payload of each UMTP datagram - i.e., excluding the outer UDP header - 178 consists of a 12 or 16-octet 'trailer' descriptor. For commands other than 179 "DATA", this descriptor makes up the entire UMTP payload. In the case of 180 a "DATA" command, however, this descriptor is also preceded by the data 181 that is being tunneled (i.e., the original UDP payload). The format 182 of the 'trailer' descriptor is as follows: 184 12-octet trailer: 185 ================= 186 0 1 2 3 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | source cookie | destination cookie | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | (IPv4) multicast address | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | port | TTL |S|vers.|command| 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 16-octet trailer: 197 ================= 198 0 1 2 3 199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | (IPv4) source address | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | source cookie | destination cookie | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | (IPv4) multicast address | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | port | TTL |S|vers.|command| 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Note that UMTP is defined only for IPv4. (In IPv6, native multicast 211 routing should be ubiquitous.) 213 The "S" bit (the high-order bit of the last octet of the trailer) 214 indicates the size of the trailer. S==0 denotes a 12-octet trailer; 215 S==1 denotes a 16-octet trailer. 217 The 16-octet trailer is identical to the 12-octet trailer, except for 218 the addition of an IP source address. This extended trailer is used 219 to tunnel (and control the tunneling of) Source-Specific Multicast 220 sessions. 222 "source cookie" and "destination cookie" are used to protect against IP 223 source address spoofing, as described below. 225 "vers" - the protocol version - is currently zero. 227 The following "command"s are currently defined: 228 0 (unused) 229 1 DATA 230 2 JOIN_GROUP 231 3 LEAVE_GROUP 232 4 TEAR_DOWN 233 5 PROBE 234 6 PROBE_ACK 235 7 PROBE_NACK 236 8 JOIN_RTP_GROUP 237 9 LEAVE_RTP_GROUP 238 10-15 (unused) 240 Notes: 241 - The primary reason for having the tunneled payload data appear 242 *before* the descriptor is that the payload data will often be a RTP 243 packet [2], and by retaining this data in its usual position, 244 IP/UDP/RTP header compression [3] - if present - will work properly. 245 A secondary reason is that this order may allow UMTP implementations 246 written in some type-safe programming languages - such as Java - to 247 reduce the amount of byte copying that they would otherwise have to 248 perform. Note that UMTP implementations must allow for the 249 possibility of the 'trailer' descriptor not being aligned on a 250 4-byte boundary. 251 - The S/vers/command fields always occupy the last byte of the data 252 payload. This allows a receiving implementation to easily determine 253 the size of the trailer, and allows for the possibility of having 254 other kinds of tunneling trailers (e.g., for trailer compression) 255 in future versions of this protocol. 256 - The DATA, JOIN_GROUP, LEAVE_GROUP, JOIN_GROUP_RTP, and LEAVE_GROUP_RTP 257 commands can be used with either a 12-octet trailer, or (if the "S" 258 bit is set to 1) with a 16-octet trailer that adds a source address 259 (specifying a SSM session). In the Protocol Operation described in 260 the next section, replace "(group, port)" with "(group, source, port)" 261 when dealing with a SSM session. 263 7. Protocol Operation 265 For the purposes of describing the protocol, a tunnel endpoint has the 266 following state: 267 - a set E of allowable remote endpoints (each defined by a unicast 268 address & port). Each such endpoint, e, is also tagged with: 269 - localCookie_e: a hard-to-guess (e.g., random) 16-bit value 270 - remoteCookie_e: a 16-bit value (initially, some arbitrary value) 271 - a set G of active (group, port) tuples. Each such tuple, g, is also 272 tagged with: 273 - a flag F_g with one of two values: {"master", "slave"} 274 - a subset E_g of E: the tunnels that are members of g 275 - a default TTL T_g (the TTL to use if one is not otherwise known) 277 Also, for each tunnel endpoint, the following events of note may occur: 278 1/ The local node requests the joining of a (group, port) g, 279 with default TTL t 280 2/ The local node requests the leaving of a (group, port) g 281 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 282 4/ A (non-local) multicast packet arrives for a (group, port) g, 283 with source address s 284 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 285 6/ A tunneled UMTP packet arrives, with source address s, 286 and containing 'cookies' (srcCookie, dstCookie) 288 Each of these events is handled as follows: 290 1/ The local node requests the joining of a (group, port) g, 291 with default TTL t 292 add g to G; set F_g to "master"; set T_g to t 293 locally join the multicast group g 294 for each tunnel endpoint e in E_g, 295 send, to e, at 15 second intervals, a command 296 JOIN_GROUP(group, port, t, 297 srcCookie<-localCookie_e, 298 dstCookie<-remoteCookie_e) 300 2/ The local node requests the leaving of a (group, port) g 301 ignore this if g is not a member of G; otherwise: 302 if F_g is "master" 303 for each tunnel endpoint e in E_g, 304 cancel the ongoing periodic JOIN_GROUP commands 305 send, to e, a command 306 LEAVE_GROUP(group, port, 307 srcCookie<-localCookie_e, 308 dstCookie<-remoteCookie_e) 309 (The TTL field in the packet is unused) 310 (optional: Repeat this send several times) 311 locally leave the multicast group g 312 remove g from G 314 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 315 ignore this if g is not a member of G (or if t==0); otherwise: 316 for each tunnel endpoint e in E_g, 317 send, to e, a command 318 DATA(group, port, t-1, 319 srcCookie<-localCookie_e, 320 dstCookie<-remoteCookie_e) 321 with the original packet's data prepended 323 4/ A (non-local) multicast packet arrives for a (group, port) g, 324 with source address s 325 IMPORTANT (see below): If s is one of the endpoints e in E: 326 send, to e, a command 327 TEAR_DOWN(srcCookie<-localCookie_e, 328 dstCookie<-remoteCookie_e) 329 (the address, port, TTL fields are unused) 330 remove e from E 331 otherwise: 332 ignore this if g is not a member of G; otherwise: 333 if the TTL t of the incoming packet is not known: 334 set t to T_g 335 for each tunnel endpoint e in E_g, 336 (if t>0) send, to e, a command 337 DATA(group, port, t-1, 338 srcCookie<-localCookie_e, 339 dstCookie<-remoteCookie_e) 340 with the original packet's data prepended 342 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 343 ignore this if g is not a member of G; otherwise: 344 if F_g is "slave" 345 remove g from G 346 locally leave the multicast group g 348 6/ A tunneled UMTP packet arrives, with source address s, 349 and containing 'cookies' (srcCookie, dstCookie) 350 If s is not one of the endpoints e in E, ignore this packet 351 *unless* the "command" is PROBE, in which case: 352 replace the packet's "command" field with PROBE_NACK, 353 swap the packet's source and destination cookie fields 354 send the resulting packet back to s 355 continue normal processing 356 If dstCookie does *not* equal localCookie_s [*] 357 send, to s, a command 358 PROBE_ACK(srcCookie<-localCookie_s, 359 dstCookie<-the srcCookie from the packet) 360 (the address, port, TTL fields are ignored; they 361 should be given the same values as those in the 362 incoming packet) 363 continue normal processing 364 [*] (Note: An implementation may omit this check if it is sure 365 that source addresses incoming packets cannot be spoofed.) 366 Set remoteCookie_s <- srcCookie 367 Process the packet, based on the "command" field: 368 DATA(group, port, t) 369 set g to (group, port) 370 (Note: It is not required that g be a member of G.) 371 multicast the enclosed (prepended) data to g, with TTL t 372 (optional: Instead limit the TTL; see below) 373 (if t>0) for each tunnel endpoint e in E_g, EXCEPT for s 374 send, to e, a command 375 DATA(group, port, t-1, 376 srcCookie<-localCookie_e, 377 dstCookie<-remoteCookie_e) 378 with the original packet's data prepended 379 JOIN_GROUP(group, port, t) 380 set g to (group, port) 381 ignore this if g is not a multicast address; otherwise: 382 if g is not already a member of G: 383 add g to G; set F_g to "slave"; set T_g to t 384 locally join the multicast group g 385 if F_g is "slave": 386 set a 'JOIN_GROUP timeout' to occur in 60 seconds time 387 (replacing any existing such timeout) 388 LEAVE_GROUP(group, port) 389 set g to (group, port) 390 ignore this if g is not a member of G; otherwise: 391 if F_g is "slave" 392 locally leave the multicast group g 393 remove g from G 394 TEAR_DOWN 395 remove e from E 396 PROBE 397 send, to s, a command 398 PROBE_ACK(srcCookie<-localCookie_s, 399 dstCookie<-remoteCookie_s) 400 (the address, port, TTL fields are ignored; they 401 should be given the same values as those in the 402 incoming packet) 403 PROBE_ACK, PROBE_NACK 404 Ignore this packet (unless we have recently sent a PROBE) 405 Note: The PROBE command is one that a node can (optionally) 406 use to determine whether a prospective endpoint 407 exists, and if so, whether it would accept us as an 408 endpoint in turn. A PROBE can also be used, by a 409 master, to obtain the correct "remoteCookie" - via 410 the subsequent PROBE_ACK - prior to sending its 411 first JOIN_GROUP. 413 8. Illustration of Protocol Operation 415 In this simple example, consider a tunnel between a single pair of 416 nodes, A and B, and suppose that node A (the master) wishes that data 417 for a particular (group, port) "g" be relayed across the tunnel, with 418 default TTL "t". 420 Initial state: 422 A (master) B (slave) 423 ========== ========= 424 E == {B} E == {A} 425 localCookie_B: 914 localCookie_A: 1442 426 (initially chosen at random) (initially chosen at random) 427 remoteCookie_B: 2207 (ditto) remoteCookie_A: 4913 (ditto) 428 G == {} G == {} 430 A begins by sending a PROBE command across the tunnel to B. This is 431 optional, but it allows each endpoint to immediately 'synchronize' 432 their cookies. 434 A --> PROBE(914,2207) -->B 436 B receives this command, and notices that the source (A) is one of his 437 legitimate endpoints. However, he also notices that the command's 438 destination cookie (2207) does *not* equal his local cookie (1442). 439 Therefore, he sends back a PROBE_ACK, containing his correct cookie 440 (and the source cookie from the original PROBE): 442 A<-- PROBE_ACK(1442,914) <--B 444 A receives this command, notices that the source (B) is one of his 445 legitimate endpoints. He also notices that the command's destination 446 cookie (914) equals his own local cookie. This authenticates the 447 remote endpoint B (showing that it hasn't been spoofed), so A then sets 448 his remoteCookie_B to 1442 (the local cookie from the incoming command). 450 Current state: 452 A (master) B (slave) 453 ========== ========= 454 E == {B} E == {A} 455 localCookie_B: 914 localCookie_A: 1442 456 remoteCookie_B: 1442 remoteCookie_A: 4913 457 G == {} G == {} 459 Note that B hasn't yet authenticated the remote endpoint A. This 460 happens after the next packet: 462 Next, A joins the multicast (group, port), and tells B to relay this: 464 A--> JOIN_GROUP(group, port, t, 914, 1442) -->B 466 (A repeats this command every 15 seconds.) 468 B receives each such command, authenticates its endpoint and cookies, 469 sets his remoteCookie_A to 914, and handles the JOIN_GROUP command by 470 - locally joining the group (if it hasn't already done so) 471 - setting F_g to "slave" 472 - setting a "JOIN_GROUP timeout" to occur in 60 seconds 473 (if no more JOIN_GROUP commands are received within this time) 475 Current state: 477 A (master) B (slave) 478 ========== ========= 479 E == {B} E == {A} 480 localCookie_B: 914 localCookie_A: 1442 481 remoteCookie_B: 1442 remoteCookie_A: 914 482 G == {g} G == {g} 483 F_g == "master" F_g == "slave" 484 E_g == {B} E_g == {A} 485 T_g == t T_g == t 487 Suppose now that B receives a local multicast packet addressed to "g". 488 He then sends a DATA command across the tunnel to A: 490 A<-- DATA(group, port, t-1, 914, 1442) <--B 491 (with the original data prepended) 493 (If B knew the TTL of the incoming packet, he'd use this instead of t.) 495 A then receives this command, authenticates its endpoint and cookies, 496 and re-multicasts the enclosed payload data to (group, port). 498 (The same steps happen, in the reverse direction, if A receives a local 499 multicast packet addressed to "g".) 501 9. Relaying RTP/RTCP Sessions 503 RTP/RTCP sessions [2] use two ports: an even numbered port for RTP, and 504 an odd-numbered port (the next highest) for RTCP. These sessions could 505 be relayed using two separate JOIN_GROUP commands - one for each port. 507 As an alternative, the single command JOIN_RTP_GROUP can be used. 508 This command works exactly like JOIN_GROUP, except that it implicitly 509 specifies a pair of ports: the port in the command, and that port +1. 510 Similarly, the command LEAVE_RTP_GROUP can be used to stop relaying a 511 RTP/RTCP session, as an alternative to using two separate LEAVE_GROUPs. 513 A UMTP master should use JOIN_RTP_GROUP and LEAVE_RTP_GROUP only for 514 RTP/RTCP sessions - not for other kinds of sessions that also happen 515 to use port pairs. A UMTP implementation may handle these commands 516 especially, based upon the knowledge that they represent RTP/RTCP 517 sessions. For example, an implementation might wish to perform 518 RTP/RTCP-specific monitoring or statistics gathering, or to check the 519 RTP SSRC ("synchronization source") field in each incoming multicast 520 packet for possible collisions (i.e., in case two separate multicast 521 sources happen to be using the same SSRC, but have not yet detected 522 and corrected this themselves) [4]. 524 10. Loop Detection and Avoidance 526 A data loop may occur if the two endpoints of a UMTP tunnel are connected 527 by multicast, or via another UMTP tunnel elsewhere. Each UMTP 528 implementation must take steps to prevent a loop from occurring: 529 - When multicasting a payload extracted from a DATA packet, a UMTP 530 implementation should choose a TTL that's no larger than necessary. 531 It must also ensure that if this packet is then re-received 532 (via loop-back), it is not resent back over the same tunnel. 533 - If a UMTP implementation receives a multicast packet whose source address 534 is also the endpoint of a tunnel, it must immediately shut down this tunnel 535 (& send a TEAR_DOWN command to the endpoint) 536 - If a UMTP implementation is running on a node for which no more than one 537 tunnel is expected (e.g., the node is a non-MBone-connected PC), then this 538 implementation should attempt to ensure that no more than one tunnel can 539 be started on this note. (For example, the implementation could use 540 operating system-level locking to prevent more than one copy of itself 541 from running simultaneously.) 542 - If loops in the tunneling topology remain possible, then each end of 543 the tunnel should periodically send a short 'status' packet - containing 544 its unicast address - to a common multicast address, and also listen on 545 this address, checking the contents of each received status packet. 546 Should these contents be the same as its original status packet, it must 547 immediately shut down all of its tunnels. 548 (Note: These are the same loop detection techniques used by "mTunnel" [5] - 549 a similar multicast tunneling system, developed independently.) 551 11. Security Considerations 553 Each UMTP implementation should specify, in advance, its set of allowable 554 endpoints (E), and thus should not permit arbitrary nodes to form tunnels 555 (unless some additional authentication mechanism is used for this purpose). 557 Tunnels are authenticated by IP source address. However, the 'cookie' 558 mechanism protects against source address spoofing, thereby preventing a 559 malicious third party from - for example - joining an unwanted multicast 560 group. To enhance this protection, an implementation may also choose to 561 occasionally change its 'localCookies' while it is running. (This should 562 be done immediately prior to sending a packet across the tunnel, so that 563 the remote endpoint can learn about the new cookie immediately.) 565 Note, however, that the 'cookie' mechanism protects against source address 566 spoofing only if packets cannot be inspected in transit. Thus, UMTP 567 should be used with caution on insecure networks (such as unencrypted 568 wireless LANs). 570 12. References 572 [1] LIVE.COM, 573 The "liveGate" multicast tunneling server 574 http://www.live.com/liveGate/ 575 (This application is an implementation of UMTP.) 576 [2] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., 577 "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 578 July, 2003. 579 [3] Jacobson, V., Casner, S., 580 "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" 581 RFC 2508, February, 1999. 582 [4] Casner, S., 583 Personal communication, December, 1997. 584 [5] Parnes, P., 585 "mTunnel" 586 http://www.cdt.luth.se/~peppar/progs/mTunnel/ 587 [6] Holbrook, H., Cain, B., 588 "Source-Specific Multicast for IP" 589 Work-in-Progress, Internet-Draft "draft-ietf-ssm-arch-03.txt" 590 May, 2003. 592 13. Author's Address 594 Ross Finlayson, 595 Live Networks, Inc. (LIVE.COM) 596 email: finlayson(at)live.com 597 WWW: http://www.live.com/ 599