draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt   rfc6284.txt 
AVT A. Begen Internet Engineering Task Force (IETF) A. Begen
Internet-Draft D. Wing Request for Comments: 6284 D. Wing
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: October 17, 2011 T. VanCaenegem ISSN: 2070-1721 T. Van Caenegem
Alcatel-Lucent Alcatel-Lucent
April 15, 2011 June 2011
Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping between Unicast and Multicast RTP Sessions
draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02
Abstract Abstract
This document presents a port mapping solution that allows RTP This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services. The in RTP applications using both unicast and multicast services. The
solution provides protection against denial-of-service or packet solution provides protection against denial-of-service or packet
amplification attacks that could be used to cause one or more RTP amplification attacks that could be used to cause one or more RTP
packets to be sent to a victim client. packets to be sent to a victim client.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 17, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6284.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 5
3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 7 3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6
3.2. Normative Behavior and Requirements . . . . . . . . . . . 9 3.2. Normative Behavior and Requirements . . . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 14 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 14 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
4.3. Token Verification Request . . . . . . . . . . . . . . . . 17 4.3. Token Verification Request . . . . . . . . . . . . . . . . 15
4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 18 4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 19 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17
5. Procedures for Token Construction . . . . . . . . . . . . . . 21 5. Procedures for Token Construction . . . . . . . . . . . . . . 18
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 23 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 20
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 24 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 24 7.1. The 'portmapping-req' Attribute . . . . . . . . . . . . . 21
7.1.1. ABNF Definition of portmapping-req . . . . . . . . . . 24 7.1.1. ABNF Definition of 'portmapping-req' . . . . . . . . . 21
7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 24 7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 22
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 25 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 23
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 28 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. The portmapping and portmapping-req Attributes . . . . . . 30 9.2. The 'portmapping-req' Attribute . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 31 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26
10.2. Registration of RTCP Control Packet Types . . . . . . . . 31 10.2. Registration of RTCP Control Packet Types . . . . . . . . 27
10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 31 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 27
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 32 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
In (any-source or source-specific) multicast RTP applications, In (any-source or source-specific) multicast RTP applications,
destination ports, i.e., the ports on which the multicast receivers destination ports (i.e., the ports on which the multicast receivers
receive the RTP and RTCP packets, are defined declaratively. In receive the RTP and RTP Control Protocol (RTCP) packets) are defined
other words, the receivers cannot choose their receive ports and the declaratively. In other words, the receivers cannot choose their
sender(s) use the pre-defined ports. receive ports, and the sender(s) use the predefined ports.
In unicast RTP applications, the receiving end needs to choose its In unicast RTP applications, the receiving end needs to choose its
ports for RTP and RTCP since these ports are local resources and only ports for RTP and RTCP since these ports are local resources and only
the receiving end can determine which ports are available to use. In the receiving end can determine which ports are available to use. In
addition, Network Address Port Translators (NAPT - hereafter simply addition, Network Address Port Translation (NAPT, hereafter simply
called NAT) devices are commonly deployed in networks, thus, static called NAT) devices are commonly deployed in networks; thus, static
port assignments cannot be used. The receiving end may convey its port assignments cannot be used. The receiving end may convey its
request to the sending end through different ways, one of which is request to the sending end through different ways, one of which is
the Offer/Answer Model [RFC3264] for the Session Description Protocol the Offer/Answer Model [RFC3264] for the Session Description Protocol
(SDP) [RFC4566]. However, the Offer/Answer Model requires offer/ (SDP) [RFC4566]. However, the Offer/Answer Model requires offer/
answer exchange(s) between the endpoints, and the resulting delay may answer exchange(s) between the endpoints, and the resulting delay may
not be desirable in delay-sensitive real-time applications. not be desirable in delay-sensitive real-time applications.
Furthermore, the Offer/Answer Model may be burdensome for the Furthermore, the Offer/Answer Model may be burdensome for the
endpoints that are concurrently running a large number of unicast endpoints that are concurrently running a large number of unicast
sessions with other endpoints. sessions with other endpoints.
In this specification, we consider an RTP application that uses one In this specification, we consider an RTP application that uses one
or more unicast and multicast RTP sessions together. While the or more unicast and multicast RTP sessions together. While the
declaration and selection of the ports are well defined and work well declaration and selection of the ports are well defined and work well
for multicast and unicast RTP applications, respectively, the usage for multicast and unicast RTP applications, respectively, the usage
of the ports introduces complications when a receiving end mixes of the ports introduces complications when a receiving end mixes
unicast and multicast RTP sessions within the same RTP application. unicast and multicast RTP sessions within the same RTP application.
An example scenario is where the RTP packets are distributed through An example scenario is where the RTP packets are distributed through
source-specific multicast (SSM) [RFC4607] and a receiver sends source-specific multicast (SSM) [RFC4607] and a receiver sends
unicast RTCP NACK feedback to a local repair server (also functioning unicast RTCP NACK feedback [RFC4585] to a local repair server (also
as a unicast RTCP feedback target) [RFC5760] asking for a functioning as a unicast RTCP feedback target) [RFC5760] asking for a
retransmission of the packets it is missing, and the local repair retransmission of the packets it is missing, and the local repair
server sends the retransmission packets over a unicast RTP session server sends the retransmission packets over a unicast RTP session
[RFC4588]. [RETRANSMISSION-FOR-SSM].
Another scenario is where a receiver wants to rapidly acquire a new Another scenario is where a receiver wants to rapidly acquire a new
primary multicast RTP session and receives one or more RTP burst primary multicast RTP session and receives one or more RTP burst
packets over a unicast session before joining the SSM session packets over a unicast session before joining the SSM session; see
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in [RFC6285] regarding Rapid Acquisition of Multicast RTP Sessions
applications where some part of the content is distributed through (RAMS). Similar scenarios exist in applications where some part of
multicast while the receivers get additional and/or auxiliary content the content is distributed through multicast while the receivers get
through one or more unicast connections, as sketched in Figure 1. additional and/or auxiliary content through one or more unicast
connections, as illustrated in Figure 1.
In this document, we discuss this problem and introduce a solution In this document, we discuss this problem and introduce a solution
that we refer to as Port Mapping. This solution allows receivers to that we refer to as port mapping. This solution allows receivers to
choose their desired UDP ports for RTP and RTCP in every unicast choose their desired UDP ports for RTP and RTCP in every unicast
session when they are running RTP applications using both unicast and session when they are running RTP applications using both unicast and
multicast services, and offer/answer exchange is not available. The multicast services and offer/answer exchange is not available. The
solution includes a Token-based protection mechanism against denial- solution includes a Token-based protection mechanism against denial-
of-service (DoS) or packet amplification attacks that could be used 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 to cause one or more RTP packets to be sent to a victim client. This
solution is not applicable in cases where TCP is used as the solution is not applicable in cases where TCP is used as the
transport protocol in the unicast sessions. For such scenarios, transport protocol in the unicast sessions. For such scenarios,
refer to [RFC4145]. refer to [RFC4145].
----------- -----------
| Unicast |................ | Unicast |................
| Source |............. : | Source |............. :
skipping to change at page 4, line 33 skipping to change at page 4, line 36
----------- ---------- ----------- ----------- ---------- -----------
| : | :
| : ----------- | : -----------
| :..............>|Client RTP | | :..............>|Client RTP |
+---------------->|Application| +---------------->|Application|
----------- -----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 1: RTP applications simultaneously using both unicast and Figure 1: RTP Applications Simultaneously Using Both Unicast and
multicast services Multicast Services
In the remainder of this document, we refer to the RTP endpoints that In the remainder of this document, we refer to the RTP endpoints that
serve other RTP endpoints over a unicast session as the Servers. The serve other RTP endpoints over a unicast session as the Servers. The
receiving RTP endpoints are referred to as Clients. This terminology receiving RTP endpoints are referred to as Clients. This terminology
also reflects the fact that when port mapping is used, the RTP also reflects the fact that when port mapping is used, the RTP
packets can only flow in one direction (from the server to the packets can only flow in one direction (from the server to the
client) in the unicast sessions. client) in the unicast sessions.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Token-Based Port Mapping 3. Token-Based Port Mapping
Token-based Port Mapping consists of the server providing the client Token-based port mapping consists of the server providing the client
a Token that can be used to establish a unicast session, without the a Token that can be used to establish a unicast session without the
possibility of an attacker redirecting traffic to an unsuspecting possibility of an attacker redirecting traffic to an unsuspecting
third party to create a DoS attack. The Token is essentially an third party to create a DoS attack. The Token is essentially an
opaque encapsulation that is based on client's IP address (as seen by opaque encapsulation that is based on the client's IP address (as
the server), a time-to-live value and a random nonce provided by the seen by the server), a time-to-live value, and a random nonce
client. provided by the client.
Token-based Port Mapping consists of two steps: (i) Token request Token-based port mapping consists of two steps: (i) Token request and
and retrieval, and (ii) unicast session establishment. retrieval, and (ii) unicast session establishment.
When a Token request is received, the server creates a Token for this When a Token request is received, the server creates a Token for this
particular client, and sends it back to the client. particular client and sends it back to the client.
Once a Token is retrieved from a particular server, it can be used Once a Token is retrieved from a particular server, it can be used
for all the unicast sessions the client will be running with this for all the unicast sessions the client will be running with this
particular server till the Token expires. By default, Tokens are particular server until the Token expires. By default, Tokens are
server specific. However, the client can use the same Token to server specific. However, the client can use the same Token to
communicate with different servers if these servers are provided with communicate with different servers if these servers are provided with
the same secret key and algorithm used to generate the Token and are the same secret key and algorithm used to generate the Token and are
at least loosely clock-synchronized. at least loosely clock-synchronized.
The Token becomes invalid if client's IP address (as seen by the The Token becomes invalid if the client's IP address (as seen by the
server) changes (note that the client cannot necessarily detect this server) changes (note that the client cannot necessarily detect this
in a timely manner) or when the server expires the Token. In these in a timely manner) or if the server expires the Token. In these
cases, the client has to request a new Token. cases, the client has to request a new Token.
As the second step, when the client wants to establish a unicast As the second step, when the client wants to establish a unicast
session, the client includes the Token with its RTCP feedback session, the client includes the Token with its RTCP feedback
message. The server validates the Token, making sure that the IP message. The server validates the Token, making sure that the IP
address information matches. This is effective against DoS attacks, address information matches. This is effective against DoS attacks,
e.g., an attacker cannot simply spoof another client's IP address and e.g., an attacker cannot simply spoof another client's IP address and
start a unicast transmission towards random clients. If the start a unicast transmission towards random clients. If the
validation passes, the unicast session gets established. Otherwise, validation passes, the unicast session gets established. Otherwise,
the server notifies the client that the validation has failed, and in the server notifies the client that the validation has failed, and in
skipping to change at page 7, line 20 skipping to change at page 6, line 20
Consider an SSM distribution network where a distribution source Consider an SSM distribution network where a distribution source
multicasts RTP packets to a large number of clients, and one or more multicasts RTP packets to a large number of clients, and one or more
retransmission servers function as feedback targets to collect retransmission servers function as feedback targets to collect
unicast RTCP feedback from these clients [RFC5760]. The unicast RTCP feedback from these clients [RFC5760]. The
retransmission servers also join the multicast session to receive the retransmission servers also join the multicast session to receive the
multicast packets and cache them for a certain time period. When a multicast packets and cache them for a certain time period. When a
client detects missing packets in the multicast session, it requests client detects missing packets in the multicast session, it requests
a retransmission from one of the retransmission servers by using an a retransmission from one of the retransmission servers by using an
RTCP NACK message [RFC4585]. The retransmission server pulls the RTCP NACK message [RFC4585]. The retransmission server pulls the
requested packet(s) out of the cache and retransmits them to the requested packet(s) out of the cache and retransmits them to the
requesting client [RFC4588]. requesting client [RETRANSMISSION-FOR-SSM].
The RTP and RTCP flows pertaining to the scenario described above are The RTP and RTCP flows pertaining to the scenario described above are
sketched in Figure 2. Between the client and server, we assume there illustrated in Figure 2. Between the client and server, we assume
exists at least one NAT device [RFC4787] (If there are no NAT devices there exists at least one NAT device [RFC4787]. (If there are no NAT
between the server and client, the method still works the same devices between the server and client, the method still works in the
fashion). The multicast and unicast sessions are clearly identified same fashion.) The multicast and unicast sessions are clearly
with their individual RTP and RTCP flows and port numbers. identified with their individual RTP and RTCP flows and port numbers.
-------------- --- ---------- -------------- --- ----------
| |-------------------------------| |-->|P1 | | |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | | | | | | | |
| Distribution | ---------------- | | | | | Distribution | ---------------- | | | |
| Source | | | | | | | | Source | | | | | | |
| |---->|P1 | | | | | | |---->|P1 | | | | |
| |.-.->|P2 | | | | | | |.-.->|P2 | | | | |
| | | | | | | | | | | | | | | |
skipping to change at page 8, line 41 skipping to change at page 7, line 41
| P4|<.=.=.=.| |=.=|*c2 | | P4|<.=.=.=.| |=.=|*c2 |
| | | | | | | | | | | |
---------------- --- ---------- ---------------- --- ----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP (Feedback) Messages ~~~~~~~> Unicast RTCP (Feedback) Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 2: Example scenario showing an SSM distribution with support Figure 2: Example Scenario Showing an SSM Distribution with Support
for retransmissions from a server for Retransmissions from a Server
In Figure 2, we have the following multicast and unicast ports: In Figure 2, we have the following multicast and unicast ports:
o Ports P1 and P2 denote the destination RTP and RTCP ports in the o Ports P1 and P2 denote the destination RTP and RTCP ports in the
multicast session, respectively. The clients listen to these multicast session, respectively. The clients listen to these
ports to receive the multicast RTP and RTCP packets. Ports P1 and ports to receive the multicast RTP and RTCP packets. Ports P1 and
P2 are defined declaratively. P2 are defined declaratively.
o Port P3 denotes the RTCP port on the feedback target running on o Port P3 denotes the RTCP port on the feedback target running on
the retransmission server to collect any RTCP packet sent by the the retransmission server to collect any RTCP packet sent by the
clients including feedback messages, and RTCP receiver and clients, including feedback messages and RTCP receiver and
extended reports. This is also the port that the retransmission extended reports. This is also the port that the retransmission
server uses to send the RTP packets and RTCP sender reports in the server uses to send the RTP packets and RTCP sender reports in the
unicast session. Port P3 is defined declaratively. unicast session. Port P3 is defined declaratively.
o Port P4 denotes the RTCP port on the retransmission server used to o Port P4 denotes the RTCP port on the retransmission server used to
collect the RTCP receiver and extended reports for the unicast collect the RTCP receiver and extended reports for the unicast
session. Port P4 is defined declaratively. session. Port P4 is defined declaratively.
o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the o Ports *c0, *c1, and *c2 are chosen by the client. (Note: "*"
port on the client used to send the RTCP reports for the multicast indicates that the port can be chosen randomly; once chosen, the
session. *c1 denotes the port on the client used to send the "*" is no longer used.) *c0 denotes the port on the client used to
unicast RTCP feedback messages in the multicast session and to send the RTCP reports for the multicast session. *c1 denotes the
receive the RTP packets and RTCP sender reports in the unicast port on the client used to send the unicast RTCP feedback messages
session. *c2 denotes the port on the client used to send the RTCP in the multicast session and to receive the RTP packets and RTCP
receiver and extended reports in the unicast session. Ports c0, sender reports in the unicast session. *c2 denotes the port on the
c1 and c2 could be the same port or different ports. There are client used to send the RTCP receiver and extended reports in the
two advantages of using the same port for both c0 and c1: unicast session. Ports c0, c1, and c2 could be the same port or
different ports. There are two advantages of using the same port
for both c0 and c1:
1. Some NATs only keep bindings active when a packet goes from 1. 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 the inside to the outside of the NAT (see REQ-6 of Section 4.3
of [RFC4787]). When the gap between the packets sent from the of [RFC4787]). When the gap between the packets sent from the
client to the server is long, this can exceed that timeout. client to the server is long, this can exceed the timeout
If c0=c1, the occasional (periodic) RTCP receiver reports sent limit. If c0=c1, the occasional (periodic) RTCP receiver
from port c0 (for the multicast session's RTCP port P3) will reports sent from port c0 (for the multicast session's RTCP
ensure the NAT does not time out the public port associated port P3) will ensure the NAT does not time out the public port
with the incoming unicast traffic to port c1. associated with the incoming unicast traffic to port c1.
2. Having c0=c1 conserves NAT port bindings. 2. Having c0=c1 conserves NAT port bindings.
o Ports PT and *cT denote the ports through which the Token request o Ports PT and *cT denote the ports through which the Token request
and retrieval occur at the server and client sides, respectively. and retrieval occur at the server and client sides, respectively.
Port PT is declared on a per unicast session basis, although the Port PT is declared on a per-unicast-session basis, although the
same port could be used for two or more unicast sessions sourced same port could be used for two or more unicast sessions sourced
by the server. A Token once requested and retrieved by a client by the server. A Token once requested and retrieved by a client
from port PT remains valid until its expiration time. from port PT remains valid until its expiration time.
We assume that the information declaratively defined is available as We assume that the information declaratively defined is available as
part of the session description information and is provided to the part of the session description information and is provided to the
clients. The Session Description Protocol (SDP) [RFC4566] and other clients. The Session Description Protocol (SDP) [RFC4566] and other
session description methods can be used for this purpose. session description methods can be used for this purpose.
3.2. Normative Behavior and Requirements 3.2. Normative Behavior and Requirements
In this section, we describe the normative behavior and requirements. In this section, we describe the normative behavior and requirements.
To simplify the presentation, we refer to the port numbers described To simplify the presentation, we refer to the port numbers described
in the example presented in Figure 2. However, the behavior and in the example presented in Figure 2. However, the behavior and
requirements described here are not specific to that particular requirements described here are not specific to that particular
example, and can be applied to any scenario where analogous ports can example and can be applied to any scenario where analogous ports can
be identified. be identified.
First of all, a client compliant with this specification MUST be able First of all, a client compliant with this specification MUST be able
to include a Token with any type of RTCP message (as described below) to include a Token with any type of RTCP message (as described below)
when it is needed. when it is needed.
Second, the solution provided in this specification is not applicable Second, the solution provided in this specification is not applicable
in cases where there is RTP traffic flowing from the client to the in cases where there is RTP traffic flowing from the client to the
server in the unicast session. In other words, the direction of RTP server in the unicast session. In other words, the direction of RTP
traffic MUST be only from the server to the client in the unicast traffic MUST be only from the server to the client in the unicast
skipping to change at page 10, line 35 skipping to change at page 9, line 40
port P3. Port PT MAY be equal to port P3. port P3. Port PT MAY be equal to port P3.
2. The client selects its local port numbers (*c0, *c1, *c2 and 2. The client selects its local port numbers (*c0, *c1, *c2 and
*cT). It is strongly RECOMMENDED that the client uses the same *cT). It is strongly RECOMMENDED that the client uses the same
port for c0 and c1. Port cT MAY be equal to ports c0 and c1. port for c0 and c1. Port cT MAY be equal to ports c0 and c1.
3. If the client does not have a Token (or the existing Token has 3. If the client does not have a Token (or the existing Token has
expired): expired):
A. The client first sends a Port Mapping Request message A. The client first sends a Port Mapping Request message
(Section 4.1) to port PT. This message is sent from port *cT (Section 4.1) to port PT. This message is sent from port cT
on the client side. The server learns client's IP address on the client side. The server learns the client's IP
from the received message. The client can send this message address from the received message. The client can send this
anytime it wants (e.g., during initialization), and does not message anytime it wants (e.g., during initialization) and
normally ever need to re-send this message (See Section 6). does not normally ever need to resend this message (see
Section 6).
B. The server generates an opaque encapsulation (i.e., the B. The server generates an opaque encapsulation (i.e., the
Token) based on certain information including the client's IP Token) based on certain information, including the client's
address. IP address.
C. The server sends the Token back to the client using a Port C. The server sends the Token back to the client using a Port
Mapping Response message (Section 4.2). This message MUST be Mapping Response message (Section 4.2). This message MUST be
sent from port PT towards port cT. sent from port PT towards port cT.
4. The client needs to provide the Token to the server using a Token 4. The client needs to provide the Token to the server using a Token
Verification Request message (Section 4.3), whenever the client Verification Request message (Section 4.3) whenever the client
sends an RTCP feedback message for triggering or controlling a sends an RTCP feedback message for triggering or controlling a
unicast session (See Section 4.3.1). If the Token is invalid or unicast session (see Section 4.3.1). If the Token is invalid or
missing, the server sends a Token Verification Failure message missing, the server sends a Token Verification Failure message
(Section 4.4) to the client. (Section 4.4) to the client.
Note that the unicast session is only established after the Note that the unicast session is only established after the
server has received a feedback message (along with a valid Token) server has received a feedback message (along with a valid Token)
from the client for which it needs to react by sending unicast from the client for which it needs to react by sending unicast
data. Until a unicast session is established, neither the server data. Until a unicast session is established, neither the server
nor the client needs to send RTCP reports for the unicast nor the client needs to send RTCP reports for the unicast
session. session.
5. Normal flows ensue as shown in Figure 2. It is strongly 5. Normal flows ensue as shown in Figure 2. It is strongly
RECOMMENDED that the client uses the same port for both c0 and RECOMMENDED that the client uses the same port for both c0 and
c1, as this causes the periodic RTCP reports to keep the NAT c1, as this causes the periodic RTCP reports to keep the NAT
mapping alive. However, if the client uses different ports for mapping alive. However, if the client uses different ports for
c0 and c1, the client MUST keep its own NAT mapping alive for the c0 and c1, the client MUST keep its own NAT mapping alive for the
P3->c1 session (See [I-D.ietf-avt-app-rtp-keepalive] for P3->c1 session (see [RFC6263] for additional information).
additional information).
In the unicast session, traffic from the server to the client In the unicast session, traffic from the server to the client
(i.e., both the RTP and RTCP packets sent from port P3 towards (i.e., both the RTP and RTCP packets sent from port P3 towards
port c1) MUST be multiplexed on the (same) port c1 [RFC5761]. port c1) MUST be multiplexed on the same port [RFC5761].
The client sends the RTCP receiver and extended reports in the The client sends the RTCP receiver and extended reports in the
unicast session from port c2 towards port P4. The server unicast session from port c2 towards port P4. The server
correlates these reports with the reports received in the correlates these reports with the reports received in the
multicast session based on the client's RTCP Canonical Name multicast session based on the client's RTCP Canonical Name
(CNAME). Thus, the client MUST use the same RTCP CNAME in both (CNAME). Thus, the client MUST use the same RTCP CNAME in both
sessions and its RTCP CNAME MUST be unique [RFC6222]. sessions, and its RTCP CNAME MUST be unique [RFC6222].
A unicast session on a particular receive port c1 can last as long as A unicast session on a particular receive port c1 can last as long as
the associated multicast session lasts. However, a client cannot the associated multicast session lasts. However, a client cannot
keep using the same receive port c1 for different subsequent unicast keep using the same receive port c1 for different subsequent unicast
sessions since there could be packet leakage when switching from one sessions since there could be packet leakage when switching from one
unicast session to another unless each received unicast stream has unicast session to another unless each received unicast stream has
its own distinct Synchronization Source (SSRC) identifier to allow its own distinct Synchronization Source (SSRC) identifier to allow
the client to filter out the undesired packets. Unless this is the client to filter out the undesired packets. Unless this is
guaranteed (which is not often easy), a client SHOULD use separate guaranteed (which is not often easy), a client SHOULD use separate
receive ports for subsequent unicast sessions. After a sufficient receive ports for subsequent unicast sessions. After a sufficient
time (two minutes is RECOMMENDED, similar to one TCP Maximum Segment time (two minutes is RECOMMENDED, similar to one TCP Maximum Segment
Lifetime specified in [RFC0793]), a previously used receive port Lifetime specified in [RFC0793]), a previously used receive port can
could be used again. be used again.
The established unicast session can be explicitly terminated by the The established unicast session can be explicitly terminated by the
procedures specified by an application or extension using the port procedures specified by an application or extension using the port
mapping approach described in this document. In addition, the mapping approach described in this document. In addition, the
unicast session can also be terminated by the procedure defined unicast session can also be terminated by the procedure defined
below, which is based on timing all participants out following the below, which is based on timing all participants out following the
timeout rules of [RFC3550]. Both the server and client periodically timeout rules of [RFC3550]. Both the server and client periodically
check the liveness of the other peer, and if there was no RTCP check the liveness of the other peer, and if there is no RTCP traffic
traffic from the other peer for a certain time (Section 6.3.5 of from the other peer for a certain amount of time (Section 6.3.5 of
[RFC3550] suggests five RTCP reporting intervals), the unicast [RFC3550] suggests five RTCP reporting intervals), the unicast
session SHOULD be considered terminated and no further RTP and/or session SHOULD be considered terminated, and no further RTP and/or
RTCP packets SHOULD be sent in this session. The client can attempt RTCP packets SHOULD be sent in that session. The client can attempt
to establish a new unicast session, if needed. If no explicit to establish a new unicast session if needed. If no explicit
procedure for session termination exists, the client MAY stop sending procedure for session termination exists, the client MAY stop sending
RTCP to the server to accomplish session termination. However, the RTCP to the server to accomplish session termination. However, the
server SHALL NOT stop sending RTCP until the unicast session is server SHALL NOT stop sending RTCP until the unicast session is
terminated. If Token-based authentication is also signaled to be terminated. If Token-based authentication is also signaled to be
allowed in the unicast session, i.e., in the RTCP messages sent from allowed in the unicast session, i.e., in the RTCP messages sent from
port c2 towards port P4, the client SHOULD terminate the unicast port c2 towards port P4, the client SHOULD terminate the unicast
session by sending an RTCP BYE message for each SSRC it has used in session by sending an RTCP BYE message for each SSRC it has used in
this unicast session. that unicast session.
4. Message Formats 4. Message Formats
This section defines the formats of the RTCP messages that are This section defines the formats of the RTCP messages that are
exchanged between a server and a client for the purpose of port exchanged between a server and a client for the purpose of port
mapping. A new RTCP control packet type is introduced and four port mapping. A new RTCP control packet type is introduced, and four port
mapping messages using this control packet are defined: mapping messages using this control packet are defined:
1. Port Mapping Request 1. Port Mapping Request
2. Port Mapping Response 2. Port Mapping Response
3. Token Verification Request 3. Token Verification Request
4. Token Verification Failure 4. Token Verification Failure
Each message has a fixed-length field for version (V), padding (P), Each message has a fixed-length field for version (V), padding (P),
sub-message type (SMT), packet type (PT), length and SSRC of packet sub-message type (SMT), packet type (PT), length, and SSRC of packet
sender. Messages have other fields as defined below. In all sender. Messages have other fields as defined below. In all
messages defined in this section, the PT field is set to TOKEN. messages defined in this section, the PT field is set to TOKEN (210).
Individual messages are identified by the SMT field. The length Individual messages are identified by the SMT field. The length
field indicates the message size in 32-bit words minus one, including field indicates the message size in 32-bit words minus one, including
the header and any padding. This definition is in line with the the header and any padding. This definition is in line with the
definition of the length field used in RTCP sender and receiver definition of the Length field used in RTCP sender and receiver
reports. In all messages, any Reserved field SHALL be set to zero reports. In all messages, any Reserved field SHALL be set to zero
and ignored. and ignored.
Following the rules specified in [RFC3550], all integer fields in the Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is, messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian. most significant byte (octet) first, also known as big-endian.
Unless otherwise stated, numeric constants are in decimal (base 10). Unless otherwise stated, numeric constants are in decimal (base 10).
Note that RTCP is not a timely or reliable protocol. The RTCP Note that RTCP is not a timely or reliable protocol. The RTCP
packets might get lost or re-ordered in the network and it is not packets might get lost or reordered in the network, and it is not
easy to detect these events. When sending a new Port Mapping Request easy to detect these events. When sending a new Port Mapping Request
message, the scheduling rules that apply to sending initial RTCP message, the scheduling rules that apply to sending initial RTCP
messages [RFC4585] apply. When a client sends a Port Mapping Request messages [RFC4585] apply. When a client sends a Port Mapping Request
or Token Verification Request message but it does not receive a or Token Verification Request message but it does not receive a
response back from the server (either a Port Mapping Response or response back from the server (either a Port Mapping Response or
Token Verification Failure message), it MAY resend its request by Token Verification Failure message), it MAY resend its request by
following the timer rules defined for RTCP feedback messages in following the timer rules defined for RTCP feedback messages in
Section 3.5 of [RFC4585] as a good practice. However, Section 3.5 of [RFC4585] as a good practice. However,
implementations are advised to avoid sending spurious RTCP messages implementations are advised to avoid sending spurious RTCP messages
just because the timer rules (based on some RTCP configuration just because the timer rules (based on some RTCP configuration
parameters) allow. Reasonably safe practices are to be used to parameters) allow. Reasonably safe practices are to be used to
detect RTCP message loss. When sending an RTCP (feedback) message detect RTCP message loss. When sending an RTCP (feedback) message
bundled with a Token Verification Request message, the timer rules of bundled with a Token Verification Request message, the timer rules of
[RFC4585] apply as usual. [RFC4585] apply as usual.
4.1. Port Mapping Request 4.1. Port Mapping Request
The Port Mapping Request message is identified by SMT=1. This The Port Mapping Request message is identified by SMT=1. This
message is transmitted by the client to a dedicated server port (and message is transmitted by the client to a dedicated server port (and
possibly a dedicated address) to request a Token. In the Port possibly a dedicated address) to request a Token. In the Port
Mapping Request message, the packet sender SSRC is set to the Mapping Request message, the packet sender's SSRC is set to the
client's SSRC, which is chosen randomly by the client. The packet client's SSRC, which is chosen randomly by the client. The packet
format has the structure depicted in Figure 3. format has the structure depicted in Figure 3.
0 1 2 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 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 | |V=2|P| SMT=1 | PT=TOKEN | Length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random | | Random |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Packet format for the Port Mapping Request message Figure 3: Packet Format for the Port Mapping Request Message
o Random Nonce (64 bits): Field that contains a random value o Random Nonce (64 bits): Field that contains a random value
generated by the client following the procedures of [RFC4086]. generated by the client following the procedures of [RFC4086].
This nonce is taken into account by the server when generating a This nonce is taken into account by the server when generating a
Token for the client to enable better security for clients that Token for the client to enable better security for clients that
share the same IP address (Such clients need to produce a random share the same IP address (such clients need to produce a random
value extremely unlikely to collide with other clients sharing the value extremely unlikely to collide with other clients sharing the
same IP address). If the same Port Mapping Request message is same IP address). If the same Port Mapping Request message is
transmitted multiple times for redundancy reasons, the random transmitted multiple times for redundancy reasons, the random
nonce value MUST remain the same in these duplicated messages. nonce value MUST remain the same in these duplicated messages.
However, the client MUST generate a new random nonce for every new However, the client MUST generate a new random nonce for every new
Port Mapping Request message. Port Mapping Request message.
4.2. Port Mapping Response 4.2. Port Mapping Response
The Port Mapping Response message is identified by SMT=2. This The Port Mapping Response message is identified by SMT=2. This
message is sent by the server and delivers the Token to the client as message is sent by the server and delivers the Token to the client as
a response to the Port Mapping Request message. In the Port Mapping a response to the Port Mapping Request message. In the Port Mapping
Response message, the packet sender SSRC is set to the server's SSRC. Response message, the packet sender's SSRC is set to the server's
The packet format has the structure depicted in Figure 4. SSRC. The packet format has the structure depicted in Figure 4.
0 1 2 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 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 | |V=2|P| SMT=2 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client | | SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 27 skipping to change at page 13, line 42
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute | | Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time | | Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Packet Types Element : : Packet Types Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Packet format for the Port Mapping Response message Figure 4: Packet Format for the Port Mapping Response Message
o SSRC of Requesting Client (32 bits): Field that contains the SSRC o SSRC of Requesting Client (32 bits): Field that contains the SSRC
of the client who sent the request. of the client who sent the request.
o Associated Nonce (64 bits): Field that contains the nonce o Associated Nonce (64 bits): Field that contains the nonce received
received in the Port Mapping Request message and used in Token in the Port Mapping Request message and used in Token
construction. construction.
o Token Element (Variable size): Element that is used to carry the o Token Element (variable size): Element that is used to carry the
Token generated by the server. This element is a 32-bit aligned Token generated by the server. This element is a 32-bit aligned
Length-Value element. The Length field, which is 16 bits, Length-Value element. The Length field, which is 16 bits,
indicates the length (in octets) of the Value field that follows indicates the length (in octets) of the Value field that follows
the Length field. While a 16-bit length allows for Tokens with a the Length field. While a 16-bit length allows for Tokens with a
size of up to 65535 bytes, using Tokens of sizes that make the size of up to 65535 bytes, using Tokens of sizes that make the
RTCP compound packet larger than the MTU might have a negative RTCP compound packet larger than the MTU might have a negative
impact on functionality because of IP fragmentation. Some NATs or impact on functionality because of IP fragmentation. Some NATs or
other middleboxes do not pass IP fragments, thus a large Token can other middleboxes do not pass IP fragments; thus, a large Token
cause the whole mechanism to fail. In addition, fragmentation can cause the whole mechanism to fail. In addition, fragmentation
increases the risk for packet loss. increases the risk for packet loss.
The length does not include any padding that is required for The length does not include any padding that is required for
alignment. The Value field carries the Token (or more accurately, alignment. The Value field carries the Token (or more accurately,
the output of the encoding process on the server). If the Token the output of the encoding process on the server). If the Token
element does not fall on a 32-bit boundary, the last word MUST be element does not fall on a 32-bit boundary, the last word MUST be
padded to the boundary using further bits set to zero. padded to the boundary using further bits set to zero.
o Absolute Expiration Time (64 bits): Field that contains the o Absolute Expiration Time (64 bits): Field that contains the
absolute expiration time of the Token. The absolute expiration absolute expiration time of the Token. The absolute expiration
time is expressed as a Network Time Protocol (NTP) timestamp value time is expressed as a Network Time Protocol (NTP) timestamp value
in seconds since year 1900 [RFC5905]. The client does not need to in seconds since the year 1900 [RFC5905]. The client does not
use this element directly, thus, does not need to synchronize its need to use this element directly and thus does not need to
clock with the server. However, the client needs to send this synchronize its clock with the server. However, the client needs
element back to the server along with the associated nonce in the to send this element back to the server along with the associated
Token Verification Request message, thus, needs to keep it nonce in the Token Verification Request message and thus needs to
associated with the Token. keep it associated with the Token.
o Relative Expiration Time (32 bits): Field that contains the o Relative Expiration Time (32 bits): Field that contains the
relative expiration time of the Token. The relative expiration relative expiration time of the Token. The relative expiration
time is expressed in seconds from the time the Token was time is expressed in seconds from the time the Token was
generated. Whenever a server decides to not grant a Token to a generated. Whenever a server decides to not grant a Token to a
requesting client, the relative expiration time will be set to requesting client, the relative expiration time will be set to
zero (and hence, the accompanying Token will be invalid). zero (and hence, the accompanying Token will be invalid).
The server conveys the relative expiration time in the clear to The server conveys the relative expiration time in the clear to
the client to allow the client to request a new Token well before the client to allow the client to request a new Token well before
the expiration time. the expiration time.
o Packet Types Element (Variable size): Element that is used to o Packet Types Element (variable size): Element that is used to
signal which RTCP packet types require Token-based authentication. signal which RTCP packet types require Token-based authentication.
This element is a 32-bit aligned Length-Value element. The Length This element is a 32-bit aligned Length-Value element. The Length
field, which is 8 bits, indicates the length (in octets) of the field, which is 8 bits, indicates the length (in octets) of the
Value field that follows the Length field. This length does not Value field that follows the Length field. This length does not
include any padding that is required for alignment. The Value include any padding that is required for alignment. The Value
field carries zero or more 8-bit sub-fields each carrying an RTCP field carries zero or more 8-bit sub-fields, each carrying an RTCP
packet type. If the Packet Types element does not fall on a 32- packet type. If the Packet Types element does not fall on a
bit boundary, the last word MUST be padded to the boundary using 32-bit boundary, the last word MUST be padded to the boundary
further bits set to zero. An example Packet Types element is using further bits set to zero. An example Packet Types element
shown in Figure 5. is shown in Figure 5.
A server MAY change its policy on which RTCP packet types would A server MAY change its policy on which RTCP packet types would
require Token-based authentication based on observations, require Token-based authentication based on observations,
configuration or other policies. However, upon such a change the configuration, or other policies. However, upon such a change,
server SHALL NOT send a new Port Mapping Response message to the the server SHALL NOT send a new Port Mapping Response message to
clients who requested a Token earlier. A client learns about this the clients who requested a Token earlier. A client learns about
change when and if it gets a Token Verification Failure message. this change when and if it gets a Token Verification Failure
message.
0 1 2 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 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 | | Length=4 | 205 | 206 | 203 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 204 | Padding | | 204 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example Packet Types element Figure 5: Example Packet Types Element
4.3. Token Verification Request 4.3. Token Verification Request
The Token Verification Request message is identified by SMT=3. This The Token Verification Request message is identified by SMT=3. This
message contains the Token and accompanies any RTCP message that message contains the Token and accompanies any RTCP message that
would trigger a new or control an existing unicast session. For a would trigger a new unicast session or control an existing unicast
list of such messages, see Section 4.3.1. session. For a list of such messages, see Section 4.3.1.
In the Token Verification Request message, the packet sender SSRC is In the Token Verification Request message, the packet sender's SSRC
set to the client's SSRC. The client MUST NOT send a Token is set to the client's SSRC. The client MUST NOT send a Token
Verification Request message with a Token that has expired. The Verification Request message with a Token that has expired. The
packet format has the structure depicted in Figure 6. packet format has the structure depicted in Figure 6.
0 1 2 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 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 | |V=2|P| SMT=3 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute | | Associated Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packet format for the Token Verification Request message Figure 6: Packet Format for the Token Verification Request Message
o Associated Nonce (64 bits): Field that contains the nonce o Associated Nonce (64 bits): Field that contains the nonce
associated with the Token above. associated with the Token below.
o Token Element (Variable size): Token element that was previously o Token Element (variable size): Token element that was previously
received in the Port Mapping Response message. received in the Port Mapping Response message.
o Associated Absolute Expiration Time (64 bits): Field that o Associated Absolute Expiration Time (64 bits): Field that contains
contains the absolute expiration time associated with the Token the absolute expiration time associated with the Token above.
above.
4.3.1. Where to Include Token 4.3.1. Where to Include Token
This section provides guidelines about which RTCP packet types would This section provides guidelines about which RTCP packet types would
need to be accompanied by a Token Verification Request message. need to be accompanied by a Token Verification Request message.
However, since a server might determine in real time that other RTCP However, since a server might determine in real time that other RTCP
messages also need to be authenticated by a Token, a client MUST act messages also need to be authenticated by a Token, a client MUST act
according to the up-to-date list provided to the client in the Port according to the up-to-date list provided to the client in the Port
Mapping Response message (in the Packet Types element). Clients need Mapping Response message (in the Packet Types element). Clients need
to support using Token-based authentication with any necessary RTCP to support the use of Token-based authentication with any necessary
message (See Section 3.2). RTCP message (see Section 3.2).
As a general rule, when the Token capability is declared in the As a general rule, when the Token capability is declared in the
session description, the RTCP messages that trigger transmission of session description, the RTCP messages that trigger transmission of
RTP packets in a port-mapped unicast session are REQUIRED to be RTP packets in a port mapped unicast session are REQUIRED to be
authenticated by using a Token. Such messages include but are not authenticated by using a Token. Such messages include but are not
limited to: limited to:
o NACK messages [RFC4585] o NACK messages [RFC4585]
o RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] o RAMS Request (RAMS-R) messages [RFC6285]
Additionally, some RTCP messages might directly or indirectly control Additionally, some RTCP messages might directly or indirectly control
an existing unicast session associated with a multicast session. an existing unicast session associated with a multicast session.
Unless another authentication method as described in their respective Unless another authentication method as described in their respective
specifications is used, implementations MUST support authenticating specifications is used, implementations MUST support authenticating
such RTCP messages by using a Token. such RTCP messages by using a Token.
Examples are: Examples are:
o BYE messages [RFC3550] o BYE messages [RFC3550]
o RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp] o RAMS Termination (RAMS-T) messages [RFC6285]
o CCM messages [RFC5104] o Codec Control Messages (CCMs) [RFC5104]
Note that even if a packet type is listed to require Token-based Note that even if a packet type is listed to require Token-based
authentication, it does not need to be authenticated when it does not authentication, it does not need to be authenticated when it does not
control the unicast session. For example, if BYE (203) is listed in control the unicast session. For example, if BYE (203) is listed in
the Port Mapping Response message as one of the packet types that the Port Mapping Response message as one of the packet types that
requires authentication, the client does not need to bundle the RTCP requires authentication, the client does not need to bundle the RTCP
BYE message with a Token when it is sending it for the multicast BYE message with a Token when it is sending it for the multicast
session. session.
The Token Verification Request message might also be bundled with The Token Verification Request message might also be bundled with
skipping to change at page 19, line 14 skipping to change at page 17, line 39
might desire to have a more controlled reporting scheme from the might desire to have a more controlled reporting scheme from the
clients. In this case, the server lists the packet types for the clients. In this case, the server lists the packet types for the
receiver (201) and/or extended reports (207) in the Port Mapping receiver (201) and/or extended reports (207) in the Port Mapping
Response message. Response message.
4.4. Token Verification Failure 4.4. Token Verification Failure
The Token Verification Failure message is identified by SMT=4. This The Token Verification Failure message is identified by SMT=4. This
message is sent by the server and notifies the client that the Token message is sent by the server and notifies the client that the Token
was invalid or that the client did not include a Token Verification was invalid or that the client did not include a Token Verification
Request message in the RTCP packet although it was supposed to (The Request message in the RTCP packet although it was supposed to (the
message is sent from port P3 towards port c1). The packet format has message is sent from port P3 towards port c1). The packet format has
the structure depicted in Figure 7. the structure depicted in Figure 7.
0 1 2 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 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 | |V=2|P| SMT=4 | PT=TOKEN | Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client | | SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed PT | FMT | Reserved | | Failed PT | FMT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Packet format for the Token Verification Failure message Figure 7: Packet Format for the Token Verification Failure Message
o SSRC of Packet Sender: This is server's SSRC, which equals the o SSRC of Packet Sender: This is the server's SSRC, which equals the
SSRC of the respective multicast stream. Note that this SSRC SSRC of the respective multicast stream. Note that this SSRC
value is from a different SSRC space than the one used in the value is from a different SSRC space than the one used in the
unicast session. unicast session.
o SSRC of Requesting Client (32 bits): Field that contains the SSRC o SSRC of Requesting Client (32 bits): Field that contains the SSRC
of the client who sent the verification request. of the client.
o Failed PT (8 bits): Field that indicates the type of the RTCP o Failed PT (8 bits): Field that indicates the type of the RTCP
packet that caused this failure message. packet that caused this failure message.
o FMT (5 bits): Field that indicates the feedback message type o FMT (5 bits): Field that indicates the feedback message type (FMT)
(FMT) value of the RTCP packet that caused this failure. Together value of the RTCP packet that caused this failure. Together with
with the field above, the client can infer which RTCP message it the field above, the client can infer which RTCP message it had
has previously sent caused this failure message to be sent by the previously sent caused this failure message to be sent by the
server. For example, if the client did not include a valid Token server. For example, if the client did not include a valid Token
with an RTCP NACK message, the Failed PT field will indicate 205 with an RTCP NACK message, the Failed PT field will indicate 205
(RTPFB) and the FMT field will indicate 1 (Generic NACK). If the (RTPFB) and the FMT field will indicate 1 (Generic NACK). If the
RTCP message did not have an associated FMT value (such as an RTCP RTCP message did not have an associated FMT value (such as an RTCP
BYE message), the FMT field SHALL be set to zero. BYE message), the FMT field SHALL be set to zero.
o Associated Nonce (64 bits): Field that contains the nonce o Associated Nonce (64 bits): Field that contains the nonce received
received in the Token Verification Request message. If there was in the Token Verification Request message. If there was no Token
no Token Verification Request message included by the client, this Verification Request message included by the client, this field is
field is set to 0. set to zero.
5. Procedures for Token Construction 5. Procedures for Token Construction
The Token encoding is known to the server but opaque to the client. The Token encoding is known to the server but opaque to the client.
Implementations MUST encode the following information into the Token Implementations MUST encode the following information into the Token
as a minimum, in order to provide adequate security: as a minimum, in order to provide adequate security:
o Client's IP address as seen by the server (32/128 bits for IPv4/ o Client's IP address as seen by the server (32/128 bits for IPv4/
IPv6 addresses) IPv6 addresses)
o The nonce generated and inserted in the Port Mapping Request o The nonce generated and inserted in the Port Mapping Request
message by the client (64 bits) message by the client (64 bits)
o The absolute expiration time chosen by the server indicated as an o The absolute expiration time chosen by the server indicated as an
NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, NTP timestamp value in seconds since the year 1900 [RFC5905] (64
to protect against replay attacks) bits, to protect against replay attacks)
The RECOMMENDED way for constructing Tokens is to perform HMAC-SHA1 The RECOMMENDED way for constructing Tokens is to perform HMAC-SHA1
[RFC2104] on the concatenated values of the information listed above [RFC2104] on the concatenated values of the information listed above
(Implementations might adopt different approaches). If HMAC-SHA1 is (implementations might adopt different approaches). If HMAC-SHA1 is
used, the HMAC key MUST be at least 160 bits long, and generated used, the Hashed Message Authentication Code (HMAC) key MUST be at
using a cryptographically secure random source [RFC4086]. least 160 bits long and generated using a cryptographically secure
random source [RFC4086].
In addition to the information listed above, implementations are In addition to the information listed above, implementations are
encouraged to encode whatever additional information is deemed encouraged to encode whatever additional information is deemed
necessary or useful. For example, key rollover is simplified by necessary or useful. For example, key rollover is simplified by
encoding a key-id into the Token. As another example, a cluster of encoding a key-id into the Token. As another example, a cluster of
anycast servers could find advantage by encoding a server identifier anycast servers could find advantage by encoding a server identifier
into the Token. As another example, while HMAC-SHA1 provides a level into the Token. As another example, while HMAC-SHA1 provides a level
of security that is widely regarded as being more than sufficient for of security that is widely regarded as being more than sufficient for
providing message authentication and it is secure against all known providing message authentication and it is secure against all known
cryptanalytic attacks that use computational resources that are cryptanalytic attacks that use computational resources that are
currently economically feasible, if HMAC-SHA1 has been compromised, a currently economically feasible, a replacement HMAC algorithm (e.g.,
replacement HMAC algorithm could be used instead (e.g., HMAC-SHA256). HMAC-SHA256) could be used instead if HMAC-SHA1 has been compromised.
To protect from offline attacks, the server SHOULD occasionally To protect from offline attacks, the server SHOULD occasionally
choose a new HMAC key. To ease implementation, a key-id can be choose a new HMAC key. To ease implementation, a key-id can be
assigned to each HMAC key. This can be encoded as simply as one bit assigned to each HMAC key. This can be encoded as simply as one bit
(where the new key is X (e.g., 1) and the old key is the inverted (where the new key is X (e.g., 1) and the old key is the inverted
value of X (e.g., 0)), or if several keys are supported at once could value of X (e.g., 0)), or if several keys are supported at once, the
be encoded into several bits. As the encoding of the Token is key-id could be encoded into several bits. As the encoding of the
entirely private to the server and opaque to the clients, any Token is entirely private to the server and opaque to the clients,
encoding can be used. By encoding the key-id into the Token element, any encoding can be used. By encoding the key-id into the Token
the server can reject an old key without bothering to do HMAC element, the server can reject an old key without bothering to do
validation (saving CPU cycles). The key-id can be encoded into the HMAC validation (saving CPU cycles). The key-id can be encoded into
Value field of the Token element by simply concatenating the the Value field of the Token element by simply concatenating the
(plaintext) key-id with the hashed information (i.e., the Token (plaintext) key-id with the hashed information (i.e., the Token
itself). itself).
For example, the Value field in the Token element can be computed as: For example, the Value field in the Token element can be computed as:
key-id || mac-alg (client-ip | nonce | abs-expiration) key-id || mac-alg (client-ip | nonce | abs-expiration)
During Token construction, the expiration time has to be chosen During Token construction, the expiration time has to be chosen
carefully based on the intended service duration. Tokens that are carefully based on the intended service duration. Tokens that are
valid for an unnecessarily long period of time (e.g., several hours) valid for an unnecessarily long period of time (e.g., several hours)
might impose security risks. Depending on the application and use might impose security risks. Depending on the application and use
cases, a reasonable value needs to be chosen by the server. Note cases, a reasonable value needs to be chosen by the server. Note
that using shorter lifetimes requires the clients to acquire Tokens that using shorter lifetimes requires the clients to acquire Tokens
more frequently. However, since a client can acquire a new Token more frequently. However, since a client can acquire a new Token
well before it will need to use it, the client will not necessarily well before it will need to use it, the client will not necessarily
be penalized for the acquisition delay. be penalized for the acquisition delay.
Finally, be aware that NTP timestamps will wrap around in year 2036. Finally, be aware that NTP timestamps will wrap around in the year
Refer to Section 6 of [RFC5905] for further details. 2036. Refer to Section 6 of [RFC5905] for further details.
6. Validating Tokens 6. Validating Tokens
Upon receipt of an RTCP feedback message along with the Token The server MUST validate the Token upon receipt of an RTCP feedback
Verification Request message that contains a Token, nonce and message along with the Token Verification Request message that
absolute expiration time, the server MUST validate the Token. contains a Token, nonce, and absolute expiration time.
The server first applies its own procedure for constructing the The server first applies its own procedure for constructing the
Tokens by using client's IP address from the received Token Tokens by using the client's IP address from the received Token
Verification Request message, and the nonce and absolute expiration Verification Request message and the nonce and absolute expiration
time values reported in the received Token Verification Request time values reported in the received Token Verification Request
message. The server then compares the resulting output with the message. The server then compares the resulting output with the
Token sent by the client in the Token Verification Request message. Token sent by the client in the Token Verification Request message.
If they match and the absolute expiration time has not passed yet, If they match and the absolute expiration time has not passed yet,
the server declares that the Token is valid. the server declares that the Token is valid.
Note that if the client's IP address changes, the Token will not Note that if the client's IP address changes, the Token will not
validate. Similarly, if the client inserts an incorrect nonce or validate. Similarly, if the client inserts an incorrect nonce or
absolute expiration time value in the Token Verification Request absolute expiration time value in the Token Verification Request
message, validation will fail. It is also possible that the server message, validation will fail. It is also possible that the server
wants to expire the Token prematurely. In these cases, the server wants to expire the Token prematurely. In these cases, the server
MUST reply back to the client with a Token Verification Failure MUST reply back to the client with a Token Verification Failure
message (that goes from port P3 on the server towards port c1 on the message (that goes from port P3 on the server towards port c1 on the
client). client).
In addition to the Token Verification Failure message, it is In addition to the Token Verification Failure message, it is
RECOMMENDED that applications define an application-specific error RECOMMENDED that applications define an application-specific error
response to be sent by the server when the server detects that the response to be sent by the server when the server detects that the
Token is invalid. For applications using Token is invalid. For applications using [RFC6285], this document
[I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new defines a new 4xx-level response code in the RAMS Response Code Space
4xx-level response code in the RAMS Response Code Space Registry. A Registry. A client that receives a Token Verification Failure
client that received a Token Verification Failure message can request message can request a new Token from the server.
a new Token from the server.
If a client receives a Port Mapping Response message with an invalid If a client receives a Port Mapping Response message with an invalid
Token (i.e., the relative expiration time is set to zero) two or more Token (i.e., the relative expiration time is set to zero) two or more
times for a particular Port Mapping Request message, or the client times for a particular Port Mapping Request message or the client
receives a Token Verification Failure message two or more times for receives a Token Verification Failure message two or more times for
the same Token Verification Request message, the client SHOULD do the the same Token Verification Request message, the client SHOULD do the
following: following:
1. Check whether the session description has been updated or not. 1. Check whether or not the session description has been updated.
If it was updated, act according to the new session description. If it was updated, act according to the new session description.
2. Exponentially back off for the third and subsequent attempts. 2. Exponentially back off for the third and subsequent attempts.
Exponential back-off does not apply when the client sends a Port Exponential back-off does not apply when the client sends a Port
Mapping Request or Token Verification Request message to a new Mapping Request or Token Verification Request message to a new
address and/or port. address and/or port.
7. SDP Signaling 7. SDP Signaling
7.1. The portmapping-req Attribute 7.1. The 'portmapping-req' Attribute
This attribute is used declaratively in any media block that This attribute is used declaratively in any media block that
describes an RTP session that uses Token-based authentication for one describes an RTP session that uses Token-based authentication for one
or more RTCP messages relating to that session. It indicates the or more RTCP messages relating to that session. It indicates the
port and optionally the address for obtaining a Token. port and optionally the address for obtaining a Token.
The presence of the 'portmapping-req' attribute indicates that (i) a The presence of the 'portmapping-req' attribute indicates that (i) a
Token MUST be included in certain RTCP messages sent to the server Token MUST be included in certain RTCP messages sent to the server
triggering or controlling a unicast session (See Section 4.3.1), and triggering or controlling a unicast session (see Section 4.3.1) and
(ii) the client MUST receive the unicast session's RTP and RTCP (ii) the client MUST receive the unicast session's RTP and RTCP
packets from the server on the port from which it sent the RTCP packets from the server on the port from which it sent the RTCP
message triggering the unicast session. message triggering the unicast session.
Note: This does not imply that Token Verification Request Note: This does not imply that Token Verification Request messages
messages need to be always sent in the unicast session. Token always need to be sent in the unicast session. Token Verification
Verification Request messages accompany RTCP messages that trigger Request messages accompany RTCP messages that trigger or control
or control this unicast session, and are sent either in the this unicast session and are sent either in the multicast session
multicast session or the unicast session, depending on the RTCP or the unicast session, depending on the RTCP message (see
message (See Section 4.3.1). Section 4.3.1).
7.1.1. ABNF Definition of portmapping-req 7.1.1. ABNF Definition of 'portmapping-req'
The formal description of the 'portmapping-req' attribute is defined The formal description of the 'portmapping-req' attribute is defined
by the following ABNF [RFC5234] syntax: by the following ABNF [RFC5234] syntax:
portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP portmapping-req-attr = "a=portmapping-req:" port [SP nettype SP
addrtype SP connection-address]] CRLF addrtype SP connection-address] CRLF
Here, 'port', 'nettype', 'addrtype' and 'connection-address' are Here, 'port', 'nettype', 'addrtype', and 'connection-address' are
defined as specified in Section 9 of [RFC4566]. defined as specified in Section 9 of [RFC4566].
The 'portmapping-req' attribute SHALL only be used as a media-level The 'portmapping-req' attribute SHALL only be used as a media-level
attribute. attribute.
In the optional address value, only unicast addresses SHOULD be used In the optional address value, only unicast addresses SHOULD be used
unless one wants to use a multicast address after evaluating the unless one wants to use a multicast address after evaluating the
additional security risks such as non-legit servers generating fake additional security risks such as non-legit servers generating fake
Tokens. If the address is not specified, the (source) address in the Tokens. If the address is not specified, the (source) address in the
"c" line applicable to the media description SHALL be used. "c" line applicable to the media description SHALL be used.
skipping to change at page 25, line 15 skipping to change at page 22, line 27
'portmapping-req' attribute is included declaratively. There will 'portmapping-req' attribute is included declaratively. There will
not be offer/answer exchanges between the answerer and the actual not be offer/answer exchanges between the answerer and the actual
server providing the unicast service(s). server providing the unicast service(s).
When the answerer supports the Token approach, it MUST echo in its When the answerer supports the Token approach, it MUST echo in its
answer back to the offerer the 'portmapping-req' attribute from the answer back to the offerer the 'portmapping-req' attribute from the
offer including the same port number and address (if any). If the offer including the same port number and address (if any). If the
answerer does not implement this specification, it follows normal SDP answerer does not implement this specification, it follows normal SDP
parsing of unknown attributes (they are ignored and are not sent in parsing of unknown attributes (they are ignored and are not sent in
the answer). This means that the answerer can still join the the answer). This means that the answerer can still join the
multicast session, but will not be able to use the unicast service(s) multicast session but will not be able to use the unicast service(s)
that require the use of Tokens. that require the use of Tokens.
7.2. Requirements 7.2. Requirements
The use of SDP for the port mapping solution normatively requires the The use of SDP for the port mapping solution normatively requires
support for: support for:
o The SDP grouping framework and flow identification (FID) semantics o The SDP grouping framework and flow identification (FID) semantics
[RFC5888] [RFC5888]
o The RTP/AVPF profile [RFC4585] o The RTP/Audio-Visual Profile with Feedback (AVPF) profile
[RFC4585]
o The 'rtcp-mux' attribute (To multiplex RTP and RTCP on a single o The 'rtcp-mux' attribute (to multiplex RTP and RTCP on a single
port on both endpoints in the unicast session [RFC5761]) port on both endpoints in the unicast session [RFC5761])
7.3. Example and Discussion 7.3. Example and Discussion
The declarative SDP describing the scenario given in Figure 2 is The declarative SDP describing the scenario given in Figure 2 is
written as: written as:
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions s=Local Retransmissions
skipping to change at page 26, line 32 skipping to change at page 23, line 37
i=Unicast Retransmission Stream i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=sendonly a=sendonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp-mux ; Note 5 a=rtcp-mux ; Note 5
a=rtcp:42500 ; Note 6 a=rtcp:42500 ; Note 6
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30001 ; Note 3 a=portmapping-req:30001 ; Note 3
a=mid:2 a=mid:2
Figure 8: SDP describing an SSM distribution with support for Figure 8: SDP Describing an SSM Distribution with Support for
retransmissions from a local server Retransmissions from a Local Server
In this description, we highlight the following notes: In this description, we highlight the following notes:
Note 1: The source stream is multicast from a distribution source 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 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 address of 233.252.0.2 and port 41000 (P1). The associated RTCP
packets are multicast in the same group to port 41500 (P2). packets are multicast in the same group to port 41500 (P2).
Note 2: A retransmission server including feedback target Note 2: A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 and port of 42000 (P3) 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 specified with the 'rtcp' attribute. The feedback functionality
is enabled for the RTP stream with payload type 98 through the is enabled for the RTP stream with payload type 98 through the
'rtcp-fb' attribute [RFC4585]. 'rtcp-fb' attribute [RFC4585].
Note 3: The "a=portmapping-req" line indicates that one or more RTCP Note 3: The "a=portmapping-req" line indicates that one or more RTCP
messages relating to the RTP session described in this media block messages relating to the RTP session described in this media block
uses Token-based authentication, and a Token needs to be retrieved uses Token-based authentication, and a Token needs to be retrieved
first from the designated port (PT) before the unicast session can be first from the designated port (PT) before the unicast session can be
established. In the first appearance, an explicit address is established. In the first appearance, an explicit address is
provided. In the second appearance, there is no address indicated in provided. In the second appearance, there is no address indicated in
this line and the client needs to send the Token request to the this line and the client needs to send the Token request to the
address specified in the "c" line in the unicast media block. address specified in the "c" line in the unicast media block.
Note 4: The port specified in the second "m" line (for the unicast 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 stream) does not mean anything in this scenario as the client does
not send any RTP traffic back to the server. not send any RTP traffic back to the server.
Note 5: The server multiplexes RTP and RTCP packets on the same port Note 5: The server multiplexes RTP and RTCP packets sent towards c1
(c1 in Figure 2). on the same port.
Note 6: The server uses port 42500 (P4) for the unicast session. Note 6: The server uses port 42500 (P4) for the unicast session.
8. Address Pooling NATs 8. Address Pooling NATs
Large-scale NAT devices have a pool of public IPv4 addresses and map Large-scale NAT devices have a pool of public IPv4 addresses and map
internal hosts to one of those public IPv4 addresses. As long as an internal hosts to one of those public IPv4 addresses. As long as an
internal host maintains an active mapping in the NAT, the same IPv4 internal host maintains an active mapping in the NAT, the same IPv4
address is assigned to new connections. However, once all of the address is assigned to new connections. However, once all of the
host's mappings have been deleted (e.g., because of timeout), it is host's mappings have been deleted (e.g., because of timeout), it is
possible that a new connection from that same host will be assigned a possible that a new connection from that same host will be assigned a
different IPv4 address from the pool. When that occurs, the Token different IPv4 address from the pool. When that occurs, the Token
will be considered invalid by the server, causing an additional round will be considered invalid by the server, causing an additional round
trip for the client to acquire a fresh Token. trip for the client to acquire a fresh Token.
Any traffic from the host which traverses the NAT will prevent this Any traffic from the host that traverses the NAT will prevent this
problem. As the host is sending RTCP receiver reports at least every problem. As the host is sending RTCP receiver reports at least every
5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is
receiving, those RTCP messages will be sufficient to prevent this receiving, those RTCP messages will be sufficient to prevent this
problem. problem.
9. Security Considerations 9. Security Considerations
9.1. Tokens 9.1. Tokens
The Token, which is generated based on a client's IP address and The Token, which is generated based on a client's IP address and
expiration date, provides protection against off-path denial-of- expiration date, provides protection against off-path denial-of-
service (DoS) attacks. An attacker using a certain IP address cannot 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 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 different IP address. However, if the attacker acquires a valid
Token for a victim and can spoof the victim's source address, this Token for a victim and can spoof the victim's source address, this
approach becomes vulnerable to replay attacks. This is especially approach becomes vulnerable to replay attacks. This is especially
easy if the attacker and victim are behind a large-scale NAT and easy if the attacker and victim are behind a large-scale NAT and
share the same IP address. share the same IP address.
Multicast is deployed on managed networks - not the Internet. These Multicast is deployed on managed networks, not the Internet. These
managed networks will choose to enable network ingress filtering managed networks will choose whether or not to enable network ingress
[RFC2827] or not. If ingress filtering is enabled on a network, an filtering [RFC2827]. If ingress filtering is enabled on a network,
attacker cannot spoof a victim's IP address to use a Token to an attacker cannot spoof a victim's IP address to use a Token to
initiate an attack against a victim. However, if ingress filtering initiate an attack against a victim. However, if ingress filtering
is not enabled on a network, an attacker could obtain a Token and 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 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 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 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, case, the server can expire the Token in such a short period of time
such that the client will have to acquire a new Token immediately that the client will have to acquire a new Token immediately before
before using it in a Token Verification Request message. One should, using it in a Token Verification Request message. One should,
however, note that such a behavior might have an adverse effect on however, note that such a behavior might have an adverse effect on
the delay in establishing or controlling a unicast session. the delay in establishing or controlling a unicast session.
RTCP messages could be subject to on-path or man-in-the-middle 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 attacks. For example, an attacker can modify a value in one or more
fields in the Port Mapping Response or the Token Verification Request fields in the Port Mapping Response or the Token Verification Request
message that are used in Token construction. This will result in message that are used in Token construction. This will result in
Token validation failure. Consequently, the client ends up asking Token validation failure. Consequently, the client ends up asking
the server to generate a new Token. The resulting delay and extra the server to generate a new Token. The resulting delay and extra
processing on the server is undesirable. processing on the server is undesirable.
Alternatively, the attacker can modify a value in a field that is not Alternatively, the attacker can modify a value in a field that is not
used in Token construction. For example, the attacker can reduce the used in Token construction. For example, the attacker can reduce the
value in the Relative Expiration Time field in the Port Mapping value in the Relative Expiration Time field in the Port Mapping
Response message from two hours to two minutes. While the Token will Response message from two hours to two minutes. While the Token will
still validate, this attack will result in more frequent requests to still validate, this attack will result in more frequent requests to
the server for a new Token. Oppositely, the attacker can increase the server for a new Token. Oppositely, the attacker can increase
the value in the Relative Expiration Time field, and make the client 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 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 only detected by monitoring the activity on the server. Note that
using the relative expiration time in Token construction does not using the relative expiration time in Token construction does not
necessarily make this attack easier to detect since the attacker necessarily make this attack easier to detect since the attacker
might revert the modified value back to its original value in the might revert the modified value back to its original value in the
Token Verification Request message. This allows the Token to still Token Verification Request message. This allows the Token to still
validate on the server. In this case, the attack is still only validate on the server. In this case, the attack is still only
detectable by monitoring the server activity. detectable by monitoring the server activity.
If there is a risk or concern for on-path or man-in-the-middle 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) attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP)
[RFC3711]. [RFC3711].
A server MUST NOT use the same secret key it used for Token To minimize the risk of cross-protocol attacks, a server MUST NOT use
construction for other purposes to minimize the risk for cross- the same secret key it used for Token construction for other
protocol attacks. purposes.
9.2. The portmapping and portmapping-req Attributes 9.2. The 'portmapping-req' Attribute
The 'portmapping-req' attribute is not believed to introduce any The 'portmapping-req' attribute is not believed to introduce any
significant security risk to multimedia applications. A malevolent significant security risk to multimedia applications. A malevolent
third party could use this attribute to redirect the Port Mapping third party could use this attribute to redirect the Port Mapping
Request messages by altering the port number or cause the unicast Request messages by altering the port number or cause the unicast
session establishment to fail by removing it from the SDP session establishment to fail by removing it from the SDP
description. But, this requires intercepting and rewriting the description. However, this requires intercepting and rewriting the
packets carrying the SDP description; and if an interceptor can do packets carrying the SDP description, and if an interceptor can do
that, many more attacks are possible, including a wholesale change of that, many more attacks are possible, including a wholesale change of
the addresses and port numbers at which the media will be sent. 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 In order to avoid attacks of this sort, the SDP description needs to
be integrity protected and provided with source authentication. This be integrity protected and provided with source authentication. This
can, for example, be achieved on an end-to-end basis using S/MIME can, for example, be achieved on an end-to-end basis using Secure/
[RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME Multipurpose Internet Mail Extensions (S/MIME) [RFC5652] [RFC5751]
types (application/sdp). Alternatively, HTTPS [RFC2818] or the when SDP is used in a signaling packet using MIME types (application/
authentication method in the Session Announcement Protocol (SAP) sdp). Alternatively, HTTPS [RFC2818] or the authentication method in
[RFC2974] could be used as well. the Session Announcement Protocol (SAP) [RFC2974] could be used as
well.
10. IANA Considerations 10. IANA Considerations
The following contact information shall be used for all registrations The following contact information is used for all registrations in
in this document: this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC.
10.1. Registration of SDP Attributes 10.1. Registration of SDP Attributes
This document registers one new attribute name in SDP. This document registers one new attribute name in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: portmapping-req Attribute name: portmapping-req
Long form: Port and address for requesting Token Long form: Port and address for requesting Token
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: [RFCXXXX] Reference: [RFC6284]
Values: See this document Values: See this document
10.2. Registration of RTCP Control Packet Types 10.2. Registration of RTCP Control Packet Types
In accordance with Section 15 of [RFC3550], this specification adds In accordance with Section 15 of [RFC3550], this specification adds
the following value to the RTCP Control Packet types sub-registry in the following value to the RTCP Control Packet types sub-registry in
the Real-Time Transport Protocol (RTP) Parameters registry: the Real-Time Transport Protocol (RTP) Parameters registry:
Value Abbrev. Name Reference Value Abbrev. Name Reference
-------- --------- --------------------------------------- --------- -------- --------- ------------------------------------- ---------
TBD TOKEN Port Mapping [RFCXXXX] 210 TOKEN Port Mapping [RFC6284]
Note to the IANA: Please assign the next available value, which is
currently 210.
10.3. SMT Values for TOKEN Packet Type Registry 10.3. SMT Values for TOKEN Packet Type Registry
This document creates a new sub-registry for the sub-message type 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 (SMT) values to be used with the TOKEN packet type. The registry is
called the SMT Values for TOKEN Packet Type Registry. This registry called the SMT Values for TOKEN Packet Type Registry. This registry
is to be managed by the IANA according to the IETF Review policy of is managed by the IANA according to the IETF Review policy of
[RFC5226]. [RFC5226].
The length of the SMT field is five bits, allowing 32 values. The The length of the SMT field is five bits, allowing 32 values. The
registry is initialized with the following entries: registry is initialized with the following entries:
Value Name Reference Value Name Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- ------------
0 Reserved [RFCXXXX] 0 Reserved [RFC6284]
1 Port Mapping Request [RFCXXXX] 1 Port Mapping Request [RFC6284]
2 Port Mapping Response [RFCXXXX] 2 Port Mapping Response [RFC6284]
3 Token Verification Request [RFCXXXX] 3 Token Verification Request [RFC6284]
4 Token Verification Failure [RFCXXXX] 4 Token Verification Failure [RFC6284]
5-30 Unassigned IETF Review 5-30 Unassigned IETF Review
31 Reserved [RFCXXXX] 31 Reserved [RFC6284]
The SMT values 0 and 31 are reserved for future use. The SMT values 0 and 31 are reserved for future use.
10.4. RAMS Response Code Space Registry 10.4. RAMS Response Code Space Registry
This document adds the following entry to the RAMS Response Code This document adds the following entry to the RAMS Response Code
Space Registry. Space Registry.
Code Description Reference Code Description Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- ------------
405 Invalid Token [RFCXXXX] 405 Invalid Token [RFC6284]
This response code is used when the Token included by the RTP_Rx in This response code is used when the Token included by the RTP_Rx in
the RAMS-R message is invalid. the RAMS-R message is invalid.
11. Acknowledgments 11. Acknowledgments
The approach presented in this document came out after discussions The approach presented in this document came out after discussions
with various individuals in the AVT and MMUSIC WGs, and the breakout with various individuals in the AVT and MMUSIC WGs and the breakout
session held in the Anaheim meeting. We thank each of these session held at the Anaheim meeting. We thank each of these
individuals, in particular to Magnus Westerlund and Colin Perkins. individuals, particularly Magnus Westerlund and Colin Perkins.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. 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 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Specifications: ABNF", STD 68, RFC 5234, January 2008. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Requirements for Security", BCP 106, RFC 4086, June 2005. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011. (CNAMEs)", RFC 6222, April 2011.
12.2. Informative References 12.2. Informative References
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RETRANSMISSION-FOR-SSM]
IP", RFC 4607, August 2006. 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 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[I-D.ietf-avt-rapid-acquisition-for-rtp] [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- IP", RFC 4607, August 2006.
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in
progress), November 2010.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, "Codec Control Messages in the RTP Audio-Visual Profile
July 2006. with Feedback (AVPF)", RFC 5104, February 2008.
[I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for
keeping alive the Network Address Translator (NAT)
mappings associated to RTP/RTCP flows.",
draft-ietf-avt-app-rtp-keepalive-10 (work in progress),
March 2011.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[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.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. 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 Authors' Addresses
Ali Begen Ali Begen
Cisco Cisco
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
Canada Canada
Email: abegen@cisco.com EMail: abegen@cisco.com
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com EMail: dwing@cisco.com
Tom VanCaenegem Tom Van Caenegem
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
Antwerpen, 2018 Antwerpen 2018
Belgium Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.com EMail: Tom.Van_Caenegem@alcatel-lucent.com
 End of changes. 145 change blocks. 
356 lines changed or deleted 344 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/