idnits 2.17.1 draft-ietf-avt-ports-for-ucast-mcast-rtp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2010) is 4902 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) == Missing Reference: 'RFCXXXX' is mentioned on line 804, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-16 == Outdated reference: A later version (-10) exists of draft-ietf-avt-app-rtp-keepalive-09 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft D. Wing 4 Intended status: Standards Track Cisco 5 Expires: May 27, 2011 T. VanCaenegem 6 Alcatel-Lucent 7 November 23, 2010 9 Port Mapping Between Unicast and Multicast RTP Sessions 10 draft-ietf-avt-ports-for-ucast-mcast-rtp-04 12 Abstract 14 This document presents a port mapping solution that allows RTP 15 receivers to choose their own ports for an auxiliary unicast session 16 in RTP applications using both unicast and multicast services 17 (almost) without the need for retrieving pre-authorization. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 27, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 55 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 56 3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6 57 3.2. Unicast Session Establishment . . . . . . . . . . . . . . 6 58 4. The portmapping-req Attribute . . . . . . . . . . . . . . . . 11 59 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 60 5.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 13 61 5.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13 62 5.3. Token Verification Request . . . . . . . . . . . . . . . . 15 63 5.4. Token Verification Failure . . . . . . . . . . . . . . . . 15 64 6. Procedures for Token Construction . . . . . . . . . . . . . . 17 65 7. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 18 66 8. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 9. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 21 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 70 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 23 71 11.2. Registration of FMT Values . . . . . . . . . . . . . . . . 23 72 11.3. SFMT Values for Port Mapping Messages Registry . . . . . . 23 73 11.4. RAMS Response Code Space Registry . . . . . . . . . . . . 24 74 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 80 1. Introduction 82 In (any-source or source-specific) multicast RTP applications, 83 destination ports, i.e., the ports on which the multicast receivers 84 receive the RTP and RTCP packets, are defined declaratively. In 85 other words, the receivers cannot choose their receive ports and the 86 sender(s) use the pre-defined ports. 88 In unicast RTP applications, the receiving end needs to choose its 89 ports for RTP and RTCP since these ports are local resources and only 90 the receiving end can determine which ports are available to use. 91 The receiving may convey its request to the sending end through 92 different ways, one of which is the Offer/Answer Model [RFC3264] for 93 the Session Description Protocol (SDP) [RFC4566]. However, the 94 Offer/Answer Model requires offer/answer exchange(s) between the 95 endpoints, and the resulting delay may not be desirable in delay- 96 sensitive real-time applications. Furthermore, the Offer/Answer 97 Model may be burdensome for the endpoints that are concurrently 98 running a large number of unicast sessions with other endpoints. 100 In this specification, we consider an RTP application that uses one 101 or more unicast and multicast RTP sessions together. While the 102 declaration and selection of the ports are well defined and work well 103 for multicast and unicast RTP applications, respectively, the usage 104 of the ports introduces complications when a receiving end mixes 105 unicast and multicast RTP sessions within the same RTP application. 107 An example scenario is where the RTP packets are distributed through 108 source-specific multicast (SSM) and a receiver sends unicast RTCP 109 feedback to a local repair server (also functioning as a feedback 110 target) [RFC5760] asking for a retransmission of the packets it is 111 missing, and the local repair server sends the retransmission packets 112 over a unicast RTP session [RFC4588]. 114 Another scenario is where a receiver wants to rapidly acquire a new 115 primary multicast RTP session and receives one or more RTP burst 116 packets over a unicast session before joining the SSM session 117 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in 118 applications where some part of the content is distributed through 119 multicast while the receivers get additional and/or auxiliary content 120 through one or more unicast connections, as sketched in Figure 1. 122 In this document, we discuss this problem and introduce a solution 123 that we refer to as Port Mapping. This solution allows receivers to 124 choose their desired UDP ports for RTP and RTCP in every unicast 125 session when they are running RTP applications using both unicast and 126 multicast services, and offer/answer exchange is not available. This 127 solution is not applicable in cases where TCP is used as the 128 transport protocol in the unicast sessions. For such scenarios, 129 refer to [RFC4145]. 131 ----------- 132 | Unicast |................ 133 | Source |............. : 134 | (Server) | : : 135 ----------- : : 136 v v 137 ----------- ---------- ----------- 138 | Multicast |------->| Router |---------->|Client RTP | 139 | Source | | |..........>|Application| 140 ----------- ---------- ----------- 141 | : 142 | : ----------- 143 | :..............>|Client RTP | 144 +---------------->|Application| 145 ----------- 147 -------> Multicast RTP Flow 148 .......> Unicast RTP Flow 150 Figure 1: RTP applications simultaneously using both unicast and 151 multicast services 153 In the remainder of this document, we refer to the RTP endpoints that 154 serve other RTP endpoints over a unicast session as the Servers. The 155 receiving RTP endpoints are referred to as Clients. 157 2. Requirements Notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 3. Token-Based Port Mapping 165 Token-based Port Mapping consists of two steps: (i) Token request 166 and retrieval, and (ii) unicast session establishment. These are 167 described below. 169 3.1. Token Request and Retrieval 171 This first step is required to be completed only once. Once a Token 172 is retrieved from a particular server, it can be used for all the 173 unicast sessions the client will be running with this particular 174 server. By default, Tokens are server specific. However, the client 175 can use the same Token to communicate with different servers if these 176 servers are provided with the same secret key used to generate the 177 Token and are at least loosely clock-synchronized. The Token becomes 178 invalid if client's public IP address changes or when the server 179 expires the Token. In these cases, the client has to request a new 180 Token. 182 The Token is essentially an opaque encapsulation that conveys 183 client's IP address information (as seen by the server) using a 184 reversible transform only known to the server. When a request is 185 received, the server creates a Token for this particular client, and 186 sends it back to the client. Later, when the client wants to 187 establish a unicast session, the Token will be validated by the 188 server, making sure that the IP address information matches. This is 189 effective against DoS attacks, e.g., an attacker cannot simply spoof 190 another client's IP address and start a unicast transmission towards 191 random clients. 193 3.2. Unicast Session Establishment 195 We illustrate the second step with an example. Consider an SSM 196 distribution network where a distribution source multicasts RTP 197 packets to a large number of clients, and one or more retransmission 198 servers function as feedback targets to collect unicast RTCP feedback 199 from these clients [RFC5760]. The retransmission servers also join 200 the multicast session to receive the multicast packets and cache them 201 for a certain time period. When a client detects missing packets in 202 the multicast session, it requests a retransmission from one of the 203 retransmission servers by using an RTCP NACK message [RFC4585]. The 204 retransmission server pulls the requested packet(s) out of the cache 205 and retransmits them to the requesting client [RFC4588]. 207 The pertaining RTP and RTCP flows are sketched in Figure 2. Between 208 the client and server, there can be one or more Network Address Port 209 Translators (NAPT - hereafter simply called NAT) devices [RFC4787]. 211 -------------- --- ---------- 212 | |-------------------------------| |-->|P1 | 213 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 214 | | | | | | 215 | Distribution | ---------------- | | | | 216 | Source | | | | | | | 217 | |---->|P1 | | | | | 218 | |.-.->|P2 | | | | | 219 | | | | | | | | 220 -------------- | P3|<.=.=.=.| |=.=|*c0 | 221 | P3|<~~~~~~~| |~~~|*c1 | 222 MULTICAST RTP | | | | | | 223 SESSION with | | | | | | 224 UNICAST FEEDBACK | | | N | | | 225 | Retransmission | | A | | Client | 226 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 227 | Server | | T | | | 228 | | | | | | 229 PORT MAPPING | PT|<~~~~~~~| |~~>|*cT | 230 | | | | | | 231 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 232 | | | | | | 233 AUXILIARY UNICAST | | | | | | 234 RTP SESSION | | | | | | 235 | P3|........| |..>|*c1 | 236 | P3|=.=.=.=.| |=.>|*c1 | 237 | P4|<.=.=.=.| |=.=|*c2 | 238 | | | | | | 239 ---------------- --- ---------- 241 -------> Multicast RTP Flow 242 .-.-.-.> Multicast RTCP Flow 243 .=.=.=.> Unicast RTCP Reports 244 ~~~~~~~> Unicast RTCP Feedback Messages 245 .......> Unicast RTP Flow 247 Figure 2: Example scenario showing an SSM distribution with support 248 for retransmissions from a server 250 In this figure, we have the following multicast and unicast ports: 252 o Ports P1 and P2 denote the destination RTP and RTCP ports in the 253 multicast session, respectively. The clients listen to these 254 ports to receive the multicast RTP and RTCP packets. Ports P1 and 255 P2 are defined declaratively. 257 o Port P3 denotes the RTCP port on the feedback target running on 258 the retransmission server to collect the RTCP feedback messages, 259 and RTCP receiver and extended reports from the clients in the 260 multicast session. This is also the port that the retransmission 261 server uses to send the RTP packets and RTCP sender reports in the 262 unicast session. Port P3 is defined declaratively. 264 o Port P4 denotes the RTCP port on the retransmission server used to 265 collect the RTCP receiver and extended reports for the unicast 266 session. Port P4 is defined declaratively and MUST be different 267 from port P3. 269 o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the 270 port on the client used to send the RTCP reports for the multicast 271 session. *c1 denotes the port on the client used to send the 272 unicast RTCP feedback messages in the multicast session and to 273 receive the RTP packets and RTCP sender reports in the unicast 274 session. *c2 denotes the port on the client used to send the RTCP 275 receiver and extended reports in the unicast session. Ports c0, 276 c1 and c2 MAY be the same port or different ports. However, there 277 are two advantages of using the same port for both c0 and c1: 279 1. Some NATs only keep bindings active when a packet goes from 280 the inside to the outside of the NAT (See REQ-6 of Section 4.3 281 of [RFC4787]). When the retransmission server sends unicast 282 packets for a long period of time, this can exceed that 283 timeout. If c0=c1, the occasional (periodic) RTCP receiver 284 reports sent from port c0 (for the multicast session) will 285 ensure the NAT does not time out the public port associated 286 with the incoming unicast traffic to port c1. 288 2. Having c0=c1 conserves NAT port bindings. 290 Thus, it is strongly RECOMMENDED that the client uses the same 291 port for c0 and c1. 293 o Ports PT and cT denote the ports through which the Token request 294 and retrieval occur at the server and client sides, respectively. 295 Port PT is declared on a per unicast session basis, although its 296 value MAY be the same for all unicast sessions sourced by the 297 server. This way, a Token once requested and retrieved by a 298 client from port PT remains valid across different unicast 299 sessions. Port PT MAY be equal to port P3. Port cT MAY also be 300 equal to ports c0 and c1. 302 In addition to the ports, we use the following notation: 304 o DS: IP address of the distribution source 306 o G: Destination multicast address 308 o S: IP address of the retransmission server 310 o C: IP address of the client 312 o C': Public IP address of the client (as seen by the server) 314 We assume that the information declaratively defined is available as 315 part of the session description information and is provided to the 316 clients. The Session Description Protocol (SDP) [RFC4566] and other 317 session description methods can be used for this purpose. 319 The following steps summarize the Token-based solution: 321 1. The client ascertains server address (S) and port numbers (P3 and 322 P4) from the session description. 324 2. The client determines its port numbers (*c0, *c1 and *c2). 326 3. If the client does not have a valid Token: 328 A. The client first sends a message to the server via a new RTCP 329 message, called Port Mapping Request to port PT. This 330 message is sent from port cT on the client side. The server 331 learns client's public IP address (C') from the received 332 message. The client can send this message anytime it wants 333 (e.g., during initialization), and does not normally ever 334 need to re-send this message (See Section 7). 336 B. The server generates an opaque encapsulation (i.e., the 337 Token) that conveys client's IP address information using a 338 reversible transform only known to the server. For details, 339 see Section 6. 341 C. The server sends the Token back to the client using a new 342 RTCP message, called Port Mapping Response. This message 343 MUST be sent from port PT to port cT. 345 4. The client provides the Token to the server using a new RTCP 346 message, called Token Verification Request, whenever the client 347 sends an RTCP feedback message for triggering or controlling a 348 unicast session. Note that the unicast session is only 349 established after the server has received a feedback message 350 (along with a valid Token) from the client for which it needs to 351 react by sending unicast data. Until a unicast session is 352 established, neither the server nor the client needs to send RTCP 353 reports for the unicast session. 355 5. Normal flows ensue as shown in Figure 2. Note that in the 356 unicast session the RTP and RTCP packets MUST be multiplexed on 357 the (same) port c1. If the client uses the same port for both c0 358 and c1, the RTCP reports sent for the multicast session keep the 359 P3->c1(=c0) binding alive. If the client uses different ports 360 for c0 and c1, the client needs to periodically send an explicit 361 keep-alive message [I-D.ietf-avt-app-rtp-keepalive] to keep the 362 P3->c1 binding alive during the lifetime of the unicast session 363 if the unicast session's lifetime is likely to exceed the NAT's 364 timeout value. 366 4. The portmapping-req Attribute 368 This new SDP attribute is used declaratively to indicate the port for 369 obtaining a Token. Its presence indicates that a Token MUST be 370 included in the feedback messages sent to the server triggering or 371 controlling a unicast session. 373 The formal description of the 'portmapping-req' attribute is defined 374 by the following ABNF [RFC5234] syntax: 376 portmapping-req-attribute = "a=portmapping-req:" port CRLF 378 Here, 'port' is defined as specified in Section 9 of [RFC4566]. The 379 'portmapping-req' attribute is used as a session-level or media-level 380 attribute. 382 5. Message Formats 384 This section defines the formats of the RTCP transport-layer feedback 385 messages that are exchanged between a server and a client for the 386 purpose of Token-based port mapping. Four RTCP messages are defined: 388 1. Port Mapping Request 390 2. Port Mapping Response 392 3. Token Verification Request 394 4. Token Verification Failure 396 These are all payload-independent RTCP feedback messages with a 397 common format defined in Section 6.1 of [RFC4585], also sketched in 398 Figure 3. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |V=2|P| FMT | PT | length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | SSRC of packet sender | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | SSRC of media source | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 : Feedback Control Information (FCI) : 410 : : 412 Figure 3: The common packet format for the RTCP feedback messages 414 Each feedback message has a fixed-length field for version, padding, 415 feedback message type (FMT), packet type (PT), length, SSRC of packet 416 sender, SSRC of media source as well as a variable-length field for 417 feedback control information (FCI). 419 In the new messages defined in this section, the PT field is set to 420 RTPFB (205) and the FMT field is set to Port Mapping (7). Individual 421 Port Mapping messages are identified by a sub-field called Sub 422 Feedback Message Type (SFMT). Any Reserved field SHALL be set to 423 zero and ignored. 425 Following the rules specified in [RFC3550], all integer fields in the 426 messages defined below are carried in network-byte order, that is, 427 most significant byte (octet) first, also known as big-endian. 428 Unless otherwise stated, numeric constants are in decimal (base 10). 430 5.1. Port Mapping Request 432 The Port Mapping Request message is identified by SFMT=1. This 433 message is a unicast feedback message transmitted by the client to a 434 dedicated server port to request a Token. In the Port Mapping 435 Request message, the client MUST set both the packet sender SSRC and 436 media source SSRC fields to its own SSRC since the Port Mapping 437 Request message is not necessarily linked to any specific media 438 source. The FCI field has the structure depicted in Figure 4. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | SFMT=1 | Reserved | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Random | 446 | Nonce | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Figure 4: The FCI field of Port Mapping Request message 451 o Random Nonce (64 bits): Mandatory field that contains a random 452 nonce value generated by the client following the procedures of 453 [RFC4086]. This nonce is taken into account by the server when 454 generating a Token for the client to enable better security for 455 clients that share the same IP address. If the Port Mapping 456 Request message is transmitted multiple times for redundancy 457 reasons, the random nonce value MUST remain the same in these 458 duplicated messages. 460 5.2. Port Mapping Response 462 The Port Mapping Response message is identified by SFMT=2. This 463 message is sent by the server and delivers the Token to the client. 464 In the Port Mapping Response message, the packet sender SSRC and 465 media sender SSRC fields are both set to the client's SSRC since the 466 Port Mapping Response message is not necessarily linked to any 467 specific media source. The FCI field has the structure depicted in 468 Figure 5. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | SFMT=2 | Reserved | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 : Token : 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Associated | 478 | Nonce | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Absolute | 481 | Expiration Time | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Relative Expiration Time | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 5: FCI field syntax for the Port Mapping Response message 488 o Token (128 bits): Mandatory element that contains the Token 489 generated by the server. 491 o Associated Nonce (64 bits): Mandatory field that contains the 492 nonce received in the Port Mapping Request message and used in 493 Token construction. 495 o Absolute Expiration Time (64 bits): Mandatory element that 496 contains the absolute expiration time of the Token. The absolute 497 expiration time is expressed as a Network Time Protocol (NTP) 498 timestamp value in seconds since year 1900 [RFC5905]. The client 499 does not need to use this element directly, thus, does not need to 500 synchronize its clock with the server. However, the client needs 501 to send this element back to the server along with the associated 502 nonce in the Token Verification Request message, thus, needs to 503 keep it associated with the Token. 505 o Relative Expiration Time (32 bits): Mandatory element that 506 contains the relative expiration time of the Token. The relative 507 expiration time is expressed in seconds from the time the Token 508 was generated. A relative expiration time of zero indicates that 509 the accompanying Token is not valid. 511 The server conveys the relative expiration time in the clear to 512 the client to allow the client to request a new Token well before 513 the expiration time. 515 5.3. Token Verification Request 517 The Token Verification Request message is identified by SFMT=3. This 518 message contains the Token and MUST accompany any other RTCP feedback 519 message sent by the client to trigger or control a unicast session. 520 Examples include the RAMS-R and RAMS-T messages 521 [I-D.ietf-avt-rapid-acquisition-for-rtp] as well as the NACK messages 522 [RFC4585]. In the Token Verification Request message, the client 523 MUST set both the packet sender SSRC and media source SSRC fields to 524 its own SSRC since the media source SSRC may not be known. The 525 client MUST NOT send a Token Verification Request message with a 526 Token that has expired. The FCI field has the structure depicted in 527 Figure 6. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | SFMT=3 | Reserved | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 : Token : 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Associated | 537 | Nonce | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Associated Absolute | 540 | Expiration Time | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 6: FCI field syntax for the Token Verification message 545 o Token (128 bits): Mandatory element that contains the Token 546 previously acquired by the client. 548 o Associated Nonce (64 bits): Mandatory field that contains the 549 nonce associated with the Token above. 551 o Associated Absolute Expiration Time (64 bits): Mandatory element 552 that contains the absolute expiration time associated with the 553 Token above. 555 5.4. Token Verification Failure 557 The Token Verification Failure message is identified by SFMT=4. This 558 message is sent by the server and notifies the client that the Token 559 was invalid. In the Token Verification Failure message, the packet 560 sender SSRC and media sender SSRC fields are both set to the client's 561 SSRC. The FCI field has the structure depicted in Figure 6. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | SFMT=4 | Reserved | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 7: FCI field syntax for the Token Failure message 571 6. Procedures for Token Construction 573 The Token is calculated by the server by performing HMAC-SHA1 574 [RFC2104] on the concatenated values of: 576 o Client's IP address as seen by the server (32/128 bits for IPv4/ 577 IPv6 addresses) 579 o The nonce generated and inserted in the Port Mapping Request 580 message by the client (64 bits) 582 o The absolute expiration time chosen by the server indicated as an 583 NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, 584 to protect against replay attacks) 586 After performing the HMAC-SHA1, the output is truncated to 128 bits, 587 which is then converted to ASCII using Base64 encoding [RFC4648]. In 588 this process, only the server knows the HMAC secret key. However, 589 the HMAC secret key can be shared by multiple servers to provide 590 portability for the Tokens. 592 7. Validating Tokens 594 Upon receipt of an RTCP feedback message along with the Token 595 Verification Request message that contains a Token, nonce and 596 absolute expiration time, the server MUST validate the Token. 598 The server first applies the procedure given in Section 6 by using 599 client's IP address from the received Token Verification Request 600 message, and the nonce and absolute expiration time values reported 601 in the received Token Verification Request message. The server then 602 compares the resulting output with the Token sent by the client in 603 the Token Verification Request message. If they match and the 604 absolute expiration time has not passed yet, the server declares that 605 the Token is valid. 607 Note that if the client's IP address changes, the Token will not 608 validate. Similarly, if the client inserts an incorrect nonce or 609 absolute expiration time value in the Token Verification Request 610 message, validation will fail. 612 It is RECOMMENDED that applications define an application-specific 613 error response to be sent by the server when the server detects that 614 the Token is invalid, rather than silently discarding client's 615 message (since this adds an undesired delay). For applications using 616 [I-D.ietf-avt-rapid-acquisition-for-rtp], this draft defines a new 617 4xx-level response code in the RAMS Response Code Space Registry. 619 In applications that have not defined an error response, the server 620 MUST reply back to the client with a Token Verification Failure 621 message (that goes from port P3 on the server to port c1 on the 622 client). 624 8. SDP Example 626 The declarative SDP describing the scenario given in Figure 2 is 627 written as: 629 v=0 630 o=ali 1122334455 1122334466 IN IP4 nack.example.com 631 s=Local Retransmissions 632 t=0 0 633 a=group:FID 1 2 634 a=rtcp-unicast:rsi 635 m=video 41000 RTP/AVPF 98 636 i=Multicast Stream 637 c=IN IP4 233.252.0.2/255 638 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 639 a=rtpmap:98 MP2T/90000s 640 a=multicast-rtcp:41500 ; Note 1 641 a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 642 a=rtcp-fb:98 nack ; Note 2 643 a=mid:1 644 m=video 42000 RTP/AVPF 99 ; Note 3 645 i=Unicast Retransmission Stream 646 c=IN IP4 192.0.2.1 647 a=sendonly 648 a=rtpmap:99 rtx/90000 649 a=rtcp-mux ; Note 4 650 a=rtcp:42500 ; Note 5 651 a=fmtp:99 apt=98; rtx-time=5000 652 a=portmapping-req:30000 ; Note 6 653 a=mid:2 655 Figure 8: SDP describing an SSM distribution with support for 656 retransmissions from a local server 658 In this description, we highlight the following notes: 660 Note 1: The source stream is multicast from a distribution source 661 with a source IP address of 198.51.100.1 (DS) to the multicast 662 destination address of 233.252.0.2 (G) and port 41000 (P1). The 663 associated RTCP packets are multicast in the same group to port 41500 664 (P2). 666 Note 2: A retransmission server including feedback target 667 functionality with an IP address of 192.0.2.1 (S) and port of 42000 668 (P3) is specified with the 'rtcp' attribute. The feedback 669 functionality is enabled for the RTP stream with payload type 98 670 through the 'rtcp-fb' attribute [RFC4585]. 672 Note 3: The port specified in the second "m" line (for the unicast 673 stream) does not mean anything in this scenario as the client does 674 not send any RTP traffic back to the server. 676 Note 4: The server multiplexes RTP and RTCP packets on the same port 677 (c1 in Figure 2). 679 Note 5: The server uses port 42500 (P4) for the unicast sessions. 681 Note 6: The "a=portmapping-req" line indicates that a Token needs to 682 be retrieved first before a unicast session associated to the 683 multicast session can be established and that the Port Mapping 684 Request message needs to be sent to port 30000 (PT). 686 9. Address Pooling NATs 688 Large-scale NAT devices have a pool of public IPv4 addresses and map 689 internal hosts to one of those public IPv4 addresses. As long as an 690 internal host maintains an active mapping in the NAT, the same IPv4 691 address is assigned to new connections. However, once all of the 692 host's mappings have been deleted (e.g., because of timeout), it is 693 possible that a new connection from that same host will be assigned a 694 different IPv4 address from the pool. When that occurs, the Token 695 will be considered invalid by the server, causing an additional round 696 trip for the client to acquire a fresh Token. 698 Any traffic from the host which traverses the NAT will prevent this 699 problem. As the host is sending RTCP receiver reports at least every 700 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is 701 receiving, those RTCP messages will be sufficient to prevent this 702 problem. 704 10. Security Considerations 706 The Token, which is generated based on a client's IP address and 707 expiration date, provides protection against denial-of-service (DoS) 708 attacks. An attacker using a certain IP address cannot cause one or 709 more RTP packets to be sent to a victim client who has a different IP 710 address. However, if the attacker acquires a valid Token for a 711 victim and can spoof the victim's source address, this approach 712 becomes vulnerable to replay attacks. This is especially easy if the 713 attacker and victim are behind a large-scale NAT and share the same 714 IP address. 716 Multicast is deployed on managed networks - not the Internet. These 717 managed networks will choose to enable network ingress filtering 718 [RFC2827] or not. If ingress filtering is enabled on a network, an 719 attacker attacker cannot spoof a victim's IP address to use a Token 720 to initiate an attack against a victim. However, if ingress 721 filtering is not enabled on a network, an attacker could obtain a 722 Token and spoof the victim's address, causing traffic to flood the 723 victim. On such a network, the server can reduce the time period for 724 such an attack by expiring a Token in a short period of time. In the 725 extreme case, the server can expire the Token in such a short period 726 of time, such that the client will have to acquire a new Token 727 immediately before using it in a Token Verification Request message. 729 11. IANA Considerations 731 The following contact information shall be used for all registrations 732 in this document: 734 Ali Begen 735 abegen@cisco.com 737 Note to the RFC Editor: In the following, please replace "XXXX" with 738 the number of this document prior to publication as an RFC. 740 11.1. Registration of SDP Attributes 742 This document registers a new attribute name in SDP. 744 SDP Attribute ("att-field"): 745 Attribute name: portmapping-req 746 Long form: Port for requesting Token 747 Type of name: att-field 748 Type of attribute: Either session or media level 749 Subject to charset: No 750 Purpose: See this document 751 Reference: [RFCXXXX] 752 Values: See this document 754 11.2. Registration of FMT Values 756 Within the RTPFB range, the following format (FMT) value is 757 registered: 759 Name: Port Mapping 760 Long name: Port Mapping Between Unicast and Multicast RTP Sessions 761 Value: 7 762 Reference: [RFCXXXX] 764 11.3. SFMT Values for Port Mapping Messages Registry 766 This document creates a new sub-registry for the sub-feedback message 767 type (SFMT) values to be used with the FMT value registered for Port 768 Mapping messages. The registry is called the SFMT Values for Port 769 Mapping Messages Registry. This registry is to be managed by the 770 IANA according to the Specification Required policy of [RFC5226]. 772 The length of the SFMT field in the Port Mapping messages is a single 773 octet, allowing 256 values. The registry is initialized with the 774 following entries: 776 Value Name Reference 777 ----- -------------------------------------------------- ------------- 778 0 Reserved [RFCXXXX] 779 1 Port Mapping Request [RFCXXXX] 780 2 Port Mapping Response [RFCXXXX] 781 3 Token Verification Request [RFCXXXX] 782 4 Token Verification Failure [RFCXXXX] 783 5-254 Assignable - Specification Required 784 255 Reserved [RFCXXXX] 786 The SFMT values 0 and 255 are reserved for future use. 788 Any registration for an unassigned SFMT value needs to contain the 789 following information: 791 o Contact information of the one doing the registration, including 792 at least name, address, and email. 794 o A detailed description of what the new SFMT represents and how it 795 shall be interpreted. 797 11.4. RAMS Response Code Space Registry 799 This document adds the following entry to the RAMS Response Code 800 Space Registry. 802 Code Description Reference 803 ----- -------------------------------------------------- ------------- 804 405 Invalid Token [RFCXXXX] 806 This response code is used when the Token included by the RTP_Rx in 807 the RAMS-R message is invalid. 809 12. Acknowledgments 811 The approach presented in this document came out after discussions 812 with various individuals in the AVT and MMUSIC WGs, and the breakout 813 session held in the Anaheim meeting. We thank each of these 814 individuals. 816 13. References 818 13.1. Normative References 820 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 821 Jacobson, "RTP: A Transport Protocol for Real-Time 822 Applications", STD 64, RFC 3550, July 2003. 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 828 Description Protocol", RFC 4566, July 2006. 830 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 831 "Extended RTP Profile for Real-time Transport Control 832 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 833 July 2006. 835 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 836 Protocol (RTCP) Extensions for Single-Source Multicast 837 Sessions with Unicast Feedback", RFC 5760, February 2010. 839 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 840 Specifications: ABNF", STD 68, RFC 5234, January 2008. 842 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 843 Requirements for Security", BCP 106, RFC 4086, June 2005. 845 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 846 Encodings", RFC 4648, October 2006. 848 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 849 Time Protocol Version 4: Protocol and Algorithms 850 Specification", RFC 5905, June 2010. 852 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 853 Hashing for Message Authentication", RFC 2104, 854 February 1997. 856 13.2. Informative References 858 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 859 with Session Description Protocol (SDP)", RFC 3264, 860 June 2002. 862 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 863 the Session Description Protocol (SDP)", RFC 4145, 864 September 2005. 866 [I-D.ietf-avt-rapid-acquisition-for-rtp] 867 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 868 Based Rapid Acquisition of Multicast RTP Sessions", 869 draft-ietf-avt-rapid-acquisition-for-rtp-16 (work in 870 progress), October 2010. 872 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 873 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 874 RFC 4787, January 2007. 876 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 877 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 878 July 2006. 880 [I-D.ietf-avt-app-rtp-keepalive] 881 Marjou, X. and A. Sollaud, "Application Mechanism for 882 keeping alive the Network Address Translator (NAT) 883 mappings associated to RTP flows.", 884 draft-ietf-avt-app-rtp-keepalive-09 (work in progress), 885 September 2010. 887 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 888 Defeating Denial of Service Attacks which employ IP Source 889 Address Spoofing", BCP 38, RFC 2827, May 2000. 891 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 892 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 893 May 2008. 895 Authors' Addresses 897 Ali Begen 898 Cisco 899 181 Bay Street 900 Toronto, ON M5J 2T3 901 Canada 903 Email: abegen@cisco.com 905 Dan Wing 906 Cisco Systems, Inc. 907 170 West Tasman Dr. 908 San Jose, CA 95134 909 USA 911 Email: dwing@cisco.com 913 Tom VanCaenegem 914 Alcatel-Lucent 915 Copernicuslaan 50 916 Antwerpen, 2018 917 Belgium 919 Email: Tom.Van_Caenegem@alcatel-lucent.com