idnits 2.17.1 draft-ietf-avt-ports-for-ucast-mcast-rtp-10.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 (December 20, 2010) is 4876 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 1175, 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) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: June 23, 2011 T. VanCaenegem 6 Alcatel-Lucent 7 December 20, 2010 9 Port Mapping Between Unicast and Multicast RTP Sessions 10 draft-ietf-avt-ports-for-ucast-mcast-rtp-10 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 June 23, 2011. 38 Copyright Notice 40 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . 12 61 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12 62 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13 63 4.3. Token Verification Request . . . . . . . . . . . . . . . . 15 64 4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16 65 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17 66 5. Procedures for Token Construction . . . . . . . . . . . . . . 19 67 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 21 68 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 22 69 7.1. The portmapping and portmapping-req Attributes . . . . . . 22 70 7.1.1. ABNF Definition of portmapping . . . . . . . . . . . . 22 71 7.1.2. ABNF Definition of portmapping-req . . . . . . . . . . 22 72 7.1.3. Offer/Answer Model Considerations . . . . . . . . . . 23 73 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23 74 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 24 75 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 26 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 77 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 27 78 9.2. The portmapping and portmapping-req Attributes . . . . . . 28 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 80 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 29 81 10.2. Registration of RTCP Control Packet Types . . . . . . . . 29 82 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 30 83 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 30 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 90 1. Introduction 92 In (any-source or source-specific) multicast RTP applications, 93 destination ports, i.e., the ports on which the multicast receivers 94 receive the RTP and RTCP packets, are defined declaratively. In 95 other words, the receivers cannot choose their receive ports and the 96 sender(s) use the pre-defined ports. 98 In unicast RTP applications, the receiving end needs to choose its 99 ports for RTP and RTCP since these ports are local resources and only 100 the receiving end can determine which ports are available to use. In 101 addition, Network Address Port Translators (NAPT - hereafter simply 102 called NAT) devices are commonly deployed in networks, thus, static 103 port assignments cannot be used. The receiving end may convey its 104 request to the sending end through different ways, one of which is 105 the Offer/Answer Model [RFC3264] for the Session Description Protocol 106 (SDP) [RFC4566]. However, the Offer/Answer Model requires offer/ 107 answer exchange(s) between the endpoints, and the resulting delay may 108 not be desirable in delay-sensitive real-time applications. 109 Furthermore, the Offer/Answer Model may be burdensome for the 110 endpoints that are concurrently running a large number of unicast 111 sessions with other endpoints. 113 In this specification, we consider an RTP application that uses one 114 or more unicast and multicast RTP sessions together. While the 115 declaration and selection of the ports are well defined and work well 116 for multicast and unicast RTP applications, respectively, the usage 117 of the ports introduces complications when a receiving end mixes 118 unicast and multicast RTP sessions within the same RTP application. 120 An example scenario is where the RTP packets are distributed through 121 source-specific multicast (SSM) and a receiver sends unicast RTCP 122 NACK feedback to a local repair server (also functioning as a unicast 123 RTCP feedback target) [RFC5760] asking for a retransmission of the 124 packets it is missing, and the local repair server sends the 125 retransmission packets over a unicast RTP session [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", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [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 unicast session lifetime, certain actions and 218 messages by the client might need to be authorized by the server by 219 requiring a valid Token. Therefore, the server will need the client 220 to also include the Token along with the RTCP messages that are 221 different from the RTCP message that triggerred the unicast session 222 establishment. These are explained later in this document. 224 Below, we first present a motivating scenario for port mapping and 225 then describe the normative behavior and requirements. 227 3.1. Motivating Scenario 229 Consider an SSM distribution network where a distribution source 230 multicasts RTP packets to a large number of clients, and one or more 231 retransmission servers function as feedback targets to collect 232 unicast RTCP feedback from these clients [RFC5760]. The 233 retransmission servers also join the multicast session to receive the 234 multicast packets and cache them for a certain time period. When a 235 client detects missing packets in the multicast session, it requests 236 a retransmission from one of the retransmission servers by using an 237 RTCP NACK message [RFC4585]. The retransmission server pulls the 238 requested packet(s) out of the cache and retransmits them to the 239 requesting client [RFC4588]. 241 The RTP and RTCP flows pertaining to the scenario described above are 242 sketched in Figure 2. Between the client and server, we assume there 243 exists at least one NAT device [RFC4787] (If there is no NAT devices 244 between the server and client, the method still works the same 245 fashion). The multicast and unicast sessions are clearly identified 246 with their individual RTP and RTCP flows and port numbers. 248 -------------- --- ---------- 249 | |-------------------------------| |-->|P1 | 250 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 251 | | | | | | 252 | Distribution | ---------------- | | | | 253 | Source | | | | | | | 254 | |---->|P1 | | | | | 255 | |.-.->|P2 | | | | | 256 | | | | | | | | 257 -------------- | P3|<.=.=.=.| |=.=|*c0 | 258 | P3|<~~~~~~~| |~~~|*c1 | 259 MULTICAST RTP | | | | | | 260 SESSION with | | | N | | | 261 UNICAST FEEDBACK | | | A | | | 262 | Retransmission | | T | | Client | 263 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 264 | Server | | | | | 265 | | | | | | 266 PORT MAPPING | PT|<~~~~~~~| |~~>|*cT | 267 | | | | | | 268 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 269 | | | | | | 270 AUXILIARY UNICAST | | | | | | 271 RTP SESSION | | | | | | 272 | P3|........| |..>|*c1 | 273 | P3|=.=.=.=.| |=.>|*c1 | 274 | P4|<.=.=.=.| |=.=|*c2 | 275 | | | | | | 276 ---------------- --- ---------- 278 -------> Multicast RTP Flow 279 .-.-.-.> Multicast RTCP Flow 280 .=.=.=.> Unicast RTCP Reports 281 ~~~~~~~> Unicast RTCP (Feedback) Messages 282 .......> Unicast RTP Flow 284 Figure 2: Example scenario showing an SSM distribution with support 285 for retransmissions from a server 287 In Figure 2, we have the following multicast and unicast ports: 289 o Ports P1 and P2 denote the destination RTP and RTCP ports in the 290 multicast session, respectively. The clients listen to these 291 ports to receive the multicast RTP and RTCP packets. Ports P1 and 292 P2 are defined declaratively. 294 o Port P3 denotes the RTCP port on the feedback target running on 295 the retransmission server to collect any RTCP packet sent by the 296 clients including feedback messages, and RTCP receiver and 297 extended reports. This is also the port that the retransmission 298 server uses to send the RTP packets and RTCP sender reports in the 299 unicast session. Port P3 is defined declaratively. 301 o Port P4 denotes the RTCP port on the retransmission server used to 302 collect the RTCP receiver and extended reports for the unicast 303 session. Port P4 is defined declaratively. 305 o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the 306 port on the client used to send the RTCP reports for the multicast 307 session. *c1 denotes the port on the client used to send the 308 unicast RTCP feedback messages in the multicast session and to 309 receive the RTP packets and RTCP sender reports in the unicast 310 session. *c2 denotes the port on the client used to send the RTCP 311 receiver and extended reports in the unicast session. Ports c0, 312 c1 and c2 could be the same port or different ports. There are 313 two advantages of using the same port for both c0 and c1: 315 1. Some NATs only keep bindings active when a packet goes from 316 the inside to the outside of the NAT (See REQ-6 of Section 4.3 317 of [RFC4787]). When the gap between the packets sent from the 318 client to the server is long, this can exceed that timeout. 319 If c0=c1, the occasional (periodic) RTCP receiver reports sent 320 from port c0 (for the multicast session's RTCP port P3) will 321 ensure the NAT does not time out the public port associated 322 with the incoming unicast traffic to port c1. 324 2. Having c0=c1 conserves NAT port bindings. 326 o Ports PT and *cT denote the ports through which the Token request 327 and retrieval occur at the server and client sides, respectively. 328 Port PT is declared on a per unicast session basis, although the 329 same port could be used for two or more unicast sessions sourced 330 by the server. A Token once requested and retrieved by a client 331 from port PT remains valid until its expiration time. 333 We assume that the information declaratively defined is available as 334 part of the session description information and is provided to the 335 clients. The Session Description Protocol (SDP) [RFC4566] and other 336 session description methods can be used for this purpose. 338 3.2. Normative Behavior and Requirements 340 In this section, we describe the normative behavior and requirements. 341 To simplify the presentation, we refer to the port numbers described 342 in the example presented in Figure 2. However, the behavior and 343 requirements described here are not specific to that particular 344 example, and can be applied to any scenario where analogous ports can 345 be identified. 347 First of all, a client compliant with this specification MUST be able 348 to include a Token with any type of RTCP message (as described below) 349 when it is needed. That is, clients MUST NOT implement this 350 specification with only a specific use case in mind. 352 Second, the solution provided in this specification is not applicable 353 in cases where there is RTP traffic flowing from the client to the 354 server in the unicast session. In other words, the direction of RTP 355 traffic MUST be only from the server to the client in the unicast 356 session. If the client wants to send RTP traffic back to the server, 357 the regular session establishment methods such as [RFC3264] need to 358 be used. 360 The following steps summarize the Token-based solution: 362 1. The client ascertains server address and port numbers (P3, P4 and 363 PT) from the session description. Port P4 MUST be different from 364 port P3. Port PT MAY be equal to port P3. 366 2. The client selects its local port numbers (*c0, *c1, *c2 and 367 *cT). It is strongly RECOMMENDED that the client uses the same 368 port for c0 and c1. Port cT MAY be equal to ports c0 and c1. 370 3. If the client does not have a Token (or the existing Token has 371 expired): 373 A. The client first sends a Port Mapping Request message 374 (Section 4.1) to port PT. This message is sent from port *cT 375 on the client side. The server learns client's IP address 376 from the received message. The client can send this message 377 anytime it wants (e.g., during initialization), and does not 378 normally ever need to re-send this message (See Section 6). 380 B. The server generates an opaque encapsulation (i.e., the 381 Token) based on certain information including the client's IP 382 address. 384 C. The server sends the Token back to the client using a Port 385 Mapping Response message (Section 4.2). This message MUST be 386 sent from port PT to port cT. 388 4. The client needs to provide the Token to the server using a Token 389 Verification Request message (Section 4.3), whenever the client 390 sends an RTCP feedback message for triggering or controlling a 391 unicast session (See Section 4.3.1). If the Token is invalid or 392 missing, the server sends a Token Verification Failure message 393 (Section 4.4) to the client. 395 Note that the unicast session is only established after the 396 server has received a feedback message (along with a valid Token) 397 from the client for which it needs to react by sending unicast 398 data. Until a unicast session is established, neither the server 399 nor the client needs to send RTCP reports for the unicast 400 session. 402 5. Normal flows ensue as shown in Figure 2. Note that in the 403 unicast session, traffic from the server to the client (i.e., 404 both the RTP and RTCP packets sent from port P3 to port c1) MUST 405 be multiplexed on the (same) port c1. If the client uses the 406 same port for both c0 and c1, the RTCP reports sent for the 407 multicast session keep the P3->c1(=c0) binding alive. If the 408 client uses different ports for c0 and c1, the client needs to 409 periodically send an explicit keep-alive message 410 [I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive 411 during the lifetime of the unicast session if the time between 412 unicast feedback messages (from c1 to P3) is likely to exceed the 413 NAT's timeout value (For the NAT timeout value requirements, see 414 [RFC4787]). 416 A unicast session on a particular receive port c1 can last as long as 417 the associated multicast session lasts. However, a client cannot 418 keep using the same receive port c1 for different subsequent unicast 419 sessions since there could be packet leakage when switching from one 420 unicast session to another unless each received unicast stream has 421 its own distinct Synchronization Source (SSRC) identifier to allow 422 the client to filter out the undesired packets. Unless this is 423 guaranteed (which is not often easy), a client SHOULD use separate 424 receive ports for subsequent unicast sessions. After a sufficient 425 time, a previously used receive port could be used again. 427 4. Message Formats 429 This section defines the formats of the RTCP messages that are 430 exchanged between a server and a client for the purpose of port 431 mapping. A new RTCP control packet type is introduced and four port 432 mapping messages using this control packet are defined: 434 1. Port Mapping Request 436 2. Port Mapping Response 438 3. Token Verification Request 440 4. Token Verification Failure 442 Each message has a fixed-length field for version (V), padding (P), 443 sub-message type (SMT), packet type (PT), length and SSRC of packet 444 sender. Messages have other fields as defined below. In all 445 messages defined in this section, the PT field is set to TOKEN. 446 Individual messages are identified by the SMT field. The length 447 field indicates the message size in 32-bit words minus one, including 448 the header and any padding. This definition is in line with the 449 definition of the length field used in RTCP sender and receiver 450 reports. In all messages, any Reserved field SHALL be set to zero 451 and ignored. 453 Following the rules specified in [RFC3550], all integer fields in the 454 messages defined below are carried in network-byte order, that is, 455 most significant byte (octet) first, also known as big-endian. 456 Unless otherwise stated, numeric constants are in decimal (base 10). 458 Note that RTCP is not a timely or reliable protocol. The RTCP 459 packets might get lost or re-ordered in the network. When sending a 460 new Port Mapping Request message, the scheduling rules that apply to 461 sending initial RTCP messages [RFC4585] apply. When a client sends a 462 Port Mapping Request or Token Verification Request message but it 463 does not receive a response back from the server (either a Port 464 Mapping Response or Token Verification Failure message), it MAY 465 resend its request by following the timer rules defined for RTCP 466 feedback messages in Section 3.5 of [RFC4585] as a good practice. 467 When sending an RTCP (feedback) message bundled with a Token 468 Verification Request message, the timer rules of [RFC4585] apply as 469 usual. 471 4.1. Port Mapping Request 473 The Port Mapping Request message is identified by SMT=1. This 474 message is transmitted by the client to a dedicated server port (and 475 possibly a dedicated address) to request a Token. In the Port 476 Mapping Request message, the packet sender SSRC is set to the 477 client's SSRC. Here, the SSRC value is not necessarily linked to the 478 one used by the client in the multicast session. The packet format 479 has the structure depicted in Figure 3. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |V=2|P| SMT=1 | PT=TOKEN | Length=3 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | SSRC of Packet Sender | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Random | 489 | Nonce | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 3: Packet format for the Port Mapping Request message 494 o Random Nonce (64 bits): Field that contains a random value 495 generated by the client following the procedures of [RFC4086]. 496 This nonce is taken into account by the server when generating a 497 Token for the client to enable better security for clients that 498 share the same IP address (Such clients need to produce a random 499 value guaranteed to be temporally and globally unique). If the 500 same Port Mapping Request message is transmitted multiple times 501 for redundancy reasons, the random nonce value MUST remain the 502 same in these duplicated messages. However, the client MUST 503 generate a new random nonce for every new Port Mapping Request 504 message. 506 4.2. Port Mapping Response 508 The Port Mapping Response message is identified by SMT=2. This 509 message is sent by the server and delivers the Token to the client as 510 a response to the Port Mapping Request message. In the Port Mapping 511 Response message, the packet sender SSRC is set to the server's SSRC. 512 The packet format has the structure depicted in Figure 4. 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=2 | PT=TOKEN | Length | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | SSRC of Packet Sender | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | SSRC of Requesting Client | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Associated | 524 | Nonce | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 : Token Element : 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Absolute | 529 | Expiration Time | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Relative Expiration Time | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 : Packet Types Element : 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Figure 4: Packet format for the Port Mapping Response message 538 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 539 of the client who sent the request. 541 o Associated Nonce (64 bits): Field that contains the nonce 542 received in the Port Mapping Request message and used in Token 543 construction. 545 o Token Element (Variable size): Element that is used to carry the 546 Token generated by the server. This element is a 32-bit aligned 547 Length-Value element. The Length field, which is 8 bits, 548 indicates the length (in octets) of the Value field that follows 549 the Length field. This length does not include any padding that 550 is required for alignment. The Value field carries the Token (or 551 more accurately, the output of the encoding process on the 552 server). If the Token element does not fall on a 32-bit boundary, 553 the last word MUST be padded to the boundary using further bits 554 set to zero. 556 o Absolute Expiration Time (64 bits): Field that contains the 557 absolute expiration time of the Token. The absolute expiration 558 time is expressed as a Network Time Protocol (NTP) timestamp value 559 in seconds since year 1900 [RFC5905]. The client does not need to 560 use this element directly, thus, does not need to synchronize its 561 clock with the server. However, the client needs to send this 562 element back to the server along with the associated nonce in the 563 Token Verification Request message, thus, needs to keep it 564 associated with the Token. 566 o Relative Expiration Time (32 bits): Field that contains the 567 relative expiration time of the Token. The relative expiration 568 time is expressed in seconds from the time the Token was 569 generated. Whenever a server decides to not grant a Token to a 570 requesting client, the relative expiration time will be set to 571 zero (and hence, the accompanying Token will be invalid). 573 The server conveys the relative expiration time in the clear to 574 the client to allow the client to request a new Token well before 575 the expiration time. 577 o Packet Types Element (Variable size): Element that is used to 578 signal which RTCP packet types require Token-based authentication. 579 This element is a 32-bit aligned Length-Value element. The Length 580 field, which is 8 bits, indicates the length (in octets) of the 581 Value field that follows the Length field. This length does not 582 include any padding that is required for alignment. The Value 583 field carries zero or more 8-bit sub-fields each carrying an RTCP 584 packet type. If the Packet Types element does not fall on a 32- 585 bit boundary, the last word MUST be padded to the boundary using 586 further bits set to zero. 588 A server MAY change its policy on which RTCP packet types would 589 require Token-based authentication based on observations, 590 configuration or other policies. However, upon such a change the 591 server SHALL NOT send a new Port Mapping Response message to the 592 clients who requested a Token earlier. A client learns about this 593 change when and if it gets a Token Verification Failure message. 595 4.3. Token Verification Request 597 The Token Verification Request message is identified by SMT=3. This 598 message contains the Token and accompanies any RTCP message that 599 would trigger a new or control an existing unicast session. For a 600 list of such messages, see Section 4.3.1. 602 In the Token Verification Request message, the packet sender SSRC is 603 set to the client's SSRC. The client MUST NOT send a Token 604 Verification Request message with a Token that has expired. The 605 packet format has the structure depicted in Figure 5. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 |V=2|P| SMT=3 | PT=TOKEN | Length | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | SSRC of Packet Sender | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Associated | 615 | Nonce | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 : Token Element : 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Associated Absolute | 620 | Expiration Time | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Figure 5: Packet format for the Token Verification Request message 625 o Associated Nonce (64 bits): Field that contains the nonce 626 associated with the Token above. 628 o Token Element (Variable size): Token element that was previously 629 received in the Port Mapping Response message. 631 o Associated Absolute Expiration Time (64 bits): Field that 632 contains the absolute expiration time associated with the Token 633 above. 635 4.3.1. Where to Include Token 637 This section provides guidelines about which RTCP packet types would 638 need to be accompanied by a Token Verification Request message. 639 However, since a server might determine in real time that other RTCP 640 messages also need to be authenticated by a Token, a client MUST act 641 according to the up-to-date list provided to the client in the Port 642 Mapping Response message (in the Packet Types element). Clients need 643 to support using Token-based authentication with any necessary RTCP 644 message (See Section 3.2). 646 As a general rule, when the Token capability is declared in the 647 session description, the RTCP messages that trigger transmission of 648 RTP packets in a port-mapped unicast session are REQUIRED to be 649 authenticated by using a Token. Such messages include but are not 650 limited to: 652 o NACK messages [RFC4585] 653 o RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 655 Additionally, some RTCP messages might directly or indirectly control 656 an existing unicast session associated with a multicast session. 657 Unless another authentication method as described in their respective 658 specifications is used, such RTCP messages might also need to be 659 authenticated by using a Token. Examples are: 661 o BYE messages [RFC3550] 663 o RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 665 o CCM messages [RFC5104] 667 Note that even if a packet type is listed to require Token-based 668 authentication, it does not need to be authenticated when it does not 669 control the unicast session. For example, if BYE (203) is listed in 670 the Port Mapping Response message as one of the packet types that 671 requires authentication, the client does not need to bundle the RTCP 672 BYE message with a Token when it is sending it for the multicast 673 session. 675 The Token Verification Request message might also be bundled with 676 packets carrying RTCP receiver and/or extended reports. While such 677 packets do not have a strong security impact, a specific application 678 might desire to have a more controlled reporting scheme from the 679 clients. In this case, the server lists the packet types for the 680 receiver (201) and/or extended reports (207) in the Port Mapping 681 Response message. 683 4.4. Token Verification Failure 685 The Token Verification Failure message is identified by SMT=4. This 686 message is sent by the server and notifies the client that the Token 687 was invalid or that the client did not include a Token Verification 688 Request message in the RTCP packet although it was supposed to. In 689 the Token Verification Failure message, the packet sender SSRC is set 690 to the server's SSRC. The packet format has the structure depicted 691 in Figure 6. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |V=2|P| SMT=4 | PT=TOKEN | Length=5 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | SSRC of Packet Sender | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | SSRC of Requesting Client | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | PT of Request | Req. FMT| Reserved | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Associated | 705 | Nonce | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 6: Packet format for the Token Verification Failure message 710 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 711 of the client who sent the verification request. 713 o PT of Request (8 bits): Field that indicates the type of the RTCP 714 packet that caused this failure message. 716 o Req. FMT (5 bits): Field that indicates the feedback message type 717 (FMT) value of the RTCP packet that caused this failure. Together 718 with the field above, the client can infer which RTCP message it 719 has previously sent caused this failure message to be sent by the 720 server. For example, if the client did not include a valid Token 721 with an RTCP NACK message, the PT of Request field will indicate 722 205 (RTPFB) and the Req. FMT field will indicate 1 (Generic NACK). 723 If the RTCP message did not have an associated FMT value (such as 724 an RTCP BYE message), the Req. FMT field SHALL be set to zero. 726 o Associated Nonce (64 bits): Field that contains the nonce 727 received in the Token Verification Request message. If there was 728 no Token Verification Request message included by the client, this 729 field is set to 0. 731 5. Procedures for Token Construction 733 The Token encoding is known to the server but opaque to the client. 734 Implementations MUST encode the following information into the Token 735 as a minimum, in order to provide adequate security: 737 o Client's IP address as seen by the server (32/128 bits for IPv4/ 738 IPv6 addresses) 740 o The nonce generated and inserted in the Port Mapping Request 741 message by the client (64 bits) 743 o The absolute expiration time chosen by the server indicated as an 744 NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, 745 to protect against replay attacks) 747 An example way for constructing Tokens is to perform HMAC-SHA1 748 [RFC2104] on the concatenated values of the information listed above. 749 The HMAC key needs to be at least 160 bits long, and generated using 750 a cryptographically secure random source [RFC4086]. While HMAC-SHA1 751 is the RECOMMENDED procedure, implementations might adopt different 752 approaches. 754 In addition to the information listed above, implementations are 755 encouraged to encode whatever additional information is deemed 756 necessary or useful. For example, key rollover is simplified by 757 encoding a key-id into the Token. As another example, a cluster of 758 anycast servers could find advantage by encoding a server identifier 759 into the Token. As another example, while HMAC-SHA1 provides a level 760 of security that is widely regarded as being more than sufficient for 761 providing message authentication and it is secure against all known 762 cryptanalytic attacks that use computational resources that are 763 currently economically feasible, if HMAC-SHA1 has been compromised, a 764 replacement HMAC algorithm could be used instead (e.g., HMAC-SHA256). 766 To protect from offline attacks, the server SHOULD occasionally 767 choose a new HMAC key. To ease implementation, a key-id can be 768 assigned to each HMAC key. This can be encoded as simply as one bit 769 (where the new key is X (e.g., 1) and the old key is the inverted 770 value of X (e.g., 0)), or if several keys are supported at once could 771 be encoded into several bits. As the encoding of the Token is 772 entirely private to the server and opaque to the clients, any 773 encoding can be used. By encoding the key-id into the Token element, 774 the server can reject an old key without bothering to do HMAC 775 validation (saving CPU cycles). The key-id can be encoded into the 776 Value field of the Token element by simply concatenating the 777 (plaintext) key-id with the hashed information (i.e., the Token 778 itself). 780 For example, the Value field in the Token element can be computed as: 782 key-id || hash-alg (client-ip | nonce | abs-expiration) 784 During Token construction, the expiration time has to be chosen 785 carefully based on the intended service duration. Tokens that are 786 valid for an unnecessarily long period of time (e.g., several hours) 787 might impose security risks. Depending on the application and use 788 cases, a reasonable value needs to be chosen by the server. Note 789 that using shorter lifetimes requires the clients to acquire Tokens 790 more frequently. However, since a client can acquire a new Token 791 well before it will need to use it, the client will not necessarily 792 be penalized for the acquisition delay. 794 Finally, be aware that NTP timestamps will wrap around in year 2036 795 and implementations might need to handle this eventually. Refer to 796 Section 6 of [RFC5905] for further details. 798 6. Validating Tokens 800 Upon receipt of an RTCP feedback message along with the Token 801 Verification Request message that contains a Token, nonce and 802 absolute expiration time, the server MUST validate the Token. 804 The server first applies its own procedure for constructing the 805 Tokens by using client's IP address from the received Token 806 Verification Request message, and the nonce and absolute expiration 807 time values reported in the received Token Verification Request 808 message. The server then compares the resulting output with the 809 Token sent by the client in the Token Verification Request message. 810 If they match and the absolute expiration time has not passed yet, 811 the server declares that the Token is valid. 813 Note that if the client's IP address changes, the Token will not 814 validate. Similarly, if the client inserts an incorrect nonce or 815 absolute expiration time value in the Token Verification Request 816 message, validation will fail. It is also possible that the server 817 wants to expire the Token prematurely. In these cases, the server 818 MUST reply back to the client with a Token Verification Failure 819 message (that goes from port P3 on the server to port c1 on the 820 client). 822 In addition to the Token Verification Failure message, it is 823 RECOMMENDED that applications define an application-specific error 824 response to be sent by the server when the server detects that the 825 Token is invalid. For applications using 826 [I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new 827 4xx-level response code in the RAMS Response Code Space Registry. A 828 client that received a Token Verification Failure message can request 829 a new Token from the server. 831 7. SDP Signaling 833 7.1. The portmapping and portmapping-req Attributes 835 The 'portmapping' attribute is used declaratively without any 836 parameters in a multicast block in an SDP description. It provides a 837 hint information to the SDP recipient that one or more unicast 838 sessions associated with this multicast session require the use of 839 Tokens for certain RTCP messages. The 'portmapping-req' attribute is 840 also used declaratively but in a unicast block. It indicates the 841 port and optionally the address for obtaining a Token. 843 In an SDP description, there could be one or more multicast sessions 844 described, each associated with zero or more unicast sessions. The 845 recipient of the SDP description infers the association(s) between 846 the multicast and unicast sessions through the "a=group" line(s). 848 The presence of the 'portmapping' and 'portmapping-req' attribute 849 pair indicates that (i) a Token MUST be included in certain feedback 850 messages sent to the server triggering or controlling a unicast 851 session (See Section 4.3.1), and (ii) the client MUST receive the 852 unicast session's RTP and RTCP packets from the server on the port 853 from which it sent the RTCP message triggering or controlling the 854 unicast session. 856 Note: This does not imply that Token Verification Request 857 messages need to be sent in the unicast session. Token 858 Verification Request messages accompany RTCP messages that trigger 859 or control this unicast session, and are sent either in the 860 multicast session or the unicast session, depending on the RTCP 861 message (See Section 4.3.1). 863 7.1.1. ABNF Definition of portmapping 865 The formal description of the 'portmapping' attribute is defined by 866 the following ABNF [RFC5234] syntax: 868 portmapping-attr = "a=portmapping" 870 This attribute SHALL be used as a media-level attribute in a 871 multicast block in SDP descriptions. 873 7.1.2. ABNF Definition of portmapping-req 875 The formal description of the 'portmapping-req' attribute is defined 876 by the following ABNF [RFC5234] syntax: 878 portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP 879 addrtype SP connection-address]] CRLF 881 Here, 'port', 'nettype', 'addrtype' and 'connection-address' are 882 defined as specified in Section 9 of [RFC4566]. 884 The 'portmapping-req' attribute SHALL be used as a media-level 885 attribute in a unicast block in SDP descriptions. 887 In the optional address value, only unicast addresses SHOULD be used 888 unless one wants to use a multicast address after evaluating the 889 additional security risks such as non-legit servers generating fake 890 Tokens. If the address is not specified, the (source) address in the 891 "c" line corresponding to the unicast media stream is implied. 893 7.1.3. Offer/Answer Model Considerations 895 When using the attributes defined above in SDP offer/answer exchanges 896 [RFC3264], the following considerations apply. When an offerer sends 897 an answerer an offer of an SDP description making use of the Token 898 approach described in this specification, the 'portmapping' and 899 'portmapping-req' attributes are included declaratively. There will 900 not be offer/answer exchanges between the answerer and the actual 901 server providing the unicast service(s). 903 When the answerer supports the Token approach, it MUST echo in its 904 answer back to the offerer the 'portmapping' and 'portmapping-req' 905 attributes from the offer including the same port number and address 906 (if any) for the 'portmapping-req' attribute. If the answerer does 907 not implement this specification, it follows normal SDP parsing of 908 unknown attributes (they are ignored and are not sent in the answer). 909 This means that the answerer can still join the multicast session, 910 but will not be able to use the unicast service(s) that require the 911 use of Tokens. 913 7.2. Requirements 915 The use of SDP for the port mapping solution normatively requires the 916 support for: 918 o The SDP grouping framework and flow identification (FID) semantics 919 [RFC5888] 921 o The RTP/AVPF profile [RFC4585] 923 o Multiplexing RTP and RTCP on a single port on both endpoints in 924 the unicast session [RFC5761] 926 7.3. Example and Discussion 928 The declarative SDP describing the scenario given in Figure 2 is 929 written as: 931 v=0 932 o=ali 1122334455 1122334466 IN IP4 nack.example.com 933 s=Local Retransmissions 934 t=0 0 935 a=group:FID 1 2 936 a=rtcp-unicast:rsi 937 m=video 41000 RTP/AVPF 98 938 i=Multicast Stream 939 c=IN IP4 233.252.0.2/255 940 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 941 a=rtpmap:98 MP2T/90000 942 a=multicast-rtcp:41500 ; Note 1 943 a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 944 a=rtcp-fb:98 nack ; Note 2 945 a=portmapping ; Note 3 946 a=mid:1 947 m=video 42000 RTP/AVPF 99 ; Note 4 948 i=Unicast Retransmission Stream 949 c=IN IP4 192.0.2.1 950 a=sendonly 951 a=rtpmap:99 rtx/90000 952 a=rtcp-mux ; Note 5 953 a=rtcp:42500 ; Note 6 954 a=fmtp:99 apt=98; rtx-time=5000 955 a=portmapping-req:30000 ; Note 7 956 a=mid:2 958 Figure 7: SDP describing an SSM distribution with support for 959 retransmissions from a local server 961 In this description, we highlight the following notes: 963 Note 1: The source stream is multicast from a distribution source 964 with a source IP address of 198.51.100.1 to the multicast destination 965 address of 233.252.0.2 and port 41000 (P1). The associated RTCP 966 packets are multicast in the same group to port 41500 (P2). 968 Note 2: A retransmission server including feedback target 969 functionality with an IP address of 192.0.2.1 and port of 42000 (P3) 970 is specified with the 'rtcp' attribute. The feedback functionality 971 is enabled for the RTP stream with payload type 98 through the 972 'rtcp-fb' attribute [RFC4585]. 974 Note 3: The "a=portmapping" line together with the "a=group" line 975 hints that a Token needs to be retrieved first before the unicast 976 session can be established. 978 Note 4: The port specified in the second "m" line (for the unicast 979 stream) does not mean anything in this scenario as the client does 980 not send any RTP traffic back to the server. 982 Note 5: The server multiplexes RTP and RTCP packets on the same port 983 (c1 in Figure 2). 985 Note 6: The server uses port 42500 (P4) for the unicast session. 987 Note 7: The "a=portmapping-req" line indicates that the Port Mapping 988 Request message needs to be sent to port 30000 (PT). Since there is 989 no address indicated in this line, the client needs to send the Token 990 request to the address specified in the "c" line. 992 8. Address Pooling NATs 994 Large-scale NAT devices have a pool of public IPv4 addresses and map 995 internal hosts to one of those public IPv4 addresses. As long as an 996 internal host maintains an active mapping in the NAT, the same IPv4 997 address is assigned to new connections. However, once all of the 998 host's mappings have been deleted (e.g., because of timeout), it is 999 possible that a new connection from that same host will be assigned a 1000 different IPv4 address from the pool. When that occurs, the Token 1001 will be considered invalid by the server, causing an additional round 1002 trip for the client to acquire a fresh Token. 1004 Any traffic from the host which traverses the NAT will prevent this 1005 problem. As the host is sending RTCP receiver reports at least every 1006 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is 1007 receiving, those RTCP messages will be sufficient to prevent this 1008 problem. 1010 9. Security Considerations 1012 9.1. Tokens 1014 The Token, which is generated based on a client's IP address and 1015 expiration date, provides protection against off-path denial-of- 1016 service (DoS) attacks. An attacker using a certain IP address cannot 1017 cause one or more RTP packets to be sent to a victim client who has a 1018 different IP address. However, if the attacker acquires a valid 1019 Token for a victim and can spoof the victim's source address, this 1020 approach becomes vulnerable to replay attacks. This is especially 1021 easy if the attacker and victim are behind a large-scale NAT and 1022 share the same IP address. 1024 Multicast is deployed on managed networks - not the Internet. These 1025 managed networks will choose to enable network ingress filtering 1026 [RFC2827] or not. If ingress filtering is enabled on a network, an 1027 attacker cannot spoof a victim's IP address to use a Token to 1028 initiate an attack against a victim. However, if ingress filtering 1029 is not enabled on a network, an attacker could obtain a Token and 1030 spoof the victim's address, causing traffic to flood the victim. On 1031 such a network, the server can reduce the time period for such an 1032 attack by expiring a Token in a short period of time. In the extreme 1033 case, the server can expire the Token in such a short period of time, 1034 such that the client will have to acquire a new Token immediately 1035 before using it in a Token Verification Request message. One should, 1036 however, note that such a behavior might have an adverse effect on 1037 the delay in establishing or controlling a unicast session. 1039 RTCP messages could be subject to on-path or man-in-the-middle 1040 attacks. For example, an attacker can modify a value in one or more 1041 fields in the Port Mapping Response or the Token Verification Request 1042 message that are used in Token construction. This will result in 1043 Token validation failure. Consequently, the client ends up asking 1044 the server to generate a new Token. The resulting delay and extra 1045 processing on the server are undesirable. 1047 Alternatively, the attacker can modify a value in a field that is not 1048 used in Token construction. For example, the attacker can reduce the 1049 value in the Relative Expiration Time field in the Port Mapping 1050 Response message from two hours to two minutes. While the Token will 1051 still validate, this attack will result in more frequent requests to 1052 the server for a new Token. Oppositely, the attacker can increase 1053 the value in the Relative Expiration Time field, and make the client 1054 think the Token will be valid for a longer time. This attack can be 1055 only detected by monitoring the activity on the server. Note that 1056 using the relative expiration time in Token construction does not 1057 necessarily make this attack to be detected more easily since the 1058 attacker might revert the modified value back to its original value 1059 in the Token Verification Request message. This allows the Token to 1060 still validate on the server. In this case, the attack is still only 1061 detectable by monitoring the server activity. 1063 If there is a risk or concern for on-path or man-in-the-middle 1064 attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP) 1065 [RFC3711]. 1067 9.2. The portmapping and portmapping-req Attributes 1069 The 'portmapping' attribute does not introduce a significant security 1070 risk. It is used for informative purposes as a hint in a multicast 1071 block in SDP descriptions and without the use of the 'portmapping- 1072 req' attribute in an associated unicast block, its existence does not 1073 mean anything and SHALL be ignored. However, if the 'portmapping- 1074 req' attribute exists in the unicast block but the 'portmapping' 1075 attribute is missing in the associated multicast block (which is 1076 inferred through the "a=group" line), the clients MUST still behave 1077 as if the 'portmapping' attribute existed in the multicast block. 1079 The 'portmapping-req' attribute is not believed to introduce any 1080 significant security risk to multimedia applications. A malevolent 1081 third party could use this attribute to redirect the Port Mapping 1082 Request messages by altering the port number or cause the unicast 1083 session establishment to fail by removing it from the SDP 1084 description. But, this requires intercepting and rewriting the 1085 packets carrying the SDP description; and if an interceptor can do 1086 that, many more attacks are possible, including a wholesale change of 1087 the addresses and port numbers at which the media will be sent. 1089 In order to avoid attacks of this sort, the SDP description needs to 1090 be integrity protected and provided with source authentication. This 1091 can, for example, be achieved on an end-to-end basis using S/MIME 1092 [RFC5652] when SDP is used in a signaling packet using MIME types 1093 (application/sdp). Alternatively, HTTPS [RFC2818] or the 1094 authentication method in the Session Announcement Protocol (SAP) 1095 [RFC2974] could be used as well. 1097 10. IANA Considerations 1099 The following contact information shall be used for all registrations 1100 in this document: 1102 Ali Begen 1103 abegen@cisco.com 1105 Note to the RFC Editor: In the following, please replace "XXXX" with 1106 the number of this document prior to publication as an RFC. 1108 10.1. Registration of SDP Attributes 1110 This document registers two new attribute names in SDP. 1112 SDP Attribute ("att-field"): 1113 Attribute name: portmapping 1114 Long form: Hint for the use of port mapping 1115 Type of name: att-field 1116 Type of attribute: Media level 1117 Subject to charset: No 1118 Purpose: See this document 1119 Reference: [RFCXXXX] 1120 Values: See this document 1122 SDP Attribute ("att-field"): 1123 Attribute name: portmapping-req 1124 Long form: Port and address for requesting Token 1125 Type of name: att-field 1126 Type of attribute: Media level 1127 Subject to charset: No 1128 Purpose: See this document 1129 Reference: [RFCXXXX] 1130 Values: See this document 1132 10.2. Registration of RTCP Control Packet Types 1134 In accordance with Section 15 of [RFC3550], this specification adds 1135 the following value to the RTCP Control Packet types sub-registry of 1136 the Real-Time Transport Protocol (RTP) Parameters registry: 1138 Value Abbrev. Name Reference 1139 -------- --------- --------------------------------------- --------- 1140 TBD TOKEN Port Mapping [RFCXXXX] 1142 Note to the IANA: Please assign the next available value, which is 1143 currently 210. 1145 10.3. SMT Values for TOKEN Packet Type Registry 1147 This document creates a new sub-registry for the sub-message type 1148 (SMT) values to be used with the TOKEN packet type. The registry is 1149 called the SMT Values for TOKEN Packet Type Registry. This registry 1150 is to be managed by the IANA according to the IETF Review policy of 1151 [RFC5226]. 1153 The length of the SMT field is five bits, allowing 32 values. The 1154 registry is initialized with the following entries: 1156 Value Name Reference 1157 ----- -------------------------------------------------- ------------- 1158 0 Reserved [RFCXXXX] 1159 1 Port Mapping Request [RFCXXXX] 1160 2 Port Mapping Response [RFCXXXX] 1161 3 Token Verification Request [RFCXXXX] 1162 4 Token Verification Failure [RFCXXXX] 1163 5-30 Unassigned IETF Review 1164 31 Reserved [RFCXXXX] 1166 The SMT values 0 and 31 are reserved for future use. 1168 10.4. RAMS Response Code Space Registry 1170 This document adds the following entry to the RAMS Response Code 1171 Space Registry. 1173 Code Description Reference 1174 ----- -------------------------------------------------- ------------- 1175 405 Invalid Token [RFCXXXX] 1177 This response code is used when the Token included by the RTP_Rx in 1178 the RAMS-R message is invalid. 1180 11. Acknowledgments 1182 The approach presented in this document came out after discussions 1183 with various individuals in the AVT and MMUSIC WGs, and the breakout 1184 session held in the Anaheim meeting. We thank each of these 1185 individuals, in particular to Magnus Westerlund and Colin Perkins. 1187 12. References 1189 12.1. Normative References 1191 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1192 Jacobson, "RTP: A Transport Protocol for Real-Time 1193 Applications", STD 64, RFC 3550, July 2003. 1195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1196 Requirement Levels", BCP 14, RFC 2119, March 1997. 1198 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1199 Description Protocol", RFC 4566, July 2006. 1201 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1202 "Extended RTP Profile for Real-time Transport Control 1203 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1204 July 2006. 1206 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1207 Protocol (RTCP) Extensions for Single-Source Multicast 1208 Sessions with Unicast Feedback", RFC 5760, February 2010. 1210 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1211 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1213 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1214 Requirements for Security", BCP 106, RFC 4086, June 2005. 1216 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1217 Time Protocol Version 4: Protocol and Algorithms 1218 Specification", RFC 5905, June 2010. 1220 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1221 Hashing for Message Authentication", RFC 2104, 1222 February 1997. 1224 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1225 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1227 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1228 Control Packets on a Single Port", RFC 5761, April 2010. 1230 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1231 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1232 RFC 3711, March 2004. 1234 12.2. Informative References 1236 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1237 with Session Description Protocol (SDP)", RFC 3264, 1238 June 2002. 1240 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1241 the Session Description Protocol (SDP)", RFC 4145, 1242 September 2005. 1244 [I-D.ietf-avt-rapid-acquisition-for-rtp] 1245 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 1246 Based Rapid Acquisition of Multicast RTP Sessions", 1247 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 1248 progress), November 2010. 1250 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1251 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1252 RFC 4787, January 2007. 1254 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1255 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1256 July 2006. 1258 [I-D.ietf-avt-app-rtp-keepalive] 1259 Marjou, X. and A. Sollaud, "Application Mechanism for 1260 keeping alive the Network Address Translator (NAT) 1261 mappings associated to RTP flows.", 1262 draft-ietf-avt-app-rtp-keepalive-09 (work in progress), 1263 September 2010. 1265 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1266 Defeating Denial of Service Attacks which employ IP Source 1267 Address Spoofing", BCP 38, RFC 2827, May 2000. 1269 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1270 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1271 May 2008. 1273 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1274 "Codec Control Messages in the RTP Audio-Visual Profile 1275 with Feedback (AVPF)", RFC 5104, February 2008. 1277 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1278 RFC 5652, September 2009. 1280 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1282 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1283 Announcement Protocol", RFC 2974, October 2000. 1285 Authors' Addresses 1287 Ali Begen 1288 Cisco 1289 181 Bay Street 1290 Toronto, ON M5J 2T3 1291 Canada 1293 Email: abegen@cisco.com 1295 Dan Wing 1296 Cisco Systems, Inc. 1297 170 West Tasman Dr. 1298 San Jose, CA 95134 1299 USA 1301 Email: dwing@cisco.com 1303 Tom VanCaenegem 1304 Alcatel-Lucent 1305 Copernicuslaan 50 1306 Antwerpen, 2018 1307 Belgium 1309 Email: Tom.Van_Caenegem@alcatel-lucent.com