idnits 2.17.1 draft-ietf-avt-ports-for-ucast-mcast-rtp-03.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 18, 2010) is 4880 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 740, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == 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: 1 error (**), 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 22, 2011 T. VanCaenegem 6 Alcatel-Lucent 7 November 18, 2010 9 Token-Based Port Mapping Between Unicast and Multicast RTP Sessions 10 draft-ietf-avt-ports-for-ucast-mcast-rtp-03 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 22, 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 . . . . . . . . . . . . . . . . . . . . 14 63 6. Procedures for Token Construction . . . . . . . . . . . . . . 15 64 7. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 16 65 8. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 9. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 19 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 69 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 21 70 11.2. Registration of FMT Values . . . . . . . . . . . . . . . . 21 71 11.3. SFMT Values for Port Mapping Messages Registry . . . . . . 21 72 11.4. RAMS Response Code Space Registry . . . . . . . . . . . . 22 73 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 76 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 79 1. Introduction 81 In (any-source or source-specific) multicast RTP applications, 82 destination ports, i.e., the ports on which the multicast receivers 83 receive the RTP and RTCP packets, are defined declaratively. In 84 other words, the receivers cannot choose their receive ports and the 85 sender(s) use the pre-defined ports. 87 In unicast RTP applications, the receiving end needs to choose its 88 ports for RTP and RTCP since these ports are local resources and only 89 the receiving end can determine which ports are available to use. 90 The receiving may convey its request to the sending end through 91 different ways, one of which is the Offer/Answer Model [RFC3264] for 92 the Session Description Protocol (SDP) [RFC4566]. However, the 93 Offer/Answer Model requires offer/answer exchange(s) between the 94 endpoints, and the resulting delay may not be desirable in delay- 95 sensitive real-time applications. Furthermore, the Offer/Answer 96 Model may be burdensome for the endpoints that are concurrently 97 running a large number of unicast sessions with other endpoints. 99 In this specification, we consider an RTP application that uses one 100 or more unicast and multicast RTP sessions together. While the 101 declaration and selection of the ports are well defined and work well 102 for multicast and unicast RTP applications, respectively, the usage 103 of the ports introduces complications when a receiving end mixes 104 unicast and multicast RTP sessions within the same RTP application. 106 An example scenario is where the RTP packets are distributed through 107 source-specific multicast (SSM) and a receiver sends unicast RTCP 108 feedback to a local repair server (also functioning as a feedback 109 target) [RFC5760] asking for a retransmission of the packets it is 110 missing, and the local repair server sends the retransmission packets 111 over a unicast RTP session [RFC4588]. 113 Another scenario is where a receiver wants to rapidly acquire a new 114 primary multicast RTP session and receives one or more RTP burst 115 packets over a unicast session before joining the SSM session 116 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in 117 applications where some part of the content is distributed through 118 multicast while the receivers get additional and/or auxiliary content 119 through one or more unicast connections, as sketched in Figure 1. 121 In this document, we discuss this problem and introduce a solution 122 that we refer to as Port Mapping. This solution allows receivers to 123 choose their desired UDP ports for RTP and RTCP in every unicast 124 session when they are running RTP applications using both unicast and 125 multicast services, and offer/answer exchange is not available. This 126 solution is not applicable in cases where TCP is used as the 127 transport protocol in the unicast sessions. For such scenarios, 128 refer to [RFC4145]. 130 ----------- 131 | Unicast |................ 132 | Source |............. : 133 | (Server) | : : 134 ----------- : : 135 v v 136 ----------- ---------- ----------- 137 | Multicast |------->| Router |---------->|Client RTP | 138 | Source | | |..........>|Application| 139 ----------- ---------- ----------- 140 | : 141 | : ----------- 142 | :..............>|Client RTP | 143 +---------------->|Application| 144 ----------- 146 -------> Multicast RTP Flow 147 .......> Unicast RTP Flow 149 Figure 1: RTP applications simultaneously using both unicast and 150 multicast services 152 In the remainder of this document, we refer to the RTP endpoints that 153 serve other RTP endpoints over a unicast session as the Servers. The 154 receiving RTP endpoints are referred to as Clients. 156 2. Requirements Notation 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 3. Token-Based Port Mapping 164 Token-based Port Mapping consists of two steps: (i) Token request 165 and retrieval, and (ii) unicast session establishment. These are 166 described below. 168 3.1. Token Request and Retrieval 170 This first step is required to be completed only once. Once a Token 171 is retrieved from a particular server, it can be used for all the 172 unicast sessions the client will be running with this particular 173 server. By default, Tokens are server specific. However, the client 174 can use the same Token to communicate with different servers if these 175 servers are provided with the same key used to generate the Token. 176 The Token becomes invalid if client's public IP address changes or 177 when the server expires the Token. In these cases, the client has to 178 request a new Token. 180 The Token is essentially an opaque encapsulation that conveys 181 client's IP address information (as seen by the server) using a 182 reversible transform only known to the server. When a request is 183 received, the server creates a Token for this particular client, and 184 sends it back to the client. Later, when the client wants to 185 establish a unicast session, the Token will be validated by the 186 server, making sure that the IP address information matches. This is 187 effective against DoS attacks, e.g., an attacker cannot simply spoof 188 another client's IP address and start a unicast transmission towards 189 random clients. 191 3.2. Unicast Session Establishment 193 We illustrate the second step with an example. Consider an SSM 194 distribution network where a distribution source multicasts RTP 195 packets to a large number of clients, and one or more retransmission 196 servers function as feedback targets to collect unicast RTCP feedback 197 from these clients [RFC5760]. The retransmission servers also join 198 the multicast session to receive the multicast packets and cache them 199 for a certain time period. When a client detects missing packets in 200 the multicast session, it requests a retransmission from one of the 201 retransmission servers by using an RTCP NACK message [RFC4585]. The 202 retransmission server pulls the requested packet(s) out of the cache 203 and retransmits them to the requesting client [RFC4588]. 205 The pertaining RTP and RTCP flows are sketched in Figure 2. Between 206 the client and server, there can be one or more Network Address Port 207 Translators (NAPT - hereafter simply called NAT) devices [RFC4787]. 209 -------------- --- ---------- 210 | |-------------------------------| |-->|P1 | 211 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 212 | | | | | | 213 | Distribution | ---------------- | | | | 214 | Source | | | | | | | 215 | |---->|P1 | | | | | 216 | |.-.->|P2 | | | | | 217 | | | | | | | | 218 -------------- | P3|<.=.=.=.| |=.=|*c0 | 219 | P3|<~~~~~~~| |~~~|*c1 | 220 MULTICAST RTP | | | | | | 221 SESSION with | | | | | | 222 UNICAST FEEDBACK | | | N | | | 223 | Retransmission | | A | | Client | 224 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 225 | Server | | T | | | 226 | | | | | | 227 PORT MAPPING | PT|<~~~~~~~| |~~>|*cT | 228 | | | | | | 229 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 230 | | | | | | 231 AUXILIARY UNICAST | | | | | | 232 RTP SESSION | | | | | | 233 | P3|........| |..>|*c1 | 234 | P3|=.=.=.=.| |=.>|*c1 | 235 | P4|<.=.=.=.| |=.=|*c2 | 236 | | | | | | 237 ---------------- --- ---------- 239 -------> Multicast RTP Flow 240 .-.-.-.> Multicast RTCP Flow 241 .=.=.=.> Unicast RTCP Reports 242 ~~~~~~~> Unicast RTCP Feedback Messages 243 .......> Unicast RTP Flow 245 Figure 2: Example scenario showing an SSM distribution with support 246 for retransmissions from a server 248 In this figure, we have the following multicast and unicast ports: 250 o Ports P1 and P2 denote the destination RTP and RTCP ports in the 251 multicast session, respectively. The clients listen to these 252 ports to receive the multicast RTP and RTCP packets. Ports P1 and 253 P2 are defined declaratively. 255 o Port P3 denotes the RTCP port on the feedback target running on 256 the retransmission server to collect the RTCP feedback messages, 257 and RTCP receiver and extended reports from the clients in the 258 multicast session. This is also the port that the retransmission 259 server uses to send the RTP packets and RTCP sender reports in the 260 unicast session. Port P3 is defined declaratively. 262 o Port P4 denotes the RTCP port on the retransmission server used to 263 collect the RTCP receiver and extended reports for the unicast 264 session. Port P4 is defined declaratively and MUST be different 265 from port P3. 267 o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the 268 port on the client used to send the RTCP reports for the multicast 269 session. *c1 denotes the port on the client used to send the 270 unicast RTCP feedback messages in the multicast session and to 271 receive the RTP packets and RTCP sender reports in the unicast 272 session. *c2 denotes the port on the client used to send the RTCP 273 receiver and extended reports in the unicast session. Ports c0, 274 c1 and c2 MAY be the same port or different ports. However, there 275 are two advantages of using the same port for both c0 and c1: 277 1. Some NATs only keep bindings active when a packet goes from 278 the inside to the outside of the NAT (See REQ-6 of Section 4.3 279 of [RFC4787]). When the retransmission server sends unicast 280 packets for a long period of time, this can exceed that 281 timeout. If c0=c1, the occasional (periodic) RTCP receiver 282 reports sent from port c0 (for the multicast session) will 283 ensure the NAT does not time out the public port associated 284 with the incoming unicast traffic to port c1. 286 2. Having c0=c1 conserves NAT port bindings. 288 Thus, it is strongly RECOMMENDED that the client uses the same 289 port for c0 and c1. 291 o Ports PT and cT denote the ports through which the Token request 292 and retrieval occur at the server and client sides, respectively. 293 Port PT is declared on a per unicast session basis, although its 294 value MAY be the same for all unicast sessions sourced by the 295 server. This way, a Token once requested and retrieved by a 296 client from port PT remains valid across different unicast 297 sessions. Port PT MAY be equal to port P3. Port cT MAY also be 298 equal to ports c0 and c1. 300 In addition to the ports, we use the following notation: 302 o DS: IP address of the distribution source 304 o G: Destination multicast address 306 o S: IP address of the retransmission server 308 o C: IP address of the client 310 o C': Public IP address of the client (as seen by the server) 312 We assume that the information declaratively defined is available as 313 part of the session description information and is provided to the 314 clients. The Session Description Protocol (SDP) [RFC4566] and other 315 session description methods can be used for this purpose. 317 The following steps summarize the Token-based solution: 319 1. The client ascertains server address (S) and port numbers (P3 and 320 P4) from the session description. 322 2. The client determines its port numbers (*c0, *c1 and *c2). 324 3. If the client does not have a valid Token: 326 A. The client first sends a message to the server via a new RTCP 327 message, called Port Mapping Request to port PT. This 328 message is sent from port cT on the client side. The server 329 learns client's public IP address (C') from the received 330 message. The client can send this message anytime it wants 331 (e.g., during initialization), and does not normally ever 332 need to re-send this message (See Section 7). 334 B. The server generates an opaque encapsulation (i.e., the 335 Token) that conveys client's IP address information using a 336 reversible transform only known to the server. For details, 337 see Section 6. 339 C. The server sends the Token back to the client using a new 340 RTCP message, called Port Mapping Response. This message 341 MUST be sent from port PT to port cT. 343 4. The client provides the Token to the server using a new RTCP 344 message, called Token Verification, whenever the client sends an 345 RTCP feedback message for triggering or controlling a unicast 346 session. Note that the unicast session is only established after 347 the server has received a feedback message (along with a valid 348 Token) from the client for which it needs to react by sending 349 unicast data. Until a unicast session is established, neither 350 the server nor the client needs to send RTCP reports for the 351 unicast session. 353 5. Normal flows ensue as shown in Figure 2. Note that in the 354 unicast session the RTP and RTCP packets MUST be multiplexed on 355 the (same) port c1. If the client uses the same port for both c0 356 and c1, the RTCP reports sent for the multicast session keep the 357 P3->c1(=c0) binding alive. If the client uses different ports 358 for c0 and c1, the client needs to periodically send an explicit 359 keep-alive message [I-D.ietf-avt-app-rtp-keepalive] to keep the 360 P3->c1 binding alive during the lifetime of the unicast session 361 if the unicast session's lifetime is likely to exceed the NAT's 362 timeout value. 364 4. The portmapping-req Attribute 366 This new SDP attribute is used declaratively to indicate the port for 367 obtaining a Token. Its presence indicates that a Token MUST be 368 included in the feedback messages sent to the server triggering or 369 controlling a unicast session. 371 The formal description of the 'portmapping-req' attribute is defined 372 by the following ABNF [RFC5234] syntax: 374 portmapping-req-attribute = "a=portmapping-req:" port CRLF 376 Here, 'port' is defined as specified in Section 9 of [RFC4566]. The 377 'portmapping-req' attribute is used as a session-level or media-level 378 attribute. 380 5. Message Formats 382 This section defines the formats of the RTCP transport-layer feedback 383 messages that are exchanged between a server and a client for the 384 purpose of Token-based port mapping. Three RTCP messages are 385 defined: 387 1. Port Mapping Request 389 2. Port Mapping Response 391 3. Token Verification 393 These are all payload-independent RTCP feedback messages with a 394 common format defined in Section 6.1 of [RFC4585], also sketched in 395 Figure 3. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |V=2|P| FMT | PT | length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | SSRC of packet sender | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | SSRC of media source | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 : Feedback Control Information (FCI) : 407 : : 409 Figure 3: The common packet format for the RTCP feedback messages 411 Each feedback message has a fixed-length field for version, padding, 412 feedback message type (FMT), packet type (PT), length, SSRC of packet 413 sender, SSRC of media source as well as a variable-length field for 414 feedback control information (FCI). 416 In the new messages defined in this section, the PT field is set to 417 RTPFB (205) and the FMT field is set to Port Mapping (7). Individual 418 Port Mapping messages are identified by a sub-field called Sub 419 Feedback Message Type (SFMT). Any Reserved field SHALL be set to 420 zero and ignored. 422 Following the rules specified in [RFC3550], all integer fields in the 423 messages defined below are carried in network-byte order, that is, 424 most significant byte (octet) first, also known as big-endian. 425 Unless otherwise stated, numeric constants are in decimal (base 10). 427 5.1. Port Mapping Request 429 The Port Mapping Request message is identified by SFMT=1. This 430 message is a unicast feedback message transmitted by the client to a 431 dedicated server port to request a Token. In the Port Mapping 432 Request message, the client MUST set both the packet sender SSRC and 433 media source SSRC fields to its own SSRC since the Port Mapping 434 Request message is not necessarily linked to any specific media 435 source. The FCI field has the structure depicted in Figure 4. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | SFMT=1 | Reserved | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Random | 443 | Nonce | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 4: The FCI field of Port Mapping Request message 448 o Random Nonce (64 bits): Mandatory field that contains a random 449 nonce value generated by the client following the procedures of 450 [RFC4086]. This nonce MUST be taken into account by the server 451 when generating a Token for the client to enable better security 452 for clients that share the same IP address. If the Port Mapping 453 Request message is transmitted multiple times for redundancy 454 reasons, the random nonce value MUST remain the same in these 455 duplicated messages. 457 5.2. Port Mapping Response 459 The Port Mapping Response message is identified by SFMT=2. This 460 message is sent by the server and delivers the Token to the client. 461 In the Port Mapping Response message, the packet sender SSRC and 462 media sender SSRC fields are both set to the client's SSRC since the 463 Port Mapping Response message is not necessarily linked to any 464 specific media source. The FCI field has the structure depicted in 465 Figure 5. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | SFMT=2 | Reserved | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 : Token : 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Expiry Time | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Figure 5: FCI field syntax for the Port Mapping Response message 479 o Token (128 bits): Mandatory element that contains the Token 480 generated by the server. 482 o Expiry Time (32 bits): Mandatory element that contains the expiry 483 time of the Token. The expiry time is expressed in seconds from 484 the time the Token was generated. An expiry time of zero 485 indicates that the accompanying Token is not valid. 487 5.3. Token Verification 489 The Token Verification message is identified by SFMT=3. This message 490 contains the Token and MUST accompany any other RTCP feedback message 491 sent by the client to trigger or control a unicast session. Examples 492 include the RAMS-R and RAMS-T messages 493 [I-D.ietf-avt-rapid-acquisition-for-rtp] as well as the NACK messages 494 [RFC4585]. In the Token Verification message, the client MUST set 495 both the packet sender SSRC and media source SSRC fields to its own 496 SSRC since the media source SSRC may not be known. The client MUST 497 NOT send a Token Verification message with a Token that has expired. 498 The FCI field has the structure depicted in Figure 6. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | SFMT=3 | Reserved | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 : Token : 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 6: FCI field syntax for the Token Verification message 510 o Token (128 bits): Mandatory element that contains the Token 511 previously acquired by the client. 513 6. Procedures for Token Construction 515 Editor's notes: 517 The Token SHOULD be calculated by the server by taking into account: 519 o Client's IP address as seen by the server 521 o The nonce generated by the client and inserted in the Port Mapping 522 Request message 524 o A timestamp to protect against replay attacks 526 o HMAC [RFC2104] of the above information (where only the server 527 knows the HMAC secret) 529 The server conveys the expiration time in the clear to the client in 530 the Port Mapping Response message. Thus, the client can request a 531 new Token before the current one expires. 533 Details are TBC. 535 7. Validating Tokens 537 Upon receipt of an RTCP feedback message along with the Token 538 Verification message that contains a Token, the server MUST validate 539 the Token. The server considers a Token valid if the source IP 540 address of the RTCP feedback message matches the IP address in the 541 Token and the Token has not expired yet. 543 The IP address is encoded into the Token by the server, using an 544 algorithm known only to the server. This, combined with the 545 expiration time provides protection against DoS attacks so that a 546 client using a certain IP address cannot cause one or more RTP 547 packets to be sent to another client with a different IP address. 549 When the server detects that the Token is invalid, it SHOULD NOT 550 silently discard client's message since this adds an undesired delay. 551 Instead, it is RECOMMENDED that applications define an application- 552 specific error response. In applications that have not defined an 553 error response, the server MUST reply back to the client with a Port 554 Mapping Response message (that goes from port P3 on the server to 555 port c1 on the client) where the Token field carries the invalid 556 Token sent by the client and the Expiry Time field is set to zero 557 (indicating that the Token is invalid). 559 For applications using [I-D.ietf-avt-rapid-acquisition-for-rtp], this 560 draft defines a new 4xx-level response code in the RAMS Response Code 561 Space Registry. 563 8. SDP Example 565 The declarative SDP describing the scenario given in Figure 2 is 566 written as: 568 v=0 569 o=ali 1122334455 1122334466 IN IP4 nack.example.com 570 s=Local Retransmissions 571 t=0 0 572 a=group:FID 1 2 573 a=rtcp-unicast:rsi 574 m=video 41000 RTP/AVPF 98 575 i=Multicast Stream 576 c=IN IP4 233.252.0.2/255 577 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 578 a=rtpmap:98 MP2T/90000s 579 a=multicast-rtcp:41500 ; Note 1 580 a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 581 a=rtcp-fb:98 nack ; Note 2 582 a=mid:1 583 m=video 42000 RTP/AVPF 99 ; Note 3 584 i=Unicast Retransmission Stream 585 c=IN IP4 192.0.2.1 586 a=sendonly 587 a=rtpmap:99 rtx/90000 588 a=rtcp-mux ; Note 4 589 a=rtcp:42500 ; Note 5 590 a=fmtp:99 apt=98; rtx-time=5000 591 a=portmapping-req:30000 ; Note 6 592 a=mid:2 594 Figure 7: SDP describing an SSM distribution with support for 595 retransmissions from a local server 597 In this description, we highlight the following notes: 599 Note 1: The source stream is multicast from a distribution source 600 with a source IP address of 198.51.100.1 (DS) to the multicast 601 destination address of 233.252.0.2 (G) and port 41000 (P1). The 602 associated RTCP packets are multicast in the same group to port 41500 603 (P2). 605 Note 2: A retransmission server including feedback target 606 functionality with an IP address of 192.0.2.1 (S) and port of 42000 607 (P3) is specified with the 'rtcp' attribute. The feedback 608 functionality is enabled for the RTP stream with payload type 98 609 through the 'rtcp-fb' attribute [RFC4585]. 611 Note 3: The port specified in the second "m" line (for the unicast 612 stream) does not mean anything in this scenario as the client does 613 not send any RTP traffic back to the server. 615 Note 4: The server multiplexes RTP and RTCP packets on the same port 616 (c1 in Figure 2). 618 Note 5: The server uses port 42500 (P4) for the unicast sessions. 620 Note 6: The "a=portmapping-req" line indicates that a Token needs to 621 be retrieved first before a unicast session associated to the 622 multicast session can be established and that the Port Mapping 623 Request message needs to be sent to port 30000 (PT). 625 9. Address Pooling NATs 627 Large-scale NAT (LSN) devices have a pool of public IPv4 addresses 628 and map internal hosts to one of those public IPv4 addresses. As 629 long as an internal host maintains an active mapping in the NAT, the 630 same IPv4 address is assigned to new connections. However, once all 631 of the host's mappings have been deleted (e.g., because of timeout), 632 it is possible that a new connection from that same host will be 633 assigned a different IPv4 address from the pool. When that occurs, 634 the Token will be considered invalid by the server, causing an 635 additional round trip for the client to acquire a fresh Token. 637 Any traffic from the host which traverses the NAT will prevent this 638 problem. As the host is sending RTCP receiver reports at least every 639 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is 640 receiving, those RTCP messages will be sufficient to prevent this 641 problem. 643 10. Security Considerations 645 The Token, which is generated based on a client's IP address and 646 expiration date, provides protection against denial-of-service (DoS) 647 attacks. An attacker using a certain IP address cannot cause one or 648 more RTP packets to be sent to a victim client who has a different IP 649 address. However, if the attacker acquires a valid Token for a 650 victim and can spoof the victim's source address, this approach 651 becomes vulnerable to replay attacks. 653 Multicast is deployed on managed networks - not the Internet. These 654 managed networks will choose to enable network ingress filtering 655 [RFC2827] or not. If ingress filtering is enabled on a network, an 656 attacker attacker cannot spoof a victim's IP address to use a Token 657 to initiate an attack against a victim. However, if ingress 658 filtering is not enabled on a network, an attacker could obtain a 659 Token and spoof the victim's address, causing traffic to flood the 660 victim. On such a network, the server can reduce the time period for 661 such an attack by expiring a Token in a short period of time. In the 662 extreme case, the server can expire the Token immediately after its 663 first use. An expired Token forces a round trip from the client to 664 the server. 666 11. IANA Considerations 668 The following contact information shall be used for all registrations 669 in this document: 671 Ali Begen 672 abegen@cisco.com 674 Note to the RFC Editor: In the following, please replace "XXXX" with 675 the number of this document prior to publication as an RFC. 677 11.1. Registration of SDP Attributes 679 This document registers a new attribute name in SDP. 681 SDP Attribute ("att-field"): 682 Attribute name: portmapping-req 683 Long form: Port for requesting Token 684 Type of name: att-field 685 Type of attribute: Either session or media level 686 Subject to charset: No 687 Purpose: See this document 688 Reference: [RFCXXXX] 689 Values: See this document 691 11.2. Registration of FMT Values 693 Within the RTPFB range, the following format (FMT) value is 694 registered: 696 Name: Port Mapping 697 Long name: Port Mapping Between Unicast and Multicast RTP Sessions 698 Value: 7 699 Reference: [RFCXXXX] 701 11.3. SFMT Values for Port Mapping Messages Registry 703 This document creates a new sub-registry for the sub-feedback message 704 type (SFMT) values to be used with the FMT value registered for Port 705 Mapping messages. The registry is called the SFMT Values for Port 706 Mapping Messages Registry. This registry is to be managed by the 707 IANA according to the Specification Required policy of [RFC5226]. 709 The length of the SFMT field in the Port Mapping messages is a single 710 octet, allowing 256 values. The registry is initialized with the 711 following entries: 713 Value Name Reference 714 ----- -------------------------------------------------- ------------- 715 0 Reserved [RFCXXXX] 716 1 Port Mapping Request [RFCXXXX] 717 2 Port Mapping Response [RFCXXXX] 718 3 Token Verification [RFCXXXX] 719 4-254 Assignable - Specification Required 720 255 Reserved [RFCXXXX] 722 The SFMT values 0 and 255 are reserved for future use. 724 Any registration for an unassigned SFMT value needs to contain the 725 following information: 727 o Contact information of the one doing the registration, including 728 at least name, address, and email. 730 o A detailed description of what the new SFMT represents and how it 731 shall be interpreted. 733 11.4. RAMS Response Code Space Registry 735 This document adds the following entry to the RAMS Response Code 736 Space Registry. 738 Code Description Reference 739 ----- -------------------------------------------------- ------------- 740 405 Invalid Token [RFCXXXX] 742 This response code is used when the Token included by the RTP_Rx in 743 the RAMS-R message is invalid. 745 12. Acknowledgments 747 The approach presented in this document came out after discussions 748 with various individuals in the AVT and MMUSIC WGs, and the breakout 749 session held in the Anaheim meeting. We thank each of these 750 individuals. 752 13. References 754 13.1. Normative References 756 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 757 Jacobson, "RTP: A Transport Protocol for Real-Time 758 Applications", STD 64, RFC 3550, July 2003. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 764 Description Protocol", RFC 4566, July 2006. 766 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 767 "Extended RTP Profile for Real-time Transport Control 768 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 769 July 2006. 771 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 772 Protocol (RTCP) Extensions for Single-Source Multicast 773 Sessions with Unicast Feedback", RFC 5760, February 2010. 775 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 776 Specifications: ABNF", STD 68, RFC 5234, January 2008. 778 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 779 Requirements for Security", BCP 106, RFC 4086, June 2005. 781 13.2. Informative References 783 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 784 with Session Description Protocol (SDP)", RFC 3264, 785 June 2002. 787 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 788 the Session Description Protocol (SDP)", RFC 4145, 789 September 2005. 791 [I-D.ietf-avt-rapid-acquisition-for-rtp] 792 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 793 Based Rapid Acquisition of Multicast RTP Sessions", 794 draft-ietf-avt-rapid-acquisition-for-rtp-16 (work in 795 progress), October 2010. 797 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 798 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 799 RFC 4787, January 2007. 801 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 802 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 803 July 2006. 805 [I-D.ietf-avt-app-rtp-keepalive] 806 Marjou, X. and A. Sollaud, "Application Mechanism for 807 keeping alive the Network Address Translator (NAT) 808 mappings associated to RTP flows.", 809 draft-ietf-avt-app-rtp-keepalive-09 (work in progress), 810 September 2010. 812 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 813 Hashing for Message Authentication", RFC 2104, 814 February 1997. 816 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 817 Defeating Denial of Service Attacks which employ IP Source 818 Address Spoofing", BCP 38, RFC 2827, May 2000. 820 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 821 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 822 May 2008. 824 Authors' Addresses 826 Ali Begen 827 Cisco 828 181 Bay Street 829 Toronto, ON M5J 2T3 830 Canada 832 Email: abegen@cisco.com 834 Dan Wing 835 Cisco Systems, Inc. 836 170 West Tasman Dr. 837 San Jose, CA 95134 838 USA 840 Email: dwing@cisco.com 842 Tom VanCaenegem 843 Alcatel-Lucent 844 Copernicuslaan 50 845 Antwerpen, 2018 846 Belgium 848 Email: Tom.Van_Caenegem@alcatel-lucent.com