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