draft-ietf-avt-ports-for-ucast-mcast-rtp-04.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-05.txt 
AVT A. Begen AVT A. Begen
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: May 27, 2011 T. VanCaenegem Expires: June 5, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
November 23, 2010 December 2, 2010
Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avt-ports-for-ucast-mcast-rtp-04 draft-ietf-avt-ports-for-ucast-mcast-rtp-05
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 in RTP applications using both unicast and multicast services. The
(almost) without the need for retrieving pre-authorization. solution provides protection against denial-of-service attacks that
could be used to cause one or more RTP 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 This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 27, 2011. This Internet-Draft will expire on June 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 13 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . 5
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6
3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6 3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6
3.2. Unicast Session Establishment . . . . . . . . . . . . . . 6 3.2. Unicast Session Establishment . . . . . . . . . . . . . . 6
4. The portmapping-req Attribute . . . . . . . . . . . . . . . . 11 3.2.1. Motivating Scenario . . . . . . . . . . . . . . . . . 6
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. Normative Behavior and Requirements . . . . . . . . . 8
5.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12
5.3. Token Verification Request . . . . . . . . . . . . . . . . 15 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 12
5.4. Token Verification Failure . . . . . . . . . . . . . . . . 15 4.3. Token Verification Request . . . . . . . . . . . . . . . . 14
6. Procedures for Token Construction . . . . . . . . . . . . . . 17 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 15
7. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 18 5. Procedures for Token Construction . . . . . . . . . . . . . . 17
8. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 19
9. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 21 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 23 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 20
11.2. Registration of FMT Values . . . . . . . . . . . . . . . . 23 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 23
11.3. SFMT Values for Port Mapping Messages Registry . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11.4. RAMS Response Code Space Registry . . . . . . . . . . . . 24 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 26 10.2. Registration of FMT Values . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 10.3. SFMT Values for Port Mapping Messages Registry . . . . . . 26
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
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 RTCP packets, are defined declaratively. In
other words, the receivers cannot choose their receive ports and the other words, the receivers cannot choose their receive ports and the
sender(s) use the pre-defined ports. sender(s) use the pre-defined 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. the receiving end can determine which ports are available to use. In
The receiving may convey its request to the sending end through addition, Network Address Port Translators (NAPT - hereafter simply
different ways, one of which is the Offer/Answer Model [RFC3264] for called NAT) devices are commonly deployed in networks, thus, static
the Session Description Protocol (SDP) [RFC4566]. However, the port assignments cannot be used. The receiving may convey its
Offer/Answer Model requires offer/answer exchange(s) between the request to the sending end through different ways, one of which is
endpoints, and the resulting delay may not be desirable in delay- the Offer/Answer Model [RFC3264] for the Session Description Protocol
sensitive real-time applications. Furthermore, the Offer/Answer (SDP) [RFC4566]. However, the Offer/Answer Model requires offer/
Model may be burdensome for the endpoints that are concurrently answer exchange(s) between the endpoints, and the resulting delay may
running a large number of unicast sessions with other endpoints. not be desirable in delay-sensitive real-time applications.
Furthermore, the Offer/Answer Model may be burdensome for the
endpoints that are concurrently running a large number of unicast
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) and a receiver sends unicast RTCP source-specific multicast (SSM) and a receiver sends unicast RTCP
feedback to a local repair server (also functioning as a feedback NACK feedback to a local repair server (also functioning as a unicast
target) [RFC5760] asking for a retransmission of the packets it is RTCP feedback target) [RFC5760] asking for a retransmission of the
missing, and the local repair server sends the retransmission packets packets it is missing, and the local repair server sends the
over a unicast RTP session [RFC4588]. retransmission packets over a unicast RTP session [RFC4588].
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
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in
applications where some part of the content is distributed through applications where some part of the content is distributed through
multicast while the receivers get additional and/or auxiliary content multicast while the receivers get additional and/or auxiliary content
through one or more unicast connections, as sketched in Figure 1. through one or more unicast connections, as sketched 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
skipping to change at page 6, line 18 skipping to change at page 6, line 18
and retrieval, and (ii) unicast session establishment. These are and retrieval, and (ii) unicast session establishment. These are
described below. described below.
3.1. Token Request and Retrieval 3.1. Token Request and Retrieval
This first step is required to be completed only once. Once a Token This first step is required to be completed only once. Once a Token
is retrieved from a particular server, it can be used for all the is retrieved from a particular server, it can be used for all the
unicast sessions the client will be running with this particular unicast sessions the client will be running with this particular
server. By default, Tokens are server specific. However, the client server. By default, Tokens are server specific. However, the client
can use the same Token to communicate with different servers if these can use the same Token to communicate with different servers if these
servers are provided with the same secret key used to generate the servers are provided with the same secret key and algorithm used to
Token and are at least loosely clock-synchronized. The Token becomes generate the Token and are at least loosely clock-synchronized. The
invalid if client's public IP address changes or when the server Token becomes invalid if client's public IP address changes or when
expires the Token. In these cases, the client has to request a new the server expires the Token. In these cases, the client has to
Token. request a new Token.
The Token is essentially an opaque encapsulation that conveys The Token is essentially an opaque encapsulation that is based on
client's IP address information (as seen by the server) using a client's IP address (as seen by the server). When a request is
reversible transform only known to the server. When a request is
received, the server creates a Token for this particular client, and received, the server creates a Token for this particular client, and
sends it back to the client. Later, when the client wants to sends it back to the client. Later, when the client wants to
establish a unicast session, the Token will be validated by the establish a unicast session, the Token will be validated by the
server, making sure that the IP address information matches. This is server, making sure that the IP address information matches. This is
effective against DoS attacks, e.g., an attacker cannot simply spoof effective against DoS attacks, e.g., an attacker cannot simply spoof
another client's IP address and start a unicast transmission towards another client's IP address and start a unicast transmission towards
random clients. random clients.
3.2. Unicast Session Establishment 3.2. Unicast Session Establishment
We illustrate the second step with an example. Consider an SSM The second step is the unicast session establishment. We illustrate
distribution network where a distribution source multicasts RTP this step with an example. First, we describe the motivation
packets to a large number of clients, and one or more retransmission scenario and then define the normative behavior and requirements.
servers function as feedback targets to collect unicast RTCP feedback
from these clients [RFC5760]. The retransmission servers also join
the multicast session to receive the multicast packets and cache them
for a certain time period. When a client detects missing packets in
the multicast session, it requests a retransmission from one of the
retransmission servers by using an RTCP NACK message [RFC4585]. The
retransmission server pulls the requested packet(s) out of the cache
and retransmits them to the requesting client [RFC4588].
The pertaining RTP and RTCP flows are sketched in Figure 2. Between 3.2.1. Motivating Scenario
the client and server, there can be one or more Network Address Port
Translators (NAPT - hereafter simply called NAT) devices [RFC4787]. Consider an SSM distribution network where a distribution source
multicasts RTP packets to a large number of clients, and one or more
retransmission servers function as feedback targets to collect
unicast RTCP feedback from these clients [RFC5760]. The
retransmission servers also join the multicast session to receive the
multicast packets and cache them for a certain time period. When a
client detects missing packets in the multicast session, it requests
a retransmission from one of the retransmission servers by using an
RTCP NACK message [RFC4585]. The retransmission server pulls the
requested packet(s) out of the cache and retransmits them to the
requesting client [RFC4588].
The RTP and RTCP flows pertaining to the scenario described above are
sketched in Figure 2. Between the client and server, there can be
one or more NAT devices [RFC4787].
-------------- --- ---------- -------------- --- ----------
| |-------------------------------| |-->|P1 | | |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | | | | | | | |
| Distribution | ---------------- | | | | | Distribution | ---------------- | | | |
| Source | | | | | | | | Source | | | | | | |
| |---->|P1 | | | | | | |---->|P1 | | | | |
| |.-.->|P2 | | | | | | |.-.->|P2 | | | | |
| | | | | | | | | | | | | | | |
skipping to change at page 7, line 44 skipping to change at page 8, line 5
-------> 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 this figure, we have the following multicast and unicast ports: 3.2.2. Normative Behavior and Requirements
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 the RTCP feedback messages, the retransmission server to collect any RTCP packet sent by the
and RTCP receiver and extended reports from the clients in the clients including feedback messages, and RTCP receiver and
multicast session. 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 and MUST be different session. Port P4 is defined declaratively and MUST be different
from port P3. from port P3.
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. *c0 denotes the
port on the client used to send the RTCP reports for the multicast port on the client used to send the RTCP reports for the multicast
session. *c1 denotes the port on the client used to send the session. *c1 denotes the port on the client used to send the
unicast RTCP feedback messages in the multicast session and to unicast RTCP feedback messages in the multicast session and to
receive the RTP packets and RTCP sender reports in the unicast receive the RTP packets and RTCP sender reports in the unicast
session. *c2 denotes the port on the client used to send the RTCP session. *c2 denotes the port on the client used to send the RTCP
receiver and extended reports in the unicast session. Ports c0, receiver and extended reports in the unicast session. Ports c0,
c1 and c2 MAY be the same port or different ports. However, there c1 and c2 MAY be the same port or different ports. However, there
are two advantages of using the same port for both c0 and c1: 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 retransmission server sends unicast of [RFC4787]). When the gap between retransmission requests
packets for a long period of time, this can exceed that (or other traffic sent from the client to the server) is long,
timeout. If c0=c1, the occasional (periodic) RTCP receiver this can exceed that timeout. If c0=c1, the occasional
reports sent from port c0 (for the multicast session) will (periodic) RTCP receiver reports sent from port c0 (for the
ensure the NAT does not time out the public port associated multicast session's RTCP port P3) will ensure the NAT does not
with the incoming unicast traffic to port c1. time out the public port 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.
Thus, it is strongly RECOMMENDED that the client uses the same Thus, it is strongly RECOMMENDED that the client uses the same
port for c0 and c1. port for c0 and c1.
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 its Port PT is declared on a per unicast session basis, although its
value MAY be the same for all unicast sessions sourced by the value MAY be the same for two or more unicast sessions sourced by
server. This way, a Token once requested and retrieved by a the server. A Token once requested and retrieved by a client from
client from port PT remains valid across different unicast port PT remains valid until its expiration time. Port PT MAY be
sessions. Port PT MAY be equal to port P3. Port cT MAY also be equal to port P3. Port cT MAY also be equal to ports c0 and c1.
equal to ports c0 and c1.
In addition to the ports, we use the following notation: In addition to the ports, we use the following notation:
o DS: IP address of the distribution source o DS: IP address of the distribution source
o G: Destination multicast address o G: Destination multicast address
o S: IP address of the retransmission server o S: IP address of the retransmission server
o C: IP address of the client o C: IP address of the client
skipping to change at page 9, line 25 skipping to change at page 9, line 33
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.
The following steps summarize the Token-based solution: The following steps summarize the Token-based solution:
1. The client ascertains server address (S) and port numbers (P3 and 1. The client ascertains server address (S) and port numbers (P3 and
P4) from the session description. P4) from the session description.
2. The client determines its port numbers (*c0, *c1 and *c2). 2. The client selects its local port numbers (*c0, *c1 and *c2).
3. If the client does not have a valid Token: 3. If the client does not have a Token (or the existing Token has
expired):
A. The client first sends a message to the server via a new RTCP A. The client first sends a message to the server via a new RTCP
message, called Port Mapping Request to port PT. This message, called Port Mapping Request to port PT. This
message is sent from port cT on the client side. The server message is sent from port cT on the client side. The server
learns client's public IP address (C') from the received learns client's public IP address (C') from the received
message. The client can send this message anytime it wants message. The client can send this message anytime it wants
(e.g., during initialization), and does not normally ever (e.g., during initialization), and does not normally ever
need to re-send this message (See Section 7). need to re-send 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) that conveys client's IP address information using a Token) based on certain information including client's IP
reversible transform only known to the server. For details, address.
see Section 6.
C. The server sends the Token back to the client using a new C. The server sends the Token back to the client using a new
RTCP message, called Port Mapping Response. This message RTCP message, called Port Mapping Response. This message
MUST be sent from port PT to port cT. MUST be sent from port PT to port cT.
4. The client provides the Token to the server using a new RTCP 4. The client needs to provide the Token to the server using a new
message, called Token Verification Request, whenever the client RTCP message, called Token Verification Request, whenever the
sends an RTCP feedback message for triggering or controlling a client sends an RTCP feedback message for triggering or
unicast session. Note that the unicast session is only controlling a unicast session (See Section 4.3). Note that the
established after the server has received a feedback message unicast session is only established after the server has received
(along with a valid Token) from the client for which it needs to a feedback message (along with a valid Token) from the client for
react by sending unicast data. Until a unicast session is which it needs to react by sending unicast data. Until a unicast
established, neither the server nor the client needs to send RTCP session is established, neither the server nor the client needs
reports for the unicast session. to send RTCP reports for the unicast session.
5. Normal flows ensue as shown in Figure 2. Note that in the 5. Normal flows ensue as shown in Figure 2. Note that in the
unicast session the RTP and RTCP packets MUST be multiplexed on unicast session, traffic from the server to the client (i.e.,
the (same) port c1. If the client uses the same port for both c0 both the RTP and RTCP packets sent from port P3 to port c1) MUST
and c1, the RTCP reports sent for the multicast session keep the be multiplexed on the (same) port c1. If the client uses the
P3->c1(=c0) binding alive. If the client uses different ports same port for both c0 and c1, the RTCP reports sent for the
for c0 and c1, the client needs to periodically send an explicit multicast session keep the P3->c1(=c0) binding alive. If the
keep-alive message [I-D.ietf-avt-app-rtp-keepalive] to keep the client uses different ports for c0 and c1, the client needs to
P3->c1 binding alive during the lifetime of the unicast session periodically send an explicit keep-alive message
if the unicast session's lifetime is likely to exceed the NAT's [I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive
timeout value. during the lifetime of the unicast session if the unicast
session's lifetime is likely to exceed the NAT's timeout value.
4. The portmapping-req Attribute
This new SDP attribute is used declaratively to indicate the port for
obtaining a Token. Its presence indicates that a Token MUST be
included in the feedback messages sent to the server triggering or
controlling a unicast session.
The formal description of the 'portmapping-req' attribute is defined
by the following ABNF [RFC5234] syntax:
portmapping-req-attribute = "a=portmapping-req:" port CRLF
Here, 'port' is defined as specified in Section 9 of [RFC4566]. The
'portmapping-req' attribute is used as a session-level or media-level
attribute.
5. Message Formats 4. Message Formats
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between a server and a client for the messages that are exchanged between a server and a client for the
purpose of Token-based port mapping. Four RTCP messages are defined: purpose of Token-based port mapping. Four RTCP messages 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
skipping to change at page 13, line 5 skipping to change at page 12, line 5
RTPFB (205) and the FMT field is set to Port Mapping (7). Individual RTPFB (205) and the FMT field is set to Port Mapping (7). Individual
Port Mapping messages are identified by a sub-field called Sub Port Mapping messages are identified by a sub-field called Sub
Feedback Message Type (SFMT). Any Reserved field SHALL be set to Feedback Message Type (SFMT). Any Reserved field SHALL be set to
zero and ignored. zero 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).
5.1. Port Mapping Request Note that RTCP is not a timely or reliable protocol. The RTCP
packets might get lost or re-ordered in the network. When a client
sends a Port Mapping Request or Token Verification Request message
but it does not receive a response back from the server (either a
Port Mapping Response or Token Verification Failure message), it MAY
resend its request when it is eligible to do so based on the timer
rules defined in [RFC4585].
4.1. Port Mapping Request
The Port Mapping Request message is identified by SFMT=1. This The Port Mapping Request message is identified by SFMT=1. This
message is a unicast feedback message transmitted by the client to a message is a unicast feedback message transmitted by the client to a
dedicated server port to request a Token. In the Port Mapping dedicated server port to request a Token. In the Port Mapping
Request message, the client MUST set both the packet sender SSRC and Request message, the client MUST set both the packet sender SSRC and
media source SSRC fields to its own SSRC since the Port Mapping media source SSRC fields to its own SSRC since the Port Mapping
Request message is not necessarily linked to any specific media Request message is not necessarily linked to any specific media
source. The FCI field has the structure depicted in Figure 4. source. The FCI field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Reserved | | SFMT=1 | Random Nonce :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random | : Random Nonce |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The FCI field of Port Mapping Request message Figure 4: The FCI field of Port Mapping Request message
o Random Nonce (64 bits): Mandatory field that contains a random o Random Nonce (56 bits): Mandatory field that contains a random
nonce value generated by the client following the procedures of nonce value generated by the client following the procedures of
[RFC4086]. This nonce is taken into account by the server when [RFC4086]. This nonce is taken into account by the server when
generating a Token for the client to enable better security for generating a Token for the client to enable better security for
clients that share the same IP address. If the Port Mapping clients that share the same IP address. If the Port Mapping
Request message is transmitted multiple times for redundancy Request message is transmitted multiple times for redundancy
reasons, the random nonce value MUST remain the same in these reasons, the random nonce value MUST remain the same in these
duplicated messages. duplicated messages. However, the client MUST generate a new
random nonce for every new Port Mapping Request message.
5.2. Port Mapping Response 4.2. Port Mapping Response
The Port Mapping Response message is identified by SFMT=2. This The Port Mapping Response message is identified by SFMT=2. This
message is sent by the server and delivers the Token to the client. message is sent by the server and delivers the Token to the client as
In the Port Mapping Response message, the packet sender SSRC and a response to the Port Mapping Request message. In the Port Mapping
media sender SSRC fields are both set to the client's SSRC since the Response message, the packet sender SSRC and media sender SSRC fields
Port Mapping Response message is not necessarily linked to any are both set to the client's SSRC since the Port Mapping Response
specific media source. The FCI field has the structure depicted in message is not necessarily linked to any specific media source. The
Figure 5. FCI field has the structure depicted in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | Reserved | | SFMT=2 | Associated Nonce :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token : : Associated Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | : Token Element :
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute | | Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time | | Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FCI field syntax for the Port Mapping Response message Figure 5: FCI field syntax for the Port Mapping Response message
o Token (128 bits): Mandatory element that contains the Token o Associated Nonce (56 bits): Mandatory field that contains the
generated by the server.
o Associated Nonce (64 bits): Mandatory field that contains the
nonce received in the Port Mapping Request message and used in nonce received in the Port Mapping Request message and used in
Token construction. Token construction.
o Absolute Expiration Time (64 bits): Mandatory element that o Token Element (Variable size): Mandatory element that is used to
contains the absolute expiration time of the Token. The absolute carry the Token generated by the server. This element is a
Length-Value element. The Length field, which is 8 bits,
indicates the length (in octets) of the Value field that follows
the Length field. The Value field carries the Token (or more
accurately, the output of the encoding process on the server).
o Absolute Expiration Time (64 bits): Mandatory field that contains
the absolute expiration time of the Token. The absolute
expiration time is expressed as a Network Time Protocol (NTP) expiration time is expressed as a Network Time Protocol (NTP)
timestamp value in seconds since year 1900 [RFC5905]. The client timestamp value in seconds since year 1900 [RFC5905]. The client
does not need to use this element directly, thus, does not need to does not need to use this element directly, thus, does not need to
synchronize its clock with the server. However, the client needs synchronize its clock with the server. However, the client needs
to send this element back to the server along with the associated to send this element back to the server along with the associated
nonce in the Token Verification Request message, thus, needs to nonce in the Token Verification Request message, thus, needs to
keep it associated with the Token. keep it associated with the Token.
o Relative Expiration Time (32 bits): Mandatory element that o Relative Expiration Time (32 bits): Mandatory field that contains
contains the relative expiration time of the Token. The relative the relative expiration time of the Token. The relative
expiration time is expressed in seconds from the time the Token expiration time is expressed in seconds from the time the Token
was generated. A relative expiration time of zero indicates that was generated. A relative expiration time of zero indicates that
the accompanying Token is not valid. the accompanying Token is not valid.
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.
5.3. Token Verification Request 4.3. Token Verification Request
The Token Verification Request message is identified by SFMT=3. This The Token Verification Request message is identified by SFMT=3. This
message contains the Token and MUST accompany any other RTCP feedback message contains the Token and accompanies any RTCP message that
message sent by the client to trigger or control a unicast session. would trigger a new or control an existing unicast session.
Examples include the RAMS-R and RAMS-T messages Currently, the following RTCP messages are REQUIRED to be accompanied
[I-D.ietf-avt-rapid-acquisition-for-rtp] as well as the NACK messages by a Token Verification Request message:
[RFC4585]. In the Token Verification Request message, the client
MUST set both the packet sender SSRC and media source SSRC fields to o Messages that trigger a new unicast session:
its own SSRC since the media source SSRC may not be known. The
client MUST NOT send a Token Verification Request message with a * NACK messages [RFC4585]
Token that has expired. The FCI field has the structure depicted in
Figure 6. * RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
o Messages that control an existing unicast session associated with
a multicast session:
* BYE messages [RFC3550]
* RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
* CCM messages [RFC5104]
Other RTCP messages defined in the future, which could be abused to
cause packet amplification attacks, SHOULD also be authenticated
using the mechanism described in this document. The Token
Verification Request message might also be bundled with packets
carrying RTCP receiver or extended reports. While such packets do
not have a strong security impact, a specific application might
desire to have a more controlled reporting scheme from the clients.
In the Token Verification Request message, the client MUST set both
the packet sender SSRC and media source SSRC fields to its own SSRC
since the media source SSRC may not be known. The client MUST NOT
send a Token Verification Request message with a Token that has
expired. The FCI field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Reserved | | SFMT=3 | Associated Nonce :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token : : Associated Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | : Token Element :
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute | | Associated Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the Token Verification message Figure 6: FCI field syntax for the Token Verification message
o Token (128 bits): Mandatory element that contains the Token o Associated Nonce (56 bits): Mandatory field that contains the
previously acquired by the client.
o Associated Nonce (64 bits): Mandatory field that contains the
nonce associated with the Token above. nonce associated with the Token above.
o Associated Absolute Expiration Time (64 bits): Mandatory element o Token Element (Variable size): Mandatory Token element that was
previously received in the Port Mapping Response message.
o Associated Absolute Expiration Time (64 bits): Mandatory field
that contains the absolute expiration time associated with the that contains the absolute expiration time associated with the
Token above. Token above.
5.4. Token Verification Failure 4.4. Token Verification Failure
The Token Verification Failure message is identified by SFMT=4. This The Token Verification Failure message is identified by SFMT=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. In the Token Verification Failure message, the packet was invalid or that the client did not include a Token Verification
sender SSRC and media sender SSRC fields are both set to the client's Request message in the RTCP packet although it was supposed to. In
SSRC. The FCI field has the structure depicted in Figure 6. the Token Verification Failure message, the packet sender SSRC and
media sender SSRC fields are both set to the client's SSRC. The FCI
field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=4 | Reserved | | SFMT=4 | Associated Nonce :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Associated Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI field syntax for the Token Failure message Figure 7: FCI field syntax for the Token Failure message
6. Procedures for Token Construction o Associated Nonce (56 bits): Mandatory field that contains the
nonce received in the Token Verification Request message. If
there was no Token Verification Request message included by the
client, this field is set to 0.
The Token is calculated by the server by performing HMAC-SHA1 5. Procedures for Token Construction
[RFC2104] on the concatenated values of:
The Token encoding is known to the server but opaque to the client.
Implementations MUST encode the following information into the Token
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 (56 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 year 1900 [RFC5905] (64 bits,
to protect against replay attacks) to protect against replay attacks)
After performing the HMAC-SHA1, the output is truncated to 128 bits, An example way for constructing Tokens is to perform HMAC-SHA1
which is then converted to ASCII using Base64 encoding [RFC4648]. In [RFC2104] on the concatenated values of the information listed above.
this process, only the server knows the HMAC secret key. However, The HMAC key should be at least 160 bits long, and generated using a
the HMAC secret key can be shared by multiple servers to provide cryptographically secure random source [RFC4086]. However,
portability for the Tokens. implementations MAY adopt different approaches and are encouraged to
encode whatever additional information is deemed necessary or useful.
For example, key rollover is simplified by encoding a key-id into the
Token. As another example, a cluster of anycast servers could find
advantage by encoding a server identifier into the Token. As another
example, if HMAC-SHA1 has been compromised, a replacement HMAC
algorithm could be used instead (e.g., HMAC-SHA256).
7. Validating Tokens To protect from offline attacks, the server SHOULD occasionally
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
(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
be encoded into several bits. As the encoding of the Token is
entirely private to the server and opaque to the clients, any
encoding can be used. By encoding the key-id into the Token element,
the server can reject an old key without bothering to do HMAC
validation (saving CPU cycles). The key-id can be encoded into the
Value field of the Token element by simply concatenating the
(plaintext) key-id with the hashed information (i.e., the Token
itself).
For example, the Value field in the Token element can be computed as:
key-id || hash-alg (client-ip | nonce | abs-expiration)
During Token construction, the expiration time has to be chosen
carefully based on the intended service duration. Tokens that are
valid for an unnecessarily long period of time (e.g., several hours)
might impose security risks. Depending on the application and use
cases, a reasonable value needs to be chosen by the server. Note
that using shorter lifetimes requires the clients to acquire Tokens
more frequently. However, since a client can acquire a new Token
well before it will need to use it, the client will not necessarily
be penalized for the acquisition delay.
Finally, be aware that NTP timestamps will wrap around in year 2036
and implementations might need to handle this eventually. Refer to
Section 6 of [RFC5905] for further details.
6. Validating Tokens
Upon receipt of an RTCP feedback message along with the Token Upon receipt of an RTCP feedback message along with the Token
Verification Request message that contains a Token, nonce and Verification Request message that contains a Token, nonce and
absolute expiration time, the server MUST validate the Token. absolute expiration time, the server MUST validate the Token.
The server first applies the procedure given in Section 6 by using The server first applies the its own procedure for constructing the
client's IP address from the received Token Verification Request Tokens by using client's IP address from the received Token
message, and the nonce and absolute expiration time values reported Verification Request message, and the nonce and absolute expiration
in the received Token Verification Request message. The server then time values reported in the received Token Verification Request
compares the resulting output with the Token sent by the client in message. The server then compares the resulting output with the
the Token Verification Request message. If they match and the Token sent by the client in the Token Verification Request message.
absolute expiration time has not passed yet, the server declares that If they match and the absolute expiration time has not passed yet,
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. message, validation will fail. It is also possible that the server
wants to expire the Token prematurely. In these cases, the server
It is RECOMMENDED that applications define an application-specific
error response to be sent by the server when the server detects that
the Token is invalid, rather than silently discarding client's
message (since this adds an undesired delay). For applications using
[I-D.ietf-avt-rapid-acquisition-for-rtp], this draft defines a new
4xx-level response code in the RAMS Response Code Space Registry.
In applications that have not defined an error response, 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 to port c1 on the message (that goes from port P3 on the server to port c1 on the
client). client).
8. SDP Example In addition to the Token Verification Failure message, it is
RECOMMENDED that applications define an application-specific error
response to be sent by the server when the server detects that the
Token is invalid. For applications using
[I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new
4xx-level response code in the RAMS Response Code Space Registry. A
client that received a Token Verification Failure message can request
a new Token from the server.
7. SDP Signaling
7.1. The portmapping-req Attribute
This new SDP attribute is used declaratively to indicate the port for
obtaining a Token. Its presence indicates that a Token MUST be
included in the feedback messages sent to the server triggering or
controlling a unicast session.
The formal description of the 'portmapping-req' attribute is defined
by the following ABNF [RFC5234] syntax:
portmapping-req-attribute = "a=portmapping-req:" port CRLF
Here, 'port' is defined as specified in Section 9 of [RFC4566]. The
'portmapping-req' attribute is used as a session-level or media-level
attribute. If used at a media level, the attribute MUST be used for
a unicast media stream.
The Offer/Answer Model behavior [RFC3264] for the 'portmapping-req'
attribute is not defined, thus, MUST NOT be used. This attribute
MUST only be used in a declarative manner.
7.2. Requirements
The use of SDP for the port mapping solution normatively requires the
support for:
o The SDP grouping framework and flow identification (FID) semantics
[RFC5888]
o The RTP/AVPF profile [RFC4585]
o The RTCP extensions for SSM sessions with unicast feedback
[RFC5760]
o The 'multicast-rtcp' attribute [I-D.ietf-avt-rtcp-port-for-ssm]
o Multiplexing RTP and RTCP on a single port on both endpoints in
the unicast session [RFC5761]
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
t=0 0 t=0 0
a=group:FID 1 2 a=group:FID 1 2
a=rtcp-unicast:rsi a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Multicast Stream i=Multicast Stream
c=IN IP4 233.252.0.2/255 c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1
a=rtpmap:98 MP2T/90000s a=rtpmap:98 MP2T/90000
a=multicast-rtcp:41500 ; Note 1 a=multicast-rtcp:41500 ; Note 1
a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2
a=rtcp-fb:98 nack ; Note 2 a=rtcp-fb:98 nack ; Note 2
a=mid:1 a=mid:1
m=video 42000 RTP/AVPF 99 ; Note 3 m=video 42000 RTP/AVPF 99 ; Note 3
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 4 a=rtcp-mux ; Note 4
skipping to change at page 21, line 5 skipping to change at page 23, line 5
Note 4: The server multiplexes RTP and RTCP packets on the same port Note 4: The server multiplexes RTP and RTCP packets on the same port
(c1 in Figure 2). (c1 in Figure 2).
Note 5: The server uses port 42500 (P4) for the unicast sessions. Note 5: The server uses port 42500 (P4) for the unicast sessions.
Note 6: The "a=portmapping-req" line indicates that a Token needs to Note 6: The "a=portmapping-req" line indicates that a Token needs to
be retrieved first before a unicast session associated to the be retrieved first before a unicast session associated to the
multicast session can be established and that the Port Mapping multicast session can be established and that the Port Mapping
Request message needs to be sent to port 30000 (PT). Request message needs to be sent to port 30000 (PT).
9. 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 which 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.
10. Security Considerations 9. Security Considerations
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 denial-of-service (DoS) expiration date, provides protection against denial-of-service (DoS)
attacks. An attacker using a certain IP address cannot cause one or attacks. An attacker using a certain IP address cannot cause one or
more RTP packets to be sent to a victim client who has a different IP more RTP packets to be sent to a victim client who has a different IP
address. However, if the attacker acquires a valid Token for a address. However, if the attacker acquires a valid Token for a
victim and can spoof the victim's source address, this approach victim and can spoof the victim's source address, this approach
becomes vulnerable to replay attacks. This is especially easy if the becomes vulnerable to replay attacks. This is especially easy if the
attacker and victim are behind a large-scale NAT and share the same attacker and victim are behind a large-scale NAT and share the same
IP address. IP address.
skipping to change at page 23, line 5 skipping to change at page 24, line 32
attacker attacker cannot spoof a victim's IP address to use a Token attacker attacker cannot spoof a victim's IP address to use a Token
to initiate an attack against a victim. However, if ingress to initiate an attack against a victim. However, if ingress
filtering is not enabled on a network, an attacker could obtain a filtering is not enabled on a network, an attacker could obtain a
Token and spoof the victim's address, causing traffic to flood the Token and spoof the victim's address, causing traffic to flood the
victim. On such a network, the server can reduce the time period for victim. On such a network, the server can reduce the time period for
such an attack by expiring a Token in a short period of time. In the such an attack by expiring a Token in a short period of time. In the
extreme case, the server can expire the Token in such a short period extreme 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 of time, such that the client will have to acquire a new Token
immediately before using it in a Token Verification Request message. immediately before using it in a Token Verification Request message.
11. IANA Considerations HMAC-SHA1 provides a level of security that is widely regarded as
being more than sufficient for providing message authentication. It
is believed that the economic cost of breaking that algorithm is
significantly higher than the cost of more direct approaches to
violating system security, e.g., theft, bribery, wiretapping, and
other forms of malfeasance. HMAC-SHA1 is secure against all known
cryptanalytic attacks that use computational resources that are
currently economically feasible.
9.2. The portmapping-req Attribute
The 'portmapping-req' attribute is not believed to introduce any
significant security risk to multimedia applications. A malevolent
third party could use this attribute to redirect the Port Mapping
Request messages by altering the port number or cause the unicast
session establishment to fail by removing it from the SDP
description. But, this requires intercepting and rewriting the
packets carrying the SDP description; and if an interceptor can do
that, many more attacks are possible, including a wholesale change of
the addresses and port numbers at which the media will be sent.
In order to avoid attacks of this sort, the SDP description needs to
be integrity protected and provided with source authentication. This
can, for example, be achieved on an end-to-end basis using S/MIME
[RFC5652] when SDP is used in a signaling packet using MIME types
(application/sdp). Alternatively, HTTPS [RFC2818] or the
authentication method in the Session Announcement Protocol (SAP)
[RFC2974] could be used as well.
10. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
11.1. Registration of SDP Attributes 10.1. Registration of SDP Attributes
This document registers a new attribute name in SDP. This document registers a new attribute name in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: portmapping-req Attribute name: portmapping-req
Long form: Port for requesting Token Long form: Port for requesting Token
Type of name: att-field Type of name: att-field
Type of attribute: Either session or media level Type of attribute: Either session or media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: See this document Values: See this document
11.2. Registration of FMT Values 10.2. Registration of FMT Values
Within the RTPFB range, the following format (FMT) value is Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: Port Mapping Name: Port Mapping
Long name: Port Mapping Between Unicast and Multicast RTP Sessions Long name: Port Mapping Between Unicast and Multicast RTP Sessions
Value: 7 Value: 7
Reference: [RFCXXXX] Reference: [RFCXXXX]
11.3. SFMT Values for Port Mapping Messages Registry 10.3. SFMT Values for Port Mapping Messages Registry
This document creates a new sub-registry for the sub-feedback message This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for Port type (SFMT) values to be used with the FMT value registered for Port
Mapping messages. The registry is called the SFMT Values for Port Mapping messages. The registry is called the SFMT Values for Port
Mapping Messages Registry. This registry is to be managed by the Mapping Messages Registry. This registry is to be managed by the
IANA according to the Specification Required policy of [RFC5226]. IANA according to the Specification Required policy of [RFC5226].
The length of the SFMT field in the Port Mapping messages is a single The length of the SFMT field in the Port Mapping messages is a single
octet, allowing 256 values. The registry is initialized with the octet, allowing 256 values. The registry is initialized with the
following entries: following entries:
skipping to change at page 24, line 27 skipping to change at page 27, line 27
Any registration for an unassigned SFMT value needs to contain the Any registration for an unassigned SFMT value needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new SFMT represents and how it o A detailed description of what the new SFMT represents and how it
shall be interpreted. shall be interpreted.
11.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 [RFCXXXX]
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.
12. 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 in the Anaheim meeting. We thank each of these
individuals. individuals, in particular to Magnus Westerlund and Colin Perkins.
13. References 12. References
13.1. Normative References 12.1. Normative References
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
skipping to change at page 26, line 34 skipping to change at page 29, line 34
[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 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[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- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
13.2. Informative References [I-D.ietf-avt-rtcp-port-for-ssm]
Begen, A., "RTP Control Protocol (RTCP) Port for Source-
Specific Multicast (SSM) Sessions",
draft-ietf-avt-rtcp-port-for-ssm-03 (work in progress),
October 2010.
[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.
12.2. Informative References
[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] [I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions", Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-16 (work in draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in
progress), October 2010. 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. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[I-D.ietf-avt-app-rtp-keepalive] [I-D.ietf-avt-app-rtp-keepalive]
skipping to change at page 28, line 5 skipping to change at page 30, line 44
September 2010. September 2010.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. 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,
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.
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
 End of changes. 71 change blocks. 
215 lines changed or deleted 394 lines changed or added

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