idnits 2.17.1 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.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 (January 28, 2011) is 4831 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 1200, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-10) exists of draft-ietf-avt-app-rtp-keepalive-09 -- 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 (~~), 3 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: August 1, 2011 T. VanCaenegem 6 Alcatel-Lucent 7 January 28, 2011 9 Port Mapping Between Unicast and Multicast RTP Sessions 10 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 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 August 1, 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. That is, clients MUST NOT implement this 349 specification with only a specific use case in mind. 351 Second, the solution provided in this specification is not applicable 352 in cases where there is RTP traffic flowing from the client to the 353 server in the unicast session. In other words, the direction of RTP 354 traffic MUST be only from the server to the client in the unicast 355 session. If the client wants to send RTP traffic back to the server, 356 the regular session establishment methods such as [RFC3264] need to 357 be used. 359 The following steps summarize the Token-based solution: 361 1. The client ascertains server address and port numbers (P3, P4 and 362 PT) from the session description. Port P4 MUST be different from 363 port P3. Port PT MAY be equal to port P3. 365 2. The client selects its local port numbers (*c0, *c1, *c2 and 366 *cT). It is strongly RECOMMENDED that the client uses the same 367 port for c0 and c1. Port cT MAY be equal to ports c0 and c1. 369 3. If the client does not have a Token (or the existing Token has 370 expired): 372 A. The client first sends a Port Mapping Request message 373 (Section 4.1) to port PT. This message is sent from port *cT 374 on the client side. The server learns client's IP address 375 from the received message. The client can send this message 376 anytime it wants (e.g., during initialization), and does not 377 normally ever need to re-send this message (See Section 6). 379 B. The server generates an opaque encapsulation (i.e., the 380 Token) based on certain information including the client's IP 381 address. 383 C. The server sends the Token back to the client using a Port 384 Mapping Response message (Section 4.2). This message MUST be 385 sent from port PT towards port cT. 387 4. The client needs to provide the Token to the server using a Token 388 Verification Request message (Section 4.3), whenever the client 389 sends an RTCP feedback message for triggering or controlling a 390 unicast session (See Section 4.3.1). If the Token is invalid or 391 missing, the server sends a Token Verification Failure message 392 (Section 4.4) to the client. 394 Note that the unicast session is only established after the 395 server has received a feedback message (along with a valid Token) 396 from the client for which it needs to react by sending unicast 397 data. Until a unicast session is established, neither the server 398 nor the client needs to send RTCP reports for the unicast 399 session. 401 5. Normal flows ensue as shown in Figure 2. Note that in the 402 unicast session, traffic from the server to the client (i.e., 403 both the RTP and RTCP packets sent from port P3 towards port c1) 404 MUST be multiplexed on the (same) port c1. If the client uses 405 the same port for both c0 and c1, the RTCP reports sent for the 406 multicast session keep the P3->c1(=c0) binding alive. If the 407 client uses different ports for c0 and c1, the client needs to 408 periodically send an explicit keep-alive message 409 [I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive 410 during the lifetime of the unicast session if the time between 411 unicast feedback messages (from c1 to P3) is likely to exceed the 412 NAT's timeout value (For the NAT timeout value requirements, see 413 [RFC4787]). 415 The client sends the RTCP receiver and extended reports in the 416 unicast session from port c2 towards port P4. The server 417 correlates these reports with the reports received in the 418 multicast session based on the client's RTCP Canonical Name 419 (CNAME). Thus, the client MUST use the same RTCP CNAME in both 420 sessions and its RTCP CNAME MUST be unique 421 [I-D.ietf-avt-rtp-cnames]. 423 A unicast session on a particular receive port c1 can last as long as 424 the associated multicast session lasts. However, a client cannot 425 keep using the same receive port c1 for different subsequent unicast 426 sessions since there could be packet leakage when switching from one 427 unicast session to another unless each received unicast stream has 428 its own distinct Synchronization Source (SSRC) identifier to allow 429 the client to filter out the undesired packets. Unless this is 430 guaranteed (which is not often easy), a client SHOULD use separate 431 receive ports for subsequent unicast sessions. After a sufficient 432 time (two minutes is RECOMMENDED, similar to one TCP Maximum Segment 433 Lifetime specified in [RFC0793]), a previously used receive port 434 could be used again. 436 The established unicast session can be explicitly terminated by the 437 procedures specified by an application or extension using the port 438 mapping approach described in this document. In addition, the 439 unicast session can also be terminated by the procedure defined 440 below, which is based on timing all participants out following the 441 timeout rules of [RFC3550]. Both the server and client periodically 442 check the liveness of the other peer, and if there was no RTCP 443 traffic from the other peer for a certain time (Section 6.3.5 of 444 [RFC3550] suggests five RTCP reporting intervals), the unicast 445 session SHOULD be considered terminated and no further RTP and/or 446 RTCP packets SHOULD be sent in this session. The client can attempt 447 to establish a new unicast session, if needed. If no explicit 448 procedure for session termination exists, the client MAY stop sending 449 RTCP to the server to accomplish session termination. However, the 450 server SHALL NOT stop sending RTCP until the unicast session is 451 terminated. If Token-based authentication is also signaled to be 452 allowed in the unicast session, i.e., in the RTCP messages sent from 453 port c2 towards port P4, the client SHOULD terminate the unicast 454 session by sending an RTCP BYE message for each SSRC it has used in 455 this unicast session. 457 4. Message Formats 459 This section defines the formats of the RTCP messages that are 460 exchanged between a server and a client for the purpose of port 461 mapping. A new RTCP control packet type is introduced and four port 462 mapping messages using this control packet are defined: 464 1. Port Mapping Request 466 2. Port Mapping Response 468 3. Token Verification Request 470 4. Token Verification Failure 472 Each message has a fixed-length field for version (V), padding (P), 473 sub-message type (SMT), packet type (PT), length and SSRC of packet 474 sender. Messages have other fields as defined below. In all 475 messages defined in this section, the PT field is set to TOKEN. 476 Individual messages are identified by the SMT field. The length 477 field indicates the message size in 32-bit words minus one, including 478 the header and any padding. This definition is in line with the 479 definition of the length field used in RTCP sender and receiver 480 reports. In all messages, any Reserved field SHALL be set to zero 481 and ignored. 483 Following the rules specified in [RFC3550], all integer fields in the 484 messages defined below are carried in network-byte order, that is, 485 most significant byte (octet) first, also known as big-endian. 486 Unless otherwise stated, numeric constants are in decimal (base 10). 488 Note that RTCP is not a timely or reliable protocol. The RTCP 489 packets might get lost or re-ordered in the network and it is not 490 easy to detect these events. When sending a new Port Mapping Request 491 message, the scheduling rules that apply to sending initial RTCP 492 messages [RFC4585] apply. When a client sends a Port Mapping Request 493 or Token Verification Request message but it does not receive a 494 response back from the server (either a Port Mapping Response or 495 Token Verification Failure message), it MAY resend its request by 496 following the timer rules defined for RTCP feedback messages in 497 Section 3.5 of [RFC4585] as a good practice. However, 498 implementations are advised to avoid sending spurious RTCP messages 499 just because the timer rules (based on some RTCP configuration 500 parameters) allow. Reasonably safe practices are to be used to 501 detect RTCP message loss. When sending an RTCP (feedback) message 502 bundled with a Token Verification Request message, the timer rules of 503 [RFC4585] apply as usual. 505 4.1. Port Mapping Request 507 The Port Mapping Request message is identified by SMT=1. This 508 message is transmitted by the client to a dedicated server port (and 509 possibly a dedicated address) to request a Token. In the Port 510 Mapping Request message, the packet sender SSRC is set to the 511 client's SSRC, which is chosen randomly by the client. The packet 512 format has the structure depicted in Figure 3. 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 |V=2|P| SMT=1 | PT=TOKEN | Length=3 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | SSRC of Packet Sender | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Random | 522 | Nonce | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Figure 3: Packet format for the Port Mapping Request message 527 o Random Nonce (64 bits): Field that contains a random value 528 generated by the client following the procedures of [RFC4086]. 529 This nonce is taken into account by the server when generating a 530 Token for the client to enable better security for clients that 531 share the same IP address (Such clients need to produce a random 532 value guaranteed to be temporally and globally unique). If the 533 same Port Mapping Request message is transmitted multiple times 534 for redundancy reasons, the random nonce value MUST remain the 535 same in these duplicated messages. However, the client MUST 536 generate a new random nonce for every new Port Mapping Request 537 message. 539 4.2. Port Mapping Response 541 The Port Mapping Response message is identified by SMT=2. This 542 message is sent by the server and delivers the Token to the client as 543 a response to the Port Mapping Request message. In the Port Mapping 544 Response message, the packet sender SSRC is set to the server's SSRC. 545 The packet format has the structure depicted in Figure 4. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |V=2|P| SMT=2 | PT=TOKEN | Length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | SSRC of Packet Sender | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | SSRC of Requesting Client | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Associated | 557 | Nonce | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 : Token Element : 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Absolute | 562 | Expiration Time | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Relative Expiration Time | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 : Packet Types Element : 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 4: Packet format for the Port Mapping Response message 571 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 572 of the client who sent the request. 574 o Associated Nonce (64 bits): Field that contains the nonce 575 received in the Port Mapping Request message and used in Token 576 construction. 578 o Token Element (Variable size): Element that is used to carry the 579 Token generated by the server. This element is a 32-bit aligned 580 Length-Value element. The Length field, which is 8 bits, 581 indicates the length (in octets) of the Value field that follows 582 the Length field. This length does not include any padding that 583 is required for alignment. The Value field carries the Token (or 584 more accurately, the output of the encoding process on the 585 server). If the Token element does not fall on a 32-bit boundary, 586 the last word MUST be padded to the boundary using further bits 587 set to zero. 589 o Absolute Expiration Time (64 bits): Field that contains the 590 absolute expiration time of the Token. The absolute expiration 591 time is expressed as a Network Time Protocol (NTP) timestamp value 592 in seconds since year 1900 [RFC5905]. The client does not need to 593 use this element directly, thus, does not need to synchronize its 594 clock with the server. However, the client needs to send this 595 element back to the server along with the associated nonce in the 596 Token Verification Request message, thus, needs to keep it 597 associated with the Token. 599 o Relative Expiration Time (32 bits): Field that contains the 600 relative expiration time of the Token. The relative expiration 601 time is expressed in seconds from the time the Token was 602 generated. Whenever a server decides to not grant a Token to a 603 requesting client, the relative expiration time will be set to 604 zero (and hence, the accompanying Token will be invalid). 606 The server conveys the relative expiration time in the clear to 607 the client to allow the client to request a new Token well before 608 the expiration time. 610 o Packet Types Element (Variable size): Element that is used to 611 signal which RTCP packet types require Token-based authentication. 612 This element is a 32-bit aligned Length-Value element. The Length 613 field, which is 8 bits, indicates the length (in octets) of the 614 Value field that follows the Length field. This length does not 615 include any padding that is required for alignment. The Value 616 field carries zero or more 8-bit sub-fields each carrying an RTCP 617 packet type. If the Packet Types element does not fall on a 32- 618 bit boundary, the last word MUST be padded to the boundary using 619 further bits set to zero. An example Packet Types element is 620 shown in Figure 5. 622 A server MAY change its policy on which RTCP packet types would 623 require Token-based authentication based on observations, 624 configuration or other policies. However, upon such a change the 625 server SHALL NOT send a new Port Mapping Response message to the 626 clients who requested a Token earlier. A client learns about this 627 change when and if it gets a Token Verification Failure message. 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Length=4 | 205 | 206 | 203 | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | 204 | Padding | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Figure 5: Example Packet Types element 639 4.3. Token Verification Request 641 The Token Verification Request message is identified by SMT=3. This 642 message contains the Token and accompanies any RTCP message that 643 would trigger a new or control an existing unicast session. For a 644 list of such messages, see Section 4.3.1. 646 In the Token Verification Request message, the packet sender SSRC is 647 set to the client's SSRC. The client MUST NOT send a Token 648 Verification Request message with a Token that has expired. The 649 packet format has the structure depicted in Figure 6. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 |V=2|P| SMT=3 | PT=TOKEN | Length | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | SSRC of Packet Sender | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Associated | 659 | Nonce | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 : Token Element : 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Associated Absolute | 664 | Expiration Time | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 6: Packet format for the Token Verification Request message 669 o Associated Nonce (64 bits): Field that contains the nonce 670 associated with the Token above. 672 o Token Element (Variable size): Token element that was previously 673 received in the Port Mapping Response message. 675 o Associated Absolute Expiration Time (64 bits): Field that 676 contains the absolute expiration time associated with the Token 677 above. 679 4.3.1. Where to Include Token 681 This section provides guidelines about which RTCP packet types would 682 need to be accompanied by a Token Verification Request message. 683 However, since a server might determine in real time that other RTCP 684 messages also need to be authenticated by a Token, a client MUST act 685 according to the up-to-date list provided to the client in the Port 686 Mapping Response message (in the Packet Types element). Clients need 687 to support using Token-based authentication with any necessary RTCP 688 message (See Section 3.2). 690 As a general rule, when the Token capability is declared in the 691 session description, the RTCP messages that trigger transmission of 692 RTP packets in a port-mapped unicast session are REQUIRED to be 693 authenticated by using a Token. Such messages include but are not 694 limited to: 696 o NACK messages [RFC4585] 698 o RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 700 Additionally, some RTCP messages might directly or indirectly control 701 an existing unicast session associated with a multicast session. 702 Unless another authentication method as described in their respective 703 specifications is used, such RTCP messages might also need to be 704 authenticated by using a Token. Examples are: 706 o BYE messages [RFC3550] 708 o RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 710 o CCM messages [RFC5104] 712 Note that even if a packet type is listed to require Token-based 713 authentication, it does not need to be authenticated when it does not 714 control the unicast session. For example, if BYE (203) is listed in 715 the Port Mapping Response message as one of the packet types that 716 requires authentication, the client does not need to bundle the RTCP 717 BYE message with a Token when it is sending it for the multicast 718 session. 720 The Token Verification Request message might also be bundled with 721 packets carrying RTCP receiver and/or extended reports. While such 722 packets do not have a strong security impact, a specific application 723 might desire to have a more controlled reporting scheme from the 724 clients. In this case, the server lists the packet types for the 725 receiver (201) and/or extended reports (207) in the Port Mapping 726 Response message. 728 4.4. Token Verification Failure 730 The Token Verification Failure message is identified by SMT=4. This 731 message is sent by the server and notifies the client that the Token 732 was invalid or that the client did not include a Token Verification 733 Request message in the RTCP packet although it was supposed to (The 734 message is sent from port P3 towards port c1). The packet format has 735 the structure depicted in Figure 7. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 |V=2|P| SMT=4 | PT=TOKEN | Length=5 | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | SSRC of Packet Sender | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | SSRC of Requesting Client | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Failed PT | FMT | Reserved | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Associated | 749 | Nonce | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Figure 7: Packet format for the Token Verification Failure message 754 o SSRC of Packet Sender: This is server's SSRC, which equals the 755 SSRC of the respective multicast stream. Note that this SSRC 756 value is from a different SSRC space than the one used in the 757 unicast session. 759 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 760 of the client who sent the verification request. 762 o Failed PT (8 bits): Field that indicates the type of the RTCP 763 packet that caused this failure message. 765 o FMT (5 bits): Field that indicates the feedback message type 766 (FMT) value of the RTCP packet that caused this failure. Together 767 with the field above, the client can infer which RTCP message it 768 has previously sent caused this failure message to be sent by the 769 server. For example, if the client did not include a valid Token 770 with an RTCP NACK message, the Failed PT field will indicate 205 771 (RTPFB) and the FMT field will indicate 1 (Generic NACK). If the 772 RTCP message did not have an associated FMT value (such as an RTCP 773 BYE message), the FMT field SHALL be set to zero. 775 o Associated Nonce (64 bits): Field that contains the nonce 776 received in the Token Verification Request message. If there was 777 no Token Verification Request message included by the client, this 778 field is set to 0. 780 5. Procedures for Token Construction 782 The Token encoding is known to the server but opaque to the client. 783 Implementations MUST encode the following information into the Token 784 as a minimum, in order to provide adequate security: 786 o Client's IP address as seen by the server (32/128 bits for IPv4/ 787 IPv6 addresses) 789 o The nonce generated and inserted in the Port Mapping Request 790 message by the client (64 bits) 792 o The absolute expiration time chosen by the server indicated as an 793 NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, 794 to protect against replay attacks) 796 An example way for constructing Tokens is to perform HMAC-SHA1 797 [RFC2104] on the concatenated values of the information listed above. 798 The HMAC key needs to be at least 160 bits long, and generated using 799 a cryptographically secure random source [RFC4086]. While HMAC-SHA1 800 is the RECOMMENDED procedure, implementations might adopt different 801 approaches. 803 In addition to the information listed above, implementations are 804 encouraged to encode whatever additional information is deemed 805 necessary or useful. For example, key rollover is simplified by 806 encoding a key-id into the Token. As another example, a cluster of 807 anycast servers could find advantage by encoding a server identifier 808 into the Token. As another example, while HMAC-SHA1 provides a level 809 of security that is widely regarded as being more than sufficient for 810 providing message authentication and it is secure against all known 811 cryptanalytic attacks that use computational resources that are 812 currently economically feasible, if HMAC-SHA1 has been compromised, a 813 replacement HMAC algorithm could be used instead (e.g., HMAC-SHA256). 815 To protect from offline attacks, the server SHOULD occasionally 816 choose a new HMAC key. To ease implementation, a key-id can be 817 assigned to each HMAC key. This can be encoded as simply as one bit 818 (where the new key is X (e.g., 1) and the old key is the inverted 819 value of X (e.g., 0)), or if several keys are supported at once could 820 be encoded into several bits. As the encoding of the Token is 821 entirely private to the server and opaque to the clients, any 822 encoding can be used. By encoding the key-id into the Token element, 823 the server can reject an old key without bothering to do HMAC 824 validation (saving CPU cycles). The key-id can be encoded into the 825 Value field of the Token element by simply concatenating the 826 (plaintext) key-id with the hashed information (i.e., the Token 827 itself). 829 For example, the Value field in the Token element can be computed as: 831 key-id || hash-alg (client-ip | nonce | abs-expiration) 833 During Token construction, the expiration time has to be chosen 834 carefully based on the intended service duration. Tokens that are 835 valid for an unnecessarily long period of time (e.g., several hours) 836 might impose security risks. Depending on the application and use 837 cases, a reasonable value needs to be chosen by the server. Note 838 that using shorter lifetimes requires the clients to acquire Tokens 839 more frequently. However, since a client can acquire a new Token 840 well before it will need to use it, the client will not necessarily 841 be penalized for the acquisition delay. 843 Finally, be aware that NTP timestamps will wrap around in year 2036 844 and implementations might need to handle this eventually. Refer to 845 Section 6 of [RFC5905] for further details. 847 6. Validating Tokens 849 Upon receipt of an RTCP feedback message along with the Token 850 Verification Request message that contains a Token, nonce and 851 absolute expiration time, the server MUST validate the Token. 853 The server first applies its own procedure for constructing the 854 Tokens by using client's IP address from the received Token 855 Verification Request message, and the nonce and absolute expiration 856 time values reported in the received Token Verification Request 857 message. The server then compares the resulting output with the 858 Token sent by the client in the Token Verification Request message. 859 If they match and the absolute expiration time has not passed yet, 860 the server declares that the Token is valid. 862 Note that if the client's IP address changes, the Token will not 863 validate. Similarly, if the client inserts an incorrect nonce or 864 absolute expiration time value in the Token Verification Request 865 message, validation will fail. It is also possible that the server 866 wants to expire the Token prematurely. In these cases, the server 867 MUST reply back to the client with a Token Verification Failure 868 message (that goes from port P3 on the server towards port c1 on the 869 client). 871 In addition to the Token Verification Failure message, it is 872 RECOMMENDED that applications define an application-specific error 873 response to be sent by the server when the server detects that the 874 Token is invalid. For applications using 875 [I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new 876 4xx-level response code in the RAMS Response Code Space Registry. A 877 client that received a Token Verification Failure message can request 878 a new Token from the server. 880 If a client receives a Port Mapping Response message with an invalid 881 Token (i.e., the relative expiration time is set to zero) two or more 882 times for a particular Port Mapping Request message, or the client 883 receives a Token Verification Failure message two or more times for 884 the same Token Verification Request message, the client SHOULD do the 885 following: 887 1. Check whether the session description has been updated or not. 888 If it was updated, act according to the new session description. 890 2. Exponentially back off for the third and subsequent attempts. 891 Exponential back-off does not apply when the client sends a Port 892 Mapping Request or Token Verification Request message to a new 893 address and/or port. 895 7. SDP Signaling 897 7.1. The portmapping-req Attribute 899 This attribute is used declaratively in any media block that 900 describes an RTP session that uses Token-based authentication for one 901 or more RTCP messages relating to that session. It indicates the 902 port and optionally the address for obtaining a Token. 904 The presence of the 'portmapping-req' attribute indicates that (i) a 905 Token MUST be included in certain RTCP messages sent to the server 906 triggering or controlling a unicast session (See Section 4.3.1), and 907 (ii) the client MUST receive the unicast session's RTP and RTCP 908 packets from the server on the port from which it sent the RTCP 909 message triggering the unicast session. 911 Note: This does not imply that Token Verification Request 912 messages need to be always sent in the unicast session. Token 913 Verification Request messages accompany RTCP messages that trigger 914 or control this unicast session, and are sent either in the 915 multicast session or the unicast session, depending on the RTCP 916 message (See Section 4.3.1). 918 7.1.1. ABNF Definition of portmapping-req 920 The formal description of the 'portmapping-req' attribute is defined 921 by the following ABNF [RFC5234] syntax: 923 portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP 924 addrtype SP connection-address]] CRLF 926 Here, 'port', 'nettype', 'addrtype' and 'connection-address' are 927 defined as specified in Section 9 of [RFC4566]. 929 The 'portmapping-req' attribute SHALL be used as a media-level 930 attribute. 932 In the optional address value, only unicast addresses SHOULD be used 933 unless one wants to use a multicast address after evaluating the 934 additional security risks such as non-legit servers generating fake 935 Tokens. If the address is not specified, the (source) address in the 936 "c" line applicable to the media description SHALL be used. 938 7.1.2. Offer/Answer Model Considerations 940 When using the 'portmapping-req' attribute in SDP offer/answer 941 exchanges [RFC3264], the following considerations apply. When an 942 offerer sends an answerer an offer of an SDP description making use 943 of the Token approach described in this specification, the 944 'portmapping-req' attribute is included declaratively. There will 945 not be offer/answer exchanges between the answerer and the actual 946 server providing the unicast service(s). 948 When the answerer supports the Token approach, it MUST echo in its 949 answer back to the offerer the 'portmapping-req' attribute from the 950 offer including the same port number and address (if any). If the 951 answerer does not implement this specification, it follows normal SDP 952 parsing of unknown attributes (they are ignored and are not sent in 953 the answer). This means that the answerer can still join the 954 multicast session, but will not be able to use the unicast service(s) 955 that require the use of Tokens. 957 7.2. Requirements 959 The use of SDP for the port mapping solution normatively requires the 960 support for: 962 o The SDP grouping framework and flow identification (FID) semantics 963 [RFC5888] 965 o The RTP/AVPF profile [RFC4585] 967 o Multiplexing RTP and RTCP on a single port on both endpoints in 968 the unicast session [RFC5761] 970 7.3. Example and Discussion 972 The declarative SDP describing the scenario given in Figure 2 is 973 written as: 975 v=0 976 o=ali 1122334455 1122334466 IN IP4 nack.example.com 977 s=Local Retransmissions 978 t=0 0 979 a=group:FID 1 2 980 a=rtcp-unicast:rsi 981 m=video 41000 RTP/AVPF 98 982 i=Multicast Stream 983 c=IN IP4 233.252.0.2/255 984 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 985 a=rtpmap:98 MP2T/90000 986 a=multicast-rtcp:41500 ; Note 1 987 a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 988 a=rtcp-fb:98 nack ; Note 2 989 a=portmapping-req:30000 IN IP4 192.0.2.1 ; Note 3 990 a=mid:1 991 m=video 42000 RTP/AVPF 99 ; Note 4 992 i=Unicast Retransmission Stream 993 c=IN IP4 192.0.2.1 994 a=sendonly 995 a=rtpmap:99 rtx/90000 996 a=rtcp-mux ; Note 5 997 a=rtcp:42500 ; Note 6 998 a=fmtp:99 apt=98; rtx-time=5000 999 a=portmapping-req:30001 ; Note 3 1000 a=mid:2 1002 Figure 8: SDP describing an SSM distribution with support for 1003 retransmissions from a local server 1005 In this description, we highlight the following notes: 1007 Note 1: The source stream is multicast from a distribution source 1008 with a source IP address of 198.51.100.1 to the multicast destination 1009 address of 233.252.0.2 and port 41000 (P1). The associated RTCP 1010 packets are multicast in the same group to port 41500 (P2). 1012 Note 2: A retransmission server including feedback target 1013 functionality with an IP address of 192.0.2.1 and port of 42000 (P3) 1014 is specified with the 'rtcp' attribute. The feedback functionality 1015 is enabled for the RTP stream with payload type 98 through the 1016 'rtcp-fb' attribute [RFC4585]. 1018 Note 3: The "a=portmapping-req" line indicates that one or more RTCP 1019 messages relating to the RTP session described in this media block 1020 uses Token-based authentication, and a Token needs to be retrieved 1021 first from the designated port (PT) before the unicast session can be 1022 established. In the first appearance, an explicit address is 1023 provided. In the second appearance, there is no address indicated in 1024 this line and the client needs to send the Token request to the 1025 address specified in the "c" line in the unicast media block. 1027 Note 4: The port specified in the second "m" line (for the unicast 1028 stream) does not mean anything in this scenario as the client does 1029 not send any RTP traffic back to the server. 1031 Note 5: The server multiplexes RTP and RTCP packets on the same port 1032 (c1 in Figure 2). 1034 Note 6: The server uses port 42500 (P4) for the unicast session. 1036 8. Address Pooling NATs 1038 Large-scale NAT devices have a pool of public IPv4 addresses and map 1039 internal hosts to one of those public IPv4 addresses. As long as an 1040 internal host maintains an active mapping in the NAT, the same IPv4 1041 address is assigned to new connections. However, once all of the 1042 host's mappings have been deleted (e.g., because of timeout), it is 1043 possible that a new connection from that same host will be assigned a 1044 different IPv4 address from the pool. When that occurs, the Token 1045 will be considered invalid by the server, causing an additional round 1046 trip for the client to acquire a fresh Token. 1048 Any traffic from the host which traverses the NAT will prevent this 1049 problem. As the host is sending RTCP receiver reports at least every 1050 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is 1051 receiving, those RTCP messages will be sufficient to prevent this 1052 problem. 1054 9. Security Considerations 1056 9.1. Tokens 1058 The Token, which is generated based on a client's IP address and 1059 expiration date, provides protection against off-path denial-of- 1060 service (DoS) attacks. An attacker using a certain IP address cannot 1061 cause one or more RTP packets to be sent to a victim client who has a 1062 different IP address. However, if the attacker acquires a valid 1063 Token for a victim and can spoof the victim's source address, this 1064 approach becomes vulnerable to replay attacks. This is especially 1065 easy if the attacker and victim are behind a large-scale NAT and 1066 share the same IP address. 1068 Multicast is deployed on managed networks - not the Internet. These 1069 managed networks will choose to enable network ingress filtering 1070 [RFC2827] or not. If ingress filtering is enabled on a network, an 1071 attacker cannot spoof a victim's IP address to use a Token to 1072 initiate an attack against a victim. However, if ingress filtering 1073 is not enabled on a network, an attacker could obtain a Token and 1074 spoof the victim's address, causing traffic to flood the victim. On 1075 such a network, the server can reduce the time period for such an 1076 attack by expiring a Token in a short period of time. In the extreme 1077 case, the server can expire the Token in such a short period of time, 1078 such that the client will have to acquire a new Token immediately 1079 before using it in a Token Verification Request message. One should, 1080 however, note that such a behavior might have an adverse effect on 1081 the delay in establishing or controlling a unicast session. 1083 RTCP messages could be subject to on-path or man-in-the-middle 1084 attacks. For example, an attacker can modify a value in one or more 1085 fields in the Port Mapping Response or the Token Verification Request 1086 message that are used in Token construction. This will result in 1087 Token validation failure. Consequently, the client ends up asking 1088 the server to generate a new Token. The resulting delay and extra 1089 processing on the server are undesirable. 1091 Alternatively, the attacker can modify a value in a field that is not 1092 used in Token construction. For example, the attacker can reduce the 1093 value in the Relative Expiration Time field in the Port Mapping 1094 Response message from two hours to two minutes. While the Token will 1095 still validate, this attack will result in more frequent requests to 1096 the server for a new Token. Oppositely, the attacker can increase 1097 the value in the Relative Expiration Time field, and make the client 1098 think the Token will be valid for a longer time. This attack can be 1099 only detected by monitoring the activity on the server. Note that 1100 using the relative expiration time in Token construction does not 1101 necessarily make this attack easier to detect since the attacker 1102 might revert the modified value back to its original value in the 1103 Token Verification Request message. This allows the Token to still 1104 validate on the server. In this case, the attack is still only 1105 detectable by monitoring the server activity. 1107 If there is a risk or concern for on-path or man-in-the-middle 1108 attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP) 1109 [RFC3711]. 1111 9.2. The portmapping and portmapping-req Attributes 1113 The 'portmapping-req' attribute is not believed to introduce any 1114 significant security risk to multimedia applications. A malevolent 1115 third party could use this attribute to redirect the Port Mapping 1116 Request messages by altering the port number or cause the unicast 1117 session establishment to fail by removing it from the SDP 1118 description. But, this requires intercepting and rewriting the 1119 packets carrying the SDP description; and if an interceptor can do 1120 that, many more attacks are possible, including a wholesale change of 1121 the addresses and port numbers at which the media will be sent. 1123 In order to avoid attacks of this sort, the SDP description needs to 1124 be integrity protected and provided with source authentication. This 1125 can, for example, be achieved on an end-to-end basis using S/MIME 1126 [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME 1127 types (application/sdp). Alternatively, HTTPS [RFC2818] or the 1128 authentication method in the Session Announcement Protocol (SAP) 1129 [RFC2974] could be used as well. 1131 10. IANA Considerations 1133 The following contact information shall be used for all registrations 1134 in this document: 1136 Ali Begen 1137 abegen@cisco.com 1139 Note to the RFC Editor: In the following, please replace "XXXX" with 1140 the number of this document prior to publication as an RFC. 1142 10.1. Registration of SDP Attributes 1144 This document registers one new attribute name in SDP. 1146 SDP Attribute ("att-field"): 1147 Attribute name: portmapping-req 1148 Long form: Port and address for requesting Token 1149 Type of name: att-field 1150 Type of attribute: Media level 1151 Subject to charset: No 1152 Purpose: See this document 1153 Reference: [RFCXXXX] 1154 Values: See this document 1156 10.2. Registration of RTCP Control Packet Types 1158 In accordance with Section 15 of [RFC3550], this specification adds 1159 the following value to the RTCP Control Packet types sub-registry of 1160 the Real-Time Transport Protocol (RTP) Parameters registry: 1162 Value Abbrev. Name Reference 1163 -------- --------- --------------------------------------- --------- 1164 TBD TOKEN Port Mapping [RFCXXXX] 1166 Note to the IANA: Please assign the next available value, which is 1167 currently 210. 1169 10.3. SMT Values for TOKEN Packet Type Registry 1171 This document creates a new sub-registry for the sub-message type 1172 (SMT) values to be used with the TOKEN packet type. The registry is 1173 called the SMT Values for TOKEN Packet Type Registry. This registry 1174 is to be managed by the IANA according to the IETF Review policy of 1176 [RFC5226]. 1178 The length of the SMT field is five bits, allowing 32 values. The 1179 registry is initialized with the following entries: 1181 Value Name Reference 1182 ----- -------------------------------------------------- ------------- 1183 0 Reserved [RFCXXXX] 1184 1 Port Mapping Request [RFCXXXX] 1185 2 Port Mapping Response [RFCXXXX] 1186 3 Token Verification Request [RFCXXXX] 1187 4 Token Verification Failure [RFCXXXX] 1188 5-30 Unassigned IETF Review 1189 31 Reserved [RFCXXXX] 1191 The SMT values 0 and 31 are reserved for future use. 1193 10.4. RAMS Response Code Space Registry 1195 This document adds the following entry to the RAMS Response Code 1196 Space Registry. 1198 Code Description Reference 1199 ----- -------------------------------------------------- ------------- 1200 405 Invalid Token [RFCXXXX] 1202 This response code is used when the Token included by the RTP_Rx in 1203 the RAMS-R message is invalid. 1205 11. Acknowledgments 1207 The approach presented in this document came out after discussions 1208 with various individuals in the AVT and MMUSIC WGs, and the breakout 1209 session held in the Anaheim meeting. We thank each of these 1210 individuals, in particular to Magnus Westerlund and Colin Perkins. 1212 12. References 1214 12.1. Normative References 1216 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1217 Jacobson, "RTP: A Transport Protocol for Real-Time 1218 Applications", STD 64, RFC 3550, July 2003. 1220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", BCP 14, RFC 2119, March 1997. 1223 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1224 Description Protocol", RFC 4566, July 2006. 1226 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1227 "Extended RTP Profile for Real-time Transport Control 1228 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1229 July 2006. 1231 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1232 Protocol (RTCP) Extensions for Single-Source Multicast 1233 Sessions with Unicast Feedback", RFC 5760, February 2010. 1235 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1236 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1238 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1239 Requirements for Security", BCP 106, RFC 4086, June 2005. 1241 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1242 Time Protocol Version 4: Protocol and Algorithms 1243 Specification", RFC 5905, June 2010. 1245 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1246 Hashing for Message Authentication", RFC 2104, 1247 February 1997. 1249 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1250 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1252 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1253 Control Packets on a Single Port", RFC 5761, April 2010. 1255 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1256 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1257 RFC 3711, March 2004. 1259 [I-D.ietf-avt-rtp-cnames] 1260 Begen, A., Perkins, C., and D. Wing, "Guidelines for 1261 Choosing RTP Control Protocol (RTCP) Canonical Names 1262 (CNAMEs)", draft-ietf-avt-rtp-cnames-05 (work in 1263 progress), January 2011. 1265 12.2. Informative References 1267 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1268 with Session Description Protocol (SDP)", RFC 3264, 1269 June 2002. 1271 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1272 the Session Description Protocol (SDP)", RFC 4145, 1273 September 2005. 1275 [I-D.ietf-avt-rapid-acquisition-for-rtp] 1276 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 1277 Based Rapid Acquisition of Multicast RTP Sessions", 1278 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 1279 progress), November 2010. 1281 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1282 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1283 RFC 4787, January 2007. 1285 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1286 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1287 July 2006. 1289 [I-D.ietf-avt-app-rtp-keepalive] 1290 Marjou, X. and A. Sollaud, "Application Mechanism for 1291 keeping alive the Network Address Translator (NAT) 1292 mappings associated to RTP flows.", 1293 draft-ietf-avt-app-rtp-keepalive-09 (work in progress), 1294 September 2010. 1296 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1297 Defeating Denial of Service Attacks which employ IP Source 1298 Address Spoofing", BCP 38, RFC 2827, May 2000. 1300 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1301 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1302 May 2008. 1304 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1305 "Codec Control Messages in the RTP Audio-Visual Profile 1306 with Feedback (AVPF)", RFC 5104, February 2008. 1308 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1309 RFC 5652, September 2009. 1311 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1313 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1314 Announcement Protocol", RFC 2974, October 2000. 1316 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1317 RFC 793, September 1981. 1319 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1320 Mail Extensions (S/MIME) Version 3.2 Message 1321 Specification", RFC 5751, January 2010. 1323 Authors' Addresses 1325 Ali Begen 1326 Cisco 1327 181 Bay Street 1328 Toronto, ON M5J 2T3 1329 Canada 1331 Email: abegen@cisco.com 1333 Dan Wing 1334 Cisco Systems, Inc. 1335 170 West Tasman Dr. 1336 San Jose, CA 95134 1337 USA 1339 Email: dwing@cisco.com 1341 Tom VanCaenegem 1342 Alcatel-Lucent 1343 Copernicuslaan 50 1344 Antwerpen, 2018 1345 Belgium 1347 Email: Tom.Van_Caenegem@alcatel-lucent.com