RFC 6284
Port Mapping between Unicast and Multicast RTP Sessions
RFC 6284: Port Mapping between Unicast and Multicast RTP Sessions 🎀
Okay bestie, let's get into RFC 6284! 💖 It's a Standards Track doc about port mapping between unicast and multicast RTP sessions, and it's giving practical, clever, and very pro.
Here's the title block tea ☕:
- Request for Comments:
6284 - Authors: A. Begen (Cisco), D. Wing (Cisco), T. Van Caenegem (Alcatel-Lucent)
- Category: Standards Track
- ISSN:
2070-1721 - Date: June 2011
- The title block doesn't list anything this RFC obsoletes or updates.
Abstract ✨
Okay so this doc presents a port mapping solution that lets RTP receivers pick their own ports for an auxiliary unicast session in RTP apps that use both unicast and multicast services. 🦋 It also protects against denial-of-service or packet amplification attacks that could be used to make one or more RTP packets get sent to a victim client. Iconic protection energy 🛡️💅
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741 🌸
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6284.
Copyright Notice ©️
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please read these carefully, bestie, because they describe your rights and restrictions for this document. 🫶 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 5
3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6
3.2. Normative Behavior and Requirements . . . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
4.3. Token Verification Request . . . . . . . . . . . . . . . . 15
4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17
5. Procedures for Token Construction . . . . . . . . . . . . . . 18
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 20
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. The 'portmapping-req' Attribute . . . . . . . . . . . . . 21
7.1.1. ABNF Definition of 'portmapping-req' . . . . . . . . . 21
7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 22
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 23
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. The 'portmapping-req' Attribute . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26
10.2. Registration of RTCP Control Packet Types . . . . . . . . 27
10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 27
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 291. Introduction 🦋
Okay so in (any-source or source-specific) multicast RTP apps, the destination ports (aka the ports where multicast receivers get their RTP and RTP Control Protocol (RTCP) packets) are defined declaratively. 📋 That means receivers can't choose their receive ports, and the sender(s) just use the predefined ones. Not very flexible, ngl 🙈
Unicast RTP apps are different. The receiving end has to choose its ports for RTP and RTCP, because those ports are local resources and only the receiving end knows which ports are free 🧚 On top of that, Network Address Port Translation (NAPT, hereafter simply called NAT) devices are commonly deployed in networks, so static port assignments can't be used. 🚫
The receiving end can tell the sending end what it wants in different ways. One of them is the Offer/Answer Model [RFC3264] for the Session Description Protocol (SDP) [RFC4566]. However, the Offer/Answer Model needs offer/answer exchange(s) between the endpoints, and that delay may not be desirable in delay-sensitive real-time apps. ⏳ It can also be burdensome for endpoints that are running a large number of unicast sessions with other endpoints at the same time. 😩
In this spec, we look at an RTP app that uses one or more unicast and multicast RTP sessions together. 💞 Declaring and choosing ports is well defined and works well for multicast and unicast RTP apps, respectively. But the usage of the ports gets messy when a receiving end mixes unicast and multicast RTP sessions inside the same RTP app. Main character problem, honestly 💅
Here's an example. The RTP packets are distributed through source-specific multicast (SSM) [RFC4607]. A receiver sends unicast RTCP NACK feedback [RFC4585] to a local repair server (which also works as a unicast RTCP feedback target) [RFC5760], asking for a retransmission of the packets it's missing. The local repair server then sends those retransmission packets over a unicast RTP session [RETRANSMISSION-FOR-SSM]. Iconic teamwork 🤝
Another scenario: a receiver wants to rapidly get a new primary multicast RTP session. It receives one or more RTP burst packets over a unicast session before joining the SSM session. See [RFC6285] for Rapid Acquisition of Multicast RTP Sessions (RAMS). ⚡ Similar scenarios exist in apps where some content is distributed through multicast, while receivers get additional and/or auxiliary content through one or more unicast connections, as shown in Figure 1. 🌈
In this document, we talk about this problem and introduce a solution we call port mapping. 🎀 It lets receivers choose their desired UDP ports for RTP and RTCP in every unicast session when they're running RTP apps that use both unicast and multicast services, and when offer/answer exchange isn't available. The solution includes a Token-based protection mechanism against denial-of-service (DoS) or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. 🛡️ This solution doesn't apply when TCP is the transport protocol in the unicast sessions. For those scenarios, check out [RFC4145]. 🫶
-----------
| Unicast |................
| Source |............. :
| (Server) | : :
----------- : :
v v
----------- ---------- -----------
| Multicast |------->| Router |---------->|Client RTP |
| Source | | |..........>|Application|
----------- ---------- -----------
| :
| : -----------
| :..............>|Client RTP |
+---------------->|Application|
-----------
-------> Multicast RTP Flow
.......> Unicast RTP Flow
Figure 1: RTP Applications Simultaneously Using Both Unicast and
Multicast ServicesFor the rest of this doc, we call the RTP endpoints that serve other RTP endpoints over a unicast session the Servers. The receiving RTP endpoints are called Clients. ✨ This terminology also reflects the fact that when port mapping is used, RTP packets can only flow in one direction (from the server to the client) in the unicast sessions. ➡️
2. Requirements Notation 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 💜
That's the end of this part, bestie. Keep reading for the next chunk! 🧚
3. Token-Based Port Mapping ✨
okay so token-based port mapping is giving "the server hands the client a Token so it can set up a unicast session, and nobody can sneak in and redirect traffic onto some poor unsuspecting third party to start a DoS attack" 💅 The Token is basically an opaque little package built from three things: the client's IP address (as the server sees it), a time-to-live value, and a random nonce the client brings along 🎀
This whole thing happens in two steps: (i) Token request and retrieval, and (ii) unicast session establishment 🦋
When a Token request shows up, the server makes a Token for that one specific client and sends it right back 💌
Once a client has a Token from a particular server, it can use that Token for every unicast session it runs with that server until the Token expires. By default, Tokens are server specific 🌸 BUT the client can use the same Token to talk to different servers, as long as those servers share the same secret key and the same algorithm used to make the Token, and they are at least loosely clock-synchronized 🧚
The Token goes invalid if the client's IP address (as seen by the server) changes, or if the server expires it. (Heads up: the client might not be able to notice the IP change in time 🙈) When that happens, the client has to request a new Token 🔄
Okay, step two is where the magic happens ✨ When the client wants to establish a unicast session, it includes the Token with its RTCP feedback message. The server validates the Token and makes sure the IP address info matches. This is seriously effective against DoS attacks 🛡️ For example, an attacker can't just spoof another client's IP address and start a unicast transmission toward random clients. If validation passes, the unicast session gets established 🎉 If it doesn't, the server tells the client that validation failed, and the unicast session will not be established 💀
Once validation passes and the unicast session is up, all the RTP and RTCP rules in [RFC3550] and other relevant specifications also apply for the rest of that session, until it's terminated 🫶 During the lifetime of a unicast session, a client might need to send RTCP messages that require authorization. Those messages need a valid Token to be authorized, so the client has to include the Token along with them. Later sections of this document explain all the details 📖
Below, we first present a motivating scenario for port mapping, and then we describe the normative behavior and requirements 👑
3.1. Motivating Scenario
Picture an SSM distribution network where a distribution source multicasts RTP packets to a huge number of clients. One or more retransmission servers act as feedback targets to collect unicast RTCP feedback from those clients [RFC5760]. The retransmission servers also join the multicast session so they can receive the multicast packets and cache them for a certain time period 📦 When a client notices missing packets in the multicast session, it asks one of the retransmission servers for a retransmission by sending an RTCP NACK message [RFC4585]. The retransmission server pulls the requested packet(s) out of the cache and retransmits them to the requesting client [RETRANSMISSION-FOR-SSM] 🔁
The RTP and RTCP flows for this scenario are shown in Figure 2 🗺️ We assume there's at least one NAT device between the client and the server [RFC4787]. (If there are no NAT devices between the server and client, the method still works the exact same way 🙌) The multicast and unicast sessions are clearly identified by their own RTP and RTCP flows and port numbers 🌈
-------------- --- ----------
| |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | |
| Distribution | ---------------- | | | |
| Source | | | | | | |
| |---->|P1 | | | | |
| |.-.->|P2 | | | | |
| | | | | | | |
-------------- | P3|<.=.=.=.| |=.=|*c0 |
| P3|<~~~~~~~| |~~~|*c1 |
MULTICAST RTP | | | | | |
SESSION with | | | N | | |
UNICAST FEEDBACK | | | A | | |
| Retransmission | | T | | Client |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| Server | | | | |
| | | | | |
PORT MAPPING | PT|<~~~~~~~| |~~>|*cT |
| | | | | |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| | | | | |
AUXILIARY UNICAST | | | | | |
RTP SESSION | | | | | |
| P3|........| |..>|*c1 |
| P3|=.=.=.=.| |=.>|*c1 |
| P4|<.=.=.=.| |=.=|*c2 |
| | | | | |
---------------- --- ---------- -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP (Feedback) Messages
.......> Unicast RTP Flow
Figure 2: Example Scenario Showing an SSM Distribution with Support
for Retransmissions from a ServerIn Figure 2, we've got the following multicast and unicast ports 👀
- Ports P1 and P2 are the destination RTP and RTCP ports in the multicast session. The clients listen on these ports to receive the multicast RTP and RTCP packets 📻 Ports P1 and P2 are defined declaratively 📝
- Port P3 is the RTCP port on the feedback target running on the retransmission server. It collects any RTCP packet sent by the clients, including feedback messages and RTCP receiver and extended reports 📥 This is also the port the retransmission server uses to send the RTP packets and RTCP sender reports in the unicast session 📤 Port P3 is defined declaratively 📝
- Port P4 is the RTCP port on the retransmission server used to collect the RTCP receiver and extended reports for the unicast session 🗂️ Port P4 is defined declaratively 📝
- Ports
*c0,*c1, and*c2are chosen by the client. (Note:*means the port can be chosen randomly. Once it's chosen, the*is no longer used 🎲)*c0is the port on the client used to send the RTCP reports for the multicast session.*c1is the port on the client used to send the unicast RTCP feedback messages in the multicast session, and to receive the RTP packets and RTCP sender reports in the unicast session.*c2is the port on the client used to send the RTCP receiver and extended reports in the unicast session 💫 Ports c0, c1, and c2 could be the same port or different ports. There are two advantages to using the same port for both c0 and c1 🤩- Some NATs only keep bindings active when a packet goes from the inside to the outside of the NAT (see REQ-6 of Section 4.3 of [RFC4787]). When the gap between packets sent from the client to the server is long, it can go past the timeout limit 😬 If c0=c1, the occasional (periodic) RTCP receiver reports sent from port c0 (for the multicast session's RTCP port P3) keep the NAT from timing out the public port associated with the incoming unicast traffic to port c1 🙌
- Having c0=c1 conserves NAT port bindings 💅
- Ports PT and
*cTare the ports used for the Token request and retrieval on the server and client sides, respectively. Port PT is declared on a per-unicast-session basis, although the same port could be used for two or more unicast sessions sourced by the server 📍 A Token that a client requested and retrieved from port PT stays valid until its expiration time ⏳
We assume the information that's declaratively defined is available as part of the session description information and is provided to the clients 📋 The Session Description Protocol (SDP) [RFC4566] and other session description methods can be used for this purpose 🦋
3.2. Normative Behavior and Requirements ✨
okay so this part is where we get into the rules 🎀 the normative stuff. to keep things simple, we're gonna talk about the port numbers from the example in Figure 2, but literally everything here works for any setup where you can spot analogous ports 🦋
first things first, a client that follows this spec MUST be able to include a Token with any type of RTCP message (as described below) when it's needed 💖
second, this solution is NOT it if there's RTP traffic going from the client to the server in the unicast session. the direction of RTP traffic MUST be only from the server to the client in the unicast session 🙈 if the client wants to send RTP back to the server, it has to use the regular session establishment methods, like [RFC3264] 💅
here's the Token-based solution in steps (it's giving recipe energy 🍓):
- the client figures out the server address and port numbers (
P3,P4andPT) from the session description.P4MUST be different fromP3.PTMAY be equal toP3🌸 - the client picks its local port numbers (
*c0,*c1,*c2and*cT). it is strongly RECOMMENDED that the client uses the same port forc0andc1.cTMAY be equal toc0andc1✨ - if the client doesn't have a Token (or its Token has expired):
- A. the client first sends a Port Mapping Request message (Section 4.1) to port
PT. this message is sent from portcTon the client side. the server learns the client's IP address from the message it receives. the client can send this message anytime it wants (e.g., during initialization) and doesn't normally ever need to resend it (see Section 6) 🧚 - B. the server makes an opaque encapsulation (aka the Token) based on certain info, including the client's IP address 🔮
- C. the server sends the Token back to the client in a Port Mapping Response message (Section 4.2). this message MUST be sent from port
PTtowards portcT💜
- A. the client first sends a Port Mapping Request message (Section 4.1) to port
- the client needs to give the Token to the server using a Token Verification Request message (Section 4.3) whenever it sends an RTCP feedback message for triggering or controlling a unicast session (see Section 4.3.1) 🫶. if the Token is invalid or missing, the server sends a Token Verification Failure message (Section 4.4) to the client 💀
ngl this part is important: the unicast session only gets established after the server has received a feedback message (along with a valid Token) from the client that it needs to react to by sending unicast data 🔥. until then, neither the server nor the client needs to send RTCP reports for the unicast session 😌
- normal flows kick in as shown in Figure 2 🦋. it is strongly RECOMMENDED that the client uses the same port for both
c0andc1, because this makes the periodic RTCP reports keep the NAT mapping alive 🌈. BUT if the client uses different ports forc0andc1, the client MUST keep its own NAT mapping alive for theP3->c1session (see [RFC6263] for more info) 👑
in the unicast session, traffic from the server to the client (so both the RTP and RTCP packets sent from port P3 towards port c1) MUST be multiplexed on the same port [RFC5761] 🎀
the client sends the RTCP receiver and extended reports in the unicast session from port c2 towards port P4. the server correlates these reports with the ones it got in the multicast session based on the client's RTCP Canonical Name (CNAME) 🔍. so the client MUST use the same RTCP CNAME in both sessions, and its RTCP CNAME MUST be unique [RFC6222] 🫧
a unicast session on a particular receive port c1 can last as long as the associated multicast session lasts 🕰️. BUT a client can't keep using the same receive port c1 for different unicast sessions one after another, because packets could leak when switching between sessions. the exception is if each received unicast stream has its own distinct Synchronization Source (SSRC) identifier so the client can filter out the unwanted packets 🙅♀️. unless that's guaranteed (which is not often easy), a client SHOULD use separate receive ports for subsequent unicast sessions. after a sufficient time (two minutes is RECOMMENDED, similar to one TCP Maximum Segment Lifetime from [RFC0793]), a previously used receive port can be used again ⏳
the unicast session can be explicitly terminated by the procedures of an application or extension that uses the port mapping approach from this document 🛑. there's also a backup way to end it: everyone times out based on the rules of [RFC3550]. both the server and client periodically check if the other peer is still alive, and if there's no RTCP traffic from the other peer for a certain amount of time (Section 6.3.5 of [RFC3550] suggests five RTCP reporting intervals), the unicast session SHOULD be considered terminated, and no more RTP and/or RTCP packets SHOULD be sent in that session 🥀. the client can try to set up a new unicast session if it needs to. if there's no explicit termination procedure, the client MAY stop sending RTCP to the server to end the session. however, the server SHALL NOT stop sending RTCP until the unicast session is terminated 🧊. and if Token-based authentication is also allowed in the unicast session (so in the RTCP messages sent from portc2towards portP4), the client SHOULD terminate the unicast session by sending an RTCP BYE message for each SSRC it used in that session 👋
4. Message Formats 🎀
this section defines the formats of the RTCP messages that a server and a client swap for port mapping 💌. a brand-new RTCP control packet type is introduced, and four port mapping messages use it:
- Port Mapping Request
- Port Mapping Response
- Token Verification Request
- Token Verification Failure
every message has a fixed-length field for version (V), padding (P), sub-message type (SMT), packet type (PT), length, and the SSRC of the packet sender 🧾. messages have other fields too, as defined below. in ALL the messages in this section, the PT field is set to TOKEN (210) 🏷️. each individual message is identified by the SMT field. the length field tells you the message size in 32-bit words minus one, including the header and any padding. this matches how the Length field works in RTCP sender and receiver reports ✨. and in every message, any Reserved field SHALL be set to zero and ignored 🙃
following the rules in [RFC3550], all integer fields in the messages below are sent in network-byte order, which is most significant byte (octet) first, aka big-endian 🌊. unless it says otherwise, numeric constants are in decimal (base 10) 🔢
okay real talk: RTCP is not a timely or reliable protocol 😭. RTCP packets might get lost or reordered on the way, and it's not easy to notice when that happens. when you send a new Port Mapping Request message, the scheduling rules for sending initial RTCP messages [RFC4585] apply 📅. if a client sends a Port Mapping Request or Token Verification Request message but doesn't get a response back from the server (either a Port Mapping Response or a Token Verification Failure message), it MAY resend its request by following the timer rules for RTCP feedback messages in Section 3.5 of [RFC4585], as a good practice 🔁. BUT implementations are advised to avoid sending spurious RTCP messages just because the timer rules (based on some RTCP configuration parameters) allow it 🙅♀️. reasonably safe practices should be used to detect RTCP message loss 🛡️. when you send an RTCP (feedback) message bundled with a Token Verification Request message, the timer rules of [RFC4585] apply as usual 🫶
4.1. Port Mapping Request 💖
the Port Mapping Request message is identified by SMT=1 🆔. the client transmits this message to a dedicated server port (and possibly a dedicated address) to ask for a Token 🎟️. in this message, the packet sender's SSRC is set to the client's SSRC, which the client picks randomly ✨. the packet format looks like Figure 3:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=1 | PT=TOKEN | Length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Packet Format for the Port Mapping Request Message
- Random Nonce (64 bits): a field with a random value that the client generates following the procedures of [RFC4086] 🎲. the server takes this nonce into account when it makes a Token for the client, which gives better security for clients that share the same IP address (those clients need to produce a random value that's extremely unlikely to collide with other clients sharing that IP address) 🔐. if the same Port Mapping Request message is sent multiple times for redundancy reasons, the random nonce value MUST remain the same in those duplicated messages 🔁. however, the client MUST generate a new random nonce for every new Port Mapping Request message 🌟
4.2. Port Mapping Response 💌
Okay bestie, this is the Port Mapping Response 🎀, identified by SMT=2. The server sends it to the client as the reply to a Port Mapping Request, and it's how the Token actually gets delivered to the client 🫶. In this message the packet sender's SSRC is set to the server's SSRC ✨. Here's the packet format, which is giving structure 💅:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=2 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Packet Types Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Packet Format for the Port Mapping Response Message
Now let's break down the fields 🔍:
- SSRC of Requesting Client (32 bits): the SSRC of the client who sent the request 🧚.
- Associated Nonce (64 bits): the nonce that came in the Port Mapping Request message and got used when building the Token 🔐.
- Token Element (variable size): this is where the server's Token rides along 🚗. It's a 32-bit aligned Length-Value element. The Length field is 16 bits and tells you how many octets are in the Value field that comes right after it. A 16-bit length can handle Tokens up to 65535 bytes, BUT making the RTCP compound packet bigger than the MTU can hurt functionality because of IP fragmentation 😭. Some NATs or other middleboxes don't pass IP fragments, so one chunky Token can break the whole mechanism 💀. Fragmentation also ups the risk of packet loss, so keep it chill 🌸.
The Length doesn't count any alignment padding. The Value field carries the Token (or really, the output of the server's encoding process) 🎀. If the Token element doesn't land on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero 🫧.
- Absolute Expiration Time (64 bits): the Token's absolute expiration time 🕰️, written as a Network Time Protocol (NTP) timestamp in seconds since the year 1900 [RFC5905]. The client doesn't need to use this directly, so it doesn't have to sync its clock with the server 🙈. BUT it does need to send this value back to the server, along with the associated nonce, in the Token Verification Request message, so it has to keep it tied to the Token 🔗.
- Relative Expiration Time (32 bits): the Token's relative expiration time, in seconds counted from when the Token was generated ⏳. If the server decides NOT to grant a Token to a requesting client, this gets set to zero, which means the accompanying Token is invalid 🥀.
The server sends the relative expiration time in the clear so the client can ask for a fresh Token well before the old one expires 🦋.
- Packet Types Element (variable size): this one signals which RTCP packet types need Token-based authentication 🔥. It's another 32-bit aligned Length-Value element. This time the Length field is 8 bits and tells you the octet count of the Value field after it, and it also doesn't include alignment padding. The Value field holds zero or more 8-bit sub-fields, each one an RTCP packet type 🍓. If the Packet Types element doesn't sit on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero 🧸. Here's an example Packet Types element 👀:
A server MAY change its policy on which RTCP packet types need Token-based authentication, based on observations, configuration, or other policies 🌈. BUT when it does that, the server SHALL NOT send a new Port Mapping Response message to the clients who asked for a Token earlier 😤. The client finds out about the change when and if it gets a Token Verification Failure message 💜.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length=4 | 205 | 206 | 203 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 204 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Example Packet Types Element
4.3. Token Verification Request 🛂
The Token Verification Request message is identified by SMT=3 🦄. It carries the Token and rides along with any RTCP message that would trigger a new unicast session or control an existing one. For a list of those messages, check out Section 4.3.1 📋.
In the Token Verification Request message, the packet sender's SSRC is set to the client's SSRC 🎀. The client MUST NOT send a Token Verification Request message with a Token that has expired ❌. Here's the packet format 💖:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=3 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Packet Format for the Token Verification Request Message
- Associated Nonce (64 bits): the nonce tied to the Token 🔑.
- Token Element (variable size): the Token element you got earlier in the Port Mapping Response message 📨.
- Associated Absolute Expiration Time (64 bits): the absolute expiration time that goes with the Token above ⏰.
4.3.1. Where to Include Token 🧭
This section gives you guidelines on which RTCP packet types would need to be accompanied by a Token Verification Request message 🗺️. BUT, since a server might figure out in real time that other RTCP messages also need authenticating with a Token, a client MUST act according to the up-to-date list it got in the Port Mapping Response message (in the Packet Types element) 📜. Clients need to support Token-based authentication with any RTCP message that's necessary (see Section 3.2) 💪.
As a general rule, when the Token capability is declared in the session description, the RTCP messages that trigger transmission of RTP packets in a port mapped unicast session are REQUIRED to be authenticated by using a Token 🚨. Those messages include, but aren't limited to 👑:
Additionally, some RTCP messages might directly or indirectly control an existing unicast session associated with a multicast session 🌊. Unless another authentication method, as described in their respective specifications, is used, implementations MUST support authenticating such RTCP messages by using a Token 🛡️. Examples are 💅:
- BYE messages [RFC3550] 👋
- RAMS Termination (RAMS-T) messages [RFC6285] 🛑
- Codec Control Messages (CCMs) [RFC5104] 🎥
Note that even if a packet type is listed as requiring Token-based authentication, it doesn't need to be authenticated when it doesn't control the unicast session 🙃. For example, if BYE (203) is listed in the Port Mapping Response message as one of the packet types that requires authentication, the client doesn't need to bundle the RTCP BYE message with a Token when it's sending it for the multicast session ✨.
The Token Verification Request message might also be bundled with packets carrying RTCP receiver and/or extended reports 📊. Those packets don't carry a strong security impact, BUT a specific application might want a more controlled reporting scheme from the clients 🧁. In that case, the server lists the packet types for the receiver (201) and/or extended reports (207) in the Port Mapping Response message 🌷.
4.4. Token Verification Failure 💔
okay so the Token Verification Failure message is identified by SMT=4 🫶 the server sends it to the client to say the Token was invalid, OR the client skipped the Token Verification Request message in its RTCP packet even though it needed to send one. it goes from port P3 back to port c1 💌 here's the packet layout:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=4 | PT=TOKEN | Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed PT | FMT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Packet Format for the Token Verification Failure Message
here's the breakdown, bestie 🎀
SSRC of Packet Sender: this is the server's SSRC, which equals the SSRC of the respective multicast stream 🦋 lowkey important: this SSRC lives in a different SSRC space than the one used in the unicast session.SSRC of Requesting Client(32 bits): the field holding the client's SSRC 💜Failed PT(8 bits): tells you what type of RTCP packet caused the failure 😭FMT(5 bits): the feedback message type (FMT) of the RTCP packet that caused the failure 🔥 together withFailed PT, the client can figure out which RTCP message it sent that got this failure message sent back. for example, if the client didn't include a valid Token with an RTCP NACK message,Failed PTwill show205(RTPFB) andFMTwill show1(Generic NACK) 🙈 if the RTCP message had no associated FMT value (like an RTCP BYE message), theFMTfield SHALL be set to zero 💅Associated Nonce(64 bits): holds the nonce from the Token Verification Request message 🧚 if the client didn't include a Token Verification Request message, this field is set to zero ✨
5. Procedures for Token Construction 🔐
the Token encoding is known to the server but opaque to the client 👑 implementations MUST encode the following info into the Token as a minimum, so it's actually secure:
- Client's IP address as seen by the server (32/128 bits for IPv4/IPv6 addresses) 🌸
- The nonce generated and inserted in the Port Mapping Request message by the client (64 bits) 💖
- The absolute expiration time chosen by the server, indicated as an NTP timestamp value in seconds since the year 1900 [RFC5905] (64 bits, to protect against replay attacks) 😤
the RECOMMENDED way to build Tokens is HMAC-SHA1 [RFC2104] over the concatenated values above (implementations might do it differently tho 🫠). if you use HMAC-SHA1, the Hashed Message Authentication Code (HMAC) key MUST be at least 160 bits long and generated with a cryptographically secure random source [RFC4086] 🔑
you're also encouraged to encode whatever extra info is useful 🌈 like, key rollover gets way easier if you encode a key-id into the Token. a cluster of anycast servers could also benefit from encoding a server identifier 🧚♀️ and HMAC-SHA1 is widely regarded as more than sufficient for message authentication and is secure against all known cryptanalytic attacks that are economically feasible right now, BUT if HMAC-SHA1 ever gets compromised, a replacement like HMAC-SHA256 could be used instead 🛡️
to protect from offline attacks, the server SHOULD occasionally pick a new HMAC key 🔄 to make that easier, you can assign a key-id to each key. it can be as simple as one bit (new key is X, e.g., 1, and old key is the inverted value of X, e.g., 0) 🦋 or, if you're running several keys at once, the key-id can span several bits. the Token encoding is totally private to the server, so any encoding works 💅 bonus: by encoding the key-id into the Token, the server can reject an old key WITHOUT doing HMAC validation, which saves CPU cycles 🧠 the key-id goes into the Value field of the Token element by just concatenating the (plaintext) key-id with the hashed info (i.e., the Token itself) ✨
here's how the Value field in the Token element can be computed:
key-id || mac-alg (client-ip | nonce | abs-expiration)during Token construction, the expiration time has to be picked carefully based on the intended service duration ⏰ Tokens that are valid for an unnecessarily long time (e.g., several hours) might create security risks 💀 so the server needs a reasonable value based on the app and use case. shorter lifetimes mean clients have to grab Tokens more often, BUT since a client can get a new Token well before it needs it, it won't necessarily be penalized for the acquisition delay 🫶
last but not least: NTP timestamps will wrap around in the year 2036 😱 see Section 6 of [RFC5905] for the deets.
6. Validating Tokens 🕵️♀️
the server MUST validate the Token when it gets an RTCP feedback message along with the Token Verification Request message that has a Token, nonce, and absolute expiration time 🔍
the server first runs its own Token construction procedure, using the client's IP address from the received Token Verification Request message and the nonce and absolute expiration time values in that same message. then it compares the output with the Token the client sent. if they match AND the absolute expiration time hasn't passed yet, the server declares the Token valid ✅
heads up: if the client's IP address changes, the Token won't validate 🙈 same deal if the client puts in a wrong nonce or absolute expiration time value, validation fails. the server might also want to expire a Token early 🫠 in all of these cases, the server MUST reply to the client with a Token Verification Failure message (going from port P3 on the server to port c1 on the client) 💌
on top of the Token Verification Failure message, it is RECOMMENDED that apps define an app-specific error response the server sends when it detects an invalid Token 🎀 for apps using [RFC6285], this document defines a new 4xx-level response code in the RAMS Response Code Space Registry ✨ and a client that gets a Token Verification Failure message can ask the server for a new Token 🔁
⚠️ the retry logic, bestie: if a client gets a Port Mapping Response message with an invalid Token (the relative expiration time is set to zero) two or more times for a particular Port Mapping Request message, OR gets a Token Verification Failure message two or more times for the same Token Verification Request message, the client SHOULD do the following:
- Check whether or not the session description has been updated. if it was, act according to the new session description 📝
- Exponentially back off for the third and subsequent attempts. exponential back-off does NOT apply when the client sends a Port Mapping Request or Token Verification Request message to a new address and/or port 🦋
7. SDP Signaling 📻
7.1. The 'portmapping-req' Attribute 💜
this attribute is used declaratively in any media block that describes an RTP session that uses Token-based authentication for one or more RTCP messages related to that session 💖 it tells you the port and, optionally, the address for getting a Token.
the presence of the 'portmapping-req' attribute means that (i) a Token MUST be included in certain RTCP messages sent to the server that trigger or control a unicast session (see Section 4.3.1), AND (ii) the client MUST receive the unicast session's RTP and RTCP packets from the server on the port it sent the RTCP message from that triggered the unicast session 🎯
Note: This does not imply that Token Verification Request messages always need to be sent in the unicast session. Token Verification Request messages accompany RTCP messages that trigger or control this unicast session and are sent either in the multicast session or the unicast session, depending on the RTCP message (see Section 4.3.1). 🫶
7.1.1. ABNF Definition of 'portmapping-req' 🧩
the formal description of the 'portmapping-req' attribute is defined by the following ABNF [RFC5234] syntax 🔤
portmapping-req-attr = "a=portmapping-req:" port [SP nettype SP
addrtype SP connection-address] CRLFhere, 'port', 'nettype', 'addrtype', and 'connection-address' are defined as specified in Section 9 of [RFC4566] ✨
the 'portmapping-req' attribute SHALL only be used as a media-level attribute 📍
in the optional address value, only unicast addresses SHOULD be used, unless you want to use a multicast address after weighing the extra security risks, like non-legit servers generating fake Tokens 😬 if the address isn't specified, the (source) address in the "c" line applicable to the media description SHALL be used 💅
7.1.2. Offer/Answer Model Considerations 🤝
when using the 'portmapping-req' attribute in SDP offer/answer exchanges [RFC3264], these considerations apply 📋 when an offerer sends an answerer an offer of an SDP description that uses the Token approach from this spec, the 'portmapping-req' attribute is included declaratively. there won't be any offer/answer exchanges between the answerer and the actual server providing the unicast service(s) 🙅♀️
when the answerer supports the Token approach, it MUST echo the 'portmapping-req' attribute from the offer back in its answer, including the same port number and address (if any) 🔁 if the answerer doesn't implement this spec, it follows normal SDP parsing of unknown attributes (they're ignored and NOT sent in the answer). this means the answerer can still join the multicast session, but it won't be able to use the unicast service(s) that require Tokens 🥺
7.2. Requirements ✨
okay so bestie, the SDP port mapping solution has to support a few things, no exceptions 💅
- The SDP grouping framework and flow identification (FID) semantics [RFC5888] 🎀
- The RTP/Audio-Visual Profile with Feedback (AVPF) profile [RFC4585] 🦋
- The 'rtcp-mux' attribute (to multiplex RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761]) 🌸
7.3. Example and Discussion 🧚
okay this is the example I'm obsessed with. It's the SDP for the scenario in Figure 2, so let's look at it together 👀
v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1
a=rtpmap:98 MP2T/90000
a=multicast-rtcp:41500 ; Note 1
a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2
a=rtcp-fb:98 nack ; Note 2
a=portmapping-req:30000 IN IP4 192.0.2.1 ; Note 3
a=mid:1
m=video 42000 RTP/AVPF 99 ; Note 4
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux ; Note 5
a=rtcp:42500 ; Note 6
a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30001 ; Note 3
a=mid:2 Figure 8: SDP Describing an SSM Distribution with Support for
Retransmissions from a Local Serverso here's what each note is saying, step by step 🫶
Note 1: The source stream is multicast from a distribution source with a source IP address of 198.51.100.1 to the multicast destination address of 233.252.0.2 and port 41000 (P1). The associated RTCP packets are multicast in the same group to port 41500 (P2). 📡
Note 2: A retransmission server including feedback target functionality with an IP address of 192.0.2.1 and port of 42000 (P3) is specified with the 'rtcp' attribute. The feedback functionality is enabled for the RTP stream with payload type 98 through the 'rtcp-fb' attribute [RFC4585]. 🔁
Note 3: The "a=portmapping-req" line indicates that one or more RTCP messages relating to the RTP session described in this media block uses Token-based authentication, and a Token needs to be retrieved first from the designated port (PT) before the unicast session can be established. In the first appearance, an explicit address is provided. In the second appearance, there is no address indicated in this line and the client needs to send the Token request to the address specified in the "c" line in the unicast media block. 🎟️
Note 4: The port specified in the second "m" line (for the unicast stream) does not mean anything in this scenario as the client does not send any RTP traffic back to the server. 🙈
Note 5: The server multiplexes RTP and RTCP packets sent towards c1 on the same port. 🍓
Note 6: The server uses port 42500 (P4) for the unicast session. 💜
8. Address Pooling NATs 🌈
okay so large-scale NAT devices have a whole pool of public IPv4 addresses, and they map internal hosts onto one of those 💅 As long as an internal host keeps an active mapping in the NAT, the same IPv4 address gets handed out to new connections. BUT once all of the host's mappings have been deleted (e.g., because of timeout), a new connection from that same host might get a different IPv4 address from the pool. 😭 When that happens, the server considers the Token invalid, and the client has to make an extra round trip to get a fresh Token.
Any traffic from the host that goes through the NAT stops this from happening. The host sends RTCP receiver reports at least every 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it's receiving, and those RTCP messages are enough to prevent this problem. 🦋
9. Security Considerations 🔥
okay this section is SERIOUS, bestie. Read every word 🫣
9.1. Tokens 🔐
The Token, which is generated based on a client's IP address and expiration date, gives protection against off-path denial-of-service (DoS) attacks. An attacker using a certain IP address cannot cause one or more RTP packets to be sent to a victim client who has a different IP address. However, if the attacker acquires a valid Token for a victim and can spoof the victim's source address, this approach becomes vulnerable to replay attacks. This is especially easy if the attacker and victim are behind a large-scale NAT and share the same IP address. 💀
Multicast is deployed on managed networks, not the Internet. These managed networks will choose whether or not to enable network ingress filtering [RFC2827]. If ingress filtering is enabled on a network, an attacker cannot spoof a victim's IP address to use a Token to initiate an attack against a victim. However, if ingress filtering is not enabled on a network, an attacker could obtain a Token and spoof the victim's address, causing traffic to flood the victim. On such a network, the server can reduce the time period for such an attack by expiring a Token in a short period of time. In the extreme case, the server can expire the Token in such a short period of time that the client will have to acquire a new Token immediately before using it in a Token Verification Request message. One should, however, note that such a behavior might have an adverse effect on the delay in establishing or controlling a unicast session. 🌧️
RTCP messages could be subject to on-path or man-in-the-middle attacks. For example, an attacker can modify a value in one or more fields in the Port Mapping Response or the Token Verification Request message that are used in Token construction. This will result in Token validation failure. Consequently, the client ends up asking the server to generate a new Token. The resulting delay and extra processing on the server is undesirable. 😤
Alternatively, the attacker can modify a value in a field that is not used in Token construction. For example, the attacker can reduce the value in the Relative Expiration Time field in the Port Mapping Response message from two hours to two minutes. While the Token will still validate, this attack will result in more frequent requests to the server for a new Token. Oppositely, the attacker can increase the value in the Relative Expiration Time field and make the client think the Token will be valid for a longer time. This attack can be only detected by monitoring the activity on the server. Note that using the relative expiration time in Token construction does not necessarily make this attack easier to detect since the attacker might revert the modified value back to its original value in the Token Verification Request message. This allows the Token to still validate on the server. In this case, the attack is still only detectable by monitoring the server activity. 🕵️
If there is a risk or concern for on-path or man-in-the-middle attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP) [RFC3711]. 🔒
To minimize the risk of cross-protocol attacks, a server MUST NOT use the same secret key it used for Token construction for other purposes. 🗝️
9.2. The 'portmapping-req' Attribute 🧾
The 'portmapping-req' attribute is not believed to introduce any significant security risk to multimedia applications. A malevolent third party could use this attribute to redirect the Port Mapping Request messages by altering the port number, or cause the unicast session establishment to fail by removing it from the SDP description. However, this requires intercepting and rewriting the packets carrying the SDP description, and if an interceptor can do that, many more attacks are possible, including a wholesale change of the addresses and port numbers at which the media will be sent. 👀
In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This can, for example, be achieved on an end-to-end basis using Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the authentication method in the Session Announcement Protocol (SAP) [RFC2974] could be used as well. 🛡️
10. IANA Considerations 📚
The following contact information is used for all registrations in this document:
Ali Begen
abegen@cisco.com10.1. Registration of SDP Attributes 🎀
This document registers one new attribute name in SDP.
SDP Attribute ("att-field"):
Attribute name: portmapping-req
Long form: Port and address for requesting Token
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: [RFC6284]
Values: See this document10.2. Registration of RTCP Control Packet Types 🌸
In accordance with Section 15 of [RFC3550], this specification adds the following value to the RTCP Control Packet types sub-registry in the Real-Time Transport Protocol (RTP) Parameters registry:
Value Abbrev. Name Reference
-------- --------- ------------------------------------- ---------
210 TOKEN Port Mapping [RFC6284]10.3. SMT Values for TOKEN Packet Type Registry 🧚♀️
This document creates a new sub-registry for the sub-message type (SMT) values to be used with the TOKEN packet type. The registry is called the SMT Values for TOKEN Packet Type Registry. This registry is managed by the IANA according to the IETF Review policy of [RFC5226].
The length of the SMT field is five bits, allowing 32 values. The registry is initialized with the following entries:
Value Name Reference
----- -------------------------------------------------- ------------
0 Reserved [RFC6284]
1 Port Mapping Request [RFC6284]
2 Port Mapping Response [RFC6284]
3 Token Verification Request [RFC6284]
4 Token Verification Failure [RFC6284]
5-30 Unassigned IETF Review
31 Reserved [RFC6284]The SMT values 0 and 31 are reserved for future use. 🔮
10.4. RAMS Response Code Space Registry 🚨
This document adds the following entry to the RAMS Response Code Space Registry.
Code Description Reference
----- -------------------------------------------------- ------------
405 Invalid Token [RFC6284]This response code is used when the Token included by the RTP_Rx in the RAMS-R message is invalid. 🙅♀️
11. Acknowledgments 🫶
The approach presented in this document came out after discussions with various individuals in the AVT and MMUSIC WGs and the breakout session held at the Anaheim meeting. We thank each of these individuals, particularly Magnus Westerlund and Colin Perkins. 👑
12. References 📖
12.1. Normative References 📚✨
okay so these are the docs the spec straight up needs you to read, bestie. no cap, you can't really get the whole picture without them 🫶
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011.12.2. Informative References 🌸
these ones are the extra reading, the "ooh tell me more" section 🧚 they're not required but they're super helpful for the full vibe
[RETRANSMISSION-FOR-SSM]
Van Caenegem, T., Ver Steeg, B., and A. Begen,
"Retransmission for Source-Specific Multicast (SSM)
Sessions", Work in Progress, May 2011.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
"Unicast-Based Rapid Acquisition of Multicast RTP
Sessions", RFC 6285, June 2011.Authors' Addresses 💌
meet the squad who wrote this spec 👑 all three of them are Cisco or Alcatel-Lucent people, so you know they're legit 💅
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com
Dan Wing
Cisco
170 West Tasman Dr.
San Jose, CA 95134
USA
EMail: dwing@cisco.com
Tom Van Caenegem
Alcatel-Lucent
Copernicuslaan 50
Antwerpen 2018
Belgium
EMail: Tom.Van_Caenegem@alcatel-lucent.com📦 where this page comes from
- ietf: rfc6284 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms