idnits 2.17.1 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01.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 (March 13, 2011) is 4793 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 1198, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: September 14, 2011 T. VanCaenegem 6 Alcatel-Lucent 7 March 13, 2011 9 Port Mapping Between Unicast and Multicast RTP Sessions 10 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 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. The 17 solution provides protection against denial-of-service or packet 18 amplification attacks that could be used to cause one or more RTP 19 packets to be sent to a victim client. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 14, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 57 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 58 3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6 59 3.2. Normative Behavior and Requirements . . . . . . . . . . . 9 60 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 61 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 14 62 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 14 63 4.3. Token Verification Request . . . . . . . . . . . . . . . . 17 64 4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 17 65 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 18 66 5. Procedures for Token Construction . . . . . . . . . . . . . . 20 67 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 22 68 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 23 69 7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 23 70 7.1.1. ABNF Definition of portmapping-req . . . . . . . . . . 23 71 7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 23 72 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 73 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 24 74 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 27 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 76 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 9.2. The portmapping and portmapping-req Attributes . . . . . . 29 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 79 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 30 80 10.2. Registration of RTCP Control Packet Types . . . . . . . . 30 81 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 30 82 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 31 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 89 1. Introduction 91 In (any-source or source-specific) multicast RTP applications, 92 destination ports, i.e., the ports on which the multicast receivers 93 receive the RTP and RTCP packets, are defined declaratively. In 94 other words, the receivers cannot choose their receive ports and the 95 sender(s) use the pre-defined ports. 97 In unicast RTP applications, the receiving end needs to choose its 98 ports for RTP and RTCP since these ports are local resources and only 99 the receiving end can determine which ports are available to use. In 100 addition, Network Address Port Translators (NAPT - hereafter simply 101 called NAT) devices are commonly deployed in networks, thus, static 102 port assignments cannot be used. The receiving end may convey its 103 request to the sending end through different ways, one of which is 104 the Offer/Answer Model [RFC3264] for the Session Description Protocol 105 (SDP) [RFC4566]. However, the Offer/Answer Model requires offer/ 106 answer exchange(s) between the endpoints, and the resulting delay may 107 not be desirable in delay-sensitive real-time applications. 108 Furthermore, the Offer/Answer Model may be burdensome for the 109 endpoints that are concurrently running a large number of unicast 110 sessions with other endpoints. 112 In this specification, we consider an RTP application that uses one 113 or more unicast and multicast RTP sessions together. While the 114 declaration and selection of the ports are well defined and work well 115 for multicast and unicast RTP applications, respectively, the usage 116 of the ports introduces complications when a receiving end mixes 117 unicast and multicast RTP sessions within the same RTP application. 119 An example scenario is where the RTP packets are distributed through 120 source-specific multicast (SSM) and a receiver sends unicast RTCP 121 NACK feedback to a local repair server (also functioning as a unicast 122 RTCP feedback target) [RFC5760] asking for a retransmission of the 123 packets it is missing, and the local repair server sends the 124 retransmission packets over a unicast RTP session [RFC4588]. 126 Another scenario is where a receiver wants to rapidly acquire a new 127 primary multicast RTP session and receives one or more RTP burst 128 packets over a unicast session before joining the SSM session 129 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in 130 applications where some part of the content is distributed through 131 multicast while the receivers get additional and/or auxiliary content 132 through one or more unicast connections, as sketched in Figure 1. 134 In this document, we discuss this problem and introduce a solution 135 that we refer to as Port Mapping. This solution allows receivers to 136 choose their desired UDP ports for RTP and RTCP in every unicast 137 session when they are running RTP applications using both unicast and 138 multicast services, and offer/answer exchange is not available. The 139 solution includes a Token-based protection mechanism against denial- 140 of-service (DoS) or packet amplification attacks that could be used 141 to cause one or more RTP packets to be sent to a victim client. This 142 solution is not applicable in cases where TCP is used as the 143 transport protocol in the unicast sessions. For such scenarios, 144 refer to [RFC4145]. 146 ----------- 147 | Unicast |................ 148 | Source |............. : 149 | (Server) | : : 150 ----------- : : 151 v v 152 ----------- ---------- ----------- 153 | Multicast |------->| Router |---------->|Client RTP | 154 | Source | | |..........>|Application| 155 ----------- ---------- ----------- 156 | : 157 | : ----------- 158 | :..............>|Client RTP | 159 +---------------->|Application| 160 ----------- 162 -------> Multicast RTP Flow 163 .......> Unicast RTP Flow 165 Figure 1: RTP applications simultaneously using both unicast and 166 multicast services 168 In the remainder of this document, we refer to the RTP endpoints that 169 serve other RTP endpoints over a unicast session as the Servers. The 170 receiving RTP endpoints are referred to as Clients. This terminology 171 also reflects the fact that when port mapping is used, the RTP 172 packets can only flow in one direction (from the server to the 173 client) in the unicast sessions. 175 2. Requirements Notation 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in 180 [RFC2119]. 182 3. Token-Based Port Mapping 184 Token-based Port Mapping consists of two steps: (i) Token request 185 and retrieval, and (ii) unicast session establishment. 187 Once a Token is retrieved from a particular server, it can be used 188 for all the unicast sessions the client will be running with this 189 particular server till the Token expires. By default, Tokens are 190 server specific. However, the client can use the same Token to 191 communicate with different servers if these servers are provided with 192 the same secret key and algorithm used to generate the Token and are 193 at least loosely clock-synchronized. 195 The Token is essentially an opaque encapsulation that is based on 196 client's IP address (as seen by the server). When a Token request is 197 received, the server creates a Token for this particular client, and 198 sends it back to the client. The Token becomes invalid if client's 199 IP address (as seen by the server) changes (note that the client 200 cannot necessarily detect this in a timely manner) or when the server 201 expires the Token. In these cases, the client has to request a new 202 Token. 204 As the second step, when the client wants to establish a unicast 205 session, the client includes the Token with its RTCP feedback 206 message. The server validates the Token, making sure that the IP 207 address information matches. This is effective against DoS attacks, 208 e.g., an attacker cannot simply spoof another client's IP address and 209 start a unicast transmission towards random clients. If the 210 validation passes, the unicast session gets established. Otherwise, 211 the server notifies the client that the validation has failed, and in 212 this case, the unicast session will not be established. 214 Upon successful validation and once the unicast session is 215 established, all the RTP and RTCP rules specified in [RFC3550] and 216 other relevant specifications also apply in this session until it is 217 terminated. During the lifetime of a unicast session, a client might 218 need to send RTCP messages that require authorization. Since such 219 messages require a valid Token for authorization, the client needs to 220 include the Token along with such RTCP messages as explained in 221 detail in later sections of this document. 223 Below, we first present a motivating scenario for port mapping and 224 then describe the normative behavior and requirements. 226 3.1. Motivating Scenario 228 Consider an SSM distribution network where a distribution source 229 multicasts RTP packets to a large number of clients, and one or more 230 retransmission servers function as feedback targets to collect 231 unicast RTCP feedback from these clients [RFC5760]. The 232 retransmission servers also join the multicast session to receive the 233 multicast packets and cache them for a certain time period. When a 234 client detects missing packets in the multicast session, it requests 235 a retransmission from one of the retransmission servers by using an 236 RTCP NACK message [RFC4585]. The retransmission server pulls the 237 requested packet(s) out of the cache and retransmits them to the 238 requesting client [RFC4588]. 240 The RTP and RTCP flows pertaining to the scenario described above are 241 sketched in Figure 2. Between the client and server, we assume there 242 exists at least one NAT device [RFC4787] (If there is no NAT devices 243 between the server and client, the method still works the same 244 fashion). The multicast and unicast sessions are clearly identified 245 with their individual RTP and RTCP flows and port numbers. 247 -------------- --- ---------- 248 | |-------------------------------| |-->|P1 | 249 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 250 | | | | | | 251 | Distribution | ---------------- | | | | 252 | Source | | | | | | | 253 | |---->|P1 | | | | | 254 | |.-.->|P2 | | | | | 255 | | | | | | | | 256 -------------- | P3|<.=.=.=.| |=.=|*c0 | 257 | P3|<~~~~~~~| |~~~|*c1 | 258 MULTICAST RTP | | | | | | 259 SESSION with | | | N | | | 260 UNICAST FEEDBACK | | | A | | | 261 | Retransmission | | T | | Client | 262 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 263 | Server | | | | | 264 | | | | | | 265 PORT MAPPING | PT|<~~~~~~~| |~~>|*cT | 266 | | | | | | 267 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 268 | | | | | | 269 AUXILIARY UNICAST | | | | | | 270 RTP SESSION | | | | | | 271 | P3|........| |..>|*c1 | 272 | P3|=.=.=.=.| |=.>|*c1 | 273 | P4|<.=.=.=.| |=.=|*c2 | 274 | | | | | | 275 ---------------- --- ---------- 277 -------> Multicast RTP Flow 278 .-.-.-.> Multicast RTCP Flow 279 .=.=.=.> Unicast RTCP Reports 280 ~~~~~~~> Unicast RTCP (Feedback) Messages 281 .......> Unicast RTP Flow 283 Figure 2: Example scenario showing an SSM distribution with support 284 for retransmissions from a server 286 In Figure 2, we have the following multicast and unicast ports: 288 o Ports P1 and P2 denote the destination RTP and RTCP ports in the 289 multicast session, respectively. The clients listen to these 290 ports to receive the multicast RTP and RTCP packets. Ports P1 and 291 P2 are defined declaratively. 293 o Port P3 denotes the RTCP port on the feedback target running on 294 the retransmission server to collect any RTCP packet sent by the 295 clients including feedback messages, and RTCP receiver and 296 extended reports. This is also the port that the retransmission 297 server uses to send the RTP packets and RTCP sender reports in the 298 unicast session. Port P3 is defined declaratively. 300 o Port P4 denotes the RTCP port on the retransmission server used to 301 collect the RTCP receiver and extended reports for the unicast 302 session. Port P4 is defined declaratively. 304 o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the 305 port on the client used to send the RTCP reports for the multicast 306 session. *c1 denotes the port on the client used to send the 307 unicast RTCP feedback messages in the multicast session and to 308 receive the RTP packets and RTCP sender reports in the unicast 309 session. *c2 denotes the port on the client used to send the RTCP 310 receiver and extended reports in the unicast session. Ports c0, 311 c1 and c2 could be the same port or different ports. There are 312 two advantages of using the same port for both c0 and c1: 314 1. Some NATs only keep bindings active when a packet goes from 315 the inside to the outside of the NAT (See REQ-6 of Section 4.3 316 of [RFC4787]). When the gap between the packets sent from the 317 client to the server is long, this can exceed that timeout. 318 If c0=c1, the occasional (periodic) RTCP receiver reports sent 319 from port c0 (for the multicast session's RTCP port P3) will 320 ensure the NAT does not time out the public port associated 321 with the incoming unicast traffic to port c1. 323 2. Having c0=c1 conserves NAT port bindings. 325 o Ports PT and *cT denote the ports through which the Token request 326 and retrieval occur at the server and client sides, respectively. 327 Port PT is declared on a per unicast session basis, although the 328 same port could be used for two or more unicast sessions sourced 329 by the server. A Token once requested and retrieved by a client 330 from port PT remains valid until its expiration time. 332 We assume that the information declaratively defined is available as 333 part of the session description information and is provided to the 334 clients. The Session Description Protocol (SDP) [RFC4566] and other 335 session description methods can be used for this purpose. 337 3.2. Normative Behavior and Requirements 339 In this section, we describe the normative behavior and requirements. 340 To simplify the presentation, we refer to the port numbers described 341 in the example presented in Figure 2. However, the behavior and 342 requirements described here are not specific to that particular 343 example, and can be applied to any scenario where analogous ports can 344 be identified. 346 First of all, a client compliant with this specification MUST be able 347 to include a Token with any type of RTCP message (as described below) 348 when it is needed. 350 Second, the solution provided in this specification is not applicable 351 in cases where there is RTP traffic flowing from the client to the 352 server in the unicast session. In other words, the direction of RTP 353 traffic MUST be only from the server to the client in the unicast 354 session. If the client wants to send RTP traffic back to the server, 355 the regular session establishment methods such as [RFC3264] need to 356 be used. 358 The following steps summarize the Token-based solution: 360 1. The client ascertains server address and port numbers (P3, P4 and 361 PT) from the session description. Port P4 MUST be different from 362 port P3. Port PT MAY be equal to port P3. 364 2. The client selects its local port numbers (*c0, *c1, *c2 and 365 *cT). It is strongly RECOMMENDED that the client uses the same 366 port for c0 and c1. Port cT MAY be equal to ports c0 and c1. 368 3. If the client does not have a Token (or the existing Token has 369 expired): 371 A. The client first sends a Port Mapping Request message 372 (Section 4.1) to port PT. This message is sent from port *cT 373 on the client side. The server learns client's IP address 374 from the received message. The client can send this message 375 anytime it wants (e.g., during initialization), and does not 376 normally ever need to re-send this message (See Section 6). 378 B. The server generates an opaque encapsulation (i.e., the 379 Token) based on certain information including the client's IP 380 address. 382 C. The server sends the Token back to the client using a Port 383 Mapping Response message (Section 4.2). This message MUST be 384 sent from port PT towards port cT. 386 4. The client needs to provide the Token to the server using a Token 387 Verification Request message (Section 4.3), whenever the client 388 sends an RTCP feedback message for triggering or controlling a 389 unicast session (See Section 4.3.1). If the Token is invalid or 390 missing, the server sends a Token Verification Failure message 391 (Section 4.4) to the client. 393 Note that the unicast session is only established after the 394 server has received a feedback message (along with a valid Token) 395 from the client for which it needs to react by sending unicast 396 data. Until a unicast session is established, neither the server 397 nor the client needs to send RTCP reports for the unicast 398 session. 400 5. Normal flows ensue as shown in Figure 2. It is strongly 401 RECOMMENDED that the client uses the same port for both c0 and 402 c1, as this causes the periodic RTCP reports to keep the NAT 403 mapping alive. However, if the client uses different ports for 404 c0 and c1, the client MUST keep its own NAT mapping alive for the 405 P3->c1 session (See [I-D.ietf-avt-app-rtp-keepalive] for 406 additional information). 408 In the unicast session, traffic from the server to the client 409 (i.e., both the RTP and RTCP packets sent from port P3 towards 410 port c1) MUST be multiplexed on the (same) port c1. 412 The client sends the RTCP receiver and extended reports in the 413 unicast session from port c2 towards port P4. The server 414 correlates these reports with the reports received in the 415 multicast session based on the client's RTCP Canonical Name 416 (CNAME). Thus, the client MUST use the same RTCP CNAME in both 417 sessions and its RTCP CNAME MUST be unique 418 [I-D.ietf-avt-rtp-cnames]. 420 A unicast session on a particular receive port c1 can last as long as 421 the associated multicast session lasts. However, a client cannot 422 keep using the same receive port c1 for different subsequent unicast 423 sessions since there could be packet leakage when switching from one 424 unicast session to another unless each received unicast stream has 425 its own distinct Synchronization Source (SSRC) identifier to allow 426 the client to filter out the undesired packets. Unless this is 427 guaranteed (which is not often easy), a client SHOULD use separate 428 receive ports for subsequent unicast sessions. After a sufficient 429 time (two minutes is RECOMMENDED, similar to one TCP Maximum Segment 430 Lifetime specified in [RFC0793]), a previously used receive port 431 could be used again. 433 The established unicast session can be explicitly terminated by the 434 procedures specified by an application or extension using the port 435 mapping approach described in this document. In addition, the 436 unicast session can also be terminated by the procedure defined 437 below, which is based on timing all participants out following the 438 timeout rules of [RFC3550]. Both the server and client periodically 439 check the liveness of the other peer, and if there was no RTCP 440 traffic from the other peer for a certain time (Section 6.3.5 of 441 [RFC3550] suggests five RTCP reporting intervals), the unicast 442 session SHOULD be considered terminated and no further RTP and/or 443 RTCP packets SHOULD be sent in this session. The client can attempt 444 to establish a new unicast session, if needed. If no explicit 445 procedure for session termination exists, the client MAY stop sending 446 RTCP to the server to accomplish session termination. However, the 447 server SHALL NOT stop sending RTCP until the unicast session is 448 terminated. If Token-based authentication is also signaled to be 449 allowed in the unicast session, i.e., in the RTCP messages sent from 450 port c2 towards port P4, the client SHOULD terminate the unicast 451 session by sending an RTCP BYE message for each SSRC it has used in 452 this unicast session. 454 4. Message Formats 456 This section defines the formats of the RTCP messages that are 457 exchanged between a server and a client for the purpose of port 458 mapping. A new RTCP control packet type is introduced and four port 459 mapping messages using this control packet are defined: 461 1. Port Mapping Request 463 2. Port Mapping Response 465 3. Token Verification Request 467 4. Token Verification Failure 469 Each message has a fixed-length field for version (V), padding (P), 470 sub-message type (SMT), packet type (PT), length and SSRC of packet 471 sender. Messages have other fields as defined below. In all 472 messages defined in this section, the PT field is set to TOKEN. 473 Individual messages are identified by the SMT field. The length 474 field indicates the message size in 32-bit words minus one, including 475 the header and any padding. This definition is in line with the 476 definition of the length field used in RTCP sender and receiver 477 reports. In all messages, any Reserved field SHALL be set to zero 478 and ignored. 480 Following the rules specified in [RFC3550], all integer fields in the 481 messages defined below are carried in network-byte order, that is, 482 most significant byte (octet) first, also known as big-endian. 483 Unless otherwise stated, numeric constants are in decimal (base 10). 485 Note that RTCP is not a timely or reliable protocol. The RTCP 486 packets might get lost or re-ordered in the network and it is not 487 easy to detect these events. When sending a new Port Mapping Request 488 message, the scheduling rules that apply to sending initial RTCP 489 messages [RFC4585] apply. When a client sends a Port Mapping Request 490 or Token Verification Request message but it does not receive a 491 response back from the server (either a Port Mapping Response or 492 Token Verification Failure message), it MAY resend its request by 493 following the timer rules defined for RTCP feedback messages in 494 Section 3.5 of [RFC4585] as a good practice. However, 495 implementations are advised to avoid sending spurious RTCP messages 496 just because the timer rules (based on some RTCP configuration 497 parameters) allow. Reasonably safe practices are to be used to 498 detect RTCP message loss. When sending an RTCP (feedback) message 499 bundled with a Token Verification Request message, the timer rules of 500 [RFC4585] apply as usual. 502 4.1. Port Mapping Request 504 The Port Mapping Request message is identified by SMT=1. This 505 message is transmitted by the client to a dedicated server port (and 506 possibly a dedicated address) to request a Token. In the Port 507 Mapping Request message, the packet sender SSRC is set to the 508 client's SSRC, which is chosen randomly by the client. The packet 509 format has the structure depicted in Figure 3. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 |V=2|P| SMT=1 | PT=TOKEN | Length=3 | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | SSRC of Packet Sender | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Random | 519 | Nonce | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 3: Packet format for the Port Mapping Request message 524 o Random Nonce (64 bits): Field that contains a random value 525 generated by the client following the procedures of [RFC4086]. 526 This nonce is taken into account by the server when generating a 527 Token for the client to enable better security for clients that 528 share the same IP address (Such clients need to produce a random 529 value extremely unlikely to collide with other clients sharing the 530 same IP address). If the same Port Mapping Request message is 531 transmitted multiple times for redundancy reasons, the random 532 nonce value MUST remain the same in these duplicated messages. 533 However, the client MUST generate a new random nonce for every new 534 Port Mapping Request message. 536 4.2. Port Mapping Response 538 The Port Mapping Response message is identified by SMT=2. This 539 message is sent by the server and delivers the Token to the client as 540 a response to the Port Mapping Request message. In the Port Mapping 541 Response message, the packet sender SSRC is set to the server's SSRC. 542 The packet format has the structure depicted in Figure 4. 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |V=2|P| SMT=2 | PT=TOKEN | Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | SSRC of Packet Sender | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | SSRC of Requesting Client | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Associated | 554 | Nonce | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 : Token Element : 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Absolute | 559 | Expiration Time | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Relative Expiration Time | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 : Packet Types Element : 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 4: Packet format for the Port Mapping Response message 568 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 569 of the client who sent the request. 571 o Associated Nonce (64 bits): Field that contains the nonce 572 received in the Port Mapping Request message and used in Token 573 construction. 575 o Token Element (Variable size): Element that is used to carry the 576 Token generated by the server. This element is a 32-bit aligned 577 Length-Value element. The Length field, which is 8 bits, 578 indicates the length (in octets) of the Value field that follows 579 the Length field. This length does not include any padding that 580 is required for alignment. The Value field carries the Token (or 581 more accurately, the output of the encoding process on the 582 server). If the Token element does not fall on a 32-bit boundary, 583 the last word MUST be padded to the boundary using further bits 584 set to zero. 586 o Absolute Expiration Time (64 bits): Field that contains the 587 absolute expiration time of the Token. The absolute expiration 588 time is expressed as a Network Time Protocol (NTP) timestamp value 589 in seconds since year 1900 [RFC5905]. The client does not need to 590 use this element directly, thus, does not need to synchronize its 591 clock with the server. However, the client needs to send this 592 element back to the server along with the associated nonce in the 593 Token Verification Request message, thus, needs to keep it 594 associated with the Token. 596 o Relative Expiration Time (32 bits): Field that contains the 597 relative expiration time of the Token. The relative expiration 598 time is expressed in seconds from the time the Token was 599 generated. Whenever a server decides to not grant a Token to a 600 requesting client, the relative expiration time will be set to 601 zero (and hence, the accompanying Token will be invalid). 603 The server conveys the relative expiration time in the clear to 604 the client to allow the client to request a new Token well before 605 the expiration time. 607 o Packet Types Element (Variable size): Element that is used to 608 signal which RTCP packet types require Token-based authentication. 609 This element is a 32-bit aligned Length-Value element. The Length 610 field, which is 8 bits, indicates the length (in octets) of the 611 Value field that follows the Length field. This length does not 612 include any padding that is required for alignment. The Value 613 field carries zero or more 8-bit sub-fields each carrying an RTCP 614 packet type. If the Packet Types element does not fall on a 32- 615 bit boundary, the last word MUST be padded to the boundary using 616 further bits set to zero. An example Packet Types element is 617 shown in Figure 5. 619 A server MAY change its policy on which RTCP packet types would 620 require Token-based authentication based on observations, 621 configuration or other policies. However, upon such a change the 622 server SHALL NOT send a new Port Mapping Response message to the 623 clients who requested a Token earlier. A client learns about this 624 change when and if it gets a Token Verification Failure message. 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Length=4 | 205 | 206 | 203 | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | 204 | Padding | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 5: Example Packet Types element 636 4.3. Token Verification Request 638 The Token Verification Request message is identified by SMT=3. This 639 message contains the Token and accompanies any RTCP message that 640 would trigger a new or control an existing unicast session. For a 641 list of such messages, see Section 4.3.1. 643 In the Token Verification Request message, the packet sender SSRC is 644 set to the client's SSRC. The client MUST NOT send a Token 645 Verification Request message with a Token that has expired. The 646 packet format has the structure depicted in Figure 6. 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 |V=2|P| SMT=3 | PT=TOKEN | Length | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | SSRC of Packet Sender | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Associated | 656 | Nonce | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 : Token Element : 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Associated Absolute | 661 | Expiration Time | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Figure 6: Packet format for the Token Verification Request message 666 o Associated Nonce (64 bits): Field that contains the nonce 667 associated with the Token above. 669 o Token Element (Variable size): Token element that was previously 670 received in the Port Mapping Response message. 672 o Associated Absolute Expiration Time (64 bits): Field that 673 contains the absolute expiration time associated with the Token 674 above. 676 4.3.1. Where to Include Token 678 This section provides guidelines about which RTCP packet types would 679 need to be accompanied by a Token Verification Request message. 680 However, since a server might determine in real time that other RTCP 681 messages also need to be authenticated by a Token, a client MUST act 682 according to the up-to-date list provided to the client in the Port 683 Mapping Response message (in the Packet Types element). Clients need 684 to support using Token-based authentication with any necessary RTCP 685 message (See Section 3.2). 687 As a general rule, when the Token capability is declared in the 688 session description, the RTCP messages that trigger transmission of 689 RTP packets in a port-mapped unicast session are REQUIRED to be 690 authenticated by using a Token. Such messages include but are not 691 limited to: 693 o NACK messages [RFC4585] 695 o RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 697 Additionally, some RTCP messages might directly or indirectly control 698 an existing unicast session associated with a multicast session. 699 Unless another authentication method as described in their respective 700 specifications is used, implementations MUST support authenticating 701 such RTCP messages by using a Token. 703 Examples are: 705 o BYE messages [RFC3550] 707 o RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 709 o CCM messages [RFC5104] 711 Note that even if a packet type is listed to require Token-based 712 authentication, it does not need to be authenticated when it does not 713 control the unicast session. For example, if BYE (203) is listed in 714 the Port Mapping Response message as one of the packet types that 715 requires authentication, the client does not need to bundle the RTCP 716 BYE message with a Token when it is sending it for the multicast 717 session. 719 The Token Verification Request message might also be bundled with 720 packets carrying RTCP receiver and/or extended reports. While such 721 packets do not have a strong security impact, a specific application 722 might desire to have a more controlled reporting scheme from the 723 clients. In this case, the server lists the packet types for the 724 receiver (201) and/or extended reports (207) in the Port Mapping 725 Response message. 727 4.4. Token Verification Failure 729 The Token Verification Failure message is identified by SMT=4. This 730 message is sent by the server and notifies the client that the Token 731 was invalid or that the client did not include a Token Verification 732 Request message in the RTCP packet although it was supposed to (The 733 message is sent from port P3 towards port c1). The packet format has 734 the structure depicted in Figure 7. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 |V=2|P| SMT=4 | PT=TOKEN | Length=5 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | SSRC of Packet Sender | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | SSRC of Requesting Client | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Failed PT | FMT | Reserved | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Associated | 748 | Nonce | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Figure 7: Packet format for the Token Verification Failure message 753 o SSRC of Packet Sender: This is server's SSRC, which equals the 754 SSRC of the respective multicast stream. Note that this SSRC 755 value is from a different SSRC space than the one used in the 756 unicast session. 758 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 759 of the client who sent the verification request. 761 o Failed PT (8 bits): Field that indicates the type of the RTCP 762 packet that caused this failure message. 764 o FMT (5 bits): Field that indicates the feedback message type 765 (FMT) value of the RTCP packet that caused this failure. Together 766 with the field above, the client can infer which RTCP message it 767 has previously sent caused this failure message to be sent by the 768 server. For example, if the client did not include a valid Token 769 with an RTCP NACK message, the Failed PT field will indicate 205 770 (RTPFB) and the FMT field will indicate 1 (Generic NACK). If the 771 RTCP message did not have an associated FMT value (such as an RTCP 772 BYE message), the FMT field SHALL be set to zero. 774 o Associated Nonce (64 bits): Field that contains the nonce 775 received in the Token Verification Request message. If there was 776 no Token Verification Request message included by the client, this 777 field is set to 0. 779 5. Procedures for Token Construction 781 The Token encoding is known to the server but opaque to the client. 782 Implementations MUST encode the following information into the Token 783 as a minimum, in order to provide adequate security: 785 o Client's IP address as seen by the server (32/128 bits for IPv4/ 786 IPv6 addresses) 788 o The nonce generated and inserted in the Port Mapping Request 789 message by the client (64 bits) 791 o The absolute expiration time chosen by the server indicated as an 792 NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, 793 to protect against replay attacks) 795 An example way for constructing Tokens is to perform HMAC-SHA1 796 [RFC2104] on the concatenated values of the information listed above. 797 The HMAC key needs to be at least 160 bits long, and generated using 798 a cryptographically secure random source [RFC4086]. While HMAC-SHA1 799 is the RECOMMENDED procedure, implementations might adopt different 800 approaches. 802 In addition to the information listed above, implementations are 803 encouraged to encode whatever additional information is deemed 804 necessary or useful. For example, key rollover is simplified by 805 encoding a key-id into the Token. As another example, a cluster of 806 anycast servers could find advantage by encoding a server identifier 807 into the Token. As another example, while HMAC-SHA1 provides a level 808 of security that is widely regarded as being more than sufficient for 809 providing message authentication and it is secure against all known 810 cryptanalytic attacks that use computational resources that are 811 currently economically feasible, if HMAC-SHA1 has been compromised, a 812 replacement HMAC algorithm could be used instead (e.g., HMAC-SHA256). 814 To protect from offline attacks, the server SHOULD occasionally 815 choose a new HMAC key. To ease implementation, a key-id can be 816 assigned to each HMAC key. This can be encoded as simply as one bit 817 (where the new key is X (e.g., 1) and the old key is the inverted 818 value of X (e.g., 0)), or if several keys are supported at once could 819 be encoded into several bits. As the encoding of the Token is 820 entirely private to the server and opaque to the clients, any 821 encoding can be used. By encoding the key-id into the Token element, 822 the server can reject an old key without bothering to do HMAC 823 validation (saving CPU cycles). The key-id can be encoded into the 824 Value field of the Token element by simply concatenating the 825 (plaintext) key-id with the hashed information (i.e., the Token 826 itself). 828 For example, the Value field in the Token element can be computed as: 830 key-id || hash-alg (client-ip | nonce | abs-expiration) 832 During Token construction, the expiration time has to be chosen 833 carefully based on the intended service duration. Tokens that are 834 valid for an unnecessarily long period of time (e.g., several hours) 835 might impose security risks. Depending on the application and use 836 cases, a reasonable value needs to be chosen by the server. Note 837 that using shorter lifetimes requires the clients to acquire Tokens 838 more frequently. However, since a client can acquire a new Token 839 well before it will need to use it, the client will not necessarily 840 be penalized for the acquisition delay. 842 Finally, be aware that NTP timestamps will wrap around in year 2036. 843 Refer to Section 6 of [RFC5905] for further details. 845 6. Validating Tokens 847 Upon receipt of an RTCP feedback message along with the Token 848 Verification Request message that contains a Token, nonce and 849 absolute expiration time, the server MUST validate the Token. 851 The server first applies its own procedure for constructing the 852 Tokens by using client's IP address from the received Token 853 Verification Request message, and the nonce and absolute expiration 854 time values reported in the received Token Verification Request 855 message. The server then compares the resulting output with the 856 Token sent by the client in the Token Verification Request message. 857 If they match and the absolute expiration time has not passed yet, 858 the server declares that the Token is valid. 860 Note that if the client's IP address changes, the Token will not 861 validate. Similarly, if the client inserts an incorrect nonce or 862 absolute expiration time value in the Token Verification Request 863 message, validation will fail. It is also possible that the server 864 wants to expire the Token prematurely. In these cases, the server 865 MUST reply back to the client with a Token Verification Failure 866 message (that goes from port P3 on the server towards port c1 on the 867 client). 869 In addition to the Token Verification Failure message, it is 870 RECOMMENDED that applications define an application-specific error 871 response to be sent by the server when the server detects that the 872 Token is invalid. For applications using 873 [I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new 874 4xx-level response code in the RAMS Response Code Space Registry. A 875 client that received a Token Verification Failure message can request 876 a new Token from the server. 878 If a client receives a Port Mapping Response message with an invalid 879 Token (i.e., the relative expiration time is set to zero) two or more 880 times for a particular Port Mapping Request message, or the client 881 receives a Token Verification Failure message two or more times for 882 the same Token Verification Request message, the client SHOULD do the 883 following: 885 1. Check whether the session description has been updated or not. 886 If it was updated, act according to the new session description. 888 2. Exponentially back off for the third and subsequent attempts. 889 Exponential back-off does not apply when the client sends a Port 890 Mapping Request or Token Verification Request message to a new 891 address and/or port. 893 7. SDP Signaling 895 7.1. The portmapping-req Attribute 897 This attribute is used declaratively in any media block that 898 describes an RTP session that uses Token-based authentication for one 899 or more RTCP messages relating to that session. It indicates the 900 port and optionally the address for obtaining a Token. 902 The presence of the 'portmapping-req' attribute indicates that (i) a 903 Token MUST be included in certain RTCP messages sent to the server 904 triggering or controlling a unicast session (See Section 4.3.1), and 905 (ii) the client MUST receive the unicast session's RTP and RTCP 906 packets from the server on the port from which it sent the RTCP 907 message triggering the unicast session. 909 Note: This does not imply that Token Verification Request 910 messages need to be always sent in the unicast session. Token 911 Verification Request messages accompany RTCP messages that trigger 912 or control this unicast session, and are sent either in the 913 multicast session or the unicast session, depending on the RTCP 914 message (See Section 4.3.1). 916 7.1.1. ABNF Definition of portmapping-req 918 The formal description of the 'portmapping-req' attribute is defined 919 by the following ABNF [RFC5234] syntax: 921 portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP 922 addrtype SP connection-address]] CRLF 924 Here, 'port', 'nettype', 'addrtype' and 'connection-address' are 925 defined as specified in Section 9 of [RFC4566]. 927 The 'portmapping-req' attribute SHALL only be used as a media-level 928 attribute. 930 In the optional address value, only unicast addresses SHOULD be used 931 unless one wants to use a multicast address after evaluating the 932 additional security risks such as non-legit servers generating fake 933 Tokens. If the address is not specified, the (source) address in the 934 "c" line applicable to the media description SHALL be used. 936 7.1.2. Offer/Answer Model Considerations 938 When using the 'portmapping-req' attribute in SDP offer/answer 939 exchanges [RFC3264], the following considerations apply. When an 940 offerer sends an answerer an offer of an SDP description making use 941 of the Token approach described in this specification, the 942 'portmapping-req' attribute is included declaratively. There will 943 not be offer/answer exchanges between the answerer and the actual 944 server providing the unicast service(s). 946 When the answerer supports the Token approach, it MUST echo in its 947 answer back to the offerer the 'portmapping-req' attribute from the 948 offer including the same port number and address (if any). If the 949 answerer does not implement this specification, it follows normal SDP 950 parsing of unknown attributes (they are ignored and are not sent in 951 the answer). This means that the answerer can still join the 952 multicast session, but will not be able to use the unicast service(s) 953 that require the use of Tokens. 955 7.2. Requirements 957 The use of SDP for the port mapping solution normatively requires the 958 support for: 960 o The SDP grouping framework and flow identification (FID) semantics 961 [RFC5888] 963 o The RTP/AVPF profile [RFC4585] 965 o Multiplexing RTP and RTCP on a single port on both endpoints in 966 the unicast session [RFC5761] 968 7.3. Example and Discussion 970 The declarative SDP describing the scenario given in Figure 2 is 971 written as: 973 v=0 974 o=ali 1122334455 1122334466 IN IP4 nack.example.com 975 s=Local Retransmissions 976 t=0 0 977 a=group:FID 1 2 978 a=rtcp-unicast:rsi 979 m=video 41000 RTP/AVPF 98 980 i=Multicast Stream 981 c=IN IP4 233.252.0.2/255 982 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 983 a=rtpmap:98 MP2T/90000 984 a=multicast-rtcp:41500 ; Note 1 985 a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 986 a=rtcp-fb:98 nack ; Note 2 987 a=portmapping-req:30000 IN IP4 192.0.2.1 ; Note 3 988 a=mid:1 989 m=video 42000 RTP/AVPF 99 ; Note 4 990 i=Unicast Retransmission Stream 991 c=IN IP4 192.0.2.1 992 a=sendonly 993 a=rtpmap:99 rtx/90000 994 a=rtcp-mux ; Note 5 995 a=rtcp:42500 ; Note 6 996 a=fmtp:99 apt=98; rtx-time=5000 997 a=portmapping-req:30001 ; Note 3 998 a=mid:2 1000 Figure 8: SDP describing an SSM distribution with support for 1001 retransmissions from a local server 1003 In this description, we highlight the following notes: 1005 Note 1: The source stream is multicast from a distribution source 1006 with a source IP address of 198.51.100.1 to the multicast destination 1007 address of 233.252.0.2 and port 41000 (P1). The associated RTCP 1008 packets are multicast in the same group to port 41500 (P2). 1010 Note 2: A retransmission server including feedback target 1011 functionality with an IP address of 192.0.2.1 and port of 42000 (P3) 1012 is specified with the 'rtcp' attribute. The feedback functionality 1013 is enabled for the RTP stream with payload type 98 through the 1014 'rtcp-fb' attribute [RFC4585]. 1016 Note 3: The "a=portmapping-req" line indicates that one or more RTCP 1017 messages relating to the RTP session described in this media block 1018 uses Token-based authentication, and a Token needs to be retrieved 1019 first from the designated port (PT) before the unicast session can be 1020 established. In the first appearance, an explicit address is 1021 provided. In the second appearance, there is no address indicated in 1022 this line and the client needs to send the Token request to the 1023 address specified in the "c" line in the unicast media block. 1025 Note 4: The port specified in the second "m" line (for the unicast 1026 stream) does not mean anything in this scenario as the client does 1027 not send any RTP traffic back to the server. 1029 Note 5: The server multiplexes RTP and RTCP packets on the same port 1030 (c1 in Figure 2). 1032 Note 6: The server uses port 42500 (P4) for the unicast session. 1034 8. Address Pooling NATs 1036 Large-scale NAT devices have a pool of public IPv4 addresses and map 1037 internal hosts to one of those public IPv4 addresses. As long as an 1038 internal host maintains an active mapping in the NAT, the same IPv4 1039 address is assigned to new connections. However, once all of the 1040 host's mappings have been deleted (e.g., because of timeout), it is 1041 possible that a new connection from that same host will be assigned a 1042 different IPv4 address from the pool. When that occurs, the Token 1043 will be considered invalid by the server, causing an additional round 1044 trip for the client to acquire a fresh Token. 1046 Any traffic from the host which traverses the NAT will prevent this 1047 problem. As the host is sending RTCP receiver reports at least every 1048 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is 1049 receiving, those RTCP messages will be sufficient to prevent this 1050 problem. 1052 9. Security Considerations 1054 9.1. Tokens 1056 The Token, which is generated based on a client's IP address and 1057 expiration date, provides protection against off-path denial-of- 1058 service (DoS) attacks. An attacker using a certain IP address cannot 1059 cause one or more RTP packets to be sent to a victim client who has a 1060 different IP address. However, if the attacker acquires a valid 1061 Token for a victim and can spoof the victim's source address, this 1062 approach becomes vulnerable to replay attacks. This is especially 1063 easy if the attacker and victim are behind a large-scale NAT and 1064 share the same IP address. 1066 Multicast is deployed on managed networks - not the Internet. These 1067 managed networks will choose to enable network ingress filtering 1068 [RFC2827] or not. If ingress filtering is enabled on a network, an 1069 attacker cannot spoof a victim's IP address to use a Token to 1070 initiate an attack against a victim. However, if ingress filtering 1071 is not enabled on a network, an attacker could obtain a Token and 1072 spoof the victim's address, causing traffic to flood the victim. On 1073 such a network, the server can reduce the time period for such an 1074 attack by expiring a Token in a short period of time. In the extreme 1075 case, the server can expire the Token in such a short period of time, 1076 such that the client will have to acquire a new Token immediately 1077 before using it in a Token Verification Request message. One should, 1078 however, note that such a behavior might have an adverse effect on 1079 the delay in establishing or controlling a unicast session. 1081 RTCP messages could be subject to on-path or man-in-the-middle 1082 attacks. For example, an attacker can modify a value in one or more 1083 fields in the Port Mapping Response or the Token Verification Request 1084 message that are used in Token construction. This will result in 1085 Token validation failure. Consequently, the client ends up asking 1086 the server to generate a new Token. The resulting delay and extra 1087 processing on the server are undesirable. 1089 Alternatively, the attacker can modify a value in a field that is not 1090 used in Token construction. For example, the attacker can reduce the 1091 value in the Relative Expiration Time field in the Port Mapping 1092 Response message from two hours to two minutes. While the Token will 1093 still validate, this attack will result in more frequent requests to 1094 the server for a new Token. Oppositely, the attacker can increase 1095 the value in the Relative Expiration Time field, and make the client 1096 think the Token will be valid for a longer time. This attack can be 1097 only detected by monitoring the activity on the server. Note that 1098 using the relative expiration time in Token construction does not 1099 necessarily make this attack easier to detect since the attacker 1100 might revert the modified value back to its original value in the 1101 Token Verification Request message. This allows the Token to still 1102 validate on the server. In this case, the attack is still only 1103 detectable by monitoring the server activity. 1105 If there is a risk or concern for on-path or man-in-the-middle 1106 attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP) 1107 [RFC3711]. 1109 9.2. The portmapping and portmapping-req Attributes 1111 The 'portmapping-req' attribute is not believed to introduce any 1112 significant security risk to multimedia applications. A malevolent 1113 third party could use this attribute to redirect the Port Mapping 1114 Request messages by altering the port number or cause the unicast 1115 session establishment to fail by removing it from the SDP 1116 description. But, this requires intercepting and rewriting the 1117 packets carrying the SDP description; and if an interceptor can do 1118 that, many more attacks are possible, including a wholesale change of 1119 the addresses and port numbers at which the media will be sent. 1121 In order to avoid attacks of this sort, the SDP description needs to 1122 be integrity protected and provided with source authentication. This 1123 can, for example, be achieved on an end-to-end basis using S/MIME 1124 [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME 1125 types (application/sdp). Alternatively, HTTPS [RFC2818] or the 1126 authentication method in the Session Announcement Protocol (SAP) 1127 [RFC2974] could be used as well. 1129 10. IANA Considerations 1131 The following contact information shall be used for all registrations 1132 in this document: 1134 Ali Begen 1135 abegen@cisco.com 1137 Note to the RFC Editor: In the following, please replace "XXXX" with 1138 the number of this document prior to publication as an RFC. 1140 10.1. Registration of SDP Attributes 1142 This document registers one new attribute name in SDP. 1144 SDP Attribute ("att-field"): 1145 Attribute name: portmapping-req 1146 Long form: Port and address for requesting Token 1147 Type of name: att-field 1148 Type of attribute: Media level 1149 Subject to charset: No 1150 Purpose: See this document 1151 Reference: [RFCXXXX] 1152 Values: See this document 1154 10.2. Registration of RTCP Control Packet Types 1156 In accordance with Section 15 of [RFC3550], this specification adds 1157 the following value to the RTCP Control Packet types sub-registry in 1158 the Real-Time Transport Protocol (RTP) Parameters registry: 1160 Value Abbrev. Name Reference 1161 -------- --------- --------------------------------------- --------- 1162 TBD TOKEN Port Mapping [RFCXXXX] 1164 Note to the IANA: Please assign the next available value, which is 1165 currently 210. 1167 10.3. SMT Values for TOKEN Packet Type Registry 1169 This document creates a new sub-registry for the sub-message type 1170 (SMT) values to be used with the TOKEN packet type. The registry is 1171 called the SMT Values for TOKEN Packet Type Registry. This registry 1172 is to be managed by the IANA according to the IETF Review policy of 1174 [RFC5226]. 1176 The length of the SMT field is five bits, allowing 32 values. The 1177 registry is initialized with the following entries: 1179 Value Name Reference 1180 ----- -------------------------------------------------- ------------- 1181 0 Reserved [RFCXXXX] 1182 1 Port Mapping Request [RFCXXXX] 1183 2 Port Mapping Response [RFCXXXX] 1184 3 Token Verification Request [RFCXXXX] 1185 4 Token Verification Failure [RFCXXXX] 1186 5-30 Unassigned IETF Review 1187 31 Reserved [RFCXXXX] 1189 The SMT values 0 and 31 are reserved for future use. 1191 10.4. RAMS Response Code Space Registry 1193 This document adds the following entry to the RAMS Response Code 1194 Space Registry. 1196 Code Description Reference 1197 ----- -------------------------------------------------- ------------- 1198 405 Invalid Token [RFCXXXX] 1200 This response code is used when the Token included by the RTP_Rx in 1201 the RAMS-R message is invalid. 1203 11. Acknowledgments 1205 The approach presented in this document came out after discussions 1206 with various individuals in the AVT and MMUSIC WGs, and the breakout 1207 session held in the Anaheim meeting. We thank each of these 1208 individuals, in particular to Magnus Westerlund and Colin Perkins. 1210 12. References 1212 12.1. Normative References 1214 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1215 Jacobson, "RTP: A Transport Protocol for Real-Time 1216 Applications", STD 64, RFC 3550, July 2003. 1218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1219 Requirement Levels", BCP 14, RFC 2119, March 1997. 1221 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1222 Description Protocol", RFC 4566, July 2006. 1224 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1225 "Extended RTP Profile for Real-time Transport Control 1226 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1227 July 2006. 1229 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1230 Protocol (RTCP) Extensions for Single-Source Multicast 1231 Sessions with Unicast Feedback", RFC 5760, February 2010. 1233 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1234 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1236 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1237 Requirements for Security", BCP 106, RFC 4086, June 2005. 1239 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1240 Time Protocol Version 4: Protocol and Algorithms 1241 Specification", RFC 5905, June 2010. 1243 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1244 Hashing for Message Authentication", RFC 2104, 1245 February 1997. 1247 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1248 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1250 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1251 Control Packets on a Single Port", RFC 5761, April 2010. 1253 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1254 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1255 RFC 3711, March 2004. 1257 [I-D.ietf-avt-rtp-cnames] 1258 Begen, A., Perkins, C., and D. Wing, "Guidelines for 1259 Choosing RTP Control Protocol (RTCP) Canonical Names 1260 (CNAMEs)", draft-ietf-avt-rtp-cnames-05 (work in 1261 progress), January 2011. 1263 12.2. Informative References 1265 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1266 with Session Description Protocol (SDP)", RFC 3264, 1267 June 2002. 1269 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1270 the Session Description Protocol (SDP)", RFC 4145, 1271 September 2005. 1273 [I-D.ietf-avt-rapid-acquisition-for-rtp] 1274 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 1275 Based Rapid Acquisition of Multicast RTP Sessions", 1276 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 1277 progress), November 2010. 1279 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1280 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1281 RFC 4787, January 2007. 1283 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1284 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1285 July 2006. 1287 [I-D.ietf-avt-app-rtp-keepalive] 1288 Marjou, X. and A. Sollaud, "Application Mechanism for 1289 keeping alive the Network Address Translator (NAT) 1290 mappings associated to RTP/RTCP flows.", 1291 draft-ietf-avt-app-rtp-keepalive-10 (work in progress), 1292 March 2011. 1294 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1295 Defeating Denial of Service Attacks which employ IP Source 1296 Address Spoofing", BCP 38, RFC 2827, May 2000. 1298 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1299 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1300 May 2008. 1302 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1303 "Codec Control Messages in the RTP Audio-Visual Profile 1304 with Feedback (AVPF)", RFC 5104, February 2008. 1306 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1307 RFC 5652, September 2009. 1309 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1311 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1312 Announcement Protocol", RFC 2974, October 2000. 1314 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1315 RFC 793, September 1981. 1317 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1318 Mail Extensions (S/MIME) Version 3.2 Message 1319 Specification", RFC 5751, January 2010. 1321 Authors' Addresses 1323 Ali Begen 1324 Cisco 1325 181 Bay Street 1326 Toronto, ON M5J 2T3 1327 Canada 1329 Email: abegen@cisco.com 1331 Dan Wing 1332 Cisco Systems, Inc. 1333 170 West Tasman Dr. 1334 San Jose, CA 95134 1335 USA 1337 Email: dwing@cisco.com 1339 Tom VanCaenegem 1340 Alcatel-Lucent 1341 Copernicuslaan 50 1342 Antwerpen, 2018 1343 Belgium 1345 Email: Tom.Van_Caenegem@alcatel-lucent.com