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