idnits 2.17.1 draft-ietf-avt-ports-for-ucast-mcast-rtp-09.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 14, 2010) is 4882 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 1051, 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 17, 2011 T. VanCaenegem 6 Alcatel-Lucent 7 December 14, 2010 9 Port Mapping Between Unicast and Multicast RTP Sessions 10 draft-ietf-avt-ports-for-ucast-mcast-rtp-09 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 17, 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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 16 66 5. Procedures for Token Construction . . . . . . . . . . . . . . 18 67 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 20 68 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 21 69 7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 21 70 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22 71 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 22 72 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 25 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 74 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 26 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 77 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 28 78 10.2. Registration of RTCP Control Packet Types . . . . . . . . 28 79 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 28 80 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 29 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 84 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 87 1. Introduction 89 In (any-source or source-specific) multicast RTP applications, 90 destination ports, i.e., the ports on which the multicast receivers 91 receive the RTP and RTCP packets, are defined declaratively. In 92 other words, the receivers cannot choose their receive ports and the 93 sender(s) use the pre-defined ports. 95 In unicast RTP applications, the receiving end needs to choose its 96 ports for RTP and RTCP since these ports are local resources and only 97 the receiving end can determine which ports are available to use. In 98 addition, Network Address Port Translators (NAPT - hereafter simply 99 called NAT) devices are commonly deployed in networks, thus, static 100 port assignments cannot be used. The receiving end may convey its 101 request to the sending end through different ways, one of which is 102 the Offer/Answer Model [RFC3264] for the Session Description Protocol 103 (SDP) [RFC4566]. However, the Offer/Answer Model requires offer/ 104 answer exchange(s) between the endpoints, and the resulting delay may 105 not be desirable in delay-sensitive real-time applications. 106 Furthermore, the Offer/Answer Model may be burdensome for the 107 endpoints that are concurrently running a large number of unicast 108 sessions with other endpoints. 110 In this specification, we consider an RTP application that uses one 111 or more unicast and multicast RTP sessions together. While the 112 declaration and selection of the ports are well defined and work well 113 for multicast and unicast RTP applications, respectively, the usage 114 of the ports introduces complications when a receiving end mixes 115 unicast and multicast RTP sessions within the same RTP application. 117 An example scenario is where the RTP packets are distributed through 118 source-specific multicast (SSM) and a receiver sends unicast RTCP 119 NACK feedback to a local repair server (also functioning as a unicast 120 RTCP feedback target) [RFC5760] asking for a retransmission of the 121 packets it is missing, and the local repair server sends the 122 retransmission packets over a unicast RTP session [RFC4588]. 124 Another scenario is where a receiver wants to rapidly acquire a new 125 primary multicast RTP session and receives one or more RTP burst 126 packets over a unicast session before joining the SSM session 127 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in 128 applications where some part of the content is distributed through 129 multicast while the receivers get additional and/or auxiliary content 130 through one or more unicast connections, as sketched in Figure 1. 132 In this document, we discuss this problem and introduce a solution 133 that we refer to as Port Mapping. This solution allows receivers to 134 choose their desired UDP ports for RTP and RTCP in every unicast 135 session when they are running RTP applications using both unicast and 136 multicast services, and offer/answer exchange is not available. This 137 solution is not applicable in cases where TCP is used as the 138 transport protocol in the unicast sessions. For such scenarios, 139 refer to [RFC4145]. 141 ----------- 142 | Unicast |................ 143 | Source |............. : 144 | (Server) | : : 145 ----------- : : 146 v v 147 ----------- ---------- ----------- 148 | Multicast |------->| Router |---------->|Client RTP | 149 | Source | | |..........>|Application| 150 ----------- ---------- ----------- 151 | : 152 | : ----------- 153 | :..............>|Client RTP | 154 +---------------->|Application| 155 ----------- 157 -------> Multicast RTP Flow 158 .......> Unicast RTP Flow 160 Figure 1: RTP applications simultaneously using both unicast and 161 multicast services 163 In the remainder of this document, we refer to the RTP endpoints that 164 serve other RTP endpoints over a unicast session as the Servers. The 165 receiving RTP endpoints are referred to as Clients. 167 2. Requirements Notation 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Token-Based Port Mapping 175 Token-based Port Mapping consists of two steps: (i) Token request 176 and retrieval, and (ii) unicast session establishment. 178 The first step is required to be completed only once. Once a Token 179 is retrieved from a particular server, it can be used for all the 180 unicast sessions the client will be running with this particular 181 server. By default, Tokens are server specific. However, the client 182 can use the same Token to communicate with different servers if these 183 servers are provided with the same secret key and algorithm used to 184 generate the Token and are at least loosely clock-synchronized. 186 The Token is essentially an opaque encapsulation that is based on 187 client's IP address (as seen by the server). When a Token request is 188 received, the server creates a Token for this particular client, and 189 sends it back to the client. The Token becomes invalid if client's 190 IP address (as seen by the server) changes (note that the client 191 cannot necessarily detect this in a timely manner) or when the server 192 expires the Token. In these cases, the client has to request a new 193 Token. 195 As the second step, when the client wants to establish a unicast 196 session, the client includes the Token with its RTCP feedback 197 message. The server validates the Token, making sure that the IP 198 address information matches. This is effective against DoS attacks, 199 e.g., an attacker cannot simply spoof another client's IP address and 200 start a unicast transmission towards random clients. If the 201 validation passes, the unicast session gets established. Otherwise, 202 the server notifies the client that the validation has failed, and in 203 this case, the unicast session will not be established. 205 Upon successfull validation and once the unicast session is 206 established, all the RTP and RTCP rules specified in [RFC3550] and 207 other relevant specifications also apply in this session until it is 208 terminated. During its lifetime, certain actions and messages by the 209 client might need to be authorized by the server by requiring a valid 210 Token. These are explained later in this document. 212 Below, we first present a motivating scenario for port mapping and 213 then describe the normative behavior and requirements. 215 3.1. Motivating Scenario 217 Consider an SSM distribution network where a distribution source 218 multicasts RTP packets to a large number of clients, and one or more 219 retransmission servers function as feedback targets to collect 220 unicast RTCP feedback from these clients [RFC5760]. The 221 retransmission servers also join the multicast session to receive the 222 multicast packets and cache them for a certain time period. When a 223 client detects missing packets in the multicast session, it requests 224 a retransmission from one of the retransmission servers by using an 225 RTCP NACK message [RFC4585]. The retransmission server pulls the 226 requested packet(s) out of the cache and retransmits them to the 227 requesting client [RFC4588]. 229 The RTP and RTCP flows pertaining to the scenario described above are 230 sketched in Figure 2. Between the client and server, there can be 231 one or more NAT devices [RFC4787]. The multicast and unicast 232 sessions are clearly identified with their individual RTP and RTCP 233 flows and port numbers. 235 -------------- --- ---------- 236 | |-------------------------------| |-->|P1 | 237 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 238 | | | | | | 239 | Distribution | ---------------- | | | | 240 | Source | | | | | | | 241 | |---->|P1 | | | | | 242 | |.-.->|P2 | | | | | 243 | | | | | | | | 244 -------------- | P3|<.=.=.=.| |=.=|*c0 | 245 | P3|<~~~~~~~| |~~~|*c1 | 246 MULTICAST RTP | | | | | | 247 SESSION with | | | N | | | 248 UNICAST FEEDBACK | | | A | | | 249 | Retransmission | | T | | Client | 250 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 251 | Server | | | | | 252 | | | | | | 253 PORT MAPPING | PT|<~~~~~~~| |~~>|*cT | 254 | | | | | | 255 - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- 256 | | | | | | 257 AUXILIARY UNICAST | | | | | | 258 RTP SESSION | | | | | | 259 | P3|........| |..>|*c1 | 260 | P3|=.=.=.=.| |=.>|*c1 | 261 | P4|<.=.=.=.| |=.=|*c2 | 262 | | | | | | 263 ---------------- --- ---------- 265 -------> Multicast RTP Flow 266 .-.-.-.> Multicast RTCP Flow 267 .=.=.=.> Unicast RTCP Reports 268 ~~~~~~~> Unicast RTCP (Feedback) Messages 269 .......> Unicast RTP Flow 271 Figure 2: Example scenario showing an SSM distribution with support 272 for retransmissions from a server 274 In Figure 2, we have the following multicast and unicast ports: 276 o Ports P1 and P2 denote the destination RTP and RTCP ports in the 277 multicast session, respectively. The clients listen to these 278 ports to receive the multicast RTP and RTCP packets. Ports P1 and 279 P2 are defined declaratively. 281 o Port P3 denotes the RTCP port on the feedback target running on 282 the retransmission server to collect any RTCP packet sent by the 283 clients including feedback messages, and RTCP receiver and 284 extended reports. This is also the port that the retransmission 285 server uses to send the RTP packets and RTCP sender reports in the 286 unicast session. Port P3 is defined declaratively. 288 o Port P4 denotes the RTCP port on the retransmission server used to 289 collect the RTCP receiver and extended reports for the unicast 290 session. Port P4 is defined declaratively. 292 o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the 293 port on the client used to send the RTCP reports for the multicast 294 session. *c1 denotes the port on the client used to send the 295 unicast RTCP feedback messages in the multicast session and to 296 receive the RTP packets and RTCP sender reports in the unicast 297 session. *c2 denotes the port on the client used to send the RTCP 298 receiver and extended reports in the unicast session. Ports c0, 299 c1 and c2 could be the same port or different ports. There are 300 two advantages of using the same port for both c0 and c1: 302 1. Some NATs only keep bindings active when a packet goes from 303 the inside to the outside of the NAT (See REQ-6 of Section 4.3 304 of [RFC4787]). When the gap between the packets sent from the 305 client to the server is long, this can exceed that timeout. 306 If c0=c1, the occasional (periodic) RTCP receiver reports sent 307 from port c0 (for the multicast session's RTCP port P3) will 308 ensure the NAT does not time out the public port associated 309 with the incoming unicast traffic to port c1. 311 2. Having c0=c1 conserves NAT port bindings. 313 o Ports PT and *cT denote the ports through which the Token request 314 and retrieval occur at the server and client sides, respectively. 315 Port PT is declared on a per unicast session basis, although the 316 same port could be used for two or more unicast sessions sourced 317 by the server. A Token once requested and retrieved by a client 318 from port PT remains valid until its expiration time. 320 We assume that the information declaratively defined is available as 321 part of the session description information and is provided to the 322 clients. The Session Description Protocol (SDP) [RFC4566] and other 323 session description methods can be used for this purpose. 325 3.2. Normative Behavior and Requirements 327 In this section, we describe the normative behavior and requirements. 328 To simplify the presentation, we refer to the port numbers described 329 in the example presented in Figure 2. However, the behavior and 330 requirements described here are not specific to that particular 331 example, and can be applied to any scenario where analogous ports can 332 be identified. 334 First of all, a client compliant with this specification MUST be able 335 to include a Token with any type of RTCP message (as described below) 336 when it is needed. That is, clients MUST NOT implement this 337 specification with only a specific use case in mind. 339 Second, the solution provided in this specification is not applicable 340 in cases where there is RTP traffic flowing from the client to the 341 server in the unicast session. In other words, the direction of RTP 342 traffic MUST be only from the server to the client in the unicast 343 session. If the client wants to send RTP traffic back to the server, 344 the regular session establishment methods such as [RFC3264] need to 345 be used. 347 The following steps summarize the Token-based solution: 349 1. The client ascertains server address and port numbers (P3, P4 and 350 PT) from the session description. Port P4 MUST be different from 351 port P3. Port PT MAY be equal to port P3. 353 2. The client selects its local port numbers (*c0, *c1, *c2 and 354 *cT). It is strongly RECOMMENDED that the client uses the same 355 port for c0 and c1. Port cT MAY be equal to ports c0 and c1. 357 A client cannot keep using the same receive port for different 358 unicast sessions since there could be packet leakage when 359 switching from one unicast session to another unless each 360 received unicast stream has its own distinct Synchronization 361 Source (SSRC) identifier to allow the client to filter out the 362 undesired packets. Unless this is guaranteed (which is not often 363 easy), a client SHOULD use separate receive ports for subsequent 364 unicast sessions. After a sufficient time, a previously used 365 receive port could be used again. 367 3. If the client does not have a Token (or the existing Token has 368 expired): 370 A. The client first sends a message to the server via a new RTCP 371 message, called Port Mapping Request to port PT. This 372 message is sent from port *cT on the client side. The server 373 learns client's IP address from the received message. The 374 client can send this message anytime it wants (e.g., during 375 initialization), and does not normally ever need to re-send 376 this message (See Section 6). 378 B. The server generates an opaque encapsulation (i.e., the 379 Token) based on certain information including client's IP 380 address. 382 C. The server sends the Token back to the client using a new 383 RTCP message, called Port Mapping Response. This message 384 MUST be sent from port PT to port cT. 386 4. The client needs to provide the Token to the server using a new 387 RTCP message, called Token Verification Request, whenever the 388 client sends an RTCP feedback message for triggering or 389 controlling a unicast session (See Section 4.3.1). If the Token 390 is invalid or missing, the server sends a new RTCP message, 391 called Token Verification Failure, to the client. 393 Note that the unicast session is only established after the 394 server has received a feedback message (along with a valid Token) 395 from the client for which it needs to react by sending unicast 396 data. Until a unicast session is established, neither the server 397 nor the client needs to send RTCP reports for the unicast 398 session. 400 5. Normal flows ensue as shown in Figure 2. Note that in the 401 unicast session, traffic from the server to the client (i.e., 402 both the RTP and RTCP packets sent from port P3 to port c1) MUST 403 be multiplexed on the (same) port c1. If the client uses the 404 same port for both c0 and c1, the RTCP reports sent for the 405 multicast session keep the P3->c1(=c0) binding alive. If the 406 client uses different ports for c0 and c1, the client needs to 407 periodically send an explicit keep-alive message 408 [I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive 409 during the lifetime of the unicast session if the unicast 410 session's lifetime is likely to exceed the NAT's timeout value. 412 4. Message Formats 414 This section defines the formats of the RTCP messages that are 415 exchanged between a server and a client for the purpose of port 416 mapping. A new RTCP control packet type is introduced and four port 417 mapping messages using this control packet are defined: 419 1. Port Mapping Request 421 2. Port Mapping Response 423 3. Token Verification Request 425 4. Token Verification Failure 427 Each message has a fixed-length field for version (V), padding (P), 428 sub-message type (SMT), packet type (PT), length and SSRC of packet 429 sender. Messages have other fields as defined below. In all 430 messages defined in this section, the PT field is set to TOKEN (210). 431 Individual messages are identified by the SMT field. The length 432 field indicates the message size in 32-bit words minus one, including 433 the header and any padding. This definition is in line with the 434 definition of the length field used in RTCP sender and receiver 435 reports. In all messages, any Reserved field SHALL be set to zero 436 and ignored. 438 Following the rules specified in [RFC3550], all integer fields in the 439 messages defined below are carried in network-byte order, that is, 440 most significant byte (octet) first, also known as big-endian. 441 Unless otherwise stated, numeric constants are in decimal (base 10). 443 Note that RTCP is not a timely or reliable protocol. The RTCP 444 packets might get lost or re-ordered in the network. When sending a 445 new Port Mapping Request message, the scheduling rules that apply to 446 sending initial RTCP messages [RFC4585] apply. When a client sends a 447 Port Mapping Request or Token Verification Request message but it 448 does not receive a response back from the server (either a Port 449 Mapping Response or Token Verification Failure message), it MAY 450 resend its request by following the timer rules defined for RTCP 451 feedback messages in Section 3.5 of [RFC4585] as a good practice. 452 When sending an RTCP (feedback) message bundled with a Token 453 Verification Request message, the timer rules of [RFC4585] apply as 454 usual. 456 4.1. Port Mapping Request 458 The Port Mapping Request message is identified by SMT=1. This 459 message is transmitted by the client to a dedicated server port (and 460 possibly an address) to request a Token. In the Port Mapping Request 461 message, the packet sender SSRC is set to the client's SSRC. The 462 packet format has the structure depicted in Figure 3. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |V=2|P| SMT=1 | PT=TOKEN=210 | Length=3 | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | SSRC of Packet Sender | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Random | 472 | Nonce | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 3: Packet format for the Port Mapping Request message 477 o Random Nonce (64 bits): Field that contains a random nonce value 478 generated by the client following the procedures of [RFC4086]. 479 This nonce is taken into account by the server when generating a 480 Token for the client to enable better security for clients that 481 share the same IP address. If the Port Mapping Request message is 482 transmitted multiple times for redundancy reasons, the random 483 nonce value MUST remain the same in these duplicated messages. 484 However, the client MUST generate a new random nonce for every new 485 Port Mapping Request message. 487 4.2. Port Mapping Response 489 The Port Mapping Response message is identified by SMT=2. This 490 message is sent by the server and delivers the Token to the client as 491 a response to the Port Mapping Request message. In the Port Mapping 492 Response message, the packet sender SSRC is set to the server's SSRC. 493 The packet format has the structure depicted in Figure 4. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |V=2|P| SMT=2 | PT=TOKEN=210 | Length | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | SSRC of Packet Sender | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | SSRC of Requesting Client | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Associated | 505 | Nonce | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 : Token Element : 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Absolute | 510 | Expiration Time | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Relative Expiration Time | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 4: Packet format for the Port Mapping Response message 517 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 518 of the client who sent the request. 520 o Associated Nonce (64 bits): Field that contains the nonce 521 received in the Port Mapping Request message and used in Token 522 construction. 524 o Token Element (Variable size): Element that is used to carry the 525 Token generated by the server. This element is a 32-bit aligned 526 Length-Value element. The Length field, which is 8 bits, 527 indicates the length (in octets) of the Value field that follows 528 the Length field. This length does not include any padding that 529 is required for alignment. The Value field carries the Token (or 530 more accurately, the output of the encoding process on the 531 server). If the Token element does not fall on a 32-bit boundary, 532 the last word MUST be padded to the boundary using further bits 533 set to zero. 535 o Absolute Expiration Time (64 bits): Field that contains the 536 absolute expiration time of the Token. The absolute expiration 537 time is expressed as a Network Time Protocol (NTP) timestamp value 538 in seconds since year 1900 [RFC5905]. The client does not need to 539 use this element directly, thus, does not need to synchronize its 540 clock with the server. However, the client needs to send this 541 element back to the server along with the associated nonce in the 542 Token Verification Request message, thus, needs to keep it 543 associated with the Token. 545 o Relative Expiration Time (32 bits): Field that contains the 546 relative expiration time of the Token. The relative expiration 547 time is expressed in seconds from the time the Token was 548 generated. A relative expiration time of zero indicates that the 549 accompanying Token is not valid. 551 The server conveys the relative expiration time in the clear to 552 the client to allow the client to request a new Token well before 553 the expiration time. 555 4.3. Token Verification Request 557 The Token Verification Request message is identified by SMT=3. This 558 message contains the Token and accompanies any RTCP message that 559 would trigger a new or control an existing unicast session. For a 560 list of such messages, see Section 4.3.1. 562 In the Token Verification Request message, the packet sender SSRC is 563 set to the client's SSRC. The client MUST NOT send a Token 564 Verification Request message with a Token that has expired. The 565 packet format has the structure depicted in Figure 5. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |V=2|P| SMT=3 | PT=TOKEN=210 | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | SSRC of Packet Sender | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Associated | 575 | Nonce | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 : Token Element : 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Associated Absolute | 580 | Expiration Time | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 5: Packet format for the Token Verification Request message 585 o Associated Nonce (64 bits): Field that contains the nonce 586 associated with the Token above. 588 o Token Element (Variable size): Token element that was previously 589 received in the Port Mapping Response message. 591 o Associated Absolute Expiration Time (64 bits): Field that 592 contains the absolute expiration time associated with the Token 593 above. 595 4.3.1. Where to Include Token 597 The following RTCP messages are REQUIRED to be accompanied by a Token 598 Verification Request message when the Token capability is declared in 599 the session description: 601 o Messages that trigger a new unicast session: 603 * NACK messages [RFC4585] 605 * RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 607 o Messages that control an existing unicast session associated with 608 a multicast session: 610 * BYE messages [RFC3550] 612 * RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp] 614 * CCM messages [RFC5104] 616 A server might determine that other RTCP messages also need to be 617 authenticated using the mechanism described in this document. Thus, 618 clients need to support including a Token with any necessary RTCP 619 message (See Section 3.2). 621 The Token Verification Request message might also be bundled with 622 packets carrying RTCP receiver or extended reports. While such 623 packets do not have a strong security impact, a specific application 624 might desire to have a more controlled reporting scheme from the 625 clients. 627 4.4. Token Verification Failure 629 The Token Verification Failure message is identified by SMT=4. This 630 message is sent by the server and notifies the client that the Token 631 was invalid or that the client did not include a Token Verification 632 Request message in the RTCP packet although it was supposed to. In 633 the Token Verification Failure message, the packet sender SSRC is set 634 to the server's SSRC. The packet format has the structure depicted 635 in Figure 6. 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 |V=2|P| SMT=4 | PT=TOKEN=210 | Length=5 | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | SSRC of Packet Sender | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | SSRC of Requesting Client | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | PT of Request | Req. FMT| Reserved | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Associated | 649 | Nonce | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Figure 6: Packet format for the Token Verification Failure message 654 o SSRC of Requesting Client (32 bits): Field that contains the SSRC 655 of the client who sent the verification request. 657 o PT of Request (8 bits): Field that indicates the type of the RTCP 658 packet that caused this failure message. 660 o Req. FMT (5 bits): Field that indicates the feedback message type 661 (FMT) value of the RTCP packet that caused this failure. Together 662 with the field above, the client can infer which RTCP message it 663 has previously sent caused this failure message to be sent by the 664 server. For example, if the client did not include a valid Token 665 with an RTCP NACK message, the PT of Request field will indicate 666 205 (RTPFB) and the Req. FMT field will indicate 1 (Generic NACK). 667 If the RTCP message did not have an associated FMT value (such as 668 an RTCP BYE message), the Req. FMT field SHALL be set to zero. 670 o Associated Nonce (64 bits): Field that contains the nonce 671 received in the Token Verification Request message. If there was 672 no Token Verification Request message included by the client, this 673 field is set to 0. 675 5. Procedures for Token Construction 677 The Token encoding is known to the server but opaque to the client. 678 Implementations MUST encode the following information into the Token 679 as a minimum, in order to provide adequate security: 681 o Client's IP address as seen by the server (32/128 bits for IPv4/ 682 IPv6 addresses) 684 o The nonce generated and inserted in the Port Mapping Request 685 message by the client (64 bits) 687 o The absolute expiration time chosen by the server indicated as an 688 NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, 689 to protect against replay attacks) 691 An example way for constructing Tokens is to perform HMAC-SHA1 692 [RFC2104] on the concatenated values of the information listed above. 693 The HMAC key should be at least 160 bits long, and generated using a 694 cryptographically secure random source [RFC4086]. However, 695 implementations MAY adopt different approaches and are encouraged to 696 encode whatever additional information is deemed necessary or useful. 697 For example, key rollover is simplified by encoding a key-id into the 698 Token. As another example, a cluster of anycast servers could find 699 advantage by encoding a server identifier into the Token. As another 700 example, if HMAC-SHA1 has been compromised, a replacement HMAC 701 algorithm could be used instead (e.g., HMAC-SHA256). 703 To protect from offline attacks, the server SHOULD occasionally 704 choose a new HMAC key. To ease implementation, a key-id can be 705 assigned to each HMAC key. This can be encoded as simply as one bit 706 (where the new key is X (e.g., 1) and the old key is the inverted 707 value of X (e.g., 0)), or if several keys are supported at once could 708 be encoded into several bits. As the encoding of the Token is 709 entirely private to the server and opaque to the clients, any 710 encoding can be used. By encoding the key-id into the Token element, 711 the server can reject an old key without bothering to do HMAC 712 validation (saving CPU cycles). The key-id can be encoded into the 713 Value field of the Token element by simply concatenating the 714 (plaintext) key-id with the hashed information (i.e., the Token 715 itself). 717 For example, the Value field in the Token element can be computed as: 719 key-id || hash-alg (client-ip | nonce | abs-expiration) 721 During Token construction, the expiration time has to be chosen 722 carefully based on the intended service duration. Tokens that are 723 valid for an unnecessarily long period of time (e.g., several hours) 724 might impose security risks. Depending on the application and use 725 cases, a reasonable value needs to be chosen by the server. Note 726 that using shorter lifetimes requires the clients to acquire Tokens 727 more frequently. However, since a client can acquire a new Token 728 well before it will need to use it, the client will not necessarily 729 be penalized for the acquisition delay. 731 Finally, be aware that NTP timestamps will wrap around in year 2036 732 and implementations might need to handle this eventually. Refer to 733 Section 6 of [RFC5905] for further details. 735 6. Validating Tokens 737 Upon receipt of an RTCP feedback message along with the Token 738 Verification Request message that contains a Token, nonce and 739 absolute expiration time, the server MUST validate the Token. 741 The server first applies its own procedure for constructing the 742 Tokens by using client's IP address from the received Token 743 Verification Request message, and the nonce and absolute expiration 744 time values reported in the received Token Verification Request 745 message. The server then compares the resulting output with the 746 Token sent by the client in the Token Verification Request message. 747 If they match and the absolute expiration time has not passed yet, 748 the server declares that the Token is valid. 750 Note that if the client's IP address changes, the Token will not 751 validate. Similarly, if the client inserts an incorrect nonce or 752 absolute expiration time value in the Token Verification Request 753 message, validation will fail. It is also possible that the server 754 wants to expire the Token prematurely. In these cases, the server 755 MUST reply back to the client with a Token Verification Failure 756 message (that goes from port P3 on the server to port c1 on the 757 client). 759 In addition to the Token Verification Failure message, it is 760 RECOMMENDED that applications define an application-specific error 761 response to be sent by the server when the server detects that the 762 Token is invalid. For applications using 763 [I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new 764 4xx-level response code in the RAMS Response Code Space Registry. A 765 client that received a Token Verification Failure message can request 766 a new Token from the server. 768 7. SDP Signaling 770 7.1. The portmapping-req Attribute 772 This new SDP attribute is used declaratively to indicate the port and 773 optionally the address for obtaining a Token. Its presence indicates 774 that (i) a Token MUST be included in certain feedback messages sent 775 to the server triggering or controlling a unicast session (The list 776 of those feedback messages is in Section 4.3.1), and (ii) the client 777 MUST receive the unicast session's RTP and RTCP packets from the 778 server on the port from which it sent the RTCP message triggering or 779 controlling the unicast session. 781 The formal description of the 'portmapping-req' attribute is defined 782 by the following ABNF [RFC5234] syntax: 784 portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP 785 addrtype SP connection-address]] CRLF 787 Here, 'port', 'nettype', 'addrtype' and 'connection-address' are 788 defined as specified in Section 9 of [RFC4566]. The 'portmapping- 789 req' attribute SHALL be used as a media-level attribute. 791 Note: This does not imply that Token Verification Request 792 messages need to be sent in the unicast session. Token 793 Verification Request messages accompany RTCP messages that trigger 794 or control this unicast session, and are sent either in the 795 multicast session or the unicast session, depending on the RTCP 796 message (See Section 4.3.1). 798 In the optional address value, only unicast addresses SHOULD be used 799 unless one wants to use a multicast address after evaluating the 800 additional security risks such as non-legit servers generating fake 801 Tokens. If the address is not specified, the (source) address in the 802 "c" line corresponding to the unicast media stream is implied. 804 When using this attribute in SDP offer/answer exchanges [RFC3264], 805 the following needs to be considered. First of all, this attribute 806 is used declaratively, and there are no offer/answer exchanges 807 between the client consuming the SDP description and the actual 808 server providing the service. At media level, this applies to the 809 RTCP feedback messages declared by this media block. 811 An offerer that desires the answerer to use Tokens in RTCP messages 812 sent to the server, i.e., received by the server, the attribute is 813 included. In case an offerer desires to declare support for using 814 Tokens as defined in this specification but do not need Tokens to be 815 included for any RTCP messages to be received by the server, it can 816 include the 'portmapping-req' attribute without any parameters, 817 neither port nor address. 819 An answerer receiving an SDP offer with the "a=portmapping-req" line 820 with a port number SHALL use that port number and the address, either 821 explicitly provided in the attribute or implicitly provided by the 822 "c" line, for any needed Token request. If the "a=portmapping-req" 823 line attribute does not contain a port, the answer SHALL take note of 824 the capability. 826 When sending an answer, if the 'portmapping-req' attribute has been 827 present in the offer including a port number and the answerer 828 supports this specification, then the answerer MUST include the 829 attribute in its answer. The answer may or may not include a port 830 and address. This depends on the application and the desire of the 831 answerer. The answerer includes a port and possibly an address when 832 it requires to receive Tokens in RTCP messages. If it only supports 833 this specification but does not need Tokens to be included, the 834 attribute is included without any port or address. 836 7.2. Requirements 838 The use of SDP for the port mapping solution normatively requires the 839 support for: 841 o The SDP grouping framework and flow identification (FID) semantics 842 [RFC5888] 844 o The RTP/AVPF profile [RFC4585] 846 o Multiplexing RTP and RTCP on a single port on both endpoints in 847 the unicast session [RFC5761] 849 7.3. Example and Discussion 851 The declarative SDP describing the scenario given in Figure 2 is 852 written as: 854 v=0 855 o=ali 1122334455 1122334466 IN IP4 nack.example.com 856 s=Local Retransmissions 857 t=0 0 858 a=group:FID 1 2 859 a=rtcp-unicast:rsi 860 m=video 41000 RTP/AVPF 98 861 i=Multicast Stream 862 c=IN IP4 233.252.0.2/255 863 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 864 a=rtpmap:98 MP2T/90000 865 a=multicast-rtcp:41500 ; Note 1 866 a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 867 a=rtcp-fb:98 nack ; Note 2 868 a=mid:1 869 m=video 42000 RTP/AVPF 99 ; Note 3 870 i=Unicast Retransmission Stream 871 c=IN IP4 192.0.2.1 872 a=sendonly 873 a=rtpmap:99 rtx/90000 874 a=rtcp-mux ; Note 4 875 a=rtcp:42500 ; Note 5 876 a=fmtp:99 apt=98; rtx-time=5000 877 a=portmapping-req:30000 ; Note 6 878 a=mid:2 880 Figure 7: SDP describing an SSM distribution with support for 881 retransmissions from a local server 883 In this description, we highlight the following notes: 885 Note 1: The source stream is multicast from a distribution source 886 with a source IP address of 198.51.100.1 to the multicast destination 887 address of 233.252.0.2 and port 41000 (P1). The associated RTCP 888 packets are multicast in the same group to port 41500 (P2). 890 Note 2: A retransmission server including feedback target 891 functionality with an IP address of 192.0.2.1 and port of 42000 (P3) 892 is specified with the 'rtcp' attribute. The feedback functionality 893 is enabled for the RTP stream with payload type 98 through the 894 'rtcp-fb' attribute [RFC4585]. 896 Note 3: The port specified in the second "m" line (for the unicast 897 stream) does not mean anything in this scenario as the client does 898 not send any RTP traffic back to the server. 900 Note 4: The server multiplexes RTP and RTCP packets on the same port 901 (c1 in Figure 2). 903 Note 5: The server uses port 42500 (P4) for the unicast sessions. 905 Note 6: The "a=portmapping-req" line indicates that a Token needs to 906 be retrieved first before a unicast session associated to the 907 multicast session can be established and that the Port Mapping 908 Request message needs to be sent to port 30000 (PT). Since there is 909 no address indicated in this line, the client needs to send the Token 910 request to the address specified in the "c" line. 912 8. Address Pooling NATs 914 Large-scale NAT devices have a pool of public IPv4 addresses and map 915 internal hosts to one of those public IPv4 addresses. As long as an 916 internal host maintains an active mapping in the NAT, the same IPv4 917 address is assigned to new connections. However, once all of the 918 host's mappings have been deleted (e.g., because of timeout), it is 919 possible that a new connection from that same host will be assigned a 920 different IPv4 address from the pool. When that occurs, the Token 921 will be considered invalid by the server, causing an additional round 922 trip for the client to acquire a fresh Token. 924 Any traffic from the host which traverses the NAT will prevent this 925 problem. As the host is sending RTCP receiver reports at least every 926 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is 927 receiving, those RTCP messages will be sufficient to prevent this 928 problem. 930 9. Security Considerations 932 9.1. Tokens 934 The Token, which is generated based on a client's IP address and 935 expiration date, provides protection against off-path denial-of- 936 service (DoS) attacks. An attacker using a certain IP address cannot 937 cause one or more RTP packets to be sent to a victim client who has a 938 different IP address. However, if the attacker acquires a valid 939 Token for a victim and can spoof the victim's source address, this 940 approach becomes vulnerable to replay attacks. This is especially 941 easy if the attacker and victim are behind a large-scale NAT and 942 share the same IP address. 944 Multicast is deployed on managed networks - not the Internet. These 945 managed networks will choose to enable network ingress filtering 946 [RFC2827] or not. If ingress filtering is enabled on a network, an 947 attacker attacker cannot spoof a victim's IP address to use a Token 948 to initiate an attack against a victim. However, if ingress 949 filtering is not enabled on a network, an attacker could obtain a 950 Token and spoof the victim's address, causing traffic to flood the 951 victim. On such a network, the server can reduce the time period for 952 such an attack by expiring a Token in a short period of time. In the 953 extreme case, the server can expire the Token in such a short period 954 of time, such that the client will have to acquire a new Token 955 immediately before using it in a Token Verification Request message. 957 HMAC-SHA1 provides a level of security that is widely regarded as 958 being more than sufficient for providing message authentication. It 959 is believed that the economic cost of breaking that algorithm is 960 significantly higher than the cost of more direct approaches to 961 violating system security, e.g., theft, bribery, wiretapping, and 962 other forms of malfeasance. HMAC-SHA1 is secure against all known 963 cryptanalytic attacks that use computational resources that are 964 currently economically feasible. 966 9.2. The portmapping-req Attribute 968 The 'portmapping-req' attribute is not believed to introduce any 969 significant security risk to multimedia applications. A malevolent 970 third party could use this attribute to redirect the Port Mapping 971 Request messages by altering the port number or cause the unicast 972 session establishment to fail by removing it from the SDP 973 description. But, this requires intercepting and rewriting the 974 packets carrying the SDP description; and if an interceptor can do 975 that, many more attacks are possible, including a wholesale change of 976 the addresses and port numbers at which the media will be sent. 978 In order to avoid attacks of this sort, the SDP description needs to 979 be integrity protected and provided with source authentication. This 980 can, for example, be achieved on an end-to-end basis using S/MIME 981 [RFC5652] when SDP is used in a signaling packet using MIME types 982 (application/sdp). Alternatively, HTTPS [RFC2818] or the 983 authentication method in the Session Announcement Protocol (SAP) 984 [RFC2974] could be used as well. 986 10. IANA Considerations 988 The following contact information shall be used for all registrations 989 in this document: 991 Ali Begen 992 abegen@cisco.com 994 Note to the RFC Editor: In the following, please replace "XXXX" with 995 the number of this document prior to publication as an RFC. 997 10.1. Registration of SDP Attributes 999 This document registers a new attribute name in SDP. 1001 SDP Attribute ("att-field"): 1002 Attribute name: portmapping-req 1003 Long form: Port for requesting Token 1004 Type of name: att-field 1005 Type of attribute: Media level 1006 Subject to charset: No 1007 Purpose: See this document 1008 Reference: [RFCXXXX] 1009 Values: See this document 1011 10.2. Registration of RTCP Control Packet Types 1013 In accordance with Section 15 of [RFC3550], this specification adds 1014 the following value to the RTCP Control Packet types sub-registry of 1015 the Real-Time Transport Protocol (RTP) Parameters registry: 1017 Value Abbrev. Name Reference 1018 -------- --------- --------------------------------------- --------- 1019 210 TOKEN Port Mapping [RFCXXXX] 1021 10.3. SMT Values for TOKEN Packet Type Registry 1023 This document creates a new sub-registry for the sub-message type 1024 (SMT) values to be used with the TOKEN packet type. The registry is 1025 called the SMT Values for TOKEN Packet Type Registry. This registry 1026 is to be managed by the IANA according to the IETF Review policy of 1027 [RFC5226]. 1029 The length of the SMT field is five bits, allowing 32 values. The 1030 registry is initialized with the following entries: 1032 Value Name Reference 1033 ----- -------------------------------------------------- ------------- 1034 0 Reserved [RFCXXXX] 1035 1 Port Mapping Request [RFCXXXX] 1036 2 Port Mapping Response [RFCXXXX] 1037 3 Token Verification Request [RFCXXXX] 1038 4 Token Verification Failure [RFCXXXX] 1039 5-30 Unassigned IETF Review 1040 31 Reserved [RFCXXXX] 1042 The SMT values 0 and 31 are reserved for future use. 1044 10.4. RAMS Response Code Space Registry 1046 This document adds the following entry to the RAMS Response Code 1047 Space Registry. 1049 Code Description Reference 1050 ----- -------------------------------------------------- ------------- 1051 405 Invalid Token [RFCXXXX] 1053 This response code is used when the Token included by the RTP_Rx in 1054 the RAMS-R message is invalid. 1056 11. Acknowledgments 1058 The approach presented in this document came out after discussions 1059 with various individuals in the AVT and MMUSIC WGs, and the breakout 1060 session held in the Anaheim meeting. We thank each of these 1061 individuals, in particular to Magnus Westerlund and Colin Perkins. 1063 12. References 1065 12.1. Normative References 1067 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1068 Jacobson, "RTP: A Transport Protocol for Real-Time 1069 Applications", STD 64, RFC 3550, July 2003. 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, March 1997. 1074 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1075 Description Protocol", RFC 4566, July 2006. 1077 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1078 "Extended RTP Profile for Real-time Transport Control 1079 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1080 July 2006. 1082 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1083 Protocol (RTCP) Extensions for Single-Source Multicast 1084 Sessions with Unicast Feedback", RFC 5760, February 2010. 1086 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1087 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1089 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1090 Requirements for Security", BCP 106, RFC 4086, June 2005. 1092 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1093 Time Protocol Version 4: Protocol and Algorithms 1094 Specification", RFC 5905, June 2010. 1096 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1097 Hashing for Message Authentication", RFC 2104, 1098 February 1997. 1100 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1101 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1103 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1104 Control Packets on a Single Port", RFC 5761, April 2010. 1106 12.2. Informative References 1108 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1109 with Session Description Protocol (SDP)", RFC 3264, 1110 June 2002. 1112 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1113 the Session Description Protocol (SDP)", RFC 4145, 1114 September 2005. 1116 [I-D.ietf-avt-rapid-acquisition-for-rtp] 1117 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 1118 Based Rapid Acquisition of Multicast RTP Sessions", 1119 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 1120 progress), November 2010. 1122 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1123 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1124 RFC 4787, January 2007. 1126 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1127 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1128 July 2006. 1130 [I-D.ietf-avt-app-rtp-keepalive] 1131 Marjou, X. and A. Sollaud, "Application Mechanism for 1132 keeping alive the Network Address Translator (NAT) 1133 mappings associated to RTP flows.", 1134 draft-ietf-avt-app-rtp-keepalive-09 (work in progress), 1135 September 2010. 1137 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1138 Defeating Denial of Service Attacks which employ IP Source 1139 Address Spoofing", BCP 38, RFC 2827, May 2000. 1141 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1142 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1143 May 2008. 1145 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1146 "Codec Control Messages in the RTP Audio-Visual Profile 1147 with Feedback (AVPF)", RFC 5104, February 2008. 1149 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1150 RFC 5652, September 2009. 1152 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1154 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1155 Announcement Protocol", RFC 2974, October 2000. 1157 Authors' Addresses 1159 Ali Begen 1160 Cisco 1161 181 Bay Street 1162 Toronto, ON M5J 2T3 1163 Canada 1165 Email: abegen@cisco.com 1167 Dan Wing 1168 Cisco Systems, Inc. 1169 170 West Tasman Dr. 1170 San Jose, CA 95134 1171 USA 1173 Email: dwing@cisco.com 1175 Tom VanCaenegem 1176 Alcatel-Lucent 1177 Copernicuslaan 50 1178 Antwerpen, 2018 1179 Belgium 1181 Email: Tom.Van_Caenegem@alcatel-lucent.com